專案型軟體的開發流程，通常會包括七個步驟：
；第二步：概要設計
；第三步：詳細設計；第四步：編碼；第五步：測試；第六步：軟體交付準備；第七步：驗收與收尾工作。
在專案型產品的開發過程中，依據軟體工程思想的標準，遵循
一步步的操作是最正統和最標準而且有效的做法，專案組人員的理解並落實這一點，整個專案就會朝著良性的方向發展。
狹義的專案組成員是指軟體公司的人員，廣義的專案組成員還應該包括客戶方，對於客戶來說，更關心的是結果而不是過程。由於專案組成員們的專業素養和技術水平會有差異（比如專案開發方的長處在計算機方面，而合作方在專業知識），再加上溝通不暢等因素，會給專案帶來一些負面影響，比如甲乙雙方對於研發成果存在爭議、專案無法按期完成等等。
簡單談一下
byteh
經歷的乙個專案情況。由於專案的專業性，擺在專案組人員的第乙個問題就是理解需求其次才是後續步驟。如果嚴格按照軟體開發的流程，必然會出現一些不可控的風險。
我方專案組果斷決定採用快速原型法和敏捷開發的思想作為此次專案開發的主導，主要有以下幾個措施：
1、在獲取使用者原始需求後迅速理解開發出乙個雛形，把乙個能看到的軟體介面反饋給使用者去**更進一步的需求，去更準確的把握使用者需求，反覆迭代。這點對甲乙雙方都是有利的，當你拿著一堆文件讓客戶確認需求簽字，從文件上看雙方理解一致就簽字了，然而等中期匯報做出來成果會發現簡直就是南轅北轍，下次再簽字肯定就會猶豫了……
下圖來自網上，說明了各方理解的「需求」 和成果的差異：
、把編碼工作提到了概要設計和詳細設計的前面或者並行，不等待所有的文件都完成才去進行下一步的工作。任何好的制度如果僵化，就會出現與制度目的背離的結果，請參考
byteh
的另一篇博文央視2.4秒門對管理的啟示。3
、出現疑問和爭議時抱著「友好合作協商解決」的態度去及時溝通，當然了也是個合作與鬥爭的過程，一味的滿足使用者需求做出承諾意味著「死亡」而且客戶未必也會領你的「情」。及時，就是對無法獲得與客戶有效溝通地機會這個問題上不要給自己找太多理由，也許客戶方企業組織的乙個集體活動都會比專案重要。
儘管最終無可避免的也出現了爭議和延期兩個問題，但是我方把風險做到了最小化，專案中後期一直到匯報，客戶都是和我們站在一起的，要知道我們公司的「背景」是最薄的！
當時客戶方是兩個軟體專案同期進行的，通過幾次集中匯報和私底下的交流，我們了解開發方是嚴格按照軟體的開發流程展開工作。當客戶方按流程要求所有專案進行中期匯報檢查時，我們公司拿出的除了文件還有乙個能滿足客戶
40%左右工作需求的軟體，而另乙個專案卻只有厚厚的文件；當專案第一次申請延期時，我方專案組實際已經和客戶落實了
90%以上的需求並完成了大部分的開發工作剩餘部分為了不影響驗收工作也達成了雙方都可以接受的解決方案，而另乙個公司的專案組的需求還在變化中；當專案驗收匯報近在咫尺時，我方在科室內部匯報中獲得了客戶方大部分的認可並可能獲得優秀外協專案的評價，而另乙個公司卻還得繼續申請延期（這一次是按違約處理要扣專案款）；後來專案結束我們專案組離開駐地，3月後
byteh
以專案經理的身份出現在客戶方去交付剩餘的需求並辦理尾款結付手續時，該公司的專案還在進行，而且還出現了一些生疏的面孔……
前一段，在北京遇到了當時對方專案組的一位哥們，簡單溝通後了解到，他已經離開了那家公司而公司的老闆是國內某最著名高校的教授……
綜上所述，
byteh
個人得出結論：在專案性軟體產品的開發過程中，快速原型法要得到相關人員的重視，或者說不要生搬硬套規則！
為了網友們閱讀，特蒐集些「」知識，如下文。
【原型法
原型法（
prototyping
）是20
世紀80
年代隨著計算機軟體技術的發展，特別是在關係資料庫系統（
relational data base system
，rdbs
）、***程式生成語言（
4th generation language
，4gl
）和各種系統開發生成環境產生的基礎上，提出的一種從設計思想、工具、手段都全新的系統開發方法。它摒棄了那種一步步周密細緻地調查分析，然後逐步整理出文字檔案，最後才能讓使用者看到結果的繁瑣作法。
快速原型法
通常簡稱為原型法，其核心是，用互動的，快速建立起來的原型取代了形式的、僵硬的（不允許更改的）大部頭的規格說明，使用者通過在計算機上實際執行和試用原型系統而向開發者提供真實的、具體的反饋意見。
原型法的工作步驟
利用原型法進行資訊系統的設計過程中，分四步進行：首先快速分析，弄清使用者
/設計者的基本資訊需求；然後構造原型，開發初始原型系統；之後，使用者和系統開發人員使用並評價原型；最後系統開發人員修改和完善原型系統。
原型法的優缺點
（
1）優點：符合人們認識事物的規律，系統開發循序漸進，反覆修改，確保較好的使用者滿意度；開發周期短，費用相對少；由於有使用者的直接參與，系統更加貼近實際；易學易用，減少使用者的培訓時間；應變能力強。（2
）缺點：不適合大規模系統的開發；開發過程管理要求高，整個開發過程要經過「修改
—評價—再修改
」的多次反覆；使用者過早看到系統原型，誤認為系統就是這個模樣，易使使用者失去信心；開發人員易將原型取代系統分析；缺乏規範化的文件資料。】
既然了解缺點，就要去改正去克服，「明知故犯」罪加一等！
博主推薦閱讀
：笨的方法往往最有效---寫在被評為推薦部落格
丟了東西，哪個網際網路大佬來幫我找
互動與零距離:得民心者得天下
管理的最高目標:1加1等於1
創業靠激情守業靠制度
如何制定好的方案之一:方案與紙上談兵
「快速原型法」在專案開發中的成功案例
專案型軟體的開發流程，通常會包括七個步驟 第二步 概要設計 第三步 詳細設計 第四步 編碼 第五步 測試 第六步 軟體交付準備 第七步 驗收與收尾工作。在專案型產品的開發過程中，依據軟體工程思想的標準，遵循 一步步的操作是最正統和最標準而且有效的做法，專案組人員的理解並落實這一點，整個專案就會朝著良...
在專案開發中應該遵循的準則
根據我公司實際情況，大致列出在專案開發中應遵循的步驟原則。在各程式設計師遵循原則的情況下，方能開發出健壯有效的程式，且能提高自己的程式設計素質。1.在專案開發初期應該有專案的詳細原型。鑑於程式設計師文件能力有限，可編寫出大致的專案需求文件，只列出軟體目的，功能模組即可。在設計原型中，應該以需求為主，...
類模板在專案開發中的應用
模板是c 型別引數化的多型工具。c 提供函式模板和類模板。模板定義以模板說明開始。類屬引數必須在模板定義中至少出現一次。同乙個類屬引數可以用於多個模板。類屬引數可用於函式的引數型別 返回型別和宣告函式中的變數。模板由編譯器根據實際資料型別例項化，生成可執行 例項化的函式。模板稱為模板函式 例項化的類...