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

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

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

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

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

需要如何治理？

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

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

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

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

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

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

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

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

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

準則一：剛好就 ok

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

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

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

準則二：小而美

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

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

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