2.4 計劃為什么失敗

任何事情都可能出錯，而項目計劃最容易成為替罪羊。如果一個人隨意評估，漏掉需求，或者被車撞了，都是由計劃（或者計劃的負責人）來承擔責任。如果國家的電力供給停止10天，或者團隊里最好的程序員得了大病，有人就一定會說，“看吧，我告訴過你計劃不可行。”然后就在計劃制定者面前搖動手指。這雖然不公平，但總在發生。人們厭惡計劃，把它置于一種不可達到的程度。即使是最好的計劃者，擁有了最聰明的頭腦和最有效的工具，所能做的仍然只是試圖預測未來。

但是，如果在開始項目時能注意到那些可能使計劃散架的原因，采取措施使風險最小化，那么計劃則能在開發過程中成為實用精確的工具。

2.4.1 盲目行動

如果計劃是在項目初始時創建的，那么對計劃有影響的決定會有上百個。這就出現了問題，沒有人可以預測出，也不能草率的決定。項目管理人只有很少的信息來作出符合實際的預測，除非需求都已經理解了，高層計劃已經在進行之中了。然而更多時候，一個粗糙的計劃充滿捏造的數字和武斷的想法，這個稻草人披著可靠計劃的外衣被放置在項目中。

通常，人們很容易掉進精確度對正確性的陷阱：一個看起來印象深刻的計劃，擁有詳細的日期和時間（精確度）不一定就接近真實的情況（正確性）。精確很容易，但是正確卻很難。

然而，項目和計劃總是要啟動的。黑夜中的一槍可以給與團隊活力，在適當的位置給與限制。可以先開始一個研究過程來充實計劃，提出并解答一些重要的問題。但是如果未經驗證的糟糕設想被用作了計劃的基礎，而且還沒有進一步的改正，那么離風險就不遠了。用充分的證據顯示，任何人都無法在項目早期估算出項目需要的時間總量。

Barry Boehm 在他1989年的關于關鍵工程的論文中說道，計劃評估在項目中越早，計劃的出錯規模越大（圖 2-3 所示）。如果所有的計劃評估都在項目早期進行，那么它最后可能會向任一方向偏離近400%（雖然沒有數據證明，但我懷疑錯誤會向我們傾斜，我們花的時間要比預期的長）。在設計階段，應為更多的決定都很明晰了，分歧縮小了，但仍然很大。只有項目到了實現階段，項目評估的范圍才能變的合理，但即使這樣，還是離正確的計劃決定有20%的誤差。

圖 2-3 項目中錯誤評估的范圍（取自 Boehm的《軟件工程經濟學》）。

這就意味著項目經理需要明白計劃評估的正確性是隨著時間增長的。計劃要不停的被關注，項目前行就要不停的進行調整。

2.4.2 計劃是一種可能性

當我剛從大學畢業，開始我的第一個大型項目工作（Windows 和 IE）的時候, 高層任務書從比我更牛的人那里到了我的團隊。我因為太年輕，而沒有負責太多的工作。計劃就做一天的，我的任務是把設計任務書分給和我共事的幾個程序員和測試員。

當我們在一起討論設計任務書和我們基于工作項目做出的計劃表的差異時，高層任務書就顯得無處不在。它都是從上至下，排版細致，日期和時間的排列錯落有致，就像項目完成后制作的一樣。

盡管我們都對其不屑一顧，但多數時候，我們還是如實地遵從這些計劃。雖然我們不知道它們是怎么來的，但我們還是很信任我們的領導的，同時我們自己的工作就夠忙的了，哪里有時間去操心這些。（實際上，他們通常都提供了這些計劃書的基本解釋，但是我們太忙或是太信任了，以至于不去關心這些計劃書。）

