我是一個不合格的技術總監，在過去的快三個月裡。我帶着從40多個人的研發團隊（包含需求、開發、測試）裡抽調出20多個人去為公司開疆拓土。在這快三個月中，我們一起奮戰奮鬥拼搏。在過程中，我通宵時間超過半個月，幹到淩晨4/5點的日子數不勝數，幹到淩晨1/2點日子更是習以為常。整個團隊絕大多數人近乎兩個月沒有周末，辛苦異常，是實實在在的高峰體驗。但是三個月後，我帶着失敗和一身的慘痛教訓回到公司。
我在這次的經曆中感受到了我是怎麼失去團隊掌控力的。我所謂的團隊掌控，不是說兄弟們不聽安排，不按計劃行事。而是我對整個開發團隊、測試團隊、需求團隊都有了新的認識，重新認識了團隊，重新認識了這二十多個人。因為對個人和團隊的能力判斷誤差和對項目難度的判斷失誤，導緻了這次慘痛的教訓。
我把我所面臨的的困境和遇到的問題分享給大家，也将把我所做的決策分享給大家，并把我所意識到的錯誤分享給大家。希望能給每個面臨此種局面的同行進行提醒。
項目和團隊背景
共計三個月内有四個項目，沒有正式的項目經理，隻有三個實習項目經理
三個實習項目經理中，一個帶過一個小型持續性項目（前後端共3人）接近一年；一個帶過小項目（4人）一個月；一個帶過兩個中小項目（7人），共計半年時間
開發同僚都相對年輕，工作年限最長的也就三年。朝氣蓬勃但的确經驗不足
團隊中老同僚新同僚各占一半吧，超過半數的同僚來公司不到一年
四個項目都基于同一個客戶提供基礎版本（或者說架構）進行開發
客戶方使用的基礎架構過于老舊，十多年前的前後端架構，前端使用技術特别偏門，學習成本巨大
架構混亂不堪，表就有快2000張，說是架構但雜含着各種各樣的業務代碼，且又必須使用
開發調試的環境配置困難，項目必須跑在linux上，隻能遠端調試。項目由于過大，啟動緩慢，編譯一次大概10多分鐘。我們團隊不熟悉此種模式，摸索浪費了一段時間
客戶公司較大，研發部門較多。開發過程中部門協調工作占比超過一半，需要和各種各樣的裝置做對接，都是别的部門開發的。部門之間互相踢皮球，找人協助困難
錯誤一：高估團隊水準
自以為很了解同僚，其實了解的太片面。在過去一年中，由于做的項目比較穩定。持續産出在可控範圍内，客戶也比較認可。導緻我産生了覺得我們團隊還不錯的錯覺
整個團隊在面對全新環境的情況下，适應能力偏弱。難以快速穩定的産出，項目開始了兩個星期，基本都處于熟悉環境、熟悉項目的狀态，一直沒有有效産出。導緻時間被浪費
比如某A剛入職3個多月，在其他項目中，項目負責人給出的評價還不錯，導緻我把他放在了重要的開發位置上。但項目一開始，我就發現某A技術水準差的有點厲害，多表聯查的sql都寫不溜。此時已無人可替他，隻能我上去協助他
比如某B一年多來，帶的項目一直穩定未出大問題。但到了新項目中，了解能力較弱無法快速全面了解需求。同時也暴露出了某B沒有風險意識的緻命缺陷，不能識别風險，識别出了風險也不回報不作為，導緻項目多次跳票
反思：
考核很重要，全面的考核回報更重要
在人員和團隊方面，産生最要命的問題，我想就是考核機制的問題了。由于種種原因，對同僚的了解都太片面。在用人方面把人放錯了位置。狙擊手放到了主攻手的位置上，主攻手放到了指揮員的位置上。這樣戰鬥不失敗才怪呢
站在一個較高的位置，很容易對下面同僚的能力判斷失誤。就我認為，在人數不多的情況下，最好的了解大家的方式，是一起戰鬥。在一場戰鬥裡，觀察每個人每天的态度表現、效率産出、代碼品質、協調能力、對外溝通能力等。經過一個項目下來，就能對這個項目組中的成員有個較全面的了解。但這種方式不能隻是站在項目外看，而要和大家一起就同一個項目開展工作
從多方去了解一個人，不隻聽某一人之言。對如上的某A來說，就是因為隻聽了一人之言産生了較大的誤判（某A在另一個項目中，隻做了導出功能，未接觸資料庫）
不用靜止的眼光看人，人都是在不斷變化的
人都是在不斷變化的，而我用了以往的經驗去評判大家。有的高估了，有的低估了。沒有把最合适的人安排給最合适的項目
不應把過去的錯誤或者功能記在今天的賬上，要持續的跟進大家的變化，持續的保持對大家的新認識。不以固有的眼光看人
也應通過積極的引導，幫助同僚改掉自己的不足。而不是聽之任之，由其自生自滅。隻有這樣，團隊才能進步，這也是一個leader最應該做好的事情，我在這方面差的還太遠
因事定人不可取
某D之前由于某次技術預研的工作，讓我認定他一般。但在這次的項目中，他卻成了最穩定輸出的一環
由此可見，不能因為某人一時做的好或者不好，就給這個人定了型，先入為主的下定論。要客觀的評價一下個人，需要了解他的全部曆史和全部工作。也就是第一條說的，要有全面的考核回報機制
錯誤二：低估項目難度
項目共計4個，每個項目（隻支援IE）都需要和額外的客戶自研中間件、插件（ActiveX）、多種硬體裝置對接。此前未做過和硬體對接的裝置，低估了對接的難度
中間件、插件、硬體裝置的對接我萬萬沒想到，什麼文檔都沒有。隻能去搜曆史代碼學習測試，或者到相關部門去問問。而此前溝通過程中，我心中預設對接是有文檔或專人指導的，沒有問清楚
前端使用架構（2006年的架構和版本）過于老舊，由于對前端了解不足，錯誤的估計了學習曲線，團隊前端同僚開發前期非常吃力，進度在這塊也拖延了一大段
跨部門溝通的難度遠超我的想象，此前溝通過程中，明确好跨部門溝通有專人負責，但到了實際工作中，都變成了我們自己去對接。各個部門互相踢皮球，一個攝像頭到底是什麼型号的問題（測試需要特定型号的攝像頭，對接人不清楚借來的是什麼型号），我能花3個小時跑遍五層樓才得到答案。更不用說代碼層面的指導了
沒有了解到客戶方架構的真實情況，心中以為是在spring上封裝的腳手架。沒想到架構中包含了快2000張表，數百萬的曆史代碼。光使用者子產品就有不同的三套（該架構會在各個定制的基礎上，定期的把定制内容合到架構主幹上，導緻了各種沒有用的曆史遺留代碼），找想要使用的功能搜尋難度大增
經驗很重要，但經驗也很緻命
在此次前期溝通中，很多我以為，我認為都是經驗主義所害。比如對接文檔的問題，多問一句，可能情況就很不一樣
經驗也可能成為風險之一，需要警惕
想法設法擷取更多資訊
四個項目的對接人了解的資訊都不全面，到我這的資訊就缺失更多，而我當時以為這就是全部的情況。資訊的缺失是會讓判斷失去方向
在現有資訊中，要去挖掘出更多的問題和資訊，并找對接人确認。越多的資訊越能為判斷提供更準确的方向
對接人也不清晰的情況，需要推動對接人去找相應人員擷取，得到相對準确和完善的資訊
鎖定項目核心重難點
在這幾個項目中，有的項目沒有在一開始就抓住項目核心重難點。比如甲項目中核心功能是存儲，且需要使用客戶自研儲存設備，項目初期未鎖定該重點問題，導緻後期項目核心功能全部返工
一般采取排除法來鎖定核心重難點。把所有的頁面可見功能點和隐含功能點列上，以排除法排除獨立的關聯少的子產品。留下的就是重難點的核心要素
針對每個核心要素搞清楚聯系關系，得到最終的功能關系圖（業務架構圖）
錯誤三：戰術錯誤，同時面對過多的項目
回過頭來看，人手不足的情況同時接了過多的項目是錯誤的。但這的确是一個兩難的問題，不能簡單的用錯或者對來概述
接或者不接，這本就是一個博弈的過程。綜合分析項目是否确定會交由我們來做，再分析是否有能力完成，考慮清楚後再下結論
項目中總是會面臨資源不足的情況，永遠不要想着項目中擁有最适合的資源、人員。畢竟最适合的人員不可能一直等着你的項目
帶項目就像打牌，一手好牌做好了項目是應該。而一手爛牌打赢了才是你的能力
錯誤四：管理不是輕松的事
最後一個錯誤，是在項目無人可帶的時候，迫不得已我去帶了項目。陷入了某個項目的具體細節後，沒有了統一對所有項目進行管理協調的人
管理是很耗費精力的，需要專人專職的去處理。管理者一大職責就是溝通協調，尤其在這種需要強溝通的項目中
一旦陷入了具體的某個項目中，就很難有精力去維持其他項目了
授權很重要，但檢查更重要。傳遞出去的工作，要定期檢查，保證傳遞物是完成的、完整的、不返工的
我所吸取的教訓總結
建立更全面的考核回報體系對認識團隊至關重要
不要局限于經驗，溝通勝于一切
反思每一次戰術失誤，保證下一次的精确打擊
專人專事，專職管理的人，就不要陷入開發細節中，一旦大量精力投入了開發。這将是緻命的風險
![mybatis_入門程式Mybatis入門[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)