來自：系統分析員之窗 作者：Blueski
在上圖中已經清楚地描述了原型的處理過程，值得一提的是，原型不僅用於給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數程序員對技術的興趣遠遠高於對需求的興趣，因此其對系統的理解並不會比市場人員或者項目經理理解的深多少。這裏的公司內部人員角色可以包括很多，系統分析員/程序員自身、項目經理、部門經理、用戶代表、領域專家、測試人員等等，不同的角色往往會在其不同立場對系統提出中肯的意見來。
另外值得注意的是界面設計的引入。我們認爲將界面風格在原型階段即進行基本確定是一種優化的做法，因爲軟件前期對界面的確定可以避免後期開發時對界面進行統一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統的好感，當然，但願用戶不要只是欣賞界面而忽略了他們對系統功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那麼整個原型幾乎是白做了。
5 使用原型方法的相關問題探討
5.1 爲什麼要採用原型法？
原型對一個項目取得成功具有重要的意義。俗話說：隔行如隔山，實際上軟件公司很難保證其製作的軟件正好就是用戶所需要的，用戶也很難一次性把其真實的要求完全提交，開始階段提出的往往只是對系統的期望，和比較模糊的設想而已。而原型系統爲用戶提供了一個靶子，看着原型系統，用戶往往就能進一步提出他們的真正想法。顯然軟件公司明確用戶需求的最佳方式就是爲用戶提供原型並由用戶進行評價。
也許，跳過原型可以節省時間和前期成本，但你應該注意到，跳過原型的話，後期變更的成本會明顯增加。
5.2 爲什麼在需求說明書之外需要原型？
1）眼見爲實，文字具有歧義性，不同的人理解都不相同；
2）最終用戶往往在看到一套可運行的系統的基礎上，纔可能提出其真實的意見，如果到最終提交時纔看到這樣的系統就爲時太晚。這也是以前無數軟件開發留下的教訓；
3）便於發現問題，及時糾正；
4）便於進一步展開，並取得用戶的細節需求；
5）體現原型的其它功能：便於公司內部如經理、市場部等對軟件提出意見，便於開發人員對整個產品達成統一認識，等等。對內部人員來說，同樣地，一套形象的原型也遠勝過一堆專業術語文字；也就是說，原型對軟件公司內部也十分重要。這些評價工作無形之中改進了項目質量。
5.3 原型方法有什麼風險？
任何方法都是有利有弊，在我們可以探討一下原型方法可能存在的風險。以下是一般軟件公司所擔心的風險：需要付出前期進度和人力成本；由於程序員對問題的不瞭解而效率低下，受客戶牽制而在原型上反覆修改；因爲倉促設計而做不利於進一步在其基礎上繼續開發；由於過早展示原型給客戶，使得客戶可能提高其期望值，並提出更多離譜的要求，等等。
值得一提的是原型方法的主要價值之一就是儘早揭示軟件中可能存在的風險及不確定因素，尤其是關於用戶需求一致性方面的風險。
5.4 原型方法和其它方法或過程的關係如何，是否一致？
生命週期法中並不包括原型，或者說沒有明確提供原型的概念和定義。原型可以認爲是需求分析中的一個子部分。另外，應該說原型方法是對生命週期法的有益補充和完善。
RUP中是最優化的統一軟件過程，但RUP中似乎沒有提到原型，RUP的核心過程是在迭代中精化。我個人的見解是，原型非常類似於第一次迭代的過程和結果。實際上，如果把原型看作爲第一輪交付的成果，那麼原型的很多不利之處，諸如花費前期成本等等，這些擔心都將變得不復存在。
XP方法對原型非常推崇，這是因爲XP方法非常強調需求的重要性，甚至要求客戶參與開發過程。但原型方法和XP也有區別。XP是分批交付，先做一個幾個功能點的版本，完成後再每個開發週期往上面加其它功能點，而原型法一般要求做出比較完整，能覆蓋主要功能點的粗略的版本。XP方法仁者見仁，智者見智，不一而舉。
5.5 如何避免項目團隊做原型的時候出現部分人員閒置？
在項目管理中，對人力資源的調配應和項目進展相匹配。實際上在用戶接觸到原型製作的同時，可以進行項目計劃、架構設計、技術培訓以及技術難點攻關等等。
如果從廣義上理解原型的話，架構設計者甚至可以設計出一種用戶開發團隊使用的所謂框架原型，包含了主要的設計成分、模板和示例。
比較理想的結果是，當原型完成後，需求分析、架構設計和界面風格設計都趨於完成，從這一點可以看到，原型方法可以作爲快速軟件開發的重要手段。
5.6 如果避免項目在原型上停滯不前？
應使用有經驗的開發人員，避免因爲程序員不熟悉業務而延誤進度；不要在界面設計上猶豫不決而佔據時間；如果用戶對原型提出了很多意見，其中部分比較明確的意見可以在開發過程中進行實現；和客戶的交流應該簡潔明瞭，而不是似是而非；另外，原型方法在項目過程中佔據的時間應該在項目計劃中保留出來，而不僅僅是隱含在需求調研與分析的一個部分。
5.7 如何避免用戶看了原型後漫無邊際地提要求？
首先，應該充分尊重客戶，想想其它行業的服務質量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關懷，等等。確實，客戶提出的思路可能和你已經形成的思路不同，一下子打亂了你的思路，也許項目經理並不介意，但這確是讓設計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認爲用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。
其次應該進行坦誠協商，多數用戶其實都是通情達理的。如果你在簽訂合同時答應滿足任何要求，而此時又無法忍受用戶的要求，那麼孰是孰非應是題外之意了。一般來說，比較合理的做法可以通過增加費用、延長進度或者把需求實現分階段來提交，以保持工作的延續性。對有些軟件，尤其是信息管理系統來說，客戶的實施時間其實並不是主要的，客戶最需要的不是及時，而是合用。
其實，客戶有着很多種類型，確實，個別客戶會參考同類產品來提要求，極個別用戶並不真正懂得計算機技術而對技術路線、技術手段等提出其意見，等等。但我們爲什麼還可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露並解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然後等到用戶提出反對後，再提出補充收費，如果喜歡，也無話可說。
總之，原型應本着對軟件需求的基本理解來做，這樣才能預防不一致性的發生。尤其應該針對不清楚的地方製作原型，從而儘量暴露問題，引發用戶的聯想，不能迴避問題，掩蓋問題（以免用戶提出太多的想法），很多問題雖然一時掩蓋了，但最終還是要發生的。
5.8 如何避免在原型基礎上繼續開發時的可維護性降低？
問題是這樣的，製作原型時常希望快速提供原型，往往不及對軟件結構或者數據庫進行細緻設計。所以在此基礎上繼續設計和開發的話，有必要在開發前先進行調整。同時，在設計原型前就有必要確定，該原型是要拋棄的，還是要演化要繼承的。對於要演化的原型，其設計不能過於粗略，顯然這直接影響到今後的開發成本。
6 小結
原型方法是可視化的方法，已成爲快速軟件開發常用的手段。軟件公司或部門一旦得到了原型方法的回報，就會堅持使用。原型不是絕對必要，但非常有意義。
關鍵字：原型，尊重客戶，原型評價，可視化，變更成本，開發團隊藍圖
1 引子
太多了！終於簽下合同-->得到了“正式”的客戶提供的“需求書”的幾片紙-->憑藉自己的理解立即投入開發-->“木已成舟”，生米終於熬成粥-->用戶拒絕接受？-->艱難地修改，反覆修改，開發人員厭倦了，而用戶對系統用之無味，棄之可惜，遂成雞肋。-->由此後期收款遙遙無期，軟件公司不再和用戶保持溝通-->互相埋怨，扯皮由此而生。或者，一個項目拆成爲多期，從而收取一部分款項，而很多的開發都作廢。這樣的案例真是何其多也！
究其主要原因，與其說是沒有搞定關鍵客戶，或者項目管理不當，不如說是沒有幫助客戶解決其問題，對客戶真正的需求研究不夠。實際上，原型方法是解決此類問題、確保項目成功的最佳途徑。
我在寫此文的同時，也試圖尋找資料，不知道是本就沒有，還是自己所不幸而未找到。看來原型並沒有明確的標準，而目前不同軟件公司的理解和做法各不相同也就不奇怪了。但從軟件過程的角度來考察，原型法仍有着通用的優化的做法。本文試圖從作者的實踐經驗出發，對原型方法進行思考與探討。
另外，本文是發散型的，在研究原型的同時，也討論了原型相關的內容。原型本質上有些象是拋磚引玉，而本文也旨在拋磚引玉，但無意於一概地論定什麼。
2 什麼是原型
2.1 原型的定義
原型(prototype)即把系統主要功能和接口通過快速開發製作爲“軟件樣機”，以可視化的形式展現給用戶，及時徵求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用於徵求內部意見，作爲分析和設計的接口之一，可方便於溝通。
2.2 原型的主要價值
原型法主要價值是可視化，強化溝通，降低風險，節省後期變更成本，提高項目成功率。一般來說，採用原型法後可以改進需求質量；雖然投入了較多先期的時間，但可以顯著減少後期變更的時間；原型投入的人力成本代價並不大，但可以節省後期成本；對於較大型的軟件來說，原型系統可以成爲開發團隊的藍圖；另外，原型通過充分和客戶交流，還可以提高客戶滿意度。
2.3 基本要求
對原型的基本要求包括：
* 體現主要的功能；
* 提供基本的界面風格；
* 展示比較模糊的部分，以便於確認或進一步明確，防患於未然。
* 原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。
2.4 處理方法
原型的處理方法基本上有2種不同類型，即拋棄型和演化型（不同的軟件工程書籍稱發不同，實質意義則類似）。可以拋棄原型，在取得的明確需求基礎上重新開始設計與開發；也可在原型的基礎上繼續開發。一般小項目不採用拋棄型原型，否則成本和代價似乎會偏高。
2.5 表達工具
原型的表達工具可以有很多，如果是演化型的原型，當然優先選用軟件本身的開發工具。否則還可以應用各種快速顯示的工具，例如，HTML，Powerpoint等等，只要能夠充分而形象地表達就可以了。
根據筆者的經驗，在原型系統中，可以採用一些與常規不同的做法，例如，可以在界面上比較顯著的地方寫明當前模塊或界面的主要目的，由哪些角色操作，能解決其什麼問題。這麼做可以使得用戶或開發團隊成員一開始就有非常清楚的概念；又如，對於決策分析，你可以直接把一些分析結果畫成圖，並且配上一些文字說明，這樣可以避免輸入大量初始數據，等等。
3 原型在軟件過程的地位
軟件的根本目的是實現用戶的需求，提供用戶日常使用，解決用戶工作中有所不便的問題，提高其工作效率，改進質量，加強管理控制，最終直接或間接地提高其效益。因此軟件開發本質上就是需求的處理和實現，而軟件原型對需求確定來說具有非常重要的意義。原型方法包括2個基本過程，即原型製作和原型評價。
如果從需求角度看軟件過程，我們不妨可以把軟件過程這樣劃分：
3.1 需求收集和分析
蒐集需求得到需求說明書，瞭解軟件要做什麼，做成什麼樣，解決用戶什麼問題。
這時候軟件公司以書面文檔方式提出，例如需求問詢表等。
3.2 提供原型並進行評價
制定原型開發計劃，根據用戶需求及不確定的高風險部分進行原型開發，在內部進行原型評價，請客戶進行原型評價，以保證確實反映了用戶的真正想法。
3.3 實現需求
當前的軟件開發過程常常採用迭代方式進行開發，逐步求精，以降低風險和成本。對迭代的次數，每次迭代的里程碑，要實現的目標，及可提交的成果必須有可驗證的清晰的計劃。項目管理是一種藝術，迭代規劃及里程碑定義都是一種挑戰、一種藝術，但項目管理不在本文討論範圍。
3.4 需求變更
需求變更是正常的，也是難免的，應允許用戶和開發團隊自身對需求進行變更。變更處理的關鍵在於跟蹤和控制，如何使產生的影響應得到控制，這屬於配置管理的內容，也不在本文討論範圍。
原型在軟件過程中的定位如下圖所示：
1 引子
太多了！終於簽下合同-->得到了“正式”的客戶提供的“需求書”的幾片紙-->憑藉自己的理解立即投入開發-->“木已成舟”，生米終於熬成粥-->用戶拒絕接受？-->艱難地修改，反覆修改，開發人員厭倦了，而用戶對系統用之無味，棄之可惜，遂成雞肋。-->由此後期收款遙遙無期，軟件公司不再和用戶保持溝通-->互相埋怨，扯皮由此而生。或者，一個項目拆成爲多期，從而收取一部分款項，而很多的開發都作廢。這樣的案例真是何其多也！
究其主要原因，與其說是沒有搞定關鍵客戶，或者項目管理不當，不如說是沒有幫助客戶解決其問題，對客戶真正的需求研究不夠。實際上，原型方法是解決此類問題、確保項目成功的最佳途徑。
我在寫此文的同時，也試圖尋找資料，不知道是本就沒有，還是自己所不幸而未找到。看來原型並沒有明確的標準，而目前不同軟件公司的理解和做法各不相同也就不奇怪了。但從軟件過程的角度來考察，原型法仍有着通用的優化的做法。本文試圖從作者的實踐經驗出發，對原型方法進行思考與探討。
另外，本文是發散型的，在研究原型的同時，也討論了原型相關的內容。原型本質上有些象是拋磚引玉，而本文也旨在拋磚引玉，但無意於一概地論定什麼。
2 什麼是原型
2.1 原型的定義
原型(prototype)即把系統主要功能和接口通過快速開發製作爲“軟件樣機”，以可視化的形式展現給用戶，及時徵求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用於徵求內部意見，作爲分析和設計的接口之一，可方便於溝通。
2.2 原型的主要價值
原型法主要價值是可視化，強化溝通，降低風險，節省後期變更成本，提高項目成功率。一般來說，採用原型法後可以改進需求質量；雖然投入了較多先期的時間，但可以顯著減少後期變更的時間；原型投入的人力成本代價並不大，但可以節省後期成本；對於較大型的軟件來說，原型系統可以成爲開發團隊的藍圖；另外，原型通過充分和客戶交流，還可以提高客戶滿意度。
2.3 基本要求
對原型的基本要求包括：
* 體現主要的功能；
* 提供基本的界面風格；
* 展示比較模糊的部分，以便於確認或進一步明確，防患於未然。
* 原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。
2.4 處理方法
原型的處理方法基本上有2種不同類型，即拋棄型和演化型（不同的軟件工程書籍稱發不同，實質意義則類似）。可以拋棄原型，在取得的明確需求基礎上重新開始設計與開發；也可在原型的基礎上繼續開發。一般小項目不採用拋棄型原型，否則成本和代價似乎會偏高。
2.5 表達工具
原型的表達工具可以有很多，如果是演化型的原型，當然優先選用軟件本身的開發工具。否則還可以應用各種快速顯示的工具，例如，HTML，Powerpoint等等，只要能夠充分而形象地表達就可以了。
根據筆者的經驗，在原型系統中，可以採用一些與常規不同的做法，例如，可以在界面上比較顯著的地方寫明當前模塊或界面的主要目的，由哪些角色操作，能解決其什麼問題。這麼做可以使得用戶或開發團隊成員一開始就有非常清楚的概念；又如，對於決策分析，你可以直接把一些分析結果畫成圖，並且配上一些文字說明，這樣可以避免輸入大量初始數據，等等。
3 原型在軟件過程的地位
軟件的根本目的是實現用戶的需求，提供用戶日常使用，解決用戶工作中有所不便的問題，提高其工作效率，改進質量，加強管理控制，最終直接或間接地提高其效益。因此軟件開發本質上就是需求的處理和實現，而軟件原型對需求確定來說具有非常重要的意義。原型方法包括2個基本過程，即原型製作和原型評價。
如果從需求角度看軟件過程，我們不妨可以把軟件過程這樣劃分：
3.1 需求收集和分析
蒐集需求得到需求說明書，瞭解軟件要做什麼，做成什麼樣，解決用戶什麼問題。
這時候軟件公司以書面文檔方式提出，例如需求問詢表等。
3.2 提供原型並進行評價
制定原型開發計劃，根據用戶需求及不確定的高風險部分進行原型開發，在內部進行原型評價，請客戶進行原型評價，以保證確實反映了用戶的真正想法。
3.3 實現需求
當前的軟件開發過程常常採用迭代方式進行開發，逐步求精，以降低風險和成本。對迭代的次數，每次迭代的里程碑，要實現的目標，及可提交的成果必須有可驗證的清晰的計劃。項目管理是一種藝術，迭代規劃及里程碑定義都是一種挑戰、一種藝術，但項目管理不在本文討論範圍。
3.4 需求變更
需求變更是正常的，也是難免的，應允許用戶和開發團隊自身對需求進行變更。變更處理的關鍵在於跟蹤和控制，如何使產生的影響應得到控制，這屬於配置管理的內容，也不在本文討論範圍。
原型在軟件過程中的定位如下圖所示：
圖1 軟件原型的定位
實際上我們可以把原型看得更爲廣義一些。任何用戶或者內部演示的材料，都可以看作爲原型。例如，如果你的產品是某種通用的或者行業解決方案，雖然你其實還沒有產品，但先做出一個原型，再加一個漂亮的白皮書，就可以在市場上進行預銷售了。
對於拋棄型和演化型原型來說，也不是絕對的。演化型原型中必然會不斷拋棄一些內容，而拋棄型原型，儘管在完成歷史使命後不再使用，但很多思想以及部分設計還是可以繼承的。
4 原型方法的一般過程
基於原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。採用原型法的一般過程如下圖所示：
圖2：原型法的處理過程實際上我們可以把原型看得更爲廣義一些。任何用戶或者內部演示的材料，都可以看作爲原型。例如，如果你的產品是某種通用的或者行業解決方案，雖然你其實還沒有產品，但先做出一個原型，再加一個漂亮的白皮書，就可以在市場上進行預銷售了。
對於拋棄型和演化型原型來說，也不是絕對的。演化型原型中必然會不斷拋棄一些內容，而拋棄型原型，儘管在完成歷史使命後不再使用，但很多思想以及部分設計還是可以繼承的。
4 原型方法的一般過程
基於原型方法在整個需求過程中的地位，我們需要把原型法和需求處理放在一起進行討論。採用原型法的一般過程如下圖所示：
在上圖中已經清楚地描述了原型的處理過程，值得一提的是，原型不僅用於給用戶或者最終用戶進行評議，同時完全可以在公司內部組織評議，看看我們周圍吧，多數程序員對技術的興趣遠遠高於對需求的興趣，因此其對系統的理解並不會比市場人員或者項目經理理解的深多少。這裏的公司內部人員角色可以包括很多，系統分析員/程序員自身、項目經理、部門經理、用戶代表、領域專家、測試人員等等，不同的角色往往會在其不同立場對系統提出中肯的意見來。
另外值得注意的是界面設計的引入。我們認爲將界面風格在原型階段即進行基本確定是一種優化的做法，因爲軟件前期對界面的確定可以避免後期開發時對界面進行統一調整所帶來的不必要的成本花費，良好的界面也可以使客戶增加對系統的好感，當然，但願用戶不要只是欣賞界面而忽略了他們對系統功能的思考。要知道，如果僅僅是讓用戶看到美觀的界面，那麼整個原型幾乎是白做了。
5 使用原型方法的相關問題探討
5.1 爲什麼要採用原型法？
原型對一個項目取得成功具有重要的意義。俗話說：隔行如隔山，實際上軟件公司很難保證其製作的軟件正好就是用戶所需要的，用戶也很難一次性把其真實的要求完全提交，開始階段提出的往往只是對系統的期望，和比較模糊的設想而已。而原型系統爲用戶提供了一個靶子，看着原型系統，用戶往往就能進一步提出他們的真正想法。顯然軟件公司明確用戶需求的最佳方式就是爲用戶提供原型並由用戶進行評價。
也許，跳過原型可以節省時間和前期成本，但你應該注意到，跳過原型的話，後期變更的成本會明顯增加。
5.2 爲什麼在需求說明書之外需要原型？
1）眼見爲實，文字具有歧義性，不同的人理解都不相同；
2）最終用戶往往在看到一套可運行的系統的基礎上，纔可能提出其真實的意見，如果到最終提交時纔看到這樣的系統就爲時太晚。這也是以前無數軟件開發留下的教訓；
3）便於發現問題，及時糾正；
4）便於進一步展開，並取得用戶的細節需求；
5）體現原型的其它功能：便於公司內部如經理、市場部等對軟件提出意見，便於開發人員對整個產品達成統一認識，等等。對內部人員來說，同樣地，一套形象的原型也遠勝過一堆專業術語文字；也就是說，原型對軟件公司內部也十分重要。這些評價工作無形之中改進了項目質量。
5.3 原型方法有什麼風險？
任何方法都是有利有弊，在我們可以探討一下原型方法可能存在的風險。以下是一般軟件公司所擔心的風險：需要付出前期進度和人力成本；由於程序員對問題的不瞭解而效率低下，受客戶牽制而在原型上反覆修改；因爲倉促設計而做不利於進一步在其基礎上繼續開發；由於過早展示原型給客戶，使得客戶可能提高其期望值，並提出更多離譜的要求，等等。
值得一提的是原型方法的主要價值之一就是儘早揭示軟件中可能存在的風險及不確定因素，尤其是關於用戶需求一致性方面的風險。
5.4 原型方法和其它方法或過程的關係如何，是否一致？
生命週期法中並不包括原型，或者說沒有明確提供原型的概念和定義。原型可以認爲是需求分析中的一個子部分。另外，應該說原型方法是對生命週期法的有益補充和完善。
RUP中是最優化的統一軟件過程，但RUP中似乎沒有提到原型，RUP的核心過程是在迭代中精化。我個人的見解是，原型非常類似於第一次迭代的過程和結果。實際上，如果把原型看作爲第一輪交付的成果，那麼原型的很多不利之處，諸如花費前期成本等等，這些擔心都將變得不復存在。
XP方法對原型非常推崇，這是因爲XP方法非常強調需求的重要性，甚至要求客戶參與開發過程。但原型方法和XP也有區別。XP是分批交付，先做一個幾個功能點的版本，完成後再每個開發週期往上面加其它功能點，而原型法一般要求做出比較完整，能覆蓋主要功能點的粗略的版本。XP方法仁者見仁，智者見智，不一而舉。
5.5 如何避免項目團隊做原型的時候出現部分人員閒置？
在項目管理中，對人力資源的調配應和項目進展相匹配。實際上在用戶接觸到原型製作的同時，可以進行項目計劃、架構設計、技術培訓以及技術難點攻關等等。
如果從廣義上理解原型的話，架構設計者甚至可以設計出一種用戶開發團隊使用的所謂框架原型，包含了主要的設計成分、模板和示例。
比較理想的結果是，當原型完成後，需求分析、架構設計和界面風格設計都趨於完成，從這一點可以看到，原型方法可以作爲快速軟件開發的重要手段。
5.6 如果避免項目在原型上停滯不前？
應使用有經驗的開發人員，避免因爲程序員不熟悉業務而延誤進度；不要在界面設計上猶豫不決而佔據時間；如果用戶對原型提出了很多意見，其中部分比較明確的意見可以在開發過程中進行實現；和客戶的交流應該簡潔明瞭，而不是似是而非；另外，原型方法在項目過程中佔據的時間應該在項目計劃中保留出來，而不僅僅是隱含在需求調研與分析的一個部分。
5.7 如何避免用戶看了原型後漫無邊際地提要求？
首先，應該充分尊重客戶，想想其它行業的服務質量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關懷，等等。確實，客戶提出的思路可能和你已經形成的思路不同，一下子打亂了你的思路，也許項目經理並不介意，但這確是讓設計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認爲用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。
其次應該進行坦誠協商，多數用戶其實都是通情達理的。如果你在簽訂合同時答應滿足任何要求，而此時又無法忍受用戶的要求，那麼孰是孰非應是題外之意了。一般來說，比較合理的做法可以通過增加費用、延長進度或者把需求實現分階段來提交，以保持工作的延續性。對有些軟件，尤其是信息管理系統來說，客戶的實施時間其實並不是主要的，客戶最需要的不是及時，而是合用。
其實，客戶有着很多種類型，確實，個別客戶會參考同類產品來提要求，極個別用戶並不真正懂得計算機技術而對技術路線、技術手段等提出其意見，等等。但我們爲什麼還可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露並解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然後等到用戶提出反對後，再提出補充收費，如果喜歡，也無話可說。
總之，原型應本着對軟件需求的基本理解來做，這樣才能預防不一致性的發生。尤其應該針對不清楚的地方製作原型，從而儘量暴露問題，引發用戶的聯想，不能迴避問題，掩蓋問題（以免用戶提出太多的想法），很多問題雖然一時掩蓋了，但最終還是要發生的。
5.8 如何避免在原型基礎上繼續開發時的可維護性降低？
問題是這樣的，製作原型時常希望快速提供原型，往往不及對軟件結構或者數據庫進行細緻設計。所以在此基礎上繼續設計和開發的話，有必要在開發前先進行調整。同時，在設計原型前就有必要確定，該原型是要拋棄的，還是要演化要繼承的。對於要演化的原型，其設計不能過於粗略，顯然這直接影響到今後的開發成本。
6 小結
原型方法是可視化的方法，已成爲快速軟件開發常用的手段。軟件公司或部門一旦得到了原型方法的回報，就會堅持使用。原型不是絕對必要，但非常有意義。