稍后，當計劃安排成為了我負責的工作時，我認識到了這個關于計劃沒有點明的事實。他們不是來自未來的禮物。也沒有萬能公式和理論能創建出完美的計劃。盡管我經驗不多，但我也能認識到，作計劃并不是一個孤立的工作：它總是表現為或包括了許許多多項目當前或將來的不同方面。計劃僅僅是一種預測。不管計劃被起草的多么精確，多么令人信服，它們都是許多更小的估計的總和，每一個估計都不可避免的傾向于不同方面的，不可預見的疏漏和問題。只有那些在軟件開發的各個方面都嚴格要求并且進行良好判斷的領導和團隊才能做出優質的計劃。你不可能只精通一個很小的領域就期望能把計劃做好。

所以，如果團隊的每個人都同意計劃是一組概率的集合，那么問題就不再是計劃本身的了，就在于計劃怎么被使用上了。假設曾有一份計劃出現在小組會議上，或是用電子郵件群發，如下就是一個很好的問題：定好的期限有多大的可能性？如果沒有提出任何可能性（例如，5個最有可能的風險是什么，以及它們能出現的概率），做計劃的那個人也沒有對他的假設做出解釋，那么就應該假定計劃是可能的，但不是不可行的。計劃應該對項目組開放，得到大家的意見，使相應的事項或信息加入到計劃中，使其更加可行。

訣竅就是計劃不需要十分完美（這是安慰，其實也沒有完美的計劃）。計劃只要足夠好到讓團隊和領導信任就行了，它提供了跟蹤和調整的項目的基礎，使項目有了成功的幾率，讓客戶，業務人員和所有的項目發起人都滿意。

2.4.3 評估并不容易

在設計過程中（在第 5章和第6章講到），設計人員，程序員和測試員都有一部分的工作是將設計分解為可構建的小塊工作。這些小塊的工作通常稱為工作條目或者工作細目分類（7），成為了項目的設計說明書具體條目。這些工作條目（但愿）被合理的分布于項目組，通過總結，計劃就做出來了。每個工作條目都要有由程序員分配的的時間，有了這些評估，計劃就構建好了。
用最簡單的定義，好的工作評估擁有很高的正確度可靠性，而差的工作評估則很低。我不期望這些定義能得什么獎，但是它們至少意味著一點：這是那些定義項目標準的團隊領導人的判斷依據。這就需要一個有效的過程能夠評審估計結果，推動他人，領導他人以及引起他人注意，從而讓這些評估能夠達到所需要的一定程度。我覺得再評估過程中，如果能讓測試和QA團隊也參與進來，就更明智了。讓他們參與到設計討論中，問問題或提供解釋。最少，這樣也可以幫助他們評估自己 的工作，可能這些工作和編程工作的評估并不相關。通常。QA對于那些別人沒有注意到的設計疏漏和潛在的失敗用例有很強的洞察力。

2.4.3 .1 萬物都基于評估
做計劃很困難是因為很少有人喜歡估計他們負責的復雜的事情。平常都是對自己滿懷信心， ("這本書/這部電影/這個網站 太爛了，要是我能做的更好"), 等到了要開始做，或者要在描述自己職責的合同上簽名的時候，情況就變了。我們都知道，今天承諾要做的事情，很可能到時間的時候，根本做不出來，或者就不用作了。這可能比我們想象的還要難。程序員和普通人一樣，也都對估計問題很頭疼。誰要是說事情能夠在確定的時間內完成，就是在冒出錯的風險。
以我的經驗，即使程序員理解相信評估的過程，也不大喜歡去做。部分原因是和想象中的不符（“這么少的信息，怎么做這個工作？”），精度不夠（“告訴我這個 工作實際要做多久。“）。同情在這里要所有限制，從事工程，建筑工作的每個人都面臨著相同的挑戰，不管是蓋摩天大樓，改造廚房或者是發射太空飛船。從這些人怎樣進行評估，就可以看出來他們的挑戰或者技術與網站程序員和軟件工程師面對的沒有本質的區別。最主要的區別就是他們有多少時間來進行評估，以及他們是 怎樣合理利用這些時間的。
（第5章和第6章將會進行詳細論述）。

