二、需求的變化類型

對于需求是否明確，往往需要開發者和需求方反復溝通，有很多時候還需要把程序做出來，然后在使用的過程中反復修改，才能一步步逼近真正的需求真相。做過行業軟件的程序員都知道，真正的產品和展現給用戶的第一版產品，往往是相去甚遠的。大部分非軟件行業的客戶，對于計算機的“死板”邏輯，以及軟件的工作方式，幾乎是一無所知的，因此想讓他們在紙面上描述出一個程序模樣幾乎是不可能的。

開發團隊往往需要根據自己的猜想（很多時候是幻想）來構造第一個版本的系統，因為開發團隊也不具備行業知識，所以做出來的系統和客戶的需求之間常常有巨大的差距。然而雙方溝通需求的唯一媒介，就是這個看起來一無是處的軟件。在經過不斷地、天翻地覆地修改之后，軟件才慢慢接近需求的彼岸。而在這個過程中，開發團隊付出的巨大工作量，在最終版本的軟件上卻是看不見的。有很多運氣不佳的團隊，甚至在開發的路上就倒下了。因此說，客戶的需求變化，就是開發團隊的直接殺手。

[例子] 2004年，我經歷了一個項目，是一個著名私人醫院關于短信平臺的項目。因為是招標的項目，所以我們團隊制作了標書，在上面列滿各種功能點。最后我們順利中標，但是在經歷了無數個在機房打地鋪的通宵鏖戰后，我們發現這個項目中所需要完成的功能，實際上并不是甲方非常在意的功能，他們需要的僅僅是一個用戶注冊和廣告發送的平臺而已。雖然我們基于對合同的履行，把承諾的每一項功能都完美地做出來了，但是甲方在驗收的時候卻把這些輕輕放過，而是對那個并未納入標書、只是其初步試用系統后口頭上提出的需求最看重。我們加班加點地在驗收日到達前，趕完了這個粗糙的需求。雖然這個項目本身不至于失敗，但是客戶因為這個需求實現得不滿意，最后中止合同。

[例子] 2009年，N公司有一個網絡社區，在經過兩年多的開發后，終于上線了。然而在上線的當天，就發生了運營事故。某個運維的配置錯誤導致了服務器死機。而在后續的三個月之內，幾乎每天都有運維事故或者是在線發現重大BUG。整個團隊不斷救火，然后因為救火而引入新的BUG，然后因為BUG要補償玩家而加入新的臨時功能和操作，這些操作又引發了新一輪的運維事故。另外，產品在上線之后，各種管理指令、客服后臺、營銷活動、部署發布、壓力測試甚至還有老板的個人特殊賬號等需求紛至沓來，開發團隊一方面要應付在線的需求，另外一方面還要繼續開發內容。在上線的產品發揮了“溝通”的媒介作用之后，各種需求開始爆發。最后這個產品就在不斷的“還債”開發中失敗了，玩家因為覺得游戲內容更新太慢而紛紛離開。

第二個關于需求的溝通是否通暢的問題，在需求方和開發方兩面來看，似乎還不是非常之復雜。但是如果你深入到開發的過程中，就會發現，需求方本身對此也并不太清晰，軟件項目除了真正的使用者以外，市場部人員希望產品能有方便推廣的賣點，銷售人員時常也會提出能分渠道統計銷售業績的功能，售后人員則是希望有coredump等故障現場保留，老板則喜歡產品能體現公司的品牌風格……為了實現這些五花八門的需求，開發不再是僅僅靠程序員就能完成的了，而需要額外加入美術、策劃、測試甚至音樂制作人員，一件事情需要溝通的環節呈幾何級數上升，工作中的出錯和延誤機會也就因此暴漲。

