一、前言
在軟件項(xiàng)目的開(kāi)發(fā)過(guò)程中，需求變更貫穿了軟件項(xiàng)目的整個(gè)生命周期，從軟件的項(xiàng)目立項(xiàng)，研發(fā)，維護(hù)，用戶的經(jīng)驗(yàn)在增加，對(duì)使用軟件的感受有變化，以及整個(gè)行業(yè)的新動(dòng)態(tài)，都為軟件帶來(lái)不斷完善功能 ，優(yōu)化性能，提高用戶友好性的要求。在軟件項(xiàng)目管理過(guò)程中，項(xiàng)目經(jīng)理經(jīng)常面對(duì)用戶的需求變更。如果不能有效處理這些需求變更，項(xiàng)目計(jì)劃會(huì)一再調(diào)整，軟件交付日期一再拖延，項(xiàng)目研發(fā)人員的士氣將越來(lái)越低落，將直接導(dǎo)致項(xiàng)目成本增加、質(zhì)量下降及項(xiàng)目交付日期推后。這決定了項(xiàng)目組必須擁有需求管理策略。
二、需求管理復(fù)雜性分析
軟件需求是整個(gè)軟件開(kāi)發(fā)項(xiàng)目的最關(guān)鍵的一個(gè)輸入，和傳統(tǒng)的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點(diǎn)，他不像生產(chǎn)汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測(cè)的，軟件需求是軟件項(xiàng)目最難把握的問(wèn)題，他的復(fù)雜性體現(xiàn)在以下方面：
1、需求的描述問(wèn)題。缺少正式的完整的需求文檔浪費(fèi)了大量的人力物力，但是有了需求文檔又出現(xiàn)了新的問(wèn)題。在用戶方進(jìn)行的需求評(píng)審會(huì)完全是走形式，因?yàn)橛脩舾静蝗ヂ?tīng)他讀那上百頁(yè)的需求文檔。不同層次的客戶（用戶）關(guān)心的問(wèn)題是不一樣的，想要每個(gè)客戶都成為需求專家是不現(xiàn)實(shí)的。
2、需求的完備程度問(wèn)題。需求如何做到?jīng)]有遺漏？如何準(zhǔn)確劃定系統(tǒng)的范圍？這確實(shí)是一個(gè)兩難問(wèn)題，稍微大一點(diǎn)的系統(tǒng)要想窮舉需求幾乎是不可能的，每次開(kāi)需求評(píng)審會(huì)時(shí)，總會(huì)冒出新的需求，以至于系統(tǒng)沒(méi)有一個(gè)準(zhǔn)確的范圍界定。即使是這樣，系統(tǒng)還是要開(kāi)發(fā)，沒(méi)辦法，系統(tǒng)的范圍還要硬性的劃定一個(gè)，從而建立一個(gè)基線。
3、需求開(kāi)發(fā)的工期問(wèn)題。在需求上花費(fèi)了大量的時(shí)間，客戶、軟件公司是否能夠忍受？為了確保需求的正確性，完備性，項(xiàng)目經(jīng)理往往堅(jiān)持要在需求階段花費(fèi)大量的時(shí)間，但是客戶與公司的高層領(lǐng)導(dǎo)卻會(huì)為項(xiàng)目遲遲看不到實(shí)際可運(yùn)行的軟件擔(dān)心不已！他們往往會(huì)逼迫項(xiàng)目組盡快往前推進(jìn)，而項(xiàng)目組的成員往往也會(huì)為系統(tǒng)復(fù)雜的善變的需求折騰的筋疲力盡，他們也希望盡快結(jié)束此階段。
4、需求的細(xì)致程度問(wèn)題。需求到底描述到多細(xì)，才算可以結(jié)束了？仁者見(jiàn)仁，智者見(jiàn)智，并沒(méi)有定論，如果時(shí)間允許，要想細(xì)總可以細(xì)下去的。但是，需求的周期越長(zhǎng)，可能的變化越多，對(duì)設(shè)計(jì)的限制越嚴(yán)格，對(duì)需求的共性提取要求越高，所以只要大家（客戶、用戶、需求分析人員、設(shè)計(jì)人員、測(cè)試人員）認(rèn)為描述清楚了，就可以進(jìn)入設(shè)計(jì)階段了。
5、需求的變化問(wèn)題。在軟件開(kāi)發(fā)過(guò)程中如果只有一條真理的話，那一定是：需求的變化是永恒的，需求不可能是完備的。軟件開(kāi)發(fā)的過(guò)程實(shí)際上是同變化做斗爭(zhēng)的過(guò)程，需求的變更不一定是壞事，也有可能是好事，是商業(yè)機(jī)會(huì)，對(duì)市場(chǎng)敏感的人可以從需求的變化中發(fā)現(xiàn)市場(chǎng)機(jī)會(huì)。
需求變化的原因很多，如：
·一開(kāi)始沒(méi)有識(shí)別全，需要增加需求；
·業(yè)務(wù)發(fā)生了變化，需求必須變化；
·需求錯(cuò)誤；
·需求不清楚。
需求的變化問(wèn)題是每個(gè)開(kāi)發(fā)人員、每個(gè)項(xiàng)目經(jīng)理都遇到的問(wèn)題，也是最頭痛的問(wèn)題，一旦發(fā)生了需求變化，你不得不來(lái)修改你的設(shè)計(jì)、重寫(xiě)你的代碼、修改你的測(cè)試用例、調(diào)整你的項(xiàng)目計(jì)劃等等，需求的變化好比是萬(wàn)惡之源，為項(xiàng)目的正常的進(jìn)展帶來(lái)不盡的麻煩，怎么辦？管理它！使需求在受控的狀態(tài)下發(fā)生變化，而不是隨意變化，需求管理就是要按照標(biāo)準(zhǔn)的流程來(lái)控制需求的變化。難題隨之而來(lái)，需求中的變化一般不是突發(fā)的革命性的變化，最常見(jiàn)的是項(xiàng)目需求的漸變（Project Scope Creep）問(wèn)題，這種漸變很可能是客戶與開(kāi)發(fā)方都沒(méi)有意識(shí)到的，當(dāng)達(dá)到一定層度時(shí)，雙方才驀然回首，發(fā)現(xiàn)已經(jīng)物是人非，換了一番天地。
三、需求管理策略
需求管理需要遵守以下策略：
1、需求一定要與投入有必然的聯(lián)系。
需求一定要與投入有必然的聯(lián)系，否則如果需求變更的成本由開(kāi)發(fā)方來(lái)承擔(dān)，則項(xiàng)目需求的變更就成為必然了。人們常說(shuō)世上沒(méi)有免費(fèi)的午餐，同樣也不應(yīng)該有免費(fèi)的需求變更。但是，接受需求變更目前卻是軟件開(kāi)發(fā)商不得不咽下的苦果。所以，在項(xiàng)目的開(kāi)始無(wú)論是開(kāi)發(fā)方還是出資方都要明確這一條：需求變，軟件開(kāi)發(fā)的投入也要變。
2、需求的變更要經(jīng)過(guò)出資者的認(rèn)可。
需求的變更引起投入的變化，所以要通過(guò)出資者的認(rèn)可，這樣才會(huì)對(duì)需求的變更有成本的概念，能夠慎重地對(duì)待需求的變更。筆者曾經(jīng)經(jīng)歷過(guò)一個(gè)項(xiàng)目，為了避免項(xiàng)目的風(fēng)險(xiǎn)，我們請(qǐng)了用戶代表全程參與了開(kāi)發(fā)過(guò)程，結(jié)果此用戶代表在開(kāi)發(fā)過(guò)程提出了大量“小的需求變更，當(dāng)開(kāi)發(fā)人員按此需求變更修改了軟件時(shí)，在項(xiàng)目進(jìn)入現(xiàn)場(chǎng)實(shí)施階段時(shí)，卻有大量的這些變更需要改回去，問(wèn)題就是出在我們的項(xiàng)目組成員視該用戶代表的需求為圣旨，卻忽略了需求是否經(jīng)過(guò)了客戶方真正有決策權(quán)的人員的認(rèn)可。
3、小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理流程。
小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理流程，否則會(huì)積少成多。在實(shí)踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過(guò)程，認(rèn)為降低了開(kāi)發(fā)效率，浪費(fèi)了時(shí)間。正式由于這種觀念才使需求的漸變不可控，最終導(dǎo)致項(xiàng)目的失敗。
4、精確的需求與范圍定義并不會(huì)阻止需求的變更。
并非對(duì)需求定義的越細(xì)，越能避免需求的漸變，這是2個(gè)層面的問(wèn)題。太細(xì)的需求定義對(duì)需求漸變沒(méi)有任何效果。因?yàn)樾枨蟮淖兓怯篮愕?，并非由于需求?xiě)細(xì)了，它就不會(huì)變化了。注意溝通的技巧。實(shí)際情況是用戶、開(kāi)發(fā)者都認(rèn)識(shí)了到了上面的幾點(diǎn)問(wèn)題，但是由于需求的變更可能來(lái)自客戶方、也可能來(lái)自開(kāi)發(fā)方，作為客戶他們可能不愿意為需求的變更付出更多的投資，開(kāi)發(fā)方有可能是主動(dòng)的變更了需求，他們的目的可能是使軟件做的更精致，于是作為需求管理者、項(xiàng)目經(jīng)理需要采用各種溝通技巧來(lái)使項(xiàng)目的各方各得其所。
基于上述的問(wèn)題，必須對(duì)需求進(jìn)行管理，使需求能夠真正成為軟件工程和管理的基線，使軟件計(jì)劃、活動(dòng)和工作產(chǎn)品同軟件需求保持一致，使需求可以復(fù)用。
【?發(fā)表評(píng)論?0條?】