1.1 重新審視項目成功的標準

在預算范圍內，按期向客戶提交需求范圍要求的產品是長期以來IT企業判定項目成功以否的標準。這個著名的項目管理鐵三角（需求范圍、成本、進度）直到今天仍定義著大部分軟件項目的實施目標。多年來我一直覺得這個鐵三角有一個致命問題：它們到底是項目追求的終極目標，還是項目實施的約束條件？項目的價值似乎沒有在這3個度量指標中明確體現。

我看到很多項目為實現不合理的進度目標辛苦努力，其他很多重要的東西被忽略，特別是沒有關注項目要獲取的價值，似乎價值這個東西隨著進度目標的完成自然就會實現。也有些項目沉迷于具體的需求項，而看不見這些需求項到底給用戶帶來什么價值。一個令軟件業同行不得不面對的事實是超過50%的軟件產品功能基本沒有被用戶使用過，換句話說，對軟件項目團隊辛辛苦苦實現的一半以上的功能，客戶并無興趣使用，它們沒有給用戶帶來什么價值。這就應了一句老話：每條需求都有成本，但并不是每條需求都有價值。推想一下，又有多少沒有完成的項目，因為追求一些沒有價值的需求，導致了過多延期和預算超支，使得企業只能放棄它們。

1.1.1 傳統的三要素不一定能客觀度量項目的成功與否

圖1-1定義了傳統項目管理鐵三角：需求范圍（特性、功能）、成本（資源、預算）和進度（時間）。成功的項目應該依據客戶需求（范圍），在不超出預算的前提下，按時提交項目。

“傳統鐵三角”定義的項目成功三要素有兩個重要隱含假設。

項目定義的需求范圍真正反映了客戶的真實需要，通過使用這些需求功能，用戶可以實現其價值目標。

項目計劃是正確的，實際和計劃不符意味著錯誤。

在這兩個假設下，和計劃不符的都會被視為問題，項目管理工作就是消滅計劃的偏差。讓我們認真思考一下上面的假設，它真的總是正確嗎？按時完成，沒有超出預算提交了需求范圍的功能，一定就意味著項目是成功的嗎？如果這3個目標沒有實現，項目就一定是個失敗的項目嗎？

請你回顧一下以前你們公司發布的產品，在這3個目標方面都做得好的產品中，有多少賣得好，為公司帶來了價值？有多少用戶并不買賬，產品并未對擴大市場占有率有任何正面貢獻？而在沒有按時完成，沒有實現所有項目計劃階段定的需求范圍，預算有超出的項目中，有沒有賣得好、客戶喜歡的產品？這其中有沒有為公司帶來新的機會的項目？

我們看幾個例子。如果微軟的Vista符合這3個要求，你能認為這是個成功的項目嗎？如果你用過這個系統的話，相信你的體驗不會很好。另一方面，你很有可能沒有機會用過這個系統，因為它的市場壽命很短，Windows 7很快就替代了它。多年前，我開始為一家國際知名企業內部IT部門做過程改進的咨詢工作。作為診斷工作的一部分，我列席了內部IT部門的年終管理會議。這個由公司CIO主持的會議只有一個議題：如何向董事會展示IT部門一年的貢獻。度量內部IT部門的貢獻要稍微復雜一些，因為這個部門不掙錢、只花錢。讓我吃驚的是，超過30%項目由于完成后無人用，很快就停止維護了。這些項目就算是按時完成、不超出預算又有什么意義呢？我看到完成的項目中包含了不少重復實現的功能，這些功能的成本又該怎么算呢？雖然在這次會議上，他們做了一個看起來還是不錯的部門年度貢獻列表（其中包括所有項目）, CIO不久以后還是不自愿地離開了這家公司。

《泰坦尼克號》是一部國內觀眾熟悉的電影。也許有些內幕你可能不太清楚，它的預算嚴重超支（整個電影的制作費用超過2億美元），進度一再延期，劇情有無數的變化調整。如果按傳統三要素來度量的話，這絕對是個非常失敗的項目。但面對全球20億美元左右的票房，導演和演員地位火箭式的躥升，你能說這是一個失敗的電影項目嗎？

