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