項目的需要變化是肯定有的，而且變化一般都很頻繁，我們怎么應對客戶(hù)的這種需求變化呢，以不變應萬(wàn)變。首先在前期的需求調研要做好，盡可能的替用戶(hù)考慮，達到功能質(zhì)量滿(mǎn)足最大化。需求調研前期的《目標與范圍》和需求調研末期的《功能規格說(shuō)明書(shū)》都要跟客戶(hù)簽字確認，這樣既能保證我們所理解的需求就是客戶(hù)所要的，也使得項目末期跟客戶(hù)驗收時(shí)有據可依。根據我自己做項目的經(jīng)驗，由于客戶(hù)一般對計算機不是很了解，和他們交流用我們行業(yè)的話(huà)，他們根本就不懂，如果用文檔也很難把需求寫(xiě)的那么明白，而且文檔很多的話(huà)，客戶(hù)都看煩了，很不直觀(guān)。如果讓客戶(hù)一看就可以看出這個(gè)就是他們想要的，我個(gè)人認為最好的方式就是做系統原形。系統原形應該在需求分析的時(shí)候開(kāi)發(fā)人員在分析師的指導下完成真實(shí)環(huán)境中的開(kāi)發(fā)，當然開(kāi)發(fā)只是界面的功能模擬，沒(méi)有底層代碼的實(shí)現。這樣做的目的有三個(gè)好處，一是客戶(hù)很直觀(guān)的看到他們的系統是什么樣子的以及怎么操作，二是這些開(kāi)發(fā)的成果是可以二次利用的，三是可以更好的激發(fā)客戶(hù)的需求。
在項目中期是發(fā)生需求變更是很常見(jiàn)的，這時(shí)要做好需求變更管理流程。需求變更表，小的變更自己掌握，客戶(hù)要求的變更有開(kāi)發(fā)人員和設計人員共同商討后提交項目經(jīng)理，項目經(jīng)理預估變更損耗工程時(shí)間，在一定階段一起提交給客戶(hù)，大的變更直接提交客戶(hù)，并且要把需求變更對項目產(chǎn)生的影響讓客戶(hù)知道，把球盡可能的踢給客戶(hù)，讓客戶(hù)在進(jìn)度、功能、資源三者中取舍出一個(gè)平衡來(lái)。對需求進(jìn)行分類(lèi)評級，關(guān)鍵部分不能改動(dòng)的做特別確認（如系統架構等，如果改變等于從頭再來(lái)）。同時(shí)完成客戶(hù)簽字確認，當然如果能將這部分寫(xiě)成合同細節中去是最好，但國內的合同好像都是在打單時(shí)是基本上都承諾，也不會(huì )到細節，在合同簽訂后啟動(dòng)后才發(fā)現問(wèn)題。但合同中可以寫(xiě)明如果需求變更什么級別的怎么樣，多少錢(qián)等;簽訂合同也是一個(gè)很高的技巧，建議把系統的邊界及功能范圍和解決方案與合同一起簽署，這樣客戶(hù)提出的新功能就可以暫且擱置。當然這就需要項目經(jīng)理很高的經(jīng)驗和技巧了，不是光通過(guò)學(xué)習就能掌握的。
下面我結合我的項目開(kāi)發(fā)經(jīng)驗說(shuō)下在項目開(kāi)發(fā)中的失敗原因：
一、需求調研階段我們做的不夠細，調研的時(shí)候幾乎是一個(gè)單位半天的時(shí)間，收集一些報表，根本就沒(méi)有了解用戶(hù)的需求。
二、對客戶(hù)現有系統分析和研究重視不夠，我們開(kāi)發(fā)的系統是客戶(hù)已有的系統，他們已經(jīng)用了多年，在使用的過(guò)程中他們已形成了自己的習慣。而且他們的老系統也有他存在的優(yōu)點(diǎn)，也是在使用的過(guò)程中逐步完善的，可是我們在開(kāi)發(fā)過(guò)程中完全忽略了老系統的存在。
三、簽訂合同也是非常重要的，具體內容我在上面已說(shuō)過(guò)了。
四、沒(méi)有《功能規格說(shuō)明書(shū)》，這個(gè)是我們項目中最大的失誤，致使后來(lái)客戶(hù)的改動(dòng)讓我們很被動(dòng)。 《功能規格說(shuō)明書(shū)》反映了客戶(hù)提出的所有需求功能，我們也是按照《功能規格說(shuō)明書(shū)》來(lái)開(kāi)發(fā)的。后期 客戶(hù)的變化都可以和《功能規格說(shuō)明書(shū)》對比，具體怎么變更按照我們的變更流程來(lái)做。經(jīng)驗教訓：《功 能規格說(shuō)明書(shū)》作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開(kāi)發(fā)者和客戶(hù)不能作任 何假設。如果任何所期望的功能或非功能需求未寫(xiě)入軟件需求規格說(shuō)明那么它將不能作為協(xié)議的一部分并 且不能在產(chǎn)品中出現。并且注意以下幾點(diǎn)：完整性、正確性、 可行性、必要性、劃分優(yōu)先級、無(wú)二義性、 可驗證性、一致性、可修改性和可跟蹤性
五、前期項目開(kāi)發(fā)人員投入過(guò)少，項目周期越長(cháng)，對我方越是不利。主要有以下幾點(diǎn)：
1、時(shí)間越長(cháng)，客戶(hù)的需求越多，變化也越多，我們的風(fēng)險就越大。
2、在長(cháng)周期中往往會(huì )有政局的變動(dòng)，例如客戶(hù)領(lǐng)到的變動(dòng)等。
3、項目周期太長(cháng)容易造成人員流動(dòng)的擴大以及工作效率的降低。
經(jīng)驗教訓：前期多投入人力，盡早完工，降低我方的風(fēng)險。
六、項目管理人員是項目成敗的關(guān)鍵人員，尤其是我們的這樣的公司，對項目經(jīng)理的要求更高，對這個(gè)職位的人員的綜合素質(zhì)要求非常高。為什么這么說(shuō)呢，首先從我們公司項目經(jīng)理所做的工作說(shuō)起，在我們公司中項目經(jīng)理要承擔項目的前期調研、需求分析、架構設計、質(zhì)量的保證、計劃的安排執行和跟蹤、掌握行業(yè)知識、人員的管理、技術(shù)支持、風(fēng)險的預測以及數據庫的設計等等工作。而在大型軟件公司中這些工作至少是有3年以上本專(zhuān)業(yè)經(jīng)驗的2人來(lái)做，一個(gè)項目經(jīng)理和一個(gè)軟件架構設計師。一個(gè)項目在前期的這些工作就是一個(gè)錯誤的話(huà)，后面有再強大的開(kāi)發(fā)團隊也是白搭。我們還是一個(gè)年輕的團隊，很需要這樣的人才，需要公司來(lái)培養，如果遇到項目，再招人員來(lái)?yè)斶@樣的工作，風(fēng)險是可想而知的。而且這樣的人員肯定是從項目實(shí)戰中成長(cháng)起來(lái)的，不是有非軟件項目管理經(jīng)驗的人員或者市場(chǎng)人員轉過(guò)來(lái)就可以做好的，更不是從書(shū)本或者參加某些培訓就可以學(xué)到的。
七、一味的追求快速開(kāi)發(fā)，時(shí)間進(jìn)度。在我所去的公司中好多都是想把項目盡快做完，我們公司也是一樣，但是我知道用友不是的。做項目和孕婦懷孕一樣，沒(méi)有捷徑可以走的，必須一步一個(gè)腳印走。公司往往為了趕進(jìn)度，省略了某些工作，最終結果是后面付出幾倍省了那些時(shí)間的代價(jià)去彌補，更嚴重的是前期的工作白做了，用個(gè)成語(yǔ)形容就是“投鼠忌器”。項目中有個(gè)不變的金三角法則，即時(shí)間、功能和資源。他們永遠是相互聯(lián)系和相斥的。怎么去平衡他們，需要我們根據實(shí)際項目的情況去分析解決。作為開(kāi)發(fā)人員也不愿意在一個(gè)項目中有過(guò)多的時(shí)間，他們也想早點(diǎn)結束項目。開(kāi)發(fā)人員在一個(gè)項目中的時(shí)間太長(cháng)，他們會(huì )變得非常的煩躁，工作效率也會(huì )降低，最嚴重的風(fēng)險是他們選擇走人來(lái)解脫自己。那么怎么解決這個(gè)問(wèn)題呢，我個(gè)人的意見(jiàn)是用我們的實(shí)際能力按照一個(gè)正常的進(jìn)度去做，如果一個(gè)項目在功能、時(shí)間和資源一定的情況下，需要10月才能完成的情況下，如果我們一定要在5個(gè)月完成，那和一個(gè)孕婦懷孕5個(gè)月生個(gè)孩子的后果是一個(gè)樣的。
八、沒(méi)有確定系統的邊界，所謂系統邊界就是我們做的項目到底要做哪些功能點(diǎn)，以及這些功能點(diǎn)具體要做的什么程度。這些不確定或者和用戶(hù)不說(shuō)清楚，以后我們就是永遠做不完的工作，用戶(hù)會(huì )不斷的提出新的需求和新的功能，我們已經(jīng)無(wú)法控制。
九、對前期的調研和設計重視還是不夠，包括數據庫等的設計，從我在我們公司所做的項目中我體會(huì )到，我們總是害怕客戶(hù)提出需求，總是不敢去更深的去挖掘客戶(hù)的需求，害怕我們的工作量增大，后果是在開(kāi)發(fā)好后，給客戶(hù)一看說(shuō)：“這不是我們需要的，我們想要的是這樣的”。在代碼和數據庫設計中時(shí)間投入很少，這些工作本來(lái)就是比較抽象的，需要不斷的研究和推敲才能設計好的，但是我們?yōu)榱藭r(shí)間進(jìn)度，很快就出來(lái)了，后果是客戶(hù)的一些小的需求變動(dòng)，由于我們的設計不好，導致前期的工作白作了。
十、客戶(hù)意見(jiàn)的一致性，我們在調研的時(shí)候過(guò)分相信領(lǐng)導，我們做的項目真正的使用者不是領(lǐng)導，而且廣大的員工，領(lǐng)導只是看數據的。我們的調研對象主要是最終用戶(hù)，尤其是在大型項目中，可以說(shuō)是領(lǐng)導很多，各有各的想法和意見(jiàn)，到底他們誰(shuí)的是對于錯呢，其實(shí)這個(gè)根本沒(méi)有對于錯。而我們吃虧的一點(diǎn)就是他們的這些領(lǐng)導提出意見(jiàn)的時(shí)候都不在一起，他們也沒(méi)有開(kāi)會(huì )研究過(guò)，誰(shuí)提意見(jiàn)就按照誰(shuí)的改，后果是我們的重復工作不知道做的多少。這個(gè)就是在我們內部也發(fā)生。解決方案：在調研和需求改動(dòng)修改一定要和客戶(hù)確認好，等他們內部意見(jiàn)一致才能改動(dòng)，包括我們內部也是一樣。調研也要指導調研的真正對象，不能太相信客戶(hù)的領(lǐng)導。
十一、用戶(hù)參與，在項目的開(kāi)始和結束用戶(hù)是需要一直參與進(jìn)來(lái)的，我們每做個(gè)可以運行的功能等就需要和用戶(hù)交流，這樣可以避免很多風(fēng)險也可以盡早發(fā)現需求的誤解的等等。
聯(lián)系客服
