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