帶研發團隊的日常思考2 專案老是延期該怎麼處理

這個問題老生常談了，大部分網際網路公司的專案都可能會遇到這樣的問題，這裡並不能給到大家乙個具體的、徹底的、完美的解決方案，具體的專案、團隊情況需要具體的分析，我這裡記錄一下遇到這種問題時候的一些思考和處理方式吧。

來到新的公司後，擔任xx專案開發組長，主管先讓我帶5個人的團隊：2個前端、2個後端、1個測試。

我主要負責專案的重要業務模組開發、進度把控和日常問題處理，一半開發一半管理，在上家公司已有技術管理經驗2年多，再上任技術管理工作很快能適應。

我是4月中旬來到公司的，4月最後2周團隊都有目標要完成，結果看來都是最後2天大家都加班了去搞，但是最後也沒有搞出乙個好的結果。

於是我開始反思自己來到新團隊後，

今天是5月勞動節回來後的第一天工作日，早上到公司後，9.30組織大家開早會

主題為:4月遇到兩次專案延期了，原因是啥？如何解決？並總結。

我也早早地做好了總結，這裡做下記錄：

產品給的需求文件不明確。

前端xx也要總結一下，頁面校驗引數的統一方法、檔案上傳及回顯、後台的常規頁面基礎開發，前端開發比較拖，所以導致延期的乙個主要原因，屬於人員能力問題。

後端需要給出介面文件(請求引數、返回引數)，屬於開發規範性問題。

需求文件不明確怎麼做：

人員能力問題需要重視

團隊成員不是我招的，所以對每個人的來歷不清楚，所以當我發現人員能力不足的問題，第一時間和領導溝通了解相關人員情況，並向領導說明了能力不足的問題，領導說也注意到這個問題，說後面公司會經過考核處理。

當然結果怎麼樣不是我能決定的，我提出了我看到的問題，也給出了對應的建議解決方案，同樣我也是乙個剛來公司的人，如果我沒帶好團隊，沒做好自己的工作，我也要對自己的工作負責。

我認為團隊成員應該有的最最最最基礎能力

能勝任基礎開發工作，比如前後端開發乙個模組的後台增刪查改的模組，能夠在指定時間內開發完成。

如果有技術相關的問題，會主動找你溝通尋找解決方案，基本的溝通能力、主動性！！！

拿到需求有提問，先思考、後開發（經驗的體現）。

這裡主要是針對有工作經驗的情況，不考慮實習生，因為公司目前招人都是馬上幹活的，如果滿足，團隊的整體效率就會高很多。

如果都不滿足上述基礎能力的人，該優化就優化，如果確實要繼續用，那這個人除了能力差點，但是主動溝通，做事也比較積極、那這樣的人是可以培養的。反之，如果經過了多方面的考核，還是拖團隊後腿，該優化就優化掉，不要猶豫！

木桶效應是講乙隻水桶能裝多少水取決於它最短的那塊木板。

規範性問題需要管理者去制定一套標準的規範，比如介面文件使用xx，介面統一返回資料格式等...這個就比較好解決。

所有的開發拿到需求開發工作前，都要有乙個評估完成時間，也就是截止時間，組長做好記錄。

關於評估時間方法：

1.5倍方法:即你評估時間 x 1.5倍，比如開發這個需求我需要2天，那麼你評估3天是乙個比較合適的，因為這個評估時間主要包含了

一定要說明的這個是研發完成開發時間，不包含測試時間。

評估時間的合理性:如果乙個簡單的模組研發評估時間較長，組長需要評審他這個時間是否合理，根據實際人員能力和情況評估。

評估時間是開發前期乙個重要的能力體現,絕對不能說做一步看一步，也不能因為需求不明確我們就沒有辦法評估，這種情況找我溝通，不明確的需求我們就和提需求的人對，多花點時間把不清楚的地方理出來，就能更準確評估。

如果在需求理清楚的情況下，以及和我溝通過了，你還沒有辦法評估乙個開發時間,這個就是你的問題了！

提前預警，意思就是不要到了最後1、2天才發現進度問題做不完了，組長應該每天跟進，早發現早解決。

基於前提，已經有評估時間的情況下，那到了時間沒完成，該加班就得加班了，全體專案組都要一起加班去完成。

乙隻鳥站在樹枝上從不怕會斷,因為它相信的是自己的翅膀,這就是生存法則，i·m focus,下期再見！