“傳統鐵三角”的致命問題是前面的兩個假設。因為對一個軟件項目來說，一開始我們往往不完全清楚用戶真正的需求，產品需求的理解有個逐步演化的過程。哪怕在項目結束時，很可能我們還不能完全確定實現用戶價值的需求集合，這也是產品需要不斷升級的原因之一。

另一方面我們如何看項目初期制訂的計劃呢？我們能假設它的正確性嗎？幾乎無一例外，答案是否定的。在做計劃時，你要面對很多不確定的東西，如需求范圍、實施技術、團隊能力、外在制約等。雖然你參考了組織提供的團隊效率數據，但考慮到影響效率的各種因素及具體團隊的特殊性，估算出的進度計劃的準確性是讓人質疑的。更讓人頭疼的是，在開發過程中，很多影響項目進度的因子（如需求、人員、環境等）會發生變化。把符合一個不靠譜的計劃作為項目的主要目標之一，恐怕不是一件很明智的事。

明確成功項目的標準意義十分重要，它是軟件開發方法的綱。借用一句老話，“綱舉目張”，這是理解敏捷方法的一個很好的切入點。在本章里，我們一起重新審視項目成功要素，對舊的項目管理鐵三角做必要的修正。

1.1.2 新的項目管理鐵三角

那么究竟什么應該是衡量項目成功的終極標準呢？我們在前面已經提到了它——價值。

Jim Highsmith（2011）提出了敏捷鐵三角的概念，他提出了3個新目標。

價值目標：開發出可發布的產品。

質量目標：開發出可靠、易更改的產品。

約束目標：在特定的約束條件下實現價值目標和質量目標。

我十分認同敏捷鐵三角的核心理念，這和我多年在咨詢、教學中推薦的原則高度一致。對其略做修改，圖1-2顯示了新的項目管理鐵三角。考慮到不同的軟件企業的差異性（例如，并不是每個軟件企業都是在開發產品）這里有必要對3個目標做深入說明。

1．價值+能力目標

將項目的價值最大化是項目管理的主導因素，不同類型的項目追求的價值目標會有差異。其度量指標可能是：

銷售額及市場占有率的增加；

公司品牌及競爭力的提升；

客戶忠誠度的提升；

技術創新帶來的新機會。

不同類型的項目會有不同的價值目標，但它們有一個共同點，就是項目價值是站在組織而不是項目的角度來看的。

另一方面，在考核項目時不能忽略人的能力的提升。這也應該是一個項目后評價中的重要指標。在項目結束后，軟件工程師設計、開發、測試各環節的能力是否得到了提升？需求架構人員是否對產品的價值、合理的架構有了更好的理解？管理人員對團隊能力是否更加了解？客戶或用戶是否對后續產品方向更加清晰？過程人員，如質量保證（quality assurance, QA）人員，是否對過程的適用及執行難處有了更好的認識？對于許多軟件應用服務開發商來講，人會是企業的最重要財富，人的能力成長對公司的發展至關重要。

2．質量目標

我們不應忽視敏捷對質量管理的貢獻，它從實踐上強調質量不僅是清除缺陷，不僅是功能正確。它提出了技術債務（technical debt）的概念，將其作為后期軟件維護隱患的指標，并作為迭代開發的重要質量評估項。敏捷領軍人物也提出了許多經過驗證的有效實踐來管理技術債務，所以敏捷質量目標不僅是可發布（功能正確），同時也是可維護的！

3．約束目標

約束目標主要是進度和成本，約束不應該是目標，它是前提。例如，剛性的進度要求，應該理解成在按期交付的前提下，團隊將盡可能實現最大的價值。

我對新的項目管理鐵三角的解讀是：在特定約束條件下，控制產品遺留隱患對交付產品的使用及維護的影響，關注人員能力提升，盡可能將項目/產品價值最大化。

舊的項目管理鐵三角有時會讓團隊追求錯誤的目標，如片面追求按時交付，而忽略了是否交付了客戶需要的產品。Donald Reinertsen（1997）指出很少有人考慮延期成本，他認為這是個非常重要的度量項，每個組織都應該考慮。在某一特定時間提交產品固然很重要，但提交的產品是可以發布的，也就是說它已經實現的功能特性對客戶和用戶是有價值的，這一點應該是更重要的。顧名思義，延期成本度量的是產品不能按期提交的代價。如果它小于通過延時實現的功能帶來的價值的話，項目延期應該是順理成章的事。如果延時帶來的后果是組織不能承受的，在規定時間發布一個新的版本就是必須要做到的事了。當然在這種情況下，需求范圍往往是可調整的變量了。

至于將需求范圍作為項目的主導目標就更不合適，項目前期用戶很難對需求有全面、充分的理解。如果項目開發周期較長，用戶的想法在開發期間發生變化也是一件很正常的事情。在美國IT行業有個說法：有生就有死，工作就要交稅；做軟件，需求一定會變。

如何衡量項目價值呢？應該看它對自身企業的貢獻、對客戶的貢獻，以及對開發的產品用戶的貢獻。如何度量價值不是件容易的事，我們可以從這幾個方面來考慮：產品的銷售額、對品牌及競爭力的影響、對客戶忠誠度的影響、通過創新給企業帶來的新的機會等。實現價值目標一定意味著你發布了一版為客戶解決問題、實現了用戶一定需求的軟件產品。價值必須是項目管理的主導因素，如果值得，為什么不能延時提交？如果不會增加價值，一分錢也不應該投入。

IT業對人的要求比制造業高得多。學校教的東西和業界需要的技能有很大的差距，這個問題估計在相當長時間不可能解決。同時IT技術的生命周期比其他行業更短。持續更新提升軟件管理人員、工程人員的能力是每一個IT企業面臨的挑戰。對一個軟件人員來講，在工作中學習是最主要的能力提升方式。每個項目結束后，相關人員能力的提升也應該是考核一個項目的指標：開發人員的編程能力、工具使用能力是否有提升？設計人員的設計能力是否有提升？管理人員對自身團隊的能力是否更清晰？對項目的風險點是否更加清楚？產品經理、客戶、用戶代表對產品的理解是否更清晰？關注團隊能力的提升是每一個管理者的責任，而每一個軟件工程師都有學習提高的義務。項目相關人員能力的提升應該是項目評價的因子之一，它也應該是項目價值的考慮因素之一。

新的項目管理鐵三角的質量目標明確了更高的軟件質量要求。僅僅將通過驗收測試作為目標的話是不能接受的。質量更應該關注的是項目遺留的技術隱患對客戶使用和后期維護的負面影響。如果開發團隊為追求速度，走了很多捷徑，由此植入的隱患有時是不能通過測試發現的。但隨著代碼的增長，這些隱患會對產品的使用特別是維護有很大的負面影響。有時借一些技術債是必需的，但這些債是需要及時償還的，不然它們會嚴重損害產品的價值。在產品開發過程中有效管理這些技術債務，應該是團隊的一個重要責任。技術債務也可以是一個變量，可接受的債務多少和項目的質量目標應該是一致的。

需求范圍、成本和進度要求可以作為項目約束條件，項目的實施一定是在一個鳥籠子里面進行的，我們需要逐步了解這個籠子的空間、自由度。一般來講約束條件可以有3個度的度量：剛性、部分靈活、靈活。剛性就是絕對的約束條件，部分靈活意味著有一定的自由度，而靈活則表示更大的自由度。把握了解這個鳥籠子的自用空間是項目管理的一個關鍵活動。

新的項目管理鐵三角要求我們用投資回報分析（return on investment, ROI）作為管理者的決策方式。如果追加了投入，回報是什么？回報大于投入嗎？如果延時，延期成本是什么？追加時間完成的工作價值大于延期成本嗎？追求價值最大化應該是每一個項目的管理目標，也是所有重要決策的依據。在整個開發過程中，管理決策都應該圍繞著價值目標的實現來進行。

