您如何说服管理层扔掉原型？

我喜欢将原型设计作为将UI展示在用户面前的快速有效方法。

但是，很多时候，管理人员都无法自拔，原型被拖入主流开发中。

您如何管理管理层不这样做？

使用Microsoft SketchFlow之类的工具，或使用其他语言或平台制作原型，几乎不可能集成到主要开发中。

还有一篇有关显示屏幕截图和原型的joelonsoftware文章，他在其中使未实现和未工作的方面明显损坏/未实现，从而明确了仍需要完成的工作。

重要推论二。如果您向非程序员展示一个具有100％漂亮用户界面的屏幕，他们会认为该程序即将完成。

...

您能对此做什么？一旦您了解了Iceberg Secret，就可以轻松使用它。了解在黑暗的房间中使用投影仪进行的任何演示都将与像素有关。如果可以，请以未完成的部件看起来未完成的方式构建UI。例如对于工具栏上的图标使用草稿，直到该功能存在。在构建Web服务时，您可能需要考虑在构建这些功能之前实际上从主页中忽略这些功能。这样，随着构建的内容越来越多，人们可以观看主页从3个命令变为20个命令。

因此，尝试使用Photoshop而不是Visual Studio或类似方式制作原型。

不要使用工作代码进行原型设计。用铅笔和纸，或者一个软件原型等同。

使用Mockups感觉就像是绘图，但是由于它是数字的，因此您可以轻松地进行调整和重新排列。团队可以提出一个设计并在会议过程中实时对其进行迭代。

使用纸张的好处是团队成员可以轻松加入，每个人都知道这只是一张空白纸。这使它显得不那么珍贵。

切勿破坏代码的质量。

编写垃圾代码是不正确的。

正如其他张贴者所建议的那样，您可以通过使用特定的工具进行模拟来实现此目的。

但是，构建原型有不同的原因。有时您无需编写代码就可以显示所需的内容，但事实并非如此。利益相关者可能希望您演示功能的技术可行性。

构建绝对最精益的东西，您可以用来演示功能/证明概念。省略其他任何内容。

对于UI功能，请确保您没有在服务器上开发任何东西-完全不要触摸它。再次开发内置的模拟/伪造。

如果您需要努力使UI符合应用程序其余部分的样式，请不要打扰。如果它看起来足够好而没有任何努力，则可以更改颜色以使其突出，甚至可以使用水印来表明它是原型。

我发现最有可能导致原型转化为生产代码的人是销售人员。他们将把您的产品卖给新客户-没有此新功能，客户将不会签名。你不能责怪他们，他们有目标。小心他们；确保他们不会让您拿走表明它是原型的东西。您必须坚持自己的立场-无论如何，他们可能都不应该误导客户。

您的管理层可能会开始迫使您将原型逐步变成生产代码，如果您遵循我的第一条建议从不编写糟糕的代码，那么您应该没有问题。逐渐地，您可以毫不妥协地构建软件。

然后，如果管理层开始迫使您降低质量，您必须问自己为什么。他们是被动的吗？弱？绝望？这些都不是在公司任职的好理由。

真的很简单。告诉他们，如果他们最终把这个马车烂摊子展示出来，他们最终将失去他们最喜欢的客户。

是的，请他们把握机会，如果他们真的更了解。

最后：请不要说原型具有特定的错误A，B和C。然后您将被修复此错误，并且管理层将声称它们将精力投入了准备生产软件的过程。

这些天，这些业绩奖金和未来的股票赠款很有可能会听。

首先回避问题。不要完成它。我的意思是说不要使其看起来漂亮或不适合网站上的现有样式。目标只是尽可能地获得最原始的工作版本，以便您可以看到非常基本的UI流程正常工作。如果您将现有的网站样式放在上面或过度修饰，他们将假设您可以“插入”。管理就像《星际迷航》中的Pakleds。他们只是想让您“成功”。您似乎越做好准备，他们就越会想到它。

如果那不能解决您的问题，请至少在一家拥有知名品牌的公司工作一年。将您的电子邮件和号码放在在线简历上，您将用棍子与招聘人员进行反击，这将使您在知道他们在做什么并且可以找到新工作的开发人员的信心下对他们说“绝对不是”明天，希望您在此问题上的专业知识得到认真对待。

我目前正在开发一个代码库，该代码库不包含Rails，.NET和Java三重堆栈。我们坚持使用Rails的原因是因为原型是在Rails中完成的，该公司的最高负责人说“随它去吧”。有时我们需要拒绝。只要我们不一直这样做，他们就应该认真对待我们。

但是，是的，无论您使用原型做什么，都要确保它从丑陋开始。

不用担心。

如果您坐下来并为“原型”扔掉UI控件，那么您应该自动放弃该设计的原因就完全为零。如果它足以显示管理能力，那么它是开始编写“真实”程序的好地方。

从原型用户界面过渡到更“精细”的用户界面只不过是一系列完全合理的步骤。您必须添加第二个按钮。您从用户那里得到反馈，他们发现订单令人困惑。您组织的标准组要求进行一次较小的更改。您必须更改文本框的大小才能进行国际化。

这些原因中没有一个是“嗯，它只是一个原型”。在UI设计，代码或书面形式中，任何事物都可以永远活下去。而并非所有人都应该有很好的理由杀死他们。

而且管理层可能不在乎。

实际上，如果您不只是将UI放到现有代码中的原因是“我必须在正确的框架中重新编写它”，那应该就足够了。如果不是，您可能应该讨论UI框架本身，但这是另一个问题。

我曾经遇到过这个问题，直到意识到这不是问题，而是使自己摆脱对大多数商店施加的过时开发标准的一种方式。

因此，您告诉您的管理层您正在编写原型，针对此问题领域选择最适合您的技术，然后在充分了解将要投入生产的情况下编写该软件。

您可以摆脱“应用程序必须在Java 1.6中使用Web（插入昂贵的管理选择的J2EE引擎）”和毫无意义的命名标准等乏味的乏味。

我当前选择的原型语言是“ php”（可完全扩展到重型生产环境，只需询问Facebook），以及Groovy / Java与Tomcat或Jetty的完美结合。

groovy / java组合非常适合快速开发。Groovy易于使用，可以快速开发，但性能却像老蜗牛。但是，将性能关键部分重构为纯Java却很容易。将应用程序与Tomcat或Jetty进行婚礼意味着不必再处理EJB和其他J2EE恐怖了。

与几个海报提出的草图相比，具有工作原型的主要优点是用户反馈。原型是使企业真正参与设计的一种好方法。一旦他们意识到他们可以说诸如“该字段不应该出现在主屏幕上”之类的话，嘿！在打开下一个演示的主屏幕上，他们可以参与设计，从而为项目带来多年的宝贵业务经验。