又到新年了，日歷又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太大往事的回憶。過去的10年，毫無疑問是中國軟件業(yè)發(fā)展最快的10年。當(dāng)我們剛剛畢業(yè)的時候，還在使用VB、PB開發(fā)一些簡單的數(shù)據(jù)庫應(yīng)用，而現(xiàn)在卻幾乎看不到它們的蹤影，換來的是諸如J2EE和.NET這樣的大型web應(yīng)用。而這期間，RUP、XP、敏捷開發(fā)、持續(xù)集成••••••一個接一個的新概念層出不窮，令人眼花繚亂。現(xiàn)在想來，恍如隔世。
但更令我印象深刻而難以忘懷的，是我親自經(jīng)歷的、親眼目睹的、道聽途說的一個又一個的軟件項目，它們有的獲得了成功，但更多的是令人沮喪的失敗。套用一下大文豪托爾斯泰體：幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸；幸福的軟件項目都是一樣的，不幸的軟件項目卻各有各的不幸；或者說，成功的軟件項目都是一樣的，失敗的項目卻各有各的問題。我常常在想，我們的項目開發(fā)到底怎么了，進而把它們一個一個的剝開來深入分析，竟然觸目驚心。它們有的是需求的問題，有的是客戶關(guān)系的問題，還有設(shè)計的問題、技術(shù)的問題、時間管理的問題、人員培養(yǎng)的問題••••••但歸根到底更多的還是需求的問題。需求分析既是一份體力活兒，更是一份技術(shù)活兒，它既是人際交往的藝術(shù)，又是邏輯分析與嚴(yán)密思考的產(chǎn)物。正是我們在需求分析過程存在的巨大隱患，最終導(dǎo)致了那么多項目的失敗。也許你認(rèn)為我在危言聳聽，好吧，我來舉幾個典型事例分析分析吧。
我的第一個故事來自大名鼎鼎的東軟。我在2005年接一個項目的時候，聽說這個項目之前是東軟做的。當(dāng)時東軟在做這個項目的時候，整個過程經(jīng)歷了10多次結(jié)構(gòu)性的大變更，局部性的調(diào)整更是不計其數(shù)。據(jù)說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程序進行修改。之后客戶對修改的內(nèi)容還是不滿意，又不得不將幾百處修改重新改回來。最后這個項目導(dǎo)致的結(jié)果是，整個這個項目組的所有成員都離開了東軟，并似乎從此不愿涉足軟件開發(fā)領(lǐng)域。多么慘痛的教訓(xùn)啊！我常常聽到網(wǎng)友抱怨客戶總是對需求改來改去，但客戶對需求改來改去的真正原因是什么呢？當(dāng)我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，于是就在一點兒一點兒試，于是這種反復(fù)變更就這樣發(fā)生了。如果我們明白了這一點，深入地去理解客戶的業(yè)務(wù)，進而想到客戶的心坎兒上去，最后做出來的東西必然是客戶滿意的。記住，當(dāng)客戶提出業(yè)務(wù)變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業(yè)務(wù)角度深入的去分析，他為什么提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當(dāng)我們提出更加合理的方案時，客戶是樂于接受的，變更也變得可控了。
第二個故事來自我自己的項目，一個早期的項目。在這個項目中，客戶扔給了我們很多他們目前正在使用的統(tǒng)計報表，要我們按照報表的格式做出來。這些報表都是手工報表，許多格式既不規(guī)范，又很難于被計算機實現(xiàn)。這些報表令我耗費了不少鬧細(xì)胞，直到最終項目失敗都沒法完成。這件事留給我的深刻教訓(xùn)是，不能客戶怎么說軟件就怎么做。客戶提出的原始需求往往是不考慮技術(shù)實現(xiàn)，基于非計算機管理的操作模式提出來的。他們提出的很多需求常常比較理想而不切實際，畢竟人家是非技術(shù)的。但我們作為技術(shù)人員，需求分析必須實事求是地、基于技術(shù)可以實現(xiàn)的角度去考慮。那種“有條件要上，沒有條件創(chuàng)造條件”的魯莽行事，結(jié)果必然是悲慘的。所以我們必須要基于技術(shù)實現(xiàn)去引導(dǎo)客戶的需求。同時，計算機信息化管理就是一次改革，對以往手工管理模式的改革。如果我們上了信息化管理系統(tǒng)，采用的管理模式卻依然是過去的手工模式，新系統(tǒng)的優(yōu)勢從何而來呢？因此，我們做需求就應(yīng)當(dāng)首先理解現(xiàn)有的管理模式，然后站在信息化管理的角度去審視他們的管理模式是否合理，最后一步一步地去引導(dǎo)他們按照更加合理的方式去操作與管理。
2007年，我參與了一個集團信息化建設(shè)的項目。這個項目中的客戶是一個龐大的群體，他們分別扮演著各種角色。從機構(gòu)層次劃分，有集團領(lǐng)導(dǎo)、二級機構(gòu)人員、三級機構(gòu)人員；從職能角色劃分，有高層領(lǐng)導(dǎo)、財務(wù)人員、生產(chǎn)管理員、采購人員、銷售人員，等等。在這樣一個復(fù)雜場景中，不同人員對這個項目的需求是各自不同的。非常遺憾的是，我們在進行需求分析的時候沒有認(rèn)真分析清楚所有類型人員的需求。在進行需求調(diào)研的時候，總是集團領(lǐng)導(dǎo)帶領(lǐng)我們到基層單位，然后基層單位將各方面的人員叫來開大會。這樣的大會，各類型的人員七嘴八舌各說各自的需求，還有很多基層人員在大會上因為羞澀根本就沒有提出自己的需求。這樣經(jīng)過數(shù)次開會，需求調(diào)研就草草收場。我們拿著一個不充分的需求分析結(jié)果就開始項目開發(fā)，最終的結(jié)果可想而知。直到項目上線以后，我們才發(fā)現(xiàn)許多更加細(xì)節(jié)的業(yè)務(wù)需求都沒能分析到，系統(tǒng)根本沒法運行，不得不宣告失敗。一個軟件項目的需求調(diào)研首先必須要進行角色分析，然后對不同的角色分別進行調(diào)研。需求調(diào)研的最初需要召開項目動員大會，這是十分必要的。但真正要完成需求分析，應(yīng)該是一個一個的小會，1~3個業(yè)務(wù)專家，只討論某個領(lǐng)域的業(yè)務(wù)需求，并且很多問題都不是能一蹴而就完成的，我們必須與專家建立聯(lián)系，反復(fù)溝通后完成。需求分析必須遵從的是一定的科學(xué)方法，而不是盲目的大上快上。
我的最后一個故事可能典型到幾乎每個人都曾經(jīng)遇到過。我們的項目從需求分析到設(shè)計、開發(fā)、測試都十分順利。但到了項目進行的后期，快到達(dá)最后期限時，我們將我們的開發(fā)成果提交給客戶看，客戶卻對開發(fā)不滿意，提出了一大堆修改，而且這些修改工作量還不小。怎么辦呢？加班、趕工，測試時間被最大限度壓縮。最后項目倒是如期上線了，但大家疲憊不堪，并且上線以后才發(fā)現(xiàn)許多的BUG。需求分析不是一蹴而就的，它應(yīng)當(dāng)貫穿整個開發(fā)周期，不斷的分析確認(rèn)的過程。以上這個事例，如果我們提早將開發(fā)成果給客戶看，提早解決問題，后面的情況就將不再發(fā)生。這就是敏捷開發(fā)倡導(dǎo)的需求反饋。敏捷開發(fā)認(rèn)為，需求分析階段不可能解決所有的需求問題，因此在設(shè)計、開發(fā)、測試，直到最終交付客戶，這整個過程都應(yīng)當(dāng)不停地用開發(fā)的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證項目的成功。
以上的故事各有各自的不幸，各自都在不同的開發(fā)環(huán)節(jié)出現(xiàn)了問題。但經(jīng)過深入的分析，各自的問題最終都?xì)w結(jié)為需求分析出現(xiàn)了問題。為了使我們今后的軟件項目不會重蹈覆轍，似乎真的有必要討論一下我們應(yīng)該怎樣做需求分析。