[例子]M公司是一家創業公司，一群熱愛游戲的成員一起著手開發夢想中的游戲。但是很快他們就發現項目陷入了泥潭，技術人員往往都是在等美術人員的圖像文件，然而等來的卻是技術無法直接使用；因為那些圖片要么容量過大、精度過高，要么就是隱藏在一大堆文件名不知所云的文件包之中。而美術人員則經常抱怨策劃總是改他們做好的圖，而且角色和場景的比例這些重要的設定全部沒有，都要等畫出來之后再看，因而大大延誤了時間。策劃除了受美術抱怨以外，還要每天聽技術人員說配置的游戲數據表出錯了，有時一個簡單的格式錯誤就要花策劃一整天的時間去找。在版本發布之后，客服和市場部的抱怨也爆發了，因為他們根本不知道游戲里修改內容的細節，很多玩家的咨詢讓客服無法回答，而市場部則錯過了很多可以用來推廣的游戲內容。公司的老板則好像一個測試人員一樣，不停地玩自己的游戲，因為這樣他才能知道自己的投資到底變成了什么。這樣，整個公司團隊都在一種郁悶的環境中工作，最后導致產品的開發進度越來越慢。

第三個關于開發者自身的需求，往往是被忽視的部分。人們通常都會說這些技術人員都很清高或者固執。但是無可否認，軟件依然是現實世界中唯一一種僅僅靠思想就能“制造”出的工程產品。開發人員的思想，會直接地影響著這個產品。在很多項目組中，開發人員會因為不允許按照自己的方式開發產品而選擇辭職，這直接導致了大量產品開發項目的擱淺。開發人員對于需求的理解，直接形成了產品，他們的工作重點，會不斷地受到開發過程的影響，這些影響也可以視為一種需求變化。為了應對這種變化，開發人員會增加許多額外的工作量。最典型的例子就是，一款正在向某目標開發的軟件，會因為第二天需要迎接某個風險投資人的評估，而臨時改變開發目標。或者客戶臨時增加了某個重要需求，也會打斷既定的開發過程。這些打斷，必然會引出開發者在某些方面的需求，比如軟件的可插拔性、可擴充性等。

另外，開發者對于開發的過程也有需求，比如使用何種開發工具，在何種環境下開發，使用什么開發方法，采用什么開發架構來實現等，這些都會對軟件提出很多非功能性的需求。這些需求會隨著開發不斷變化，比如有些開發者學會了一種新的技術，就會期望應用到現有的產品中，來解決之前一直困擾他的一些問題。有一個網絡社區的服務端主程序員，就自己利用周末時間，用新發布的Spring框架重寫了整個系統。而某個CMS的開發人員，因為學會了更好地利用數據庫性能，也直接重構了整個系統，并且重寫了存儲部分的代碼。

[例子] 某在線社區產品，是使用Flash ActionScript 2.0語言開發的。但是在其上線僅僅半年之后，Flash就發布了ActionScript 3.0語言，這個新的版本對于Flash技術來說，是一次脫胎換骨的更新，令整個Flash開發都變得更加“專業”，語言本身的成熟度也提升了一個等級，而且新的語言也帶來了新的功能和性能上的顯著提升。于是開發團隊就開始提出要用新的語言來重寫整個產品，因為這個產品本身就是以“新技術”作為特征的產品。最后投資人同意了這個計劃。但是，9個月之后，團隊才完成了基本的重寫工作，因為需要一邊更新內容來留住用戶，一邊加班加點地重寫項目希望能趕上新功能的開發速度。就在這9個月里，競爭對手的產品如雨后春筍般出現，因而這個產品從市場角度上看，失去了9個月的機會窗口。更為嚴重的是，這個過程中巨大的工作壓力，導致幾乎所有參加這個項目的技術人員都辭職了。

[例子]K公司突然收到消息，說3天之后，有一個重要的風投公司將來評估此公司的投資價值。為了彰顯本公司的開發能力，老板決定集中力量盡快仿照當時最流行的《植物大戰僵尸》，做出一款類似的游戲產品。于是整個項目的其他開發都停了下來，最有能力的開發人員搬著電腦到會議室，開始了緊張的開發工作。然而3天過去了，投資的事情并沒有落實下來。整個項目中因為連續高強度地加班3天，有多人生病，需要請假等，這就讓項目本身的進度受到了較大的影響。而這種臨時性的需求，在這個項目的運營過程中發生過不止一次。

以上三種關于需求的討論，最后都指向一個結果，就是增加開發工作量。無怪乎程序員和軟件開發團隊加班是如此常見。

因此，可以總結出來，軟件開發過程中，最核心的矛盾就是——需求變化和開發效率之間的矛盾。