| p; |
|
1 |
|
1 |
|
|
| 需求 |
收益 |
代價 |
價值 |
價值% |
成本 |
成本% |
風險 |
風險% |
優(yōu)先級 |
| <需求> |
<1-9> |
<1-9> |
<> |
<> |
<1-9> |
<> |
<1-9> |
<> |
<> |
其中各權值按實際情況而定，不能確定按1取值。
收益：實現此需求對用戶的益處；
代價：未實現此需求對用戶的損害；
價值=收益*收益權值+代價*代價權值
價值%=價值/（總價值）*100%
成本：實現此需求所需的各種成本；
成本%=成本/（總成本）*100%
風險：實現此需求所承擔的風險，特別是技術上的；
風險%=風險/（總風險）*100%
優(yōu)先級=價值%/（成本%*成本權值+風險%*風險權值）
最后按需求優(yōu)先級排序，優(yōu)先實現高優(yōu)先級的需求。
風險的控制和避免：
對需求將可能面臨的風險要有充分的估計并盡量避免風險的發(fā)生及其所造成的損失。建立風險跟蹤，保持對危害最大的幾項風險的控制，并在開發(fā)過程中周期性地更新風險跟蹤項目。
需求的問題，是一個管理的問題
需求取得：市場銷售部門、技術支持或客戶服務所得到的需求，或者開發(fā)人員內部通過對業(yè)務的分析歸納得出的一些要改進的功能。
對需求進行管理的環(huán)節(jié)應該盡可能精簡。最好直接由系統(tǒng)分析來做。經過很多環(huán)節(jié)的篩選，需求可能已經走樣了。紙面上只有一兩句話的需求，背后有你看不到的真正想法存在。 所以應該主動走出去尋找需求，應該選擇最典型的客戶進行訪問。領會他們的管理思路和改革方向。
需求決策：對于相互矛盾的需求，在同類用戶中由產品代表決策；對于不同類用戶要根據重要性作適當折衷；對于用戶的特別喜好要根據用戶的重要性決定；用戶中領導的需求要服從最終實際使用的用戶需求；當開發(fā)者想象中的產品通常要服從用戶的需求，但并不表示用戶總是對的。
需求分析：分析需求的各個特性，制作出需求分析規(guī)格說明書。
需求評審：由相關人員共同對需求進行評審。
需求變更：如果遇到需求的變更，需要及時作出調整，即使與開發(fā)部門聯(lián)系，提出變更的建議，并分析可能產生的影響，如對產品穩(wěn)定性的影響。變更的需求需要嚴格的測試。
版本控制：確定需求文檔版本，確定單個需求文檔的版本；
需求跟蹤：需求的跟蹤記錄需求的狀態(tài)，包括未定義、放棄、需完善、已定義、實現中、待測試、測試中、完成、放棄實現等
需求管理工具：曾經看到過的工具有Rational Requsite Pro 4.5版。需要用Word 97支持。但對中文的支持不夠好。
筆者對Requsite Pro4.5的功能進行了整理。請在本站點的ROSE工具欄目中尋找該文。
筆者也制作了一個IE版的需求管理工具，使用了ASP/Access2000。特點是和客戶管理聯(lián)系在一起。提供了對需求各屬性的描述，也提供了對每一條需求的討論和跟蹤。這是一個1.0 Beta版的，剛開始使用的東西。
以上標題的結構，有些象一首歌的主題，其實還真有這么一首歌，叫做《三兒的問題》，不想被我改編了一下，遂成為：
需求的問題，是簡單的問題，
需求的問題，是復雜的問題，
需求的問題，是技術的問題，
需求的問題，是管理的問題，
需求的問題，是你們的，我們的，
他們的，大家的問題。
項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
