作為開發(fā)人員，您可能認(rèn)為"我沒有時(shí)間進(jìn)行需求管理"，或者"RM 與我毫無關(guān)系"。如果情況正是這樣，那么項(xiàng)目團(tuán)隊(duì)如何定義您正在構(gòu)建的系統(tǒng)功能呢？實(shí)際上，您對(duì)于項(xiàng)目交付的職責(zé)是由某位人員決定并定義的。無論這位人員只是在頭腦中計(jì)劃著這些需求、在紙上草畫出需求、在正式會(huì)議上討論了需求，還是將需求正式記錄在需求文檔中，每個(gè)軟件開發(fā)團(tuán)隊(duì)都要涉及某種形式的需求管理。他們可能并沒有意識(shí)到，因?yàn)樗麄兊?RM 實(shí)踐可能極其不規(guī)范。不管怎樣，所有軟件團(tuán)隊(duì)都要進(jìn)行某種程度的 RM。問題只是您的軟件團(tuán)隊(duì)的 RM 實(shí)踐的規(guī)范化程度如何。
理解開發(fā)人員在 RM 中的重要性，有助于反映 RM 的目的。RM 的目的是在客戶和軟件組之間建立共識(shí)，其內(nèi)容包括查找、文檔化、組織并跟蹤不斷變化的需求。與客戶達(dá)成共識(shí)是計(jì)劃和管理項(xiàng)目的基礎(chǔ)。如果項(xiàng)目團(tuán)隊(duì)不能有效管理需求，那么他們達(dá)到關(guān)鍵里程碑的能力就會(huì)受到損害，進(jìn)而影響項(xiàng)目計(jì)劃的精確度和效用。這通常導(dǎo)致開發(fā)和測試資源被浪費(fèi)在錯(cuò)誤方面。開發(fā)人員在 RM 上扮演了重要角色，不僅因?yàn)樗麄兏鶕?jù)需求構(gòu)建軟件，而且因?yàn)樗麄兡軌蚍乐鬼?xiàng)目團(tuán)隊(duì)一開始就使用不完整或者模糊需求。最大化需求的完整性和清晰度是保證整個(gè)項(xiàng)目成功的轉(zhuǎn)折點(diǎn)，可以確保包括測試人員和文檔編寫人員在內(nèi)的整修團(tuán)隊(duì)能夠在最短的時(shí)間內(nèi)構(gòu)建質(zhì)量合格的系統(tǒng)。
RM 的正式程度因項(xiàng)目和項(xiàng)目團(tuán)隊(duì)而異，并且與您的項(xiàng)目團(tuán)隊(duì)在不能交付正確的軟件解決方案方面愿意冒多大的風(fēng)險(xiǎn)直接相關(guān)。RM 過程的正式程度越差，項(xiàng)目團(tuán)隊(duì)不能向客戶交付令他們滿意的軟件的風(fēng)險(xiǎn)就越大。幸運(yùn)的是，項(xiàng)目中 RM 的松散程度是權(quán)衡 RM 形式的優(yōu)缺點(diǎn)之后所作的一個(gè)簡明的決定。關(guān)于采用松散 RM 過程的最常見的論據(jù)包括：它可以使的開發(fā)速度更快，可以更好地適應(yīng)不斷變化的市場，并且不需要正式的需求文檔來了解我們應(yīng)該創(chuàng)建什么系統(tǒng)。不幸的是，這些論據(jù)是項(xiàng)目團(tuán)隊(duì)很難實(shí)際把握的，并且需要仔細(xì)分析項(xiàng)目成功所需的 RM 正式程度。從根本上說，RM 實(shí)踐應(yīng)該產(chǎn)生：1）所有項(xiàng)目團(tuán)隊(duì)成員都能夠清楚理解的需求，2）對(duì)不斷變化的需求的控制，以保證項(xiàng)目團(tuán)隊(duì)能夠跟蹤正確解決方案的交付，3）有效的溝通，以保證整個(gè)項(xiàng)目團(tuán)隊(duì)協(xié)調(diào)一致。
有時(shí)使用非常正式的 RM 實(shí)踐可能是小題大做。比如，如果您的項(xiàng)目團(tuán)隊(duì)任務(wù)是構(gòu)建一個(gè)視頻游戲，那么擴(kuò)展請(qǐng)求和需求變更就可能頻繁出現(xiàn)，以至于隨后如果使用傳統(tǒng)變更控制過程（需要變更控制委員會(huì)的批準(zhǔn)）實(shí)際上可能妨礙項(xiàng)目成功。這種情況下，變更控制過程實(shí)際上限制了開發(fā)人員的創(chuàng)新，并且成為軟件交付的瓶頸。然而，即使在這種情況下，項(xiàng)目團(tuán)隊(duì)仍可以使用諸如故事板或原型這樣的RM技術(shù)在開發(fā)和交付之前驗(yàn)證游戲創(chuàng)意，并從中獲益。
在另一個(gè)極端上，也有極其需要使用非常正式的 RM 實(shí)踐的時(shí)候。比如，如果項(xiàng)目團(tuán)隊(duì)的任務(wù)是開發(fā)一個(gè)運(yùn)行醫(yī)療設(shè)備的軟件，它能根據(jù)情況自動(dòng)管理病人的精確的、正確的用藥量，那么項(xiàng)目團(tuán)隊(duì)就應(yīng)該采用高度正式的 RM 過程來保證開發(fā)出正確的系統(tǒng)。這種情況下需求錯(cuò)誤的風(fēng)險(xiǎn)可能危及人的生命安全。
那么 RM 如何影響像您這樣的開發(fā)人員呢？諸如 Standish Group 報(bào)告這樣的研究表明，需求錯(cuò)誤是修復(fù)成本最高的錯(cuò)誤，因?yàn)樗鼈兂鲥e(cuò)的時(shí)間越長，影響就越大。隨著軟件開發(fā)生命周期的進(jìn)展，這些錯(cuò)誤越來越難以糾正，這實(shí)際上產(chǎn)生了雪球效應(yīng)。如果您從一個(gè)錯(cuò)誤的需求或者需求變更開始，那么您的設(shè)計(jì)就是無效的，這最終會(huì)導(dǎo)致進(jìn)行代價(jià)昂貴的構(gòu)架返工。確認(rèn)測試也是錯(cuò)誤的，用戶文檔也不精確，等等。最終，這將導(dǎo)致花費(fèi)更多的時(shí)間來修復(fù)問題，而這些是完全可以避免的。
但您是開發(fā)人員，而不是分析人員。RM 不是僅用于分析人員的嗎？可以肯定的是，您項(xiàng)目團(tuán)隊(duì)中代