11.13 我是如何失去團隊掌控的?一個技術總監的反思

來源: cnblogs.com/zer0Black/p/11819696.html

我是一個不合格的技術總監,在過去的快三個月裡。我帶著從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. 考核很重要,全面的考核反饋更重要
  2. 在人員和團隊方面,產生最要命的問題,我想就是考核機制的問題了。由於種種原因,對同事的瞭解都太片面。在用人方面把人放錯了位置。狙擊手放到了主攻手的位置上,主攻手放到了指揮員的位置上。這樣戰鬥不失敗才怪呢
  3. 站在一個較高的位置,很容易對下面同事的能力判斷失誤。就我認為,在人數不多的情況下,最好的瞭解大家的方式,是一起戰鬥。在一場戰鬥裡,觀察每個人每天的態度表現、效率產出、代碼質量、協調能力、對外溝通能力等。經過一個項目下來,就能對這個項目組中的成員有個較全面的瞭解。但這種方式不能只是站在項目外看,而要和大家一起就同一個項目開展工作

  4. 從多方去了解一個人,不只聽某一人之言。對如上的某A來說,就是因為只聽了一人之言產生了較大的誤判(某A在另一個項目中,只做了導出功能,未接觸數據庫)
  5. 不用靜止的眼光看人,人都是在不斷變化的
  6. 人都是在不斷變化的,而我用了以往的經驗去評判大家。有的高估了,有的低估了。沒有把最合適的人安排給最合適的項目
  7. 不應把過去的錯誤或者功能記在今天的賬上,要持續的跟進大家的變化,持續的保持對大家的新認識。不以固有的眼光看人
  8. 也應通過積極的引導,幫助同事改掉自己的不足。而不是聽之任之,由其自生自滅。只有這樣,團隊才能進步,這也是一個leader最應該做好的事情,我在這方面差的還太遠
  9. 因事定人不可取
  10. 某D之前由於某次技術預研的工作,讓我認定他一般。但在這次的項目中,他卻成了最穩定輸出的一環

  11. 由此可見,不能因為某人一時做的好或者不好,就給這個人定了型,先入為主的下定論。要客觀的評價一下個人,需要了解他的全部歷史和全部工作。也就是第一條說的,要有全面的考核反饋機制

錯誤二:低估項目難度

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

反思:

  1. 經驗很重要,但經驗也很致命
  2. 在此次前期溝通中,很多我以為,我認為都是經驗主義所害。比如對接文檔的問題,多問一句,可能情況就很不一樣
  3. 經驗也可能成為風險之一,需要警惕
  4. 想法設法獲取更多信息
  5. 四個項目的對接人瞭解的信息都不全面,到我這的信息就缺失更多,而我當時以為這就是全部的情況。信息的缺失是會讓判斷失去方向
  6. 在現有信息中,要去挖掘出更多的問題和信息,並找對接人確認。越多的信息越能為判斷提供更準確的方向
  7. 對接人也不清晰的情況,需要推動對接人去找相應人員獲取,得到相對準確和完善的信息
  8. 鎖定項目核心重難點
  9. 在這幾個項目中,有的項目沒有在一開始就抓住項目核心重難點。比如甲項目中核心功能是存儲,且需要使用客戶自研存儲設備,項目初期未鎖定該重點問題,導致後期項目核心功能全部返工
  10. 一般採取排除法來鎖定核心重難點。把所有的頁面可見功能點和隱含功能點列上,以排除法排除獨立的關聯少的模塊。留下的就是重難點的核心要素

  11. 針對每個核心要素搞清楚聯繫關係,得到最終的功能關係圖(業務架構圖)

錯誤三:戰術錯誤,同時面對過多的項目

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

反思:

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

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

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

我所吸取的教訓總結

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


分享到:


相關文章: