什麼是“成功項目”：談談軟體的價值

    在開始本文之前，我想先講兩個故事——關於軟體項目的故事。

　　故事一

　　有兩個軟體項目（姑且稱之為“項目 A”和“項目 B”），它們在開始時的預算都是 50 個人月，時間是 5 個月。

　　項目 A 在 5 個月後完工，耗費成本 50 人月

　　項目 B 在 6 個月後完工，耗費成本 70 人月

　　在軟體圈子裡摸爬滾打多年的讀者們對這個故事一定有自己的判斷——而且我可以大致猜出是什麼樣的判斷。不過先別著急，我們還有另一個故事。

 

　　故事二

　　有兩個軟體項目（仍然姑且稱之為“項目 A”和“項目 B”），它們在開始時的計劃都是交付 200 項功能。

　　項目 A 在項目結束時一次性交付了最初計劃的 200 項功能，但客戶發現其中大約 30 項功能沒有太大用處，而另外 30 項有用的功能要等到下一個項目才能實現。

　　項目 B 在第一個月結束時交付了第一個版本，此後每兩周交付一個新的版本。在項目進行的過程中，客戶進行了一次業務調整，加入了 90 項新的功能，並擱置了 50 項用處不大的功能。最終該項目交付了 240 項功能。

　　聰明的讀者大概注意到了，前後兩個故事講的是同一回事，同樣的兩個項目。現在我的問題來了：請問哪個項目是更成功的項目？

　　這個問題並不容易回答——實際上它沒有標準答案。站在很多軟體企業的立場上，項目 A 是一個理想的成功項目：按時間、按成本完成預先約定的任務。請注意，我用了“理想的”這個詞，稍後我還會解釋這個有趣的詞，因為實際上的軟體項目往往沒有那麼理想。

　　而如果換一個角度，站在客戶的立場上呢？也許付錢購買軟體的客戶會有一些不同的想法。項目 B 從開始之後一個月便交付了第一個可工作的版本，從那時起客戶就開始使用這個軟體的部分功能，並且不斷地把自己使用的感受反饋給Team Dev。在真實的業務運營過程中，客戶甚至發現了一種新的盈利模式，並進行了一次大規模的業務調整，這次調整的結果也直觀地體現在軟體項目中。雖然項目B的整體交付速率低於項目 A，但它提供的所有功能都是客戶真正需要的，它們為客戶提供實實在在的價值——更不用說，客戶提前好幾個月就開始使用這個軟體。

　　實際上，這是一篇關於軟體價值的文章。和“成功項目”一樣，對於“軟體的價值”，不同的人也會有不同的定義。不過作為付錢購買軟體的客戶，他對於軟體價值的定義是一目瞭然的：他能夠從使用軟體中創造多少價值，軟體能夠為他的業務提供多少價值，這就是軟體的價值。或者說得更簡明一點：

 

　　軟體價值源自使用

　　這正是為什麼很多客戶青睞“項目 B”的原因——我並不打算聲稱所有客戶都有同樣的觀點，稍後我也會舉出反例，但至少支援這一觀點的客戶不在少數。因為他們處在一個殘酷而快速變化的商業環境中：他們的供應商在變化，他們的客戶在變化，他們所處的經濟環境和政策環境也在變化。這一切的變化迫使他們的業務也要隨之變化。更要命的是，今天這個經濟全球化的時代是一個“快魚吃慢魚”的時代，客戶迫切希望新的軟體系統為他們帶來競爭優勢——哪怕這個軟體系統尚未完成，只要能夠投入使用。最後，客戶對於新的軟體系統究竟應該是什麼樣子並沒有百分之百的把握，他們的想法往往要在真正使用軟體之後才會浮現成型。幾方面的因素加在一起，使得這些客戶更願意儘快開始使用軟體、提出反饋、並不斷完善軟體，而不是提出一組需求、然後坐等幾個月之後原封不動地拿到這些功能

 

  　一個真實的案例

　　在 ThoughtWorks 的一個項目中，開發人員們在項目開始之後一個月內就發布了第一個版本——只有一些簡單的資料擷取功能。在發布展示會上，發生了這樣的對話……

 

　　開發人員：這是我們的第一個功能。我們從文字檔、Excel 資料表和遺留資料庫採集資料，現在我們的資料庫中有這些資料……（展示資料庫結構）

    客戶：唔……有意思。要是你能做這樣一個查詢（寫出查詢要求），得到的結果可能會有用。

　　開發人員：可是我們的介面上沒有地方做這樣的查詢操作。

　　客戶：啊，我不需要操作介面，只要每天深夜做一次查詢，把報表發到我的信箱就可以了。

　　開發人員：這樣嗎……另一個問題是，這需要花我們幾天時間。

