软件原型以试探性的方式逐步逼近解决方案，它使需求更加真实，用例更加鲜活，是我们能进一步理解需求。但即使做一个简单的原型，也需要时间和资金。虽然原型可以降低软件项目失败的风险，但原型本身也会有风险。本文将介绍原型的四大风险和七大成功原则，供参考！

一、原型面临的四大风险

【风险一】原型发布的压力

项目干系人会看到一个可以运行的可抛弃的原型，从而得出产品快完成的结论。😱

可抛弃的原型，即用于验证某个需求、方案，注重快速实现和及时修改。其验证结果可以复用，但不管其与实际产品多么相似，其代码和设计不可用于产品。因为它仅仅是一个模型，一次模拟，一个实验。

应对策略：
1、坚持原则，不给自己和客户挖坑
2、在原型制作前和展示前，统一对原型价值的理解，是可抛弃型原型？还是迭代的第一版？
3、让原型看起来简陋一些，让客户认为必须需要至少需要一次迭代才行。如给客户看一个完全很low的色彩方案，让客户产生嫌弃的心理。

【风险二】为细节所累

用户把注意力放在与UI有关的外观和操作细节上。😔

如果使用一个看似很真实的原型，用户很容易忘记项目还在需求阶段和需要关注的问题。
应对策略：
提醒用户原型限定于显示画面、功能和导航选项，可以消除不确定的需求。

【风险三】不现实的性能预期

用户根据原型的性能来推断最终产品的预期性能。😫

创建模型时使用的工具或语言，与产品开发环境中工具或语言存在效率方面的差异。

应对策略：
为了使原型更真实的反应最终产品的预期性能，在构建原型时需要考虑时间上的延迟，或者让原型看起来还没有准备好。如在屏幕上放置一些信息，声明其并不代表最终的产品。

【风险四】对原型投入过多

在原型上投入太多的精力，导致开发团队没有精力和时间，不得不把原型作为产品，或者进入混乱的产品实现。💦

如对整个解决方案而不是针对最不确定的、高风险的或者复杂的部分进行建模，就是这类情况。
应对策略：
如何需求已经充分定义，关键的人机交互、架构问题已经基本解决，则投入已经足够了。

二、原型成功的六大原则

软件原型可以加快开发进程、提高客户满意度以及产出高质量的产品。为了有效使用原型，建议遵循以下原则：

【原则一】将原型作为正式工作

在项目计划中，包含与原型有关的任务。为开发、评估和修改原型安排必要的时间和资源。

【原则二】明确原型目标和成果

在创建原型之前，要标注原型的目的和最终的产出，并和有关方达成一致理解。是要做一个抛弃型的原型，仅保留所提供的知识、见解，还是要在原型基础上继续构建，直至迭代完成最终产品。

【原则三】做好开发多个原型的计划

很难一次就能得到正确的原型，这也要做原型的初衷和缘由。

【原则四】低成本、高效率

如果选择创建抛弃型的原型，则要尽可能快的实现，尽可能低成本的实现。
以最小的精力完成问题的回答，解决需求中的不确定的部分。
不要试图将抛弃型原型做的尽善尽美。
不在抛弃型原型中，增加输入数据验证、保护性编码等异常处理代码。

【原则五】已确定，不原型

不要对已经理解的需求创建原型，除非你是要研究其他设计方案。

【原则六】原型中的业务数据要合理

如果要在原型中现实一些数据时，这些数据一定要尽量合理。这样参与评估的人员就不会被不真实的数据分散宝贵的注意力。

【原则七】原型不等于需求文档

不要指望用原型来代替正式的需求描述文档。原型只是屏幕表面的展示，而这后面还有大量的功能，这些功能需要在需求文档中记录下来，以保证需求的完整、明确、可跟踪。

三、实践练习

第一步：识别出项目中容易混淆的需求或风险很高的功能
第二步：简要画出一个用户界面
第三步：邀请用户浏览原型，模拟一个应用场景
第四步：记录初始需求中不完整或不正确的地方
第五步：修改并重新评估

四、参考

《Software Requirements 需求分析》（第3版）[美]Karl Wiegers
、Joy bzeatty