神州布衣：如何突破項目工期瓶頸
有機會分享我對項目進度控制的一些經驗和心得，深感榮幸。
之所以受邀分享，是因為之前完成了兩個工期較為緊迫的項目。
第一個食客項目，當時評估的總工時136人天，40天左右時間內完成（12月21日-2月1日）。
這個項目採用的是亞馬遜的AWS（國內網訪問較慢，給測試帶來諸多不便），系統需要支持中英文（需要根據操作系統、註冊手機號或郵箱進行自動識別），除了本身的系統外，還需要開發視頻播放器（需要適配和兼容主流瀏覽器），另外視頻和頭像需要雲儲存及訪問等諸多難題。過程中新增了三次新需求，還遇到了一個坑爹的前端，不會寫互動式前端。
另外一個項目是接手別人的項目，3月19日接手，4月26日上線。
接手時，已經完成原型設計了，其實我覺得前面的項目經理挺不錯的，主要是這個客戶不按常理出牌（不想花錢，讓我們多實現他的需求）。前任項目經理跟我說，本來這個項目的報價在10萬左右，被客戶硬生生的砍成5萬了，砍到5萬後，後來又新加了一些功能，最後7萬多點（估計因為多加了2萬，客戶對前任項目經理意見很大）。我接收後，新增了21個新增功能，其中12個我認為工作量不大，直接給處理，還有9個，我當時說放到咱們這版驗收通過後，再迭代處理。但是奇怪的是，當我們測試驗證的時候，發現這9個功能做已經開發好了（一面懵逼……）。這個，這個項目經歷了更換項目經理，介面工程師（這個工程師做了1個禮拜，由於工作原因，不幹了），原型設計注釋特別少，加大了項目管理難度。這個項目也是按時完成的。
更難能可貴的是全部是五星好評。
說了那麼多艱辛歷程，其他項目經理，估計也有很多血淚史，我記得誰說過一句，項目經理就是用來背鍋的。
我們回到項目進度控制。
說到項目進度控制，那麼我問大家，什麼是項目進度控制？給3秒鐘的時間大家想一下。。。其實很簡單，我請大家記住三個字：「里程碑」。這個碑很重要，咱們現在互聯網流行一個詞叫口碑，口碑好，離成功就不遠了。。。為什麼咱們客棧做的那麼好，就是因為咱們口碑好，扯遠了，回正題，
里程碑。。。
里程碑裡面有兩個部分是很重要，制定里程碑，控制和調整里程碑。
制定里程碑：這個是難點，也是最關鍵的。里程碑制定的好，那就成功了一半。制定這個有一個總體原則：就是不要太滿。太滿的話，工程師很累，自己也很累，最後逾期的風險也很大，無形中給大家很大的壓力，所以我的建議是至少預留20%的緩衝時間。項目一般有兩種情況，一種是上線時間是硬性指標；另一種是項目經理制定上線時間。我這次主要說的第一種。客戶有明確的要求上線時間，其實這種情況比較簡單。採用倒推法。
客棧的項目周期有這麼幾個階段：1980需求梳理—原型設計—編寫測試用例—UI設計—Coding—技術聯調測試—業務聯調測試—驗收測試—上線，中間會穿插一些報價、對接工程師、環境準備、需求變更等可變因素。
那麼我的方法是需求梳理3-5天，原型設計（7-10天），原型設計出來後，準確的項目報價就出來了，裡面有工時評估，對接工程師時，我給的交付時間，是在這個報價工時的基礎上砍掉一半，也就是說如果報價估時是20天，那麼我只給10天時間。這個是里程碑時間節點，就是客棧裡面發布子項目給的完成時間。
整個項目進度還涉及到一個關鍵路徑的問題。
客棧的項目，工程師對接的順序一般是這樣，原型設計完成之後，先對接UI設計、後端工程師（管理端和介面端，一般是兩個，也可能用同一個人，根據項目進度情況，具體而定）以及測試工程師（這時候對接測試，主要是參與產品經理的業務培訓，否則不用那麼急）；UI設計完成之後，才能開始對接前端工程師。
前端：對於項目比較緊的項目，前端工程師可能是一個瓶頸。那麼如何讓這個瓶頸變成不是瓶頸，有這麼幾個方法：
第一：要求後端工程師，產品經理的業務培訓必須參加，二是必須先出介面文檔和資料庫設計，不要讓他邊做邊出文檔，這樣問題比較大，因為他沒有全局性，後面大面積調整的可能比較大；
第二：UI設計，可以分階段提交完成，完成第一階段時，就可以對接前端工程師；
第三：選擇前端工程師時，需要選擇能力比較強的，時間充裕的。後面後端的工期是瓶頸時，這個條件同樣適用。
後端：後端的工期也可能是個瓶頸，這種情況，一般是後端的功能點特別多，或者業務邏輯複雜，或者有技術難點或新技術（插播：說到後端，我想到了很重要的一點，就是原型設計，原型設計的成敗對整個項目的工期影響特別大，所以一個好的產品經理特別重要）。原型設計提出幾點要求：輸入項需要說明限制條件、按鈕項需要說明業務處理邏輯以及返回提示、展示項需要說明信息來源。關鍵業務流程需要梳理清楚。因為這個是原始需求，如果不清楚，都會可能會使工程師的設計及驗證出現偏差，以及增加溝通成本，進而影響整個項目進度。假設原型設計沒有任何問題，後端的工期還是很緊。一般採用的是拆分任務，增加後端工程師。通常的辦法是分為介面工程師和管理端工程師，如果還不行，那麼再根據功能模塊的獨立性再拆分。
測試：就是可以壓縮測試的時間，就是讓用戶端、管理端、分階段交付測試，這樣其實也存在一個問題，就是開發測試不充分，目前發現沒有幾個開發測試真的很充分的，多少都存在問題，所以測試早點介入還是比較好的。在測試過程中，很重要的一點，需要提醒大家，就是測試的問題一定要錄入到BUG系統進行跟蹤，千萬不要嫌麻煩就只是在群里說一下，如果不錄入BUG系統，問題一多，很容易就會遺漏掉一些了。作為項目經理，需要及時的對BUG進行跟蹤，要及時的提醒工程師還有多少個BUG未處理，如何測試發現的問題不多，需要要求測試加強測試力度。
客戶驗收：可以讓客戶早點介入系統，體驗系統效果。注意，這裡一定要告訴客戶，哪些功能是可以體驗的（測試測試通過的），哪些功能測試還未驗證完成，如果客戶想去看下，也沒有關係，告知客戶，這些功能還未測試通過，可能會存在問題，要求他理解。
最後，還有幾個可能會影響項目周期的因素，主要有報價、對接工程師、環境準備、需求變更。這裡簡單的聊一下。
報價：客棧小得報價很快，主要是客戶確認報價這塊可能會影響這個項目周期，所以在這個地方，如果客戶確定報價花的時間比較多，需要提醒客戶可能會對工期造成影響。因為前期的不確定因素比較多，所以我一般制定項目整體計劃是在原型設計完成之後。
對接：對接工程師，一個好的工程師可遇不可求，如果對接上比較優秀的工程師，那麼就恭喜你，後面你很省心；不過客棧的工程師一般不會太差，在對接後，需要項目經理對工程師做一個整體了解，以防存在渾水摸魚的情況。對接工程師一般需要預留2-3天時間。預留2-3天內，因為合適的工程師不好找，另一方面，可能小二不在服務區。
環境準備：這個很重要，需要在對接開發工程師時，就需要著手準備。如：購買伺服器、域名、SSL、資料庫搭建、應用發布配置等等，如果是公眾號或者APP都需要提前申請開通。
需求變更：這個對整個工期影響還是比較大的，特別是臨近上線的需求變更，一定要注意控制。在測試過程中，針對文案調整、字體顏色、輸入限制等這種純前端的變動，可以不算需求變更。對於新增功能，這種的，一定要警惕，如果是舉手之勞的，那麼買個人情，但是如果變動較大的，需要和客戶說明情況，可能會影響上線工期，讓客戶自己去衡量。
期待通過更多的項目，總結分享更多的心得體會～
TAG:程序員客棧項目部 |