2.4.4 好的評估來自于好的設計
通過和程序員的共事，我學到的關于評估的最重要的一點就是好的評估來自于可靠的設計和需求。如果具備了以下兩點，優質的工程評估就不是沒有可能：正確的信息和優秀的工程師。如果規格不明確，而且序員被要求從這些無法理解的混亂文檔中變出數字信息 ,那么結果顯而易見，最后得到的一定是不準確的胡亂評估。這意味著好的評估是每個人的責任，是整個團隊的工作。項目經理和設計人員特別要協助工程師進行可靠的評估。如果評估進行的雜亂無章，或者項目負責人都沒有參 與其中，就不要指望能得到可靠的評估結果了。
　　如果項目負責人承認計劃的評估進行的不夠，而且也樂意冒風險，那么這樣的評估也無所謂了。在小型，快速的項目中，粗略的估計可能正是這樣的項目需要的。需求隨時會變，業務和組織的性質可能要求更少的結構性，更多的適應性。低質量的評估沒什么錯，如果沒有人將它們同高質量評估弄混淆的話。
我發現了一個很有用的技巧，無論什么時候，只要程序員不想做評估，我就會問＂我要回答什么樣的問題，才能讓你對做評估更有信心？＂通過使他明確細節，我給了他直面其內心恐懼和挫折感的機會,這樣我就可以幫助他解決問題。當然,我可能要幫忙找出問題的答案,討論一些我認為本應該是其分內的工作，但是最后，我 們將會對怎樣得到更好的評估進行探討。
以下是另外一些保證有效評估的方法：
為評估建立基線可靠區間。 如果只是猜測，那么對正確度只能有40%的信心；擁有好的評估,則有70%；再有詳細全面的分析，則能達到90%。團隊領導需 要對評估的正確性程度達成一致，同時還有做評估的總時間花費和遺漏估計的風險怎樣管理。一個達到90%的評估應該正好差不多才行。如果你決定讓你的團隊提 高評估的質量，你就要給他們相應的時間。
骨干程序員要通過提出有價值的問題，提供完善的解決方案來設立評估質量的標準，這樣可以作為團隊仿效的榜樣。 采取一切必要措施消滅任何作假或倒退動機，（例如，“不要讓我做這個，”“可能吧，”等等。）。找出一切他們交付合格評估所需要的正面因素，并提供合理的時間以保證達到指定的評估質量目標。
要信任程序員。 如果你的腦外科醫生告訴你手術要用5個小時，你會要他3個小時做完嗎？不能吧。有些時候，壓力是用來使人誠實，但也只是作為一種平衡措施（規范的做法應該是程序員對于自己不喜歡的事要做高一些的評估，喜歡的則可以低一些）。有些時候，可以做多重評估（來自兩個開發人員），這樣也是保證全面的控制的一種方法。
評估取決于程序員對項目目標的理解。 評估不僅基于程序員對設計說明文檔（如果它們有的話）的理解，還基于對項目標的理解。在Gerald Weinberg的《計算機編程心理學》這本書中(Dorset House, 1971), ，記錄了高層目標對程序員做的低層設想的直接影響有多么缺乏透明度。可能出現技術難題是顯而易見的，程序員解決它的方法可能會隨著整個項目的高層意圖發生戲劇性的改變。
評估要基于以前的效率。 程序員在整個項目過程中跟蹤評估是很不錯的習慣。這應該是他們和項目經理討論內容的一部分。項目經理應該明白團隊里面每個人都擅長估計那些內容。極限編程使用術語“速率”基于以前的效率情況來表示一個程序員（或項目組）大概的工作效率。
規格和設計都要進行很好的評估以達到工程需要的程度。 這是在項目管理和程序員之間的評判。評估期望的質量越高，規格說明的質量就應該越高。我們將在第7章談論關于好的規格說明的事宜。
使用已知的方法做好評估。 最有名的方法就是PERT(10),它試圖通過平衡高，中，低三種評估來最小化風險。這有兩點好處。第一，它使所有人都意識到評 估只是預測，可能的結果存在一定的范圍。第二，它給項目經理扼殺那些太冒險或者太保守計劃的機會（更多的砝碼可以用在低層或高層評估上）。

