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

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

遺憾的是，實在世界的狀態(tài)不是如斯。所以常會看到慶功宴開不成，反倒以奮斗大會代之，大家交相責備，而其中又以名目經(jīng)理或業(yè)務經(jīng)理成為世人鎖定的目的，因為大家一致埋怨：「就是你們搞不清楚客戶需求，才讓大家白忙一場！」

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

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

需要如何治理？

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

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

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

再來談談什么才是「正確」的需求陳述。

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

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

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

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

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

準則一：剛好就 ok

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

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

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

準則二：小而美

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

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

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