「不要再管什么需求了，時光有限，今天就開端建系統(tǒng)了！」這句話很熟習(xí)吧？沒錯，許多從事軟件開發(fā)的人大略都曾聽過或講過這句話。因?yàn)檐浖�開發(fā)的時間老是很緊急，既然都已經(jīng)有人跟客戶談定了,呼叫中心管理，若不趕快動工，怎來得及？

是的，所有莫如「趕緊敲定,客戶信息管理系統(tǒng)，趕緊開端，趕快交差，最后 趕快收錢」來得主要，所以許多軟件開發(fā)團(tuán)隊(duì)在派出名目經(jīng)理或業(yè)務(wù)經(jīng)理去「搞定」客戶需求之后，大伙兒就立即一頭栽入全部開發(fā)流程，你剖析、我撰寫、他測試,企業(yè)內(nèi)部管理，世人忙得不可開交，只求工作如期實(shí)現(xiàn)，大家就可以開慶功宴了。

遺憾的是，實(shí)在世界的狀態(tài)不是如斯。所以常會看到慶功宴開不成，反倒以奮斗大會代之，大家交相責(zé)備，而其中又以名目經(jīng)理或業(yè)務(wù)經(jīng)理成為世人鎖定的目的，因?yàn)榇蠹乙恢侣裨梗骸妇褪悄銈兏悴磺宄�客戶需求，才讓大家白忙一場！�?/p>

「搞明白客戶需要」說起來輕易，實(shí)際上卻不輕松，否則奮斗大會的召開頻率也不會那么高。

需求很重要，起因除了確保慶功宴得以舉行，另外還有一個重要因素，就是避免本錢忽然失控、導(dǎo)致案子失敗。依據(jù)統(tǒng)計(jì)，同樣一個問題，當(dāng)它產(chǎn)生在最前面階段與最后面階段時，須要投入的解決本錢的均勻比例是 1 比 200 。需求通常呈現(xiàn)在流程前期，因此這恰是要器重「需求管理」的起因。

需要如何治理？

很多人以為，需求不外就是「客戶講的話」；不外，在 rup （ rational unified process ）功課準(zhǔn)則里，需求的定義是：「一個系統(tǒng)必須遵守的條件或才能；而這些條件或才能可以來自使用者需求，或合約標(biāo)準(zhǔn)中的文字陳述，或其它經(jīng)確認(rèn)的正式文件」。另外， rup 對需求管理的定義是：「導(dǎo)引、文件化、組織及追蹤需求變動的系統(tǒng)化進(jìn)程」。

特殊賦予定義是為了讓「雙方完全肯定與完整控制」「客戶講的話」。

此外，需求可能來自客戶端不同層級與不同職員，自己開發(fā)團(tuán)隊(duì)里的成員也有可能分辨幫助處置，因而必須斷定所有人對需求的「認(rèn)知」都雷同。另外，為了防止「令出多門」，必須特殊厘清客戶需求的真正決議者 —stakeholder （舉動主體）。

再來談?wù)勈裁床攀恰刚�確」的需求陳述。

在 rup 里，需求陳說必須滿意以下前提：明白（ verifiable ）、能夠排定主要性先后次序（ ranked for importance and stability ）、可訂正（ modifiable ）、可追蹤（ traceable ），以及能夠被懂得的（ understandable ）。此外，對任何一條需求陳說而言，它還必需是準(zhǔn)確（ correct ）、完全（ complete ）、一致（ consistent ）且清晰的（ unambiguous ）。

列出這么多前提，并不是要把需求搞得很龐雜，相反地，是為了讓需求「明白、簡略、而且可以被完整懂得與測驗(yàn)」。

