我是如何失去團(tuán)隊掌控的

　 域名預(yù)訂/競價，好“米”不錯過

我是一個不合格的技術(shù)總監(jiān)，在過去的快三個月里。我?guī)е鴱?0多個人的研發(fā)團(tuán)隊(包含需求、開發(fā)、測試)里抽調(diào)出20多個人去為公司開疆拓土。在這快三個月中，我們一起奮戰(zhàn)奮斗拼搏。在過程中，我通宵時間超過半個月，干到凌晨4/5點的日子數(shù)不勝數(shù)，干到凌晨1/2點日子更是習(xí)以為常。整個團(tuán)隊絕大多數(shù)人近乎兩個月沒有周末，辛苦異常，是實實在在的高峰體驗。但是三個月后，我?guī)е『鸵簧淼膽K痛教訓(xùn)回到公司。

我在這次的經(jīng)歷中感受到了我是怎么失去團(tuán)隊掌控力的。

我所謂的團(tuán)隊掌控，不是說兄弟們不聽安排，不按計劃行事。而是我對整個開發(fā)團(tuán)隊、測試團(tuán)隊、需求團(tuán)隊都有了新的認(rèn)識，重新認(rèn)識了團(tuán)隊，重新認(rèn)識了這二十多個人。因為對個人和團(tuán)隊的能力判斷誤差和對項目難度的判斷失誤，導(dǎo)致了這次慘痛的教訓(xùn)。

我把我所面臨的的困境和遇到的問題分享給大家，也將把我所做的決策分享給大家，并把我所意識到的錯誤分享給大家。希望能給每個面臨此種局面的同行進(jìn)行提醒。

項目和團(tuán)隊背景

共計三個月內(nèi)有四個項目，沒有正式的項目經(jīng)理，只有三個實習(xí)項目經(jīng)理。三個實習(xí)項目經(jīng)理中，一個帶過一個小型持續(xù)性項目(前后端共3人)接近一年;一個帶過小項目(4人)一個月;一個帶過兩個中小項目(7人)，共計半年時間。

開發(fā)同事都相對年輕，工作年限最長的也就三年。朝氣蓬勃但的確經(jīng)驗不足;團(tuán)隊中老同事新同事各占一半吧，超過半數(shù)的同事來公司不到一年。

四個項目都基于同一個客戶提供基礎(chǔ)版本(或者說框架)進(jìn)行開發(fā)?？蛻舴绞褂玫幕A(chǔ)框架過于老舊，十多年前的前后端框架，前端使用技術(shù)特別偏門，學(xué)習(xí)成本巨大?？蚣芑靵y不堪，表就有快2000張，說是框架但雜含著各種各樣的業(yè)務(wù)代碼，且又必須使用。

開發(fā)調(diào)試的環(huán)境配置困難，項目必須跑在linux上，只能遠(yuǎn)程調(diào)試。項目由于過大，啟動緩慢，編譯一次大概10多分鐘。我們團(tuán)隊不熟悉此種模式，摸索浪費了一段時間。

客戶公司較大，研發(fā)部門較多。開發(fā)過程中部門協(xié)調(diào)工作占比超過一半，需要和各種各樣的設(shè)備做對接，都是別的部門開發(fā)的。部門之間互相踢皮球，找人協(xié)助困難。

錯誤一：高估團(tuán)隊水平

自以為很了解同事，其實了解的太片面。在過去一年中，由于做的項目比較穩(wěn)定。持續(xù)產(chǎn)出在可控范圍內(nèi)，客戶也比較認(rèn)可。導(dǎo)致我產(chǎn)生了覺得我們團(tuán)隊還不錯的錯覺。

整個團(tuán)隊在面對全新環(huán)境的情況下，適應(yīng)能力偏弱。難以快速穩(wěn)定的產(chǎn)出，項目開始了兩個星期，基本都處于熟悉環(huán)境、熟悉項目的狀態(tài)，一直沒有有效產(chǎn)出。導(dǎo)致時間被浪費。

