原型值得一千行代码

一张图片胜过千言万语。 原型价值一千行代码。 产品管理和敏捷开发的两个关键要素是启发和反馈。 低保真度伪影可以显着改善两者。 抛光，编纂的原型可以创建阻止你获得通信的好处的问题。

原型反模式

大卫·伯恩斯坦（David Bernstein）撰写了三篇有关敏捷领域中的原型制作的快速阅读文章。 第一个描述了原型制作的主要反模式- 错误设定的期望 。

当我在不同的屏幕上浏览他时，我可以看到他开始变得不安。 当我说话时，我可以看到他变得越来越苍白和绷紧，好像他看到了一个幽灵。 过了一会儿，我问他是否还好。 他最后说：“您是要告诉我，我刚给您一张不到10万美元的支票，花了不到一周的时间？”
原型警告

第二篇文章快速提醒了原型的目标之一。

原型的目的是从其他人那里获得反馈或验证设计方法是否可行。 这样做时，我们通常只关心代码中的“快乐之路”。
原型不是产品

大卫的第三篇文章探讨了关于期望的错误设定的更多内容，并提供了与电影业的相似之处。

原型是没有最终产品的鲁棒性的粗略草图，当我们向他们展示他们的项目的半熟版本以供反馈时，即使他们知道它尚未完成，也会使用户感到困惑。
餐巾纸上的敏捷原型设计

David的建议（很好）主要是关于使用低保真原型以避免干扰启发和反馈过程。 用户体验社区中的人们很早就知道了这一点，并相应地调整了他们的流程。 早在2006年，我就原型保真度写了一篇文章，作为探索在需求收集中利用这种见解的方法的一部分。 尤其是，原型设计是引发隐式需求的好方法， 隐式需求是客户或利益相关者认为您知道或不希望告诉您的那些隐性 （“您应该已经问过！”）需求。

多层次的互动

David最初专注于“这种方法行得通吗？” 获得设计反馈的要素–并通过推断进行了一些低保真度的用户接受度测试，证明所提出的方法将满足您的客户要求。 Jan Miksovsky撰写了一篇出色的文章（也在2006年发表）， 根据您在设计过程中的位置，该文​​章对在 原型中构建多少保真度提供了出色的指导。 这很重要–在设计过程的不同阶段所需的反馈类型各不相同。 正如David指出的那样，Jan提出第一批原型应该是粗略的草图。 Jan继续展示了如何以及何时为原型添加更多保真度（请阅读Jan的文章以查看他出色的视觉示例）。 就像我说的那样，用户体验社区对此早已了解。

原型适用于双向通讯

关键因素以及创建原型的原因是进行双向通信。 原型不仅仅是关于您设计的状态更新。

原型是对话的开始。

原型设计不仅对设计对话有用，对于理解您的需求也至关重要。 是的，原型将为您提供有关所建议解决方案的设计执行的反馈。 更重要的是，原型可以帮助您确保解决正确的市场问题。

原型不仅仅是接口模型

我们考虑的第一件事以及您到目前为止在本文中所阅读的所有内容都是关于在产品的用户界面上获得反馈的。 原型对于收集业务规则* ，了解系统复杂性以及定义，阐明和验证需求也很有用 。

*在那篇文章中，我将原型显示为对收集业务规则“无用”。 当时，我只考虑接口模型，而不考虑其他原型。

当需要有关用户交互的反馈时，请使用界面模型。 当您需要有关产品其他方面的反馈时，请使用其他工件。 您也可以在收集市场数据时将原型用作主动监听技术 。 有很多方法可以画画来帮助交流 。

我经常使用流程图来制作流程原型。 在这些流程图中，决策钻石是这些产品最初表现方式的原型。 这些决策钻石为要创建的产品中的业务规则实施提供了原型 。 本着DRY的精神（请勿重复），快速完善流程图可以作为需求的持久产物。 就像用户界面模型一样。

在更复杂的场景中，我还使用UML状态图和数据流程图来原型化行为。

在上周有关风险管理和发布节奏的文章中的预先计划部分中 ，我谈到了人们为构想尚不存在的产品而需要进行的思维飞跃 。 原型就像大型跳板，可以帮助人们跨越想象的鸿沟。

重要安全提示

不要将错误的原型（模型，流程图等）用于错误的对话或与错误的利益相关者联系。 显示何时（在何处执行）业务规则（在设计过程中）对于获得有关您对这些规则的解释和潜在体现的反馈非常有用。 如果您尝试与不是这些策略所有者的人（例如代表用户）进行对话，那将是一场灾难。 有时，策略是由努力阅读图表的非技术人员“拥有”的。 您可能必须引导他们逐步了解图表的工作原理。 他们很聪明–他们会做到的。

请记住-使用正确的原型强调正确的想法，并获得正确的反馈。

参考： 业务分析|我们的JCG合作伙伴 Scott Sehlhorst提供的原型价值一千行代码 | 产品管理| 软件需求博客。

翻译自: https://www.javacodegeeks.com/2012/08/a-prototype-is-worth-thousand-lines-of.html