舉例來說，我經(jīng)常聽到客戶請求：「系統(tǒng)必須很穩(wěn)固才行」，但假如直接將此付諸文字可就麻煩了，由于該如何界定「穩(wěn)固」呢？所以這個需求陳述是過錯的。正確的作法可以是這樣：與客戶進(jìn)一步溝通后，寫成「體系必須可以知足一千個應(yīng)用者同時上線；當(dāng)應(yīng)用者提交一個請求時，系統(tǒng)送出回復(fù)的時光必須小于五百微秒；體系必須可以實(shí)用于持續(xù)七天與天天二十四小時的運(yùn)作環(huán)境」。由于這些陳述都很清晰，也可以被檢修。事實(shí)上，這個進(jìn)程就是一種需求治理的實(shí)際，因?yàn)闇?zhǔn)確的需求被「導(dǎo)引」出來，并訴諸「正式文件」。

陳述這些需求管理的原則與作法的目的是：「在既定的預(yù)算與時間內(nèi)，交出吻合客戶真正需求的優(yōu)秀產(chǎn)品」,呼叫中心系統(tǒng)。只有到達(dá)這個目的，項(xiàng)目就百分之百成功了。

固然這個目標(biāo)簡略又明了，真正能達(dá)成的卻未幾；最常產(chǎn)生的狀況就是預(yù)算或時間意外失控，導(dǎo)致預(yù)算膨脹、交貨延遲，甚至整個案子胎逝世腹中。要避免以上的狀態(tài)，有兩點(diǎn)原則值得特別留神。

準(zhǔn)則一：剛好就 ok

客戶很精明，都在尋求「預(yù)算與時間最小化，需求最大化」的高尚目標(biāo)，但假如開發(fā)團(tuán)隊(duì)基本無奈滿意這種需求組合時，該怎么辦？

第一種取舍是委曲本人做出許諾，再回公司拼命壓迫開發(fā)團(tuán)隊(duì)，成果往往是交出一個不堪入目標(biāo)產(chǎn)品，從此跟客戶說拜拜。第二種抉擇是老實(shí)面對本人與客戶,SFA，而后與客戶探討如何對需求進(jìn)行公道的切割篩選，事實(shí)上，這也是很多人與客戶溝通時常常面臨的問題。

大家都曉得需求要切割，但如何切割就是學(xué)識了。因?yàn)楸仨毞浅Ｇ宄�客戶的�?shí)際需求，要將需求的重要性排列次序，也要曉得如作甚眾多需求進(jìn)行正確的排列組合，讓他們成為一套可以被客戶接收的計(jì)劃，而且又滿意「在既定的估算與時間內(nèi)，交出契合客戶真正需求的優(yōu)良產(chǎn)品」的原則，甚至還能為后續(xù)開發(fā)進(jìn)行排程組合。事實(shí)上，這個過程就是 rup 需求管理的精華之一，此外，也可以透過合適工具，更容易地把握、追蹤與進(jìn)行全部需求管理過程。

準(zhǔn)則二：小而美

依據(jù) standish group 在 1999 年統(tǒng)計(jì)，一個項(xiàng)目的成功率與它的規(guī)模大小有親密的反向關(guān)聯(lián)，勝利比例會跟著規(guī)模增添而遞減。例如，當(dāng)項(xiàng)目的規(guī)模小于七十五萬美金時，均勻成功率大概是 55 ％；當(dāng)項(xiàng)目規(guī)模增長到六百萬美元至一千萬美元之間時，成功率剩下不到 10 ％，若項(xiàng)目規(guī)模大于一千萬美元，成功率就變成「零」。

這種項(xiàng)目范圍與勝利率的逆向關(guān)聯(lián)實(shí)在很輕易理解，因?yàn)轫?xiàng)目越大，需求就越多，必須組成更宏大的開發(fā)團(tuán)隊(duì)，進(jìn)行更多的溝通與互動，管理睬更為龐雜。對軟件開發(fā)而言，范圍是很重要的，因而野心不要太大，細(xì)水可以長流。

容我再反復(fù)一次：需求管理的目的就是「在既定的估算與時間內(nèi)，交出合乎客戶真正需求的優(yōu)良產(chǎn)品」 不下降品質(zhì)，也未幾生枝節(jié)，剛恰好就好。