關(guān)于我們

在線客服

幫助

24小時(shí)客服:010-82326699 400-810-5999

建設(shè)工程教育網(wǎng) > 建筑文苑 > 工程管理 > 正文

我的項(xiàng)目血淚史之頻繁需求變更

2010-02-08 11:43    【  【打印】【我要糾錯(cuò)】

  前段時(shí)間,我出任項(xiàng)目經(jīng)理承接了一個(gè)中型軟件項(xiàng)目,公司再三叮嚀我一定要尊重客戶(hù),充分滿(mǎn)足客戶(hù)需求。項(xiàng)目開(kāi)始比較順利,辛辛苦苦熬了幾個(gè)月的通宵,基本保持項(xiàng)目的正常進(jìn)度,客戶(hù)相當(dāng)滿(mǎn)意。但進(jìn)入后期以來(lái),客戶(hù)頻繁的需求變更卻帶來(lái)很多額外工作。

  需求變更不但越來(lái)越多,更可怕的是為了節(jié)省時(shí)間,客戶(hù)不再向我申請(qǐng)變更,而是直接找程序員商量。程序員疲于應(yīng)付,往往直接改程序而不做任何記錄,很多相關(guān)文檔也忘記修改。很快就出現(xiàn)一個(gè)問(wèn)題,就是需求、設(shè)計(jì)和代碼無(wú)法保持一致,甚至沒(méi)有人能說(shuō)清楚現(xiàn)在系統(tǒng)到底改成什么樣。后來(lái)因頻繁出現(xiàn)改好的錯(cuò)誤又重新出現(xiàn),客戶(hù)投訴表示無(wú)法容忍這種低下的項(xiàng)目管理水平。這讓我很無(wú)奈,疑惑自己到底錯(cuò)在哪里。

  什么是需求變更?

 。1)什么是需求分析?

  要知道需求變更是什么,首先要知道什么是需求分析。

  需求分析是一個(gè)復(fù)雜的問(wèn)題。作為軟件開(kāi)發(fā)人員,一定了解軟件工程學(xué),而這門(mén)科學(xué)的第一步就是需求分析。打開(kāi)任何一本軟件工程的書(shū)籍,翻看目錄就知道需求分析的地位。軟件需求分析是整個(gè)軟件開(kāi)發(fā)最關(guān)鍵的一個(gè)輸入。和傳統(tǒng)的生產(chǎn)企業(yè)相比較,軟件需求具有模糊性、不確定性、變化性和主觀性的特點(diǎn),它不像生產(chǎn)汽車(chē)、電腦等硬件的需求,是有形的、客觀的、可描述的、可檢測(cè)的。因此,軟件需求是軟件項(xiàng)目最難把握的問(wèn)題。

  簡(jiǎn)單的說(shuō):需求分析是指理解客戶(hù)需求,就軟件功能與客戶(hù)達(dá)成一致,估計(jì)軟件風(fēng)險(xiǎn)和評(píng)估項(xiàng)目成本代價(jià),最終形成開(kāi)發(fā)計(jì)劃的一個(gè)復(fù)雜過(guò)程。需求分析主要包括:業(yè)務(wù)需求、客戶(hù)需求和功能需求三個(gè)部分。業(yè)務(wù)需求意為客戶(hù)對(duì)產(chǎn)品的目標(biāo)或者要求,客戶(hù)需求意為客戶(hù)在使用產(chǎn)品過(guò)程中需要完成的一系列任務(wù),功能需求則指定了產(chǎn)品系統(tǒng)必須提供的功能。

  (2)什么是需求變更?

  在軟件開(kāi)發(fā)過(guò)程中,開(kāi)發(fā)經(jīng)理所要面對(duì)的將是一系列和多方面的考驗(yàn)。其中,最讓開(kāi)發(fā)經(jīng)理頭痛的就是需求變更。根據(jù)軟件工程思想定義,需求說(shuō)明書(shū)一般要經(jīng)過(guò)論證,如果在需求說(shuō)明書(shū)經(jīng)過(guò)論證以后,需要在原有需求基礎(chǔ)上追加和補(bǔ)充新的需求,或?qū)υ行枨筮M(jìn)行修改和削減,均屬于需求變更。而且,客戶(hù)變更需求是軟件開(kāi)發(fā)與生俱來(lái)的特性,也是一個(gè)無(wú)法避免的事實(shí)。

  需求變更好比是萬(wàn)惡之源,為項(xiàng)目的正常開(kāi)展帶來(lái)不盡的麻煩。需求變更的表現(xiàn)形式是多方面的,如客戶(hù)臨時(shí)改變想法、項(xiàng)目預(yù)算增加或減少、客戶(hù)對(duì)功能的需求改變等。需求變更問(wèn)題是每個(gè)開(kāi)發(fā)人員最頭痛的問(wèn)題。因?yàn)橐坏┌l(fā)生了需求變化,就不得不重新修改設(shè)計(jì)、重寫(xiě)代碼、修改測(cè)試用例、調(diào)整項(xiàng)目計(jì)劃等。這時(shí),如果開(kāi)發(fā)團(tuán)隊(duì)缺少明確的需求變更控制過(guò)程或采用的變更控制無(wú)效,很可能會(huì)造成開(kāi)發(fā)進(jìn)度拖延、成本超支、人員士氣低落,而且越往后的需求變更產(chǎn)生的風(fēng)險(xiǎn)將越大,甚至導(dǎo)致整個(gè)項(xiàng)目失敗。

  需求變更無(wú)可避免

  對(duì)于需求變更,我們總認(rèn)為能夠完全掌握它,可實(shí)際情況是——需求變更往往在所難免。以前出現(xiàn)這種情況時(shí),總覺(jué)得很沮喪,覺(jué)得自己的工作做得還不細(xì),有些內(nèi)容要讓用戶(hù)簽字確認(rèn)就好了。可在經(jīng)過(guò)多次需求變更的痛苦后,才恍然大悟:軟件開(kāi)發(fā)的需求變更是無(wú)可避免的。

 。1)三極世界和需求變更的必然性

  需求、客戶(hù)、開(kāi)發(fā)人員是一個(gè)三極世界。這三極的溝通是很不容易的?蛻(hù)向我們滔滔不絕地描述需求,開(kāi)發(fā)者聽(tīng)得頭暈?zāi)X脹,但又不得不根據(jù)這些來(lái)理解需求。有的時(shí)候我們也會(huì)派好幾撥人輪番折騰客戶(hù),這樣客戶(hù)也暈頭轉(zhuǎn)向,巴不得趕快需求調(diào)研結(jié)束。這樣的需求調(diào)研像透過(guò)布滿(mǎn)小水珠的玻璃看世界一樣,即使能夠看清輪廓,但細(xì)節(jié)的丟失在所難免。

  之所以這樣,是有原因的:第一,是因?yàn)榭蛻?hù)自己對(duì)需求進(jìn)行了過(guò)濾,有時(shí)是因?yàn)榭蛻?hù)對(duì)需求的理解也不準(zhǔn)確,有時(shí)是客戶(hù)的視角與我們的不同。第二,是開(kāi)發(fā)者對(duì)需求的理解偏差。有可能是由于缺乏知識(shí),開(kāi)發(fā)者對(duì)需求理解錯(cuò)了;還可能是開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部造成的偏差,比如需求調(diào)研人員往往同時(shí)做好幾個(gè)項(xiàng)目,在調(diào)研完成后便不在開(kāi)發(fā)團(tuán)隊(duì)中,這樣偏差便在所難免。還有就是內(nèi)部溝通、人員更替造成的偏差。因此,在這樣一個(gè)三極世界,需求變更是必然的。

 。2)合同簽訂馬虎,沒(méi)有真正明白客戶(hù)需求

  當(dāng)我以合同上沒(méi)有規(guī)定的需求不予開(kāi)發(fā)時(shí),客戶(hù)搬出銷(xiāo)售人員的承諾這一招,更讓我?guī)缀跬卵dN(xiāo)售人員在簽訂合同時(shí)缺乏對(duì)客戶(hù)需求的認(rèn)真對(duì)待,導(dǎo)致需求描述不清,為開(kāi)發(fā)帶來(lái)了許多困惑和后患。例如,銷(xiāo)售人員有時(shí)為使客戶(hù)能夠快速地簽訂合同,往往草率決定和片面同意客戶(hù)提出的需求。當(dāng)客戶(hù)提出新的需求時(shí),往往是銷(xiāo)售人員一看“應(yīng)該”只是一個(gè)小小的修改,沒(méi)有太大的影響,所以直接答應(yīng)能變更。

  該問(wèn)題的關(guān)鍵是合同簽署得太爛,沒(méi)有把需求明確再簽合同,而且也沒(méi)有把需求變更的流程寫(xiě)入合同。如果在簽合同前就把客戶(hù)需求弄清楚,后期就根本不需要頻繁地變更需求。簽訂合同時(shí)明確定義開(kāi)發(fā)需求的范圍,可以為以后各項(xiàng)開(kāi)發(fā)工作的開(kāi)展奠定好的基礎(chǔ)。

  需求變更為何沒(méi)完沒(méi)了?

  在軟件開(kāi)發(fā)中,最常抱怨的是這樣一個(gè)問(wèn)題:客戶(hù)為什么總是反反復(fù)復(fù)?造成需求變更沒(méi)完沒(méi)了的原因,可以是這樣幾個(gè)方面存在問(wèn)題。

  (1)沒(méi)有明確的需求變更流程沒(méi)有明確的需求變更管理流程,就會(huì)使需求變更變得泛濫,在這一點(diǎn)上我嘗盡了苦頭。并不是所有的變更都要修改,也不是所有變更都要立刻修改,明確需求變更管理流程的目的是為了決定什么類(lèi)型的變更需要修改和什么時(shí)候修改。比如單純的界面風(fēng)格問(wèn)題,就可以先不修改,或者規(guī)劃一下修改的時(shí)間待到以后進(jìn)行優(yōu)化。另外,對(duì)于核心功能的修改沒(méi)有嚴(yán)格把關(guān)流程,有些小需求看起來(lái)工作量不大,但是哪些銷(xiāo)售人員或者客戶(hù)沒(méi)有考慮到的細(xì)節(jié)問(wèn)題實(shí)際上需要花費(fèi)開(kāi)發(fā)人員相當(dāng)長(zhǎng)的時(shí)間去完成,從而是撿了芝麻掉了西瓜,得不償失,使開(kāi)發(fā)進(jìn)度失控和資源浪費(fèi)。

 。2)沒(méi)有讓客戶(hù)知道需求變更的代價(jià)對(duì)變更的影響沒(méi)有進(jìn)行成本評(píng)估是需求變更泛濫的根本原因,這是我從單純的技術(shù)人員轉(zhuǎn)變到統(tǒng)籌兼顧成本管理的轉(zhuǎn)變點(diǎn)之一,當(dāng)然為了這一點(diǎn)我也付出了血與淚,為此飽受公司領(lǐng)導(dǎo)和客戶(hù)的重重抱怨和責(zé)備。變更都是有代價(jià)的,應(yīng)該要評(píng)估變更的代價(jià)和對(duì)項(xiàng)目的影響,要讓客戶(hù)了解需求變更的后果。如果客戶(hù)不知道需求變更付出的代價(jià),對(duì)開(kāi)發(fā)人員的辛苦就會(huì)難以體會(huì)。在評(píng)估代價(jià)(包括成本、時(shí)間等多方面)過(guò)程中,可以請(qǐng)客戶(hù)一起做判斷:“我可以修改,但您能接受后果嗎?”

  如何有效控制需求變更?

  需求變更對(duì)軟件開(kāi)發(fā)項(xiàng)目成敗有重要影響,既不能一概拒絕客戶(hù)的變更要求,也不能一味地遷就客戶(hù),所以實(shí)施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發(fā)生,而是對(duì)變更進(jìn)行管理,確保變更有序進(jìn)行。

  (1)明確合同約束,建立需求基線需求變更給軟件開(kāi)發(fā)帶來(lái)的影響有目共睹,所以在與客戶(hù)簽訂合同時(shí),可以增加一些相關(guān)條款,如限定客戶(hù)提出需求變更的時(shí)間,規(guī)定何種情況的變更可以接受、拒絕或部分接受,還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更管理流程。雖然軟件開(kāi)發(fā)合同很難在簽訂之初就能夠精確定義每項(xiàng)需求,單靠合同是幫不上忙的,但也不能忽視合同的約束力。

  明確和樹(shù)立需求基線是需求變更的依據(jù)。在開(kāi)發(fā)過(guò)程中,需求確定并經(jīng)過(guò)評(píng)審后(客戶(hù)參與評(píng)審),建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后,都要重新確定新的需求基線,做到小需求可以變更,但大方向要力保不頻繁變更。例如,對(duì)于項(xiàng)目中的需求,可以實(shí)行分級(jí)管理,以達(dá)到對(duì)需求變更的控制和管理。

  (2)建立變更審批流程在實(shí)踐中,人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過(guò)程,認(rèn)為降低開(kāi)發(fā)效率,浪費(fèi)時(shí)間。正是這種觀念才使需求變更變得不可控,最終導(dǎo)致項(xiàng)目的失敗。因此,小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理流程,否則會(huì)積少成多,積重難返。

  明確需求變更審批環(huán)節(jié)、審批人員、審批事項(xiàng)、審批流程。這么做的目的有兩個(gè):一是將客戶(hù)下達(dá)變更的流程盡可能地規(guī)范化,減少?gòu)堊炀蛠?lái)的非必要、非緊急、非合理、非高層領(lǐng)導(dǎo)意圖的無(wú)效變更。二是留下書(shū)面依據(jù),為今后可能的成本變更和索賠準(zhǔn)備好“變更賬”。凡未履行審批程序的“變更”,一律是無(wú)效變更不予受理。

 。3)分級(jí)管理變更,定時(shí)批量處理軟件開(kāi)發(fā)項(xiàng)目中,“客戶(hù)永遠(yuǎn)是對(duì)的”和“客戶(hù)是上帝”并不完全正確,因?yàn)樵谝呀?jīng)簽定的項(xiàng)目合同中,任何新需求的變更和增加除了影響項(xiàng)目的正常進(jìn)行以外,還影響到客戶(hù)的成本投入收益。因此,用戶(hù)不斷提出對(duì)項(xiàng)目進(jìn)度有重大影響的需求對(duì)雙贏也并不是好事。

  當(dāng)遇到客戶(hù)提出需求,不及時(shí)處理可能會(huì)使項(xiàng)目不能驗(yàn)收通過(guò)時(shí),也不能一味拒絕不予開(kāi)發(fā)。因此,當(dāng)客戶(hù)堅(jiān)持變更新需求時(shí),可以建議客戶(hù)將新需求按重要和緊迫程度劃分檔次,作為需求變更評(píng)估的一項(xiàng)依據(jù)。例如,每周或每?jī)芍苌踔撩吭抡匍_(kāi)一次需求變更專(zhuān)題會(huì)議,集中研究處理這些零碎變更事項(xiàng),主動(dòng)控制好工作節(jié)奏,盡量避免由于處理零碎變更而影響項(xiàng)目進(jìn)度。針對(duì)會(huì)議結(jié)果可向客戶(hù)正式提交一份需求變更計(jì)劃,注明變更引起的時(shí)間、成本、工期代價(jià)和增加工作量等。要求客戶(hù)配合需求變更計(jì)劃,確定變更時(shí)限,控制變更規(guī)模,過(guò)時(shí)變更不候,離譜變更不做,保大局棄小變。

 。4)安排專(zhuān)職人員負(fù)責(zé)變更管理有時(shí)開(kāi)發(fā)任務(wù)較重,開(kāi)發(fā)人員容易陷入開(kāi)發(fā)工作中而忽略了與客戶(hù)的隨時(shí)溝通。因此,需要安排一名專(zhuān)職的需求變更聯(lián)絡(luò)人員,負(fù)責(zé)與客戶(hù)及時(shí)交流,跟蹤和匯報(bào)需求變更完成進(jìn)度和情況。同時(shí),可以成立項(xiàng)目變更控制小組,負(fù)責(zé)裁定接受哪些變更,小組由項(xiàng)目所涉及的多方人員共同組成,應(yīng)該包括客戶(hù)方和開(kāi)發(fā)方的決策人員在內(nèi)。

 。5)確認(rèn)客戶(hù)是否接受變更的代價(jià)要讓客戶(hù)認(rèn)識(shí)到變更都是有代價(jià)的,要和客戶(hù)一起判斷需求變更是否依然進(jìn)行。例如,變更是沒(méi)有問(wèn)題的,但是要明確客戶(hù)能否接受由此引起的如進(jìn)度延遲、費(fèi)用增加、效率下降等問(wèn)題。一般來(lái)說(shuō),如果客戶(hù)認(rèn)為該變更是必須的(不是其上級(jí)領(lǐng)導(dǎo)拍腦袋提出的)就會(huì)接受這些后果。通過(guò)與客戶(hù)協(xié)商,這樣開(kāi)發(fā)團(tuán)隊(duì)即使沒(méi)有回報(bào),也不會(huì)招致公司和客戶(hù)雙方的埋怨。

  如果客戶(hù)認(rèn)為該變更雖然有必要但是可以暫緩,雙方簽署備忘錄后留待以后解決。如果客戶(hù)認(rèn)為該變更可有可無(wú),多數(shù)情況下會(huì)取消變更。這樣即可防止頻繁變更,也讓客戶(hù)認(rèn)識(shí)到不是所有的需求都需要變更。

  以上便是本人在頻繁需求變更的血淚史中收獲的經(jīng)驗(yàn),與大家分享。