從簡單常識來講，價值驅動不光應該是企業層面和部門層面的決策方式，也應該是項目層面決策方式。所有的管理者應該習慣這種管理思路：不論項目中需要做什么大小決策，都應該做投資回報分析，可是傳統開發模式常常不能有效支持價值驅動管理模式。

1.1.3 敏捷讓我們實現價值驅動管理

實現價值驅動管理不是一件容易的事，我們通過下面這個簡單的例子來說明其難度。

收視率是每部電視劇追求的目標。高收視率對投資人意味著高額廣告費，對導演意味著在影視圈中的地位，對演員意味著職業生涯的飛躍。所以電視劇在制作過程中，每個重要的決策都是價值（收視率）驅動的，如劇情、演員的選擇、布景等。

每個電視劇的預算都不完全一樣，這應該是最大的約束條件。如果預算的限制使得導演不能請到他認為合適的演員，而導演認為請到合適的演員是成敗的關鍵因素之一，那么是否追加預算請出導演心儀的演員，制片人必須做個對收視率的影響分析。如果被考慮的演員有幾千萬的粉絲，請到他就是收視率的保障，只要追加的預算不是很離譜，相信預算會被調高。如果制片人選的演員和導演喜歡的演員對收視率的影響沒有明顯的差別，而換演員的代價超過數千萬，估計預算追加的可能性會很小。

在前期規劃階段，劇組會估算出電視劇的大概播出時間。如果在制作后期，劇組發現某些劇情有明顯不合理的地方，而如果重拍將導致播出時間的延遲，相信大部分制片人會通過延期成本分析做出決定。如果重拍投入不大，延時幾個月不會對收視率有很大的影響，延時重拍就是順理成章的事。但如果制片人了解到有一個類似題材的電視劇也在拍攝中，很快要殺青。如果電視劇播出時間落在它的后面，收視率就會受很大影響，這時延期成本會大于重拍帶來的效益，重拍就不是一個好的選擇。

什么劇情能打動觀眾？什么樣的演員能塑造出深入人心的角色？在電視劇播放之前，誰也沒有完全的把握，誰也無法準確預測能夠達到的收視率，這是應用新的項目管理鐵三角（價值驅動管理）面臨的最大挑戰。中國電視劇制作模式就不能有效地支持這種管理模式，一部80集的電視集，要全部拍完開始播放后，才會第一次得到大眾的反饋。那時的反饋已經太晚了，因為錢已經都花出去了。2013年年初推出的《楚漢傳奇》是一部80集的電視劇，制作成本接近2.5億元人民幣，號稱有史以來最昂貴的電視劇。它的導演演員陣容都是國內一流的，請來了國內最好的男演員（我個人認為陳道明是國內最好的男演員），制作團隊也是一流的。但是播出后，收視率大大低于期望，遠遠沒有實現預期的價值。

美國電視劇的制作模式就能夠有效支持價值驅動管理。一部幾百集的電視劇，是一集一集地拍，一集一集地播。他們電視劇的播放是每周在固定時間播放一集，第二天就能看到收視率的數據。如果電視劇播出后，收視率達到或超過預期，那么投資人會繼續投資下去。如果收視率沒有達到目標，制片人有兩個選擇：一是分析原因，在拍下一集時做出調整，等下周播放時再看調整是否有效果；二是取消這個電視劇的制作，有時放棄很可能是最好的選擇。不做任何變動不是一個可選項。哪怕我們選了個錯誤題材，損失還是很有限（也就是幾集的成本）。

國產電視劇模式就類似于以瀑布模式為代表的傳統軟件開發模式，它要求我們“先知后行”。需要有明確的計劃，只有整個電視劇殺青后，才會第一次收集到觀眾的反饋及收視率的數據。很明顯，這種模式是很難支持價值驅動的管理模式的。因為在實際場景下，價值的判斷是需要用戶的使用反饋的。

而美國電視劇模式則是“知行合一”的方式，這也是本書討論的敏捷開發模式。它能通過不斷收集反饋，支持價值驅動管理的開發模式，這個例子也告訴我們知行合一的敏捷模式能夠有效支持新的項目管理鐵三角的實施。