我是如何失去團隊掌控的？

我是一個不合格的技術總監，在過去的快三個月裏。我帶着從40多我的的研發團隊（包含需求、開發、測試）裏抽調出20多我的去爲公司開疆拓土。在這快三個月中，咱們一塊兒奮戰奮鬥拼搏。在過程當中，我通宵時間超過半個月，幹到凌晨4/5點的日子數不勝數，幹到凌晨1/2點日子更是習覺得常。整個團隊絕大多數人近乎兩個月沒有周末，辛苦異常，是實實在在的高峯體驗。可是三個月後，我帶着失敗和一身的慘痛教訓回到公司。

我在此次的經歷中感覺到了我是怎麼失去團隊掌控力的。我所謂的團隊掌控，不是說兄弟們不聽安排，不按計劃行事。而是我對整個開發團隊、測試團隊、需求團隊都有了新的認識，從新認識了團隊，從新認識了這二十多我的。由於對我的和團隊的能力判斷偏差和對項目難度的判斷失誤，致使了此次慘痛的教訓。

我把我所面臨的的困境和遇到的問題分享給你們，也將把我所作的決策分享給你們，並把我所意識到的錯誤分享給你們。但願能給每一個面臨此種局面的同行進行提醒。

項目和團隊背景

1. 共計三個月內有四個項目，沒有正式的項目經理，只有三個實習項目經理
2. 三個實習項目經理中，一個帶過一個小型持續性項目（先後端共3人）接近一年；一個帶太小項目（4人）一個月；一個帶過兩個中小項目（7人），共計半年時間
3. 開發同事都相對年輕，工做年限最長的也就三年。朝氣蓬勃但的確經驗不足
4. 團隊中老同事新同事各佔一半吧，超過半數的同事來公司不到一年
5. 四個項目都基於同一個客戶提供基礎版本（或者說框架）進行開發
6. 客戶方使用的基礎框架過於老舊，十多年前的先後端框架，前端使用技術特別偏門，學習成本巨大
7. 框架混亂不堪，表就有快2000張，說是框架但雜含着各類各樣的業務代碼，且又必須使用
8. 開發調試的環境配置困難，項目必須跑在linux上，只能遠程調試。項目因爲過大，啓動緩慢，編譯一次大概10多分鐘。咱們團隊不熟悉此種模式，摸索浪費了一段時間
9. 客戶公司較大，研發部門較多。開發過程當中部門協調工做佔比超過一半，須要和各類各樣的設備作對接，都是別的部門開發的。部門之間互相踢皮球，找人協助困難

錯誤一：高估團隊水平

1. 自覺得很瞭解同事，其實瞭解的太片面。在過去一年中，因爲作的項目比較穩定。持續產出在可控範圍內，客戶也比較承認。致使我產生了以爲咱們團隊還不錯的錯覺
   
2. 整個團隊在面對全新環境的狀況下，適應能力偏弱。難以快速穩定的產出，項目開始了兩個星期，基本都處於熟悉環境、熟悉項目的狀態，一直沒有有效產出。致使時間被浪費
   
3. 好比某A剛入職3個多月，在其餘項目中，項目負責人給出的評價還不錯，致使我把他放在了重要的開發位置上。但項目一開始，我就發現某A技術水平差的有點厲害，多表聯查的sql都寫不溜。此時已無人可替他，只能我上去協助他
   好比某B一年多來，帶的項目一直穩定未出大問題。但到了新項目中，理解能力較弱沒法快速全面理解需求。同時也暴露出了某B沒有風險意識的致命缺陷，不能識別風險，識別出了風險也不反饋不做爲，致使項目屢次跳票

反思：

1. 考覈很重要，全面的考覈反饋更重要

   • 在人員和團隊方面，產生最要命的問題，我想就是考覈機制的問題了。因爲種種緣由，對同事的瞭解都太片面。在用人方面把人放錯了位置。狙擊手放到了主攻手的位置上，主攻手放到了指揮員的位置上。這樣戰鬥不失敗纔怪呢
     
   • 站在一個較高的位置，很容易對下面同事的能力判斷失誤。就我認爲，在人數很少的狀況下，最好的瞭解你們的方式，是一塊兒戰鬥。在一場戰鬥裏，觀察每一個人天天的態度表現、效率產出、代碼質量、協調能力、對外溝通能力等。通過一個項目下來，就能對這個項目組中的成員有個較全面的瞭解。但這種方式不能只是站在項目外看，而要和你們一塊兒就同一個項目開展工做
     
   • 從多方去了解一我的，不僅聽某一人之言。對如上的某A來講，就是由於只聽了一人之言產生了較大的誤判（某A在另外一個項目中，只作了導出功能，未接觸數據庫）

2. 不用靜止的眼光看人，人都是在不斷變化的

   • 人都是在不斷變化的，而我用了以往的經驗去評判你們。有的高估了，有的低估了。沒有把最合適的人安排給最合適的項目
     
   • 不該把過去的錯誤或者功能記在今天的帳上，要持續的跟進你們的變化，持續的保持對你們的新認識。不以固有的眼光看人
     
   • 也應經過積極的引導，幫助同事改掉本身的不足。而不是聽之任之，由其自生自滅。只有這樣，團隊才能進步，這也是一個leader最應該作好的事情，我在這方面差的還太遠