收藏分享:論壇
分享到:
相關(guān)新聞
  • 特色班
    4大班次+2-3套全真模擬題
    提升學(xué)習(xí)效果
  • 精品班
    4大班次+2-3套全真模擬題+1套預(yù)測(cè)試題
  • 實(shí)驗(yàn)班
    3套全真模擬題+2套預(yù)測(cè)試題+考前沖關(guān)寶典
  • 定制班
    3套模擬題+3套預(yù)測(cè)題+考前沖關(guān)寶典+考前重點(diǎn)
  • 移動(dòng)班
    以知識(shí)點(diǎn)為單元授課練習(xí),
    強(qiáng)化重點(diǎn)、難點(diǎn)、考點(diǎn)
版權(quán)聲明

  1、凡本網(wǎng)注明“來(lái)源:建設(shè)工程教育網(wǎng)”的所有作品,版權(quán)均屬建設(shè)工程教育網(wǎng)所有,未經(jīng)本網(wǎng)授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式使用;已經(jīng)本網(wǎng)授權(quán)的,應(yīng)在授權(quán)范圍內(nèi)使用,且必須注明“來(lái)源:建設(shè)工程教育網(wǎng)”。違反上述聲明者,本網(wǎng)將追究其法律責(zé)任。
  2、本網(wǎng)部分資料為網(wǎng)上搜集轉(zhuǎn)載,均盡力標(biāo)明作者和出處。對(duì)于本網(wǎng)刊載作品涉及版權(quán)等問(wèn)題的,請(qǐng)作者與本網(wǎng)站聯(lián)系,本網(wǎng)站核實(shí)確認(rèn)后會(huì)盡快予以處理。
  本網(wǎng)轉(zhuǎn)載之作品,并不意味著認(rèn)同該作品的觀點(diǎn)或真實(shí)性。如其他媒體、網(wǎng)站或個(gè)人轉(zhuǎn)載使用,請(qǐng)與著作權(quán)人聯(lián)系,并自負(fù)法律責(zé)任。
  3、本網(wǎng)站歡迎積極投稿。