比如某A剛?cè)肼?個多月，在其他項目中，項目負(fù)責(zé)人給出的評價還不錯，導(dǎo)致我把他放在了重要的開發(fā)位置上。但項目一開始，我就發(fā)現(xiàn)某A技術(shù)水平差的有點厲害，多表聯(lián)查的sql都寫不溜。此時已無人可替他，只能我上去協(xié)助他。

比如某B一年多來，帶的項目一直穩(wěn)定未出大問題。但到了新項目中，理解能力較弱無法快速全面理解需求。同時也暴露出了某B沒有風(fēng)險意識的致命缺陷，不能識別風(fēng)險，識別出了風(fēng)險也不反饋不作為，導(dǎo)致項目多次跳票。

反思：考核很重要，全面的考核反饋更重要。

在人員和團(tuán)隊方面，產(chǎn)生最要命的問題，我想就是考核機(jī)制的問題了。由于種種原因，對同事的了解都太片面。在用人方面把人放錯了位置。狙擊手放到了主攻手的位置上，主攻手放到了指揮員的位置上。這樣戰(zhàn)斗不失敗才怪呢!

站在一個較高的位置，很容易對下面同事的能力判斷失誤。就我認(rèn)為，在人數(shù)不多的情況下，最好的了解大家的方式，是一起戰(zhàn)斗。在一場戰(zhàn)斗里，觀察每個人每天的態(tài)度表現(xiàn)、效率產(chǎn)出、代碼質(zhì)量、協(xié)調(diào)能力、對外溝通能力等。經(jīng)過一個項目下來，就能對這個項目組中的成員有個較全面的了解。但這種方式不能只是站在項目外看，而要和大家一起就同一個項目開展工作。

從多方去了解一個人，不只聽某一人之言。對如上的某A來說，就是因為只聽了一人之言產(chǎn)生了較大的誤判(某A在另一個項目中，只做了導(dǎo)出功能，未接觸數(shù)據(jù)庫)。

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

人都是在不斷變化的，而我用了以往的經(jīng)驗去評判大家。有的高估了，有的低估了。沒有把最合適的人安排給最合適的項目，不應(yīng)把過去的錯誤或者功能記在今天的賬上，要持續(xù)的跟進(jìn)大家的變化，持續(xù)的保持對大家的新認(rèn)識。不以固有的眼光看人。

也應(yīng)通過積極的引導(dǎo)，幫助同事改掉自己的不足。而不是聽之任之，由其自生自滅。只有這樣，團(tuán)隊才能進(jìn)步，這也是一個leader最應(yīng)該做好的事情，我在這方面差的還太遠(yuǎn)。

因事定人不可取

某D之前由于某次技術(shù)預(yù)研的工作，讓我認(rèn)定他一般。但在這次的項目中，他卻成了最穩(wěn)定輸出的一環(huán)。由此可見，不能因為某人一時做的好或者不好，就給這個人定了型，先入為主的下定論。要客觀的評價一下個人，需要了解他的全部歷史和全部工作。也就是第一條說的，要有全面的考核反饋機(jī)制。

錯誤二：低估項目難度

項目共計4個，每個項目(只支持IE)都需要和額外的客戶自研中間件、插件(ActiveX)、多種硬件設(shè)備對接。此前未做過和硬件對接的設(shè)備，低估了對接的難度。

中間件、插件、硬件設(shè)備的對接我萬萬沒想到，什么文檔都沒有。只能去搜歷史代碼學(xué)習(xí)測試，或者到相關(guān)部門去問問。而此前溝通過程中，我心中默認(rèn)對接是有文檔或?qū)Ｈ酥笇?dǎo)的，沒有問清楚。

前端使用框架(2006年的框架和版本)過于老舊，由于對前端了解不足，錯誤的估計了學(xué)習(xí)曲線，團(tuán)隊前端同事開發(fā)前期非常吃力，進(jìn)度在這塊也拖延了一大段。