3. 因事定人不可取

   • 某D以前因爲某次技術預研的工做，讓我認定他通常。但在此次的項目中，他卻成了最穩定輸出的一環
     
   • 因而可知，不能由於某人一時作的好或者很差，就給這我的定了型，先入爲主的下定論。要客觀的評價一下我的，須要瞭解他的所有歷史和所有工做。也就是第一條說的，要有全面的考覈反饋機制

錯誤二：低估項目難度

1. 項目共計4個，每一個項目（只支持IE）都須要和額外的客戶自研中間件、插件（ActiveX）、多種硬件設備對接。此前未作過和硬件對接的設備，低估了對接的難度
   
2. 中間件、插件、硬件設備的對接我萬萬沒想到，什麼文檔都沒有。只能去搜歷史代碼學習測試，或者到相關部門去問問。而此前溝經過程中，我心中默認對接是有文檔或專人指導的，沒有問清楚
   
3. 前端使用框架（2006年的框架和版本）過於老舊，因爲對前端了解不足，錯誤的估計了學習曲線，團隊前端同事開發前期很是吃力，進度在這塊也拖延了一大段
   
4. 跨部門溝通的難度遠超個人想象，此前溝經過程中，明確好跨部門溝通有專人負責，但到了實際工做中，都變成了咱們本身去對接。各個部門互相踢皮球，一個攝像頭究竟是什麼型號的問題（測試須要特定型號的攝像頭，對接人不清楚借來的是什麼型號），我能花3個小時跑遍五層樓才獲得答案。更不用說代碼層面的指導了
   
5. 沒有了解到客戶方框架的真實狀況，心中覺得是在spring上封裝的腳手架。沒想到框架中包含了快2000張表，數百萬的歷史代碼。光用戶模塊就有不一樣的三套（該框架會在各個定製的基礎上，按期的把定製內容合到框架主幹上，致使了各類沒有用的歷史遺留代碼），找想要使用的功能搜索難度大增

反思：

1. 經驗很重要，但經驗也很致命

   • 在這次前期溝通中，不少我覺得，我認爲都是經驗主義所害。好比對接文檔的問題，多問一句，可能狀況就很不同
     
   • 經驗也可能成爲風險之一，須要警戒

2. 想法設法獲取更多信息

   • 四個項目的對接人瞭解的信息都不全面，到我這的信息就缺失更多，而我當時覺得這就是所有的狀況。信息的缺失是會讓判斷失去方向
     
   • 在現有信息中，要去挖掘出更多的問題和信息，並找對接人確認。越多的信息越能爲判斷提供更準確的方向
     
   • 對接人也不清晰的狀況，須要推進對接人去找相應人員獲取，獲得相對準確和完善的信息

3. 鎖定項目核心重難點

   • 在這幾個項目中，有的項目沒有在一開始就抓住項目核心重難點。好比甲項目中核心功能是存儲，且須要使用客戶自研存儲設備，項目初期未鎖定該重點問題，致使後期項目核心功能所有返工
     
   • 通常採起排除法來鎖定核心重難點。把全部的頁面可見功能點和隱含功能點列上，以排除法排除獨立的關聯少的模塊。留下的就是重難點的核心要素
     
   • 針對每一個核心要素搞清楚聯繫關係，獲得最終的功能關係圖（業務架構圖）

錯誤三：戰術錯誤，同時面對過多的項目

1. 回過頭來看，人手不足的狀況同時接了過多的項目是錯誤的。但這的確是一個兩難的問題，不能簡單的用錯或者對來概述
2. 接或者不接，這本就是一個博弈的過程。綜合分析項目是否肯定會交由咱們來作，再分析是否有能力完成，考慮清楚後再下結論

反思：

1. 項目中老是會面臨資源不足的狀況，永遠不要想着項目中擁有最適合的資源、人員。畢竟最適合的人員不可能一直等着你的項目
2. 帶項目就像打牌，一手好牌作好了項目是應該。而一手爛牌打贏了纔是你的能力

錯誤四：管理不是輕鬆的事

1. 最後一個錯誤，是在項目無人可帶的時候，無可奈何我去帶了項目。陷入了某個項目的具體細節後，沒有了統一對全部項目進行管理協調的人
2. 管理是很耗費精力的，須要專人專職的去處理。管理者一大職責就是溝通協調，尤爲在這種須要強溝通的項目中
3. 一旦陷入了具體的某個項目中，就很難有精力去維持其餘項目了
   
4. 受權很重要，但檢查更重要。交付出去的工做，要按期檢查，保證交付物是完成的、完整的、不返工的

我所吸收的教訓總結

1. 創建更全面的考覈反饋體系對認識團隊相當重要
2. 不要侷限於經驗，溝通勝於一切
3. 反思每一次戰術失誤，保證下一次的精確打擊
4. 專人專事，專職管理的人，就不要陷入開發細節中，一旦大量精力投入了開發。這將是致命的風險