文章來自：ThoughtWorks，世界經(jīng)理人經(jīng)授權(quán)轉(zhuǎn)載。
“如果一個程序員告訴你他已經(jīng)完成了 90% 的工作量，那么他還需要同樣的時間完成剩下的 10%。”
軟件項目容易延期和跳票是屢見不鮮的事情，其中不乏知名項目。
剛畢業(yè)的時候，我在一家做系統(tǒng)集成的公司工作，我們定制了一套售票軟件，為景區(qū)接入互聯(lián)網(wǎng)售票方案。供應(yīng)該軟件的軟件公司非常自信的說，這東西非常簡單，最多 2 個月就能搞出來。這家公司小有名氣，我老板對 2 個月交付深信不疑，于是張羅了接入的客戶、市場的物料等。
不難猜到，最終還是沒能逃過 90% 定律，2 個月交付的東西只能算作一個 Demo。于是花了另外一個月測試，修復(fù)問題和完善業(yè)務(wù)邏輯，又花了另外幾個月時間響應(yīng)對接客戶的要求，才逐漸穩(wěn)定下來。
行百里者半九十，軟件開發(fā)也大體如此。開發(fā)者估不準(zhǔn)工時常有，估準(zhǔn)了才奇怪呢。
后來自己也做了軟件工程師，參與 IT 項目開發(fā)，項目延期也是非常常見的事情。
工時估算的前提是質(zhì)量
IT 團(tuán)隊能準(zhǔn)時交付是一項非常有價值的能力，哪怕交付時間長一點(diǎn)。計劃兩周交付，最后能準(zhǔn)時完成，比承諾 一周時間，但是花了三周才交付重要得多。
越是大項目，越是重要。大項目的各個組件可能會發(fā)生相互依賴。如果不能準(zhǔn)時交付，就會付出團(tuán)隊等待的成本，那可是真金白銀。
做過項目管理的都知道甘特圖，甘特圖的每個泳道表達(dá)了項目各項資源的進(jìn)展和計劃。然而，軟件項目不確定性非常多，存在各種突發(fā)事件。如果能提高準(zhǔn)時按質(zhì)量交付，各個單位的等待成本會小很多。
關(guān)鍵的是，衡量準(zhǔn)時交付的關(guān)鍵是質(zhì)量，其次才是交付。先給一個 demo，然后再慢慢改 bug。這種 “準(zhǔn)時” 的交付，還不如有一個明確的延期時間，本質(zhì)上還是 “猛糙快”。
談項目工時估算，應(yīng)該是在滿足質(zhì)量要求的前提下，否則估時沒有意義。
提高估算準(zhǔn)確性的方法
那么能不能提高軟件工程工時的估算的準(zhǔn)確性呢？其實是可以的，剛到 Thoughtworks 的時候，參與了一個交付項目。在一個項目開始前就計劃了項目結(jié)束的時間，以及下一個項目的計劃和安排。結(jié)果讓我非常吃驚，那個項目的結(jié)束時間，和預(yù)期相差兩周左右。并且這兩周是逐步減少開發(fā)人員，最后只有 1-2 個人負(fù)責(zé)最后一周的交接期。
這就是專業(yè)軟件團(tuán)隊和小作坊的差別，在專業(yè)項目經(jīng)理帶領(lǐng)下能把 3 個月的項目估算，精確到 20 - 30 個人天。能把項目工時估算到這種程度，體現(xiàn)了 PM 的內(nèi)功。
在一個敏捷團(tuán)隊，需要把工時估準(zhǔn)，不在于 “估” ， 而在于團(tuán)隊執(zhí)行項目的穩(wěn)定性。一般來說，準(zhǔn)確估算工時需要考慮需求分析程度、任務(wù)拆分的合理性、技術(shù)方案的可靠性、團(tuán)隊成員的能力、外部依賴和環(huán)境，如果這個項目不是新項目，還需要考慮遺留系統(tǒng)改造的成本和數(shù)據(jù)遷移的成本。
需求和任務(wù)分析
只有把需求分析做的非常徹底，才能保證估算的輸入條件。非專業(yè)的業(yè)務(wù)分析師，只能看到需求冰山水面上的部分 —— 軟件的特性、功能的復(fù)雜性等。
專業(yè)的業(yè)務(wù)分析師，不僅需要考慮功能需求，并對功能需求的邏輯性考慮完備。比如用戶需要一個 APP，他實際上還需要一個后臺，對應(yīng)這個后臺會有不同的用戶、角色等。
根據(jù)這些業(yè)務(wù)輸出、拆分出任務(wù)，敏捷開發(fā)中我們叫做用戶故事，一個用戶故事代表一個合理拆分的業(yè)務(wù)邏輯。能被評估工作量，然后根據(jù)這個工作量來評估工時。
除了這些功能需求之外，還有非功能需求。客戶不僅僅需要一個 APP，還可能需要的是一個安全的、高性能的、國際化的 APP，而這些往往被客戶當(dāng)做默認(rèn)選項。
一些性能優(yōu)化的指標(biāo)需要分析，并考慮性能優(yōu)化的任務(wù)工時；安全需求可能有 HTTPS 配置，防病毒掃描等，都需要考慮；國際化也是額外的工作量。
挖掘用戶真實需求的目的是定義怎么才算完成（Definition of Done），如果沒人說得清楚滿足什么條件這個項目才算完，那么估算工時根本無從談起。
徹底挖掘客戶的真實需求是評估項目工時的首要條件。
技術(shù)方案和團(tuán)隊能力
技術(shù)方案、團(tuán)隊能力和項目時間估算有很大關(guān)系。很多項目的時間估算都是由技術(shù)經(jīng)理或者 Tech lead 來完成，往往是他們按照自己的經(jīng)驗和能力進(jìn)行計算的。光是這樣，很難算的準(zhǔn)。
團(tuán)隊有多少人？對這套技術(shù)方案的熟悉程度如何？方案是否會發(fā)生較大的調(diào)整。人一多，人員水平差距就為工時估計帶來了不確定性。經(jīng)驗多的人來做方案，如果是他做過的相似方案，自然會估的稍準(zhǔn)一點(diǎn)。但大多數(shù)情況下沒有這么理想的場景。
要做好工時估算，需要結(jié)合技術(shù)方案和團(tuán)隊成員能力，而不是自己能干多少活兒，多快干完來算。
一方面，技術(shù)負(fù)責(zé)人需要安排相應(yīng)的技術(shù)預(yù)研，走在實際編碼的開發(fā)人員前面，探探路，驗證方案的可行性、實施難度、風(fēng)險。就像作戰(zhàn)的偵查人員一樣，我們把預(yù)研叫做 spike。spike 需要輸出一些結(jié)論、demo，支持項目的時間估算。
另外一方面，考察團(tuán)隊真實運(yùn)作效率很好的方式是根據(jù)迭代做工時統(tǒng)計。按照兩周為例，10 個人的團(tuán)隊是 100 個工時。如果按照之前的估算，2 周內(nèi)需要完成的 100 個工時的任務(wù)，實際上只完成了 50 個工時。也就是進(jìn)度只有 50%。
我這個算法比較粗糙，敏捷項目管理中還有更準(zhǔn)確的速率計算方式。通過速率，就能對下一階段的工時估算做出調(diào)整，并在工作量、人員上做出調(diào)整。
通過方案預(yù)研和速率計算是提高項目工時估算準(zhǔn)確率的良好方法。
把控遺留系統(tǒng)和外部依賴
我常?；艘幌挛鐣r間完成了某個特性升級的編碼，但是花了一個月的時間才完成了線上平滑升級、數(shù)據(jù)遷移。
真正有經(jīng)驗的工程師都知道，方案設(shè)計的難點(diǎn)往往不在設(shè)計一個新東西，而在于演進(jìn)一個老系統(tǒng)。遺留系統(tǒng)演進(jìn)是不可避免的，這種歷史包袱是造成工時估算不準(zhǔn)的一個重要因素。
遺留系統(tǒng)演進(jìn)帶來的估算困難來源下面幾個方面：
● 前置條件不滿足或者很困難。客戶可能覺得只是添加一個小功能，但是涉及數(shù)據(jù)庫變更、API 升級。軟件項目往往牽一發(fā)而動全身。
● 遺留系統(tǒng)代碼難以理解，沒有人說得清楚原委。這種系統(tǒng)往往伴隨著重構(gòu)，否則難以進(jìn)行。
● 數(shù)據(jù)遷移的成本。例如，需求只是簡單要求對用戶的某些數(shù)據(jù)加密，實際工作包括了對存量數(shù)據(jù)的遷移。
● 臨時代碼的清理。遺留系統(tǒng)往往為三個狀態(tài)，原始態(tài)-過渡態(tài)-最終態(tài)，很多人估算工時要么忘記了過渡態(tài)，就是忘記了最終態(tài)的時間成本。
不負(fù)責(zé)的猜想，有一些客戶就是遺留系統(tǒng)演進(jìn)不下去了，然后招標(biāo)做新功能，實際意圖是想乙方順便消化重構(gòu)的成本?？傊谶z留系統(tǒng)的二次開發(fā)都是一件困難的事情，能不接就不接吧。
另外，社會分工意味著一個人干不完所有的事情，IT 項目往往一個項目也不是獨(dú)立的。大多數(shù)情況下需要和外部條件進(jìn)行集成，這部分時間超出我們的掌控。
集成這件事的成本需要視主動集成還是被動集成來說：
1. 需要等待別人提供服務(wù)，我們?nèi)ゼ?。在估計工時的時候，一定要把對方的交付時間考慮進(jìn)去，提前溝通，并建立契約。
2. 提供給別人服務(wù)，被別人集成。這種情況估計工時，往往只是計算到 API 上線，實際上還需要考慮一定的支持、文檔工作量。很少有一次到位的情況，大多要磨合一段時間。
集成充滿了不確定性，估算工時時需要預(yù)留足夠的集成空間，才能讓工時估算更準(zhǔn)確。
總結(jié)
項目工時估算是一個系統(tǒng)性工作，基本上很難有一個萬能的方法。因此大多數(shù)情況下都是玄學(xué)，但是畢竟是 “估” ，也不能要求 100% 精確。軟件工程的估時更具有彈性，相對供應(yīng)鏈管理的交付時間估算成本更低。做好估時，對減少項目運(yùn)行成本和風(fēng)險有巨大意義，工時估算的準(zhǔn)確性也往往體現(xiàn)了一個 IT 團(tuán)隊工程能力。