跨部門溝通的難度遠(yuǎn)超我的想象，此前溝通過程中，明確好跨部門溝通有專人負(fù)責(zé)，但到了實際工作中，都變成了我們自己去對接。各個部門互相踢皮球，一個攝像頭到底是什么型號的問題(測試需要特定型號的攝像頭，對接人不清楚借來的是什么型號)，我能花3個小時跑遍五層樓才得到答案。更不用說代碼層面的指導(dǎo)了。

沒有了解到客戶方框架的真實情況，心中以為是在spring上封裝的腳手架。沒想到框架中包含了快2000張表，數(shù)百萬的歷史代碼。光用戶模塊就有不同的三套(該框架會在各個定制的基礎(chǔ)上，定期的把定制內(nèi)容合到框架主干上，導(dǎo)致了各種沒有用的歷史遺留代碼)，找想要使用的功能搜索難度大增。

反思：經(jīng)驗很重要，但經(jīng)驗也很致命。

在此次前期溝通中，很多我以為，我認(rèn)為都是經(jīng)驗主義所害。比如對接文檔的問題，多問一句，可能情況就很不一樣。

經(jīng)驗也可能成為風(fēng)險之一，需要警惕。

想法設(shè)法獲取更多信息，四個項目的對接人了解的信息都不全面，到我這的信息就缺失更多，而我當(dāng)時以為這就是全部的情況。信息的缺失是會讓判斷失去方向。

在現(xiàn)有信息中，要去挖掘出更多的問題和信息，并找對接人確認(rèn)。越多的信息越能為判斷提供更準(zhǔn)確的方向。對接人也不清晰的情況，需要推動對接人去找相應(yīng)人員獲取，得到相對準(zhǔn)確和完善的信息。

鎖定項目核心重難點.

在這幾個項目中，有的項目沒有在一開始就抓住項目核心重難點。比如甲項目中核心功能是存儲，且需要使用客戶自研存儲設(shè)備，項目初期未鎖定該重點問題，導(dǎo)致后期項目核心功能全部返工。一般采取排除法來鎖定核心重難點。把所有的頁面可見功能點和隱含功能點列上，以排除法排除獨立的關(guān)聯(lián)少的模塊。留下的就是重難點的核心要素。針對每個核心要素搞清楚聯(lián)系關(guān)系，得到最終的功能關(guān)系圖(業(yè)務(wù)架構(gòu)圖)。

錯誤三：戰(zhàn)術(shù)錯誤，同時面對過多的項目

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

反思：項目中總是會面臨資源不足的情況，永遠(yuǎn)不要想著項目中擁有最適合的資源、人員。

畢竟最適合的人員不可能一直等著你的項目，帶項目就像打牌，一手好牌做好了項目是應(yīng)該。而一手爛牌打贏了才是你的能力。

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

最后一個錯誤，是在項目無人可帶的時候，迫不得已我去帶了項目。陷入了某個項目的具體細(xì)節(jié)后，沒有了統(tǒng)一對所有項目進(jìn)行管理協(xié)調(diào)的人

管理是很耗費精力的，需要專人專職的去處理。管理者一大職責(zé)就是溝通協(xié)調(diào)，尤其在這種需要強(qiáng)溝通的項目中。一旦陷入了具體的某個項目中，就很難有精力去維持其他項目了。

授權(quán)很重要，但檢查更重要。交付出去的工作，要定期檢查，保證交付物是完成的、完整的、不返工的，

我所吸取的教訓(xùn)總結(jié)，建立更全面的考核反饋體系對認(rèn)識團(tuán)隊至關(guān)重要，不要局限于經(jīng)驗，溝通勝于一切，反思每一次戰(zhàn)術(shù)失誤，保證下一次的精確打擊，專人專事，專職管理的人，就不要陷入開發(fā)細(xì)節(jié)中，一旦大量精力投入了開發(fā)。這將是致命的風(fēng)險。

文章來源：盧松松博客，歡迎關(guān)注我的帳號哦!

申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！