2.4.5 常見的疏漏

當好的評估不斷改進計劃的同時，有很多影響計劃的因素是抄近路到達個別工作項的。這就出現了一個陷阱，不管所有的評估多么完美，那些真正的計劃風險是沒有被寫下來的。 在世界大部分地方，減少災難的發生幾率幾乎不可能，但骨干工程師得病，或者去休假的可能性確是很大的。這里有一些項目經理應該熟悉的常見的計劃疏漏。問題是通常你只有在被一個疏漏弄得火燒眉毛后，才會在以后留意它。這就是為什么項目管理特別是計劃管理，需要經驗才能精通。失敗有很多種方式，不對其結果負 責，就沒有辦法進行發現失敗的演練。
以下列表中的問題總是幫助我在早期就能發現計劃中潛在的問題。大多數來自于項目結束后的問題回溯。發現那些別人在項目早期就提出的問題，避免此問題的發生。（什么被錯過了？什么還沒有解決？是什么造成的差別？是什么讓我采取糾正措施的？）
病假和假期是否也采用某種形式包含在計劃中。
是否每個人都要使用計劃，是否要經常匯報工作進度（以某種不煩人的方式）。
是否要有人每周或每星期關注所有計劃。此人是否有足夠的權威來發問及做相應調整。
團隊是否對計劃有擁有權并對計劃負責。如果不是，為什么？團隊是否對計劃的制定和工作的執行有貢獻，或者只是從上面傳達下來。
項目負責人是否增加了新的特性需求而不是幫忙縮減。項目負責人是否總是對新的工作說不，并對團隊提供合理的解釋，怎樣來回應新的（晚到的）需求。
團隊成員是否被鼓勵對那些不符合目標和愿景的新工作說不。
使用什么樣的概率來作評估。90%,70%還是50%。這一點在高層計劃中提到了沒有。客戶知道這一點了嗎？是否為了能得到更高的概率而花更多時間對其他提議進行討論。
計劃中是否有周期性的時刻用來進行調整和重新商議。
在假日季節，計劃時候過少的預計了工作時間。（在美國，感恩節到圣誕節通常是工作效率不高的。）一些嚴重的自然災害是否也要考慮（例如芝加哥的暴風雪，安薩斯的龍卷風，西雅圖的酷暑）？
規格說明和設計計劃對于工程師做好評估工作是否足夠。

工程師是否進行過做工作評估的培訓，或者是否有這方面的經驗。

2.4.6雪球效應
關于上面的列表 ,讓人郁悶的是,即使你全考慮到了,因為對于計劃,每個貢獻都是相互依賴的,所以計劃很容易變動。團隊從設計選擇到評估所作的每個決定，都是以后所有決定的基礎。一個在項目早期出現并后來被解決的疏漏將會對項目有很大的影響。這種計劃的組合行為很容易被低估，因為緣由和結果不是同時出現的 （你可能會在原因發生之后看到影響）。最壞的情況，當許多主要的疏漏發生時，堅持計劃的可能幾乎為零（見圖　2-4）。

圖 2-4　雪球效應

當然，這很難發生。概率的作用形式是一系列獨立時間發生的幾率是每個事件單獨發生概率的乘積（也成為組合概率）。所以，如果你完成這一章的概率是十分之九，完成下一章的概率也是十分之九，那么你完成兩章的全部概率不是 9/10,而是81/100。這就意味著如果你的團隊一周中每天都達到90%的正確性， 隨著時間流逝，計劃變動的幾率在不斷的增加。概率是不講感情的，它提醒我們平均信息量無處不在，并且可不是項目和管理者們的好伙伴。