　　客戶：不要緊，把別的任務往後放幾天好了，我很想看到這份報表。

　　開發人員：那好吧，下周我們就會開始提供這個報表。

　　猜猜結果怎麼樣？一周之後客戶就開始每天接收這份報表，並根據報表內容做一些分析和決策。僅僅幾個月之後，這份報表給客戶帶來的收益就已經超過了整個項目的投資——這時項目其他部分的開發甚至還沒有完成。

　　想想這個客戶會怎麼定義一個“成功的軟體項目”？好吧，也許這個項目超過了預期的時間，也許投入了更多的人力，但這些並不意味著“項目失敗”——只是付出更高的成本。關鍵在於，他投入的這些成本能夠帶來多大的收益，他的投資報酬率是否划算。對於這個客戶而言，如果項目能夠隨時給他提供可用的、能夠創造最大價值的軟體，能夠隨時讓——就像故事中提到的——這種有價值的想法得以實現，這就是一個成功的項目。

　　所以，親愛的讀者，請你忘記本文標題上出現的“敏捷”二字，我們在這裡所說的不是別的，就是一種為客戶創造最大化價值的軟體開發方法。這樣的方法有很多種，但它們有一個共同的特點：儘快、儘可能頻繁地交付可以工作的軟體，讓客戶儘快開始使用軟體，從使用中創造價值、釐清思路、提出反饋。仍然以 ThoughtWorks 的項目為例，這些項目通常在啟動開發階段之後一個月內就會發布第一個版本，隨後每一周或每兩周發布一個新版本——每個版本都是一個可以工作的軟體，每個版本都比前一個版本具有更豐富的功能，並且每個版本都包含客戶認為迄今為止最有價值的那些功能。用軟體開發的“黑話”，“開發下一個版本”的過程叫做“迭代”，這些開發方法最大的共同點就是“迭代式開發”——不是一股腦地交付全部功能，而是每次增加一點、漸進地交付最有價值的功能。

 

　　軟體開發的夢想與真實

　　回到文章開始處的兩個故事。我曾經說過，對於很多軟體企業而言，項目 A 是一個“理想的”成功項目。那麼，是什麼讓情況變得不那麼理想？

　　答案是一個所有軟體開發人員耳熟能詳的詞：需求變更。在真實的項目中，客戶通常不會等到最後一天再照單全收整個項目，因為他知道自己的業務正在發生變化。這時需求變更就出現了，伴隨著來回的扯皮和討價還價。更糟的是，大量的需求變更發生在項目晚期——因為直到這時客戶才真正看到、使用到這個軟體，他的很多想法才真正浮現成型。隨著這種“最後一分鐘的需求變更”，項目超期、超出預算也就成了家常便飯。能夠像項目A這樣完工交付的，實在是鳳毛麟角的幸運兒。

　　為了對付需求變更這個噩夢，軟體開發人員們還發明了另一個詞：變更控制。這個有趣的詞暗示著：需求變更是一種“不好”的東西，是需要“控制”的東西。然而站在客戶的角度上想想，他在親身使用了軟體之後提出的要求，難道不是最有價值的東西嗎？把這種真正創造業務價值的要求“控制”起來，難道是合理的嗎？

    在前面我也暗示過，並非所有的客戶都一定青睞迭代式開發。那麼，哪些軟體項目不一定需要迭代式開發呢？從整篇文章的內容不難看出，如果客戶的業務絕對不會變化，如果客戶的需求巨細靡遺非常明確，如果客戶不需要儘快開始使用軟體以便收回成本，那麼迭代式開發對他的協助就會小得多。不過，如果讀者認真思考的話，這樣的例子也許並不多——也許比你最初認為的要少得多。一個很好的例子是“神州六號”火箭使用的電腦控制系統。還有多少這樣的例子？讀者不妨試著自己想想。

　　如果我足夠幸運的話，也許一些讀者已經被這篇文章吊起了胃口：既然有這麼好的軟體開發方法，既然它能夠為我們創造更大的價值，那還等什麼呢，我們馬上就動手吧。事情不會那麼簡單。為了讓迭代式開發能夠成為現實，為了確保儘快、儘可能頻繁地交付，為了確保每次交付的都是最有價值的功能，我們——包括軟體開發人員、軟體企業和客戶——需要很多的改變。這裡既有職責與權利的劃分，也有開發過程和團隊的重組，還有技術層面的實踐指導。這些正是敏捷方法學所涵蓋的內容。缺少了這些東西，“為客戶創造最大價值”就只能成為一句空話。在後續的文章裡，我們將結合 ThoughtWorks 的實踐經驗，逐步介紹敏捷方法的方方面面。