快速原型法在項目開發(fā)中的成功案例

“快速原型法”在項目開發(fā)中的成功案例項目型軟件的開發(fā)流程，通常會包括七個步驟：第一步：需求調(diào)研分析；第二步：概要設計第三步：詳細設計；第四步：編碼；第五步：測試；第六步：軟件交付準備；第七步：驗收與收尾工作在項目型產(chǎn)品的開發(fā)過程中，依據(jù)軟件工程思想的標準，遵循軟件開發(fā)流程（SoftwaredevelopmentprocesS—步步的操作是最正統(tǒng)和最標準而且有效的做法，項目組人員的理解并落實這一點，整個項目就會朝著良性的方向發(fā)展。狹義的項目組成員是指軟件公司的人員，廣義的項目組成員還應該包括客戶方，對于客戶來說，更關心的是結果而不是過程。由于項目組成員們的專業(yè)素養(yǎng)和技術水平會有差異（比如項目開發(fā)方的長處在計算機方面，而合作方在專業(yè)知識），再加上溝通不暢等因素，會給項目帶來一些負面影響，比如甲乙雙方對于研發(fā)成果存在爭議、項目無法按期完成等等。簡單談一下Byteh經(jīng)歷的一個項目情況。由于項目的專業(yè)性，擺在項目組人員的第一個問題就是理解需求其次才是后續(xù)步驟。如果嚴格按照軟件開發(fā)的流程，必然會出現(xiàn)一些不可控的風險。我方項目組果斷決定采用快速原型法和敏捷開發(fā)的思想作為此次項目開發(fā)的主導，主要有以下幾個措施：1、在獲取用戶原始需求后迅速理解開發(fā)出一個雛形，把一個能看到的軟件界面反饋給用戶去探討更進一步的需求，去更準確的把握用戶需求，反復迭代。這點對甲乙雙方都是有利的，當你拿著一堆文檔

讓客戶確認需求簽字，從文檔上看雙方理解一致就簽字了，然而等中期匯報做出來成果會發(fā)現(xiàn)簡直就是南轅北轍，下次再簽字肯定就會猶豫了……下圖來自網(wǎng)上，說明了各方理解的，需求”和成果的差異:■戶址廟JL> IMtanJ- >.2、把編碼工作提到了概要設計和詳細設計的前面或者并行，不等待所有的文檔都完成才去進行下一步的工作。任何好的制度如果僵化，就會出現(xiàn)與制度目的背離的結果，請參考byteh的另一篇博文央視2.4秒門對管理的啟示3、出現(xiàn)疑問和爭議時抱著“友好合作協(xié)商解決”的態(tài)度去及時溝通，當然了也是個合作與斗爭的過程，一味的滿足用戶需求做出承諾意味著“死亡”而且客戶未必也會領你的“情”。及時，就是對無法獲得與客戶有效溝通地機會這個問題上不要給自己找太多理由，也許客戶方企業(yè)組織的一個集體活動都會比項目重要。盡管最終無可避免的也出現(xiàn)了爭議和延期兩個問題，但是我方把風險做到了最小化，項目中后期一直到匯報，客戶都是和我們站在一起的，要知道我們公司的“背景”是最薄的！當時客戶方是兩個軟件項目同期進行的，通過幾次集中匯報和私底下的交流，我們了解開發(fā)方是嚴格按照軟件的開發(fā)流程展開工作。當客戶方按流程要求所有項目進行中期匯報檢查時，我們公司拿出的除了文檔還有一個能滿足客戶40%左右工作需求的軟件，而另一個項目卻只有厚厚的文檔；當項目第一次申請延期時，我方項目組實際已經(jīng)和客戶落實了90%以上的需求并完成了大部分的開發(fā)工作剩余部分為了不影響驗收工作也達成了雙方都可以接受的解決方案,而另一個公司的項目組的需求還在變化中；當項目驗收匯報近在咫尺時，我方在科室內(nèi)部匯報中獲得了客戶方大部分的認可并可能獲得優(yōu)秀外協(xié)項目的評價，而另一個公司卻還得繼續(xù)申請延期（這一次是按違約處理要扣項目款）；后來項目結束我們項目組離開駐地，3月后byteh以項目經(jīng)理的身份出現(xiàn)在客戶方去交付剩余的需求并辦理尾款結付手續(xù)時，該公司的項目還在進行，而且還出現(xiàn)了一些生疏的面孔……前一段，在北京遇到了當時對方項目組的一位哥們，簡單溝通后了解到，他已經(jīng)離開了那家公司而