程序員要面臨的挑戰千千萬，項目進度評估是有史以來就存在而且到現在也沒有完美解決的重量級問題。 我曾發過一張暴漫，描述項目行進的過程，叫做“[**軟件項目9步神曲**](http://blog.csdn.net/foruok/article/details/46678099)”。我還專門寫了一篇文章，“[**樂觀的程序員**](http://blog.csdn.net/foruok/article/details/47079003)”，里面也提到了這個。感興趣的可以點開鏈接跟過去看看。 項目進度這個坎兒其實又可以拆分為兩個： * 工作量評估 * 項目執行與評估 前一陣圈子里流行一篇文章，題目是“做一個這樣的APP要多久”，類似的版本還有“做一個這樣的網站要多久”、“做一個這樣的APP要多少錢”、“做一個這樣的網站要多少錢”…… 多年的軟件開發經驗給我施了墨刑，在臉上刻了三個字：“程序員”，所以我走到哪里都會被識破身份。嘿嘿，都不用介紹了。這不，上周我去洗車時，就被一個兄弟認出來是搞軟件的。然后呢，他就問我，做一個點餐的APP要多少錢。我馬上一臉黑線，他又說，就是那種很簡單的，送外賣用的，這邊點一下，那邊收單。就要最簡單的，他強調。 那幾天西安正是持續高溫，悟空都把西安錯認為火焰山了。我和那個小伙子站在39度的夕陽殘照下，沐著水泥地面源源不斷升騰的熱浪，認真的討論“做一個這樣的APP要多少錢”這個嚴肅的話題。從美團外賣、餓了么、百度外賣這些現成的大家伙，說到微小的微信公眾號，又說到自己實現的各種問題，比如客戶端的樣式、后臺的功能、服務器的托管……我們斷斷續續地聊了將近半個小時，最后互加了微信，他送了我一張5元的洗車抵用券，我告訴他最簡單的外賣App也得幾萬塊，我還告訴他其實做一個App不是最花錢的，最花錢的是營銷和推廣。OK，他同意這一點，也表示很難。 后來呢，沒有后來了，我走了…… 這是個有意思的小插曲，我今年已經遇到至少三次了。還記得的一次，是一個朋友問我開發一個電商網站要多少錢，說“不用太復雜，能買能賣跟京東的功能差不多就成，界面不用太炫”，我最后說京東做了好多年，花的錢數到手抽筋，作為一個個人電商的嘗試者，再簡化，也得花個十來萬吧。 還有人問我開發周期的…… 有時候看著發問者期盼的眼神和殷切的表情，你不告訴他一個數字就會在良心上受到煎熬。我這里有一個類比，就好像你覺得自己犯了病，莫名其妙但表現很嚴重整個人都不好了，于是巴巴地跑到高新醫院掛了個專家號，人家告訴你你沒病，你幾乎不能相信，總還得再跑幾家醫院再找幾個專家，直到有一個專家說，“哎呀你攤上大事兒了，直男癌”，你才會如釋重負，說，哎呀，原來我真的有病。有時候我（程序員）就是那個必須說沒病的人有病的專家，不說不行啊，你得讓他心里安穩下來。 扯太原去了，先打住吧，我們扯正事兒。 其實呢，什么是正事兒，像“做這樣一個APP要多久”這類問題，本質上是“根據需求評估工作量”這一經典問題的變體。而“做這樣一個APP要多少錢”這種問題，如果前一個問題解決了，它就不是問題了。 作為程序員，也可能你在生活中沒那么高的頻次被一個行乞者拉住問你做一個乞討O2O的APP要多少錢，但在工作過程中，你肯定經常被這種問題挑戰。那么，問題來了，你都是怎么應對的？ 嗯，你先想想看……我要接著往下逛。 ## 工作量評估 工作量評估，到底該怎么做？以攤煎餅果子為例，一個煎餅果子，雞蛋、火腿、辣子、蔥、生菜，無論怎么配置，熟練工做一個也不超過5分鐘。可軟件就不一樣啊，每一個產品每一個項目都是不同的，即便可以代碼復用，也總是存在需要重新設計重新開發的部分，否則，這個項目就不可能單獨列出來給你做！而只要是新的，哪怕一部分是新的，就一定存在你不試不知道的梗，就一定有出乎你意料的問題蹦出來，最終在這個項目上花費的工作量，就一定和你估計的不同。 **在一個項目開始之前評估的工作量，一定是不準的**，這是天條。那那那，為什么還要評估呢？ 從需求方，從客戶，從領導，從市場，從開發，從測試，從產品，從UI，從客服……從各個口的干系人來看，都需要一個時間點，所以，必須要評估出工作量，才可以給出一個時間點，然后大家才能轉起來，各做各的準備，為著一個共同的目標去努力。 但是，在完成之前的工作量評估都是不靠譜的，所以，初始的工作量預估，只是為了制定一個粗略的計劃，然后通過執行計劃達到目標。 一個項目的工作，必然是由**已知可評估部分**和**未知待實踐部分**組成的。對于已知可評估部分，過往的經驗可以幫助你做出相對準備的判斷，比如你要實現網站后臺管理系統的管理員權限，管理員、角色、權限這種通用的做法，放在哪里都差不多，你做A站和B站，這塊的工作量基本相同。而對于未知待實踐部分，則次次不同。因為每一次的未知都和上一次不同（哭了，相同就不叫未知了），而未知即風險。軟件項目的風險，相當大一部分就在這未知里面。未知的東西，不試不知道。評估這回事兒，卻往往是拿知道的推測不知道的，還總要給自己找這個那個理由來說服自己也說服別人。其實根本就顛倒了，絕大多數時候，已知經驗預測不了未知的未來，我們只能走走看看，試探著前行。 那么，工作量評估到底該怎么做？我有一些不成熟的經驗，說說看。 我們的經驗都是過去的，用過去的經驗評估不了未知的未來。這是必須接受的現實。當我們分析一個新的項目時，一定是會從經驗出發，拆分出根據經驗可以把握的部分和看不透的部分。可以把握的部分，可以用已有經驗類比，將功能從大拆小，考慮實現的方案，對每一個小模塊都進行實現上的設計和考慮，估算一個時間。這樣疊加起來就可以得出大概的工作量。 對于看不透的部分，也還是要進行估算。盡管這樣的估算百分百不靠譜，從讓相關干系人安心的角度講，也還是要有一個結果。這是軟件工程必須要做的工作。 通常老板或領導上給我們描述一個東西，然后就會問：“做這么樣一個軟件需要多長時間？”并且希望我們像士兵用“是”或“不是”回答長官提問一樣，立馬用洪亮的聲音喊出“3天”或“20天”這樣的答案。我們有時已習慣這種現實，不能立刻給出估算自己都會著急。其實，要對未知的、難以把握的部分做估算，需要花費相當的時間，一定要經過仔細推敲才可以答復相關人員。有時甚至需要先花兩天做一些技術實驗才成。所以，當我們心里沒譜時，就先說明這一點——我不能立即給出評估結果，然后申請一些時間（可以是1天、2天、1周等）來分析，約定什么時間給結果。我相信大部分的領導都能夠接受這樣的方案。 一旦我們有了專門用于評估的時間，就可以多多考慮一些問題，比如看不清的部分，它的復雜度是什么樣的，可能會用到什么新技術，新技術的學習成本是高是低，技術難點在哪里，有沒有什么好的辦法解決技術難點……考慮了這些問題，我們再去回顧以往的工程實踐，有沒有哪個項目哪個產品當時在做時也存在未知的部分，那時我們實際花費的工作量和預估的工作量之間的比值是多少，我們怎么做的？ 總而言之，雖然未知的東西難以用既有經驗準確估量，我們還是要硬著頭皮去做。做的時候，一定要有一個心理預期，不但自己要有結果可能相當不準確的預期，也要告訴項目干系人，讓他們接受這種預期。 如果能找到復雜度相當的歷史項目，分析出它的數據，就可以對未知部分有一個相對靠譜的估算。這里說的靠譜，不是誤差在3、5天內，而是指數量級上的相當，比如你估算要花2個人月，實際花了3個或4個，我認為這也是靠譜的。如果你花了20個，我覺得就不靠譜。當然人月本身也不靠譜（參看《人月神話》），不必迷信它。 有一點要提及的是，對于未知部分的評估結果，還要再預留一些余地。因為既然是未知，總會發生意想不到的狀況卡停你前進的步伐，讓實際花費的時間大大多于預期。當然，我討厭那種“把明明20個人日能完成的事兒估算成200個人日，然后再預留200個人日”的做法，這是不能接受的。 **由于工作量評估是基于估算者自身經驗，天生就有另一個難點：不同的人會得出不同的結果，有時甚至天差地別。**怎么處理這種情況？我沒看到什么特別好的辦法，最二的辦法就是去掉最低和最高然后取均值。還有一個辦法就是讓經驗更豐富的人來根據他的經驗來做折衷。不論怎樣，一個團隊里的成員生產率都是參差不齊的，張三三天完成A任務，李四就可能是八天，趙六甚至可能十天，而且三個人都可能盡了全力。這就是天生的難題。而人月、人日這種估算方法，忽略了這種因人而異的生產率差異，所以有時你只能估算一個系數來處理，或者以生產率居中的那個人的估算為基礎進行折衷。 ## 項目進度評估 有了工作量，就可以做計劃了。有了計劃，老板們就可以放第一個心了。是吧，按計劃行事，不管是A計劃還是B計劃，總歸是有個計劃了。 計劃的執行會引導我們走向預期的結果。這是大部分人的想法，所以他們看到計劃就會長出一口氣，好像光明的結果就在前方向他們招手。 實際情況呢？往往是不盡如人意的。我們看看軟件行業的各種跳票就知道了。 前面我們聊工作量評估時一再提到未知和不確定性，要謹記，我們得出的估算結果是不準確的，將來可能發生各種各樣的意外。而基于這種估算結果制定的計劃呢，在一些不可控因素發生時，必然需要改變，需要調整，需要重新尋找抵達目標的路徑。用過導航的都有體會，你在一個高架橋或者環島拐錯了路，導航軟件就會重新計算路徑，告訴你怎么走另外一條路或者怎么繞回到之前設定的路徑上。其實項目執行也是這個路子，只不過，我們不愿意接受這個事實而已。領導上客戶上總覺得承諾的日期就一定要兌現，到時要么交代碼要么交尸體。其實呢，換個角度來看，你就會發現，交付日期的變動也是可以接受的。 其實，計劃是為了應對變化，計劃本身也是要不斷變化的。如果不允許計劃發生變化，就不符這世界“唯一不變的就是變化”這種客觀規律。 我們一定要有隨時調整計劃的心理準備，也要讓項目干系人接受這種預期。不管我們的估算多么準確，都會遇到意想不到的狀況，改變我們行進的軌跡。這些狀況，就是項目的風險所在，項目管理的一大要素，就是要及時識別這些狀況，及時調整行進路線，保障在合理的預期時間內完成目標。 經過分析我們都能用腦袋接受計劃可能會變這種邏輯，但放在實際項目實踐里，計劃發生變化卻往往是不被接受的。這一方面是公司已經協調了各種資源，甚至對外做了發布宣傳，公布了日期，市場、營銷等都已經投入資源運轉，如果臨時變更日期，不但無法向市場和用戶交待，無法向各種項目干系人交待，還會造成實際的損失。這是現狀，我們不得不接受。我們必須在此基礎上來討論如何保障項目進度。 其實我們在軟件開發的過程中，能知道的是已經做完的事情和未完成的任務。我們每完成一個或一定量的任務，都來重新評估未完成的任務，用新的估算更新我們的計劃，并且將新的計劃發布給各個項目干系人。這就是動態交付日期策略。通過持續的、不斷的調整評估和計劃，我們會得到一個越來越靠譜的交付日期。相信日益明朗和確定的新計劃會讓領導上覺得曙光就在前面，會緩解他們的焦慮，即便最終交付時延期，也會有不一樣的感覺——與持續的黑洞式無反饋和傻呵呵的自以為能按期交付卻在最后時刻被告知要延期相比。 這就是動態交付日期策略，我們通過短周期的迭代，不斷完成確定的任務以及不斷評估未完成的事項來調整計劃，最終獲得動態卻相對靠譜的項目進度評估。 不過說起來容易，實際執行卻是相當的難，對開發團隊是一種不小的挑戰。