作者 | Lawrence Putnam Jr
譯者 | 蓋磊
1 本文要點
項目未按時間表完成，或是項目超出了預算，這是導致很多項目失敗的原因。前期對項目做出預測，有助於避免從一開始就做出不切實際的承諾。
在做出詳細規劃前，自上而下、基於範圍的估算要比自下而上的規模估計和“猜測”更為有效。
當項目處於初始規劃階段和推進階段時，自上而下的估算工具有助於確立切合實際的項目邊界。這對於設定期望和讓利益相關者滿意是十分關鍵的。
通過過度增加人員實現壓縮時間表，在很多情況下實現代價高昂，並且常常是無效的。項目經理可以使用自上而下的估算，對投資組合中的適當人員配置和資源需求做可視化。
當項目由於利益相關者的需求或一些不可預見的情況而發生變化時（當然，項目不可避免地會發生變化），項目經理應重新做出預測，進而用於更新計劃。
2 引言
人們通常對“未雨綢繆”一詞瞭然於胸，那麼為什麼企業卻難以遵循這一原則呢？或許是因為人們已習慣於“快速行動起來完成工作”的做事方式。問題在於，過快的項目推進實際上會導致成事不足，給軟件項目帶來很大的問題。面對來自於高層的壓力，項目經理很可能轉而採取倉促行事，跳過項目估算和前期規劃。但是從我自身 30 多年的軟件項目管理經驗看，一個倉促進入開發階段的項目很有可能註定會失敗。
早在上世紀 80 年代，柯達曾致力於實現一種由軟件驅動的文檔成像解決方案，以此實現膠捲業務的多樣化。企業在花費了一年半的時間、投入了數百萬美元和大量的人力資源建立系統之後，他們找到我來做項目估算。估算結果顯示，完成項目還需要兩年的時間，並且還要投入更多的資金。如果預先做了項目估算，那麼企業就有機會更好地評估項目的上市時間和投資回報率。反之，整個項目偃旗息鼓，浪費了寶貴的時間和資源。
一位同事曾與我分享過一個類似的悲慘故事。據他講訴，幾年前正值聖誕假期，一位顧客要求他在假期前提供一組合計 22 個估算。他們並不認可他給出的數據驅動估算，因此決定採取自己的方式。正是由於不合理的期望和時間表，他們的項目最終失敗了。他們最終還是回頭找到我的同事，按他的方式去正確做事。真應該祝聖誕快樂！
當前，一些企業也在犯著同樣的錯誤。最近，一家企業開展了一項大型高強度軟件開發項目。儘管他們擴充到 100 多名開發人員，但是由於內部壓力以及一些不切實際的短期瘋狂計劃，他們決定放棄系統集成測試。由於缺少對質量影響和趕進度開發機制的評估，他們最終遺漏了很多系統缺陷。現在，企業正在重新做評估，一切從頭做起。
當然，我們沒有理由讓歷史繼續重演。如果項目經理能關注那些“不應做”的事情，是可以避免一些會導致成本和時間超支的缺陷的，並給出創造真正價值的解決方案。
3 事項一：不應跳過估算匆忙進入詳細規劃，應採用自上而下的估算方法。
任何形式的計劃，都好過完全沒有計劃。自上而下的估算，為詳細計劃過程提供了有價值的輸入。
根據我的個人經驗，設置不切實際的期望是項目失敗的主要原因。制定準確的目標是企業的核心競爭力，但不少企業尚做得不盡如人意。
部分原因在於，企業在估算項目規模時，傾向於使用傳統的範圍界定過程，這往往會給出不準確的預測。項目經理在編制項目範圍時，傳統做法是採用一種自下而上的方式。管理者要求每個團隊成員估算自己在特定活動中的工作時長，並根據這些“假設”確定每個成員的日程安排。不幸的是，這種自下而上的過程中缺少了一個關鍵的因素，那就是“事實”。一項基於 QSM 項目完成情況數據庫的研究顯示，有三分之二的公司未能比較計劃的績效與歷史上類似項目的實際績效。比較工作可讓團隊更好地瞭解完成工作所需的時間、精力和資金情況。他們竭力做出的估算，也許會導致錯過最後期限、成本超支、客戶不滿意，以及開發人員被剝奪權利。
如果項目在開始時採用了自上而下的方式，那麼一種非常有效的策略是基於範圍的估算。藉助於類似項目提供的數據，管理者可以準確地給出完成工作和交付完成工作產品所需的工作量。他們從一開始就全面瞭解項目的各項功能，並相應地分配資源。
當項目處於初始規劃階段和推進階段時，自上而下的估算工具有助於確立切合實際的項目邊界。如下圖所示，一位項目經理具有一個由 10 位開發人員組成的團隊，團隊正在進行一個為期五個月的發佈週期。在整個工作過程中，模擬軟件顯示了細化的 Backlog，其中給出了需要完成的約 100 個 Story 點。
進一步分析表明，儘管項目經理對團隊生產力和勞動力成本的初步估計是有效的，但他可能無法將新的功能添加到建議的時間表中。由於計劃是固定的，為了滿足利益相關者的期望，項目經理需要聚集於如何調整產品功能和能力。團隊可以使用模擬軟件衡量實現所有 100 個 Story 點的概率。也許實現 80 個 Story 更現實，也許可以實現 70 個 Story。無論實現的 Story 數量多少，至少這是利益相關者可以預期的。
其中並不存在任何主觀猜測，一切估算都是基於經過驗證的數據點。因此，自頂向下的估算方法可比傳統的估算方法給出更準確的估算。團隊可以設定準確的期望，在難以管理的時間期限內達到客戶滿意，降低開發團隊交付解決方案的壓力。
4 事項二：不應因為最後期限迫近，而做出增加員工的決策。
“廚子過多，反而做不出好的肉湯”，這是另一件人們常說的事情。然而，在面對日漸積壓的最後期限時，許多項目經理的第一反應是為項目配備更多的人員。他們秉持的理念是，做事的人越多，事情完成得越快。
當然，這種做法幾乎不會很好地發揮作用。為項目添加更多的資源，通常提高了項目的複雜性，並增大了出錯的機會。更多的人員會導致溝通的不暢，這可能會增加缺陷，並導致返工。實際上，更多的人員通常會導致項目耗費更多的時間，而非節省時間。
項目經理可以使用自上而下的估算，對投資組合中的適當人員配置和資源需求做可視化展示。估算可在一段特定的時間內按計劃和月份進行細分。他們甚至可以將員工按支出率劃分，並與預算限額做比較，確保員工適合於特定項目，或是匹配組織當前的和未來的容量需求。下圖可視化展示了估算隨時間變化的情況。
5 事項三：不應為計劃所奴役。
事先做好計劃，並不意味著團隊在整個開發過程中都無法改變方向。即便給出了最好的計劃，但是大多數項目在其生命週期中，不可避免地會遇上一些未知因素，或是需要重新確定優先事項。或許管理層會要求添加一些新功能，或許一些團隊成員將被轉到其它更為關鍵的任務上。
不確定性雖然隨時可能出現，但是它可以納入到自上而下的計劃過程中，從而降低其潛在的影響。本文前面給出的項目例子就是一個很好的證明。不確定性在於團隊可能無法達成 100 個 Story 點。在計劃中預先納入這些不確定性，有助於規避項目早期的突發變化。
在整個開發過程中仍然可能存在一些波動，其中的大部分是由於利益相關者的需求的不斷變化所導致的。例如，客戶可能需要一些新的功能，以滿足不斷變化的市場動態。這些需求將不可避免地對開發產生直接的影響。團隊需要在儘可能維持最初共識的情況下，做好調整的準備。
不幸的是，當前進的道路上蹦出這些意外障礙物時，許多組織不知道如何做出調整。估算是易於上下微調的（因此稱之為“估算”），並且可以通過重新預測去適應不斷變化的需求和動態。優先事項也是可以完全改變或移除的，以適應新的工作需求。項目範圍也可以做改進，為利益相關者提供切實可用的更新後時間表，使項目保持正常進度。調整是一個動態的過程，可與組織推動敏捷開發的過程緊密結合。
做任何事情都一樣，溝通在整個調整過程中至關重要。顯示在屏幕上的數字在利益相關者的眼裡無疑是福音，即使這些數字在開發過程中會發生波動。項目經理必須能夠在項目一開始就有效地讓利益相關者明白，他們的開發估算可能會根據許多因素而發生變化（具有諷刺意味的是，大部分因素都是由利益相關者的需求驅動的）。
此外，項目經理還必須表明，估算是在給定時間點（即項目開始時）對項目範圍的一個最佳表示。團隊將會努力按時、按預算，最重要的是按預期設計，交付所需的功能。
最後一點，也是最重要的，是我們應從以往的錯誤中吸取教訓。這並非僅是將當前的項目與過去的一些努力做比較，而是應從柯達以及其它一些採取了錯誤步驟的組織中學習。一開始就做好計劃，而不是遵循傳統規範。這樣，項目經理和開發團隊才更有可能在不破壞時間表或超出預算的情況下，以客戶期望的質量交付滿足客戶價值的軟件。
英文原文：
https://www.infoq.com/articles/not-skip-estimation-planning
閱讀更多 InfoQ 的文章
