过早的扩展会阻碍系统迭代 §

尤其是在硅谷，当一个人有一个很好的原型或预兆时，很容易将其扩大规模。让它为更多的人和更多的用例工作，把它变成一个平台，让图表向上和向右，等等。这显然是一个强大的剧本，但它应该谨慎部署，因为它往往会冻结系统的概念架构。

为什么 §

一般基础设施只需要时间来构建。您必须仔细设计界面、编写文档和测试，并确保您的系统能够处理负载。所有这些都与实验相媲美，不仅因为构建需要时间：它还使系统更加僵化。

一旦拥有大量用户和大量用例，就很难改变任何东西或进行激进的实验。你必须确保你不会为别人破坏事情，或者小心地沟通和管理变化。

那些相同的不同用户只是每天消耗大量时间：1% 的人发生的故障在一个小原型中不会出现真正的问题，但当你有 10 万用户时它会是高优先级的。

一旦这个剧本成为主要目标，你的动机就会改变：你的目标自然会变成让图表上升，而不是回答关于你的系统的基本问题。

关于剩余的小 §

扩大规模的一个巨大优势是，您将通过制作过程获得更多关于洞察力的反馈。确实，有效的系统设计需要从严肃的使用环境中汲取洞察力，但是可以创建小规模的严肃使用环境，这将使您能够回答有关系统的许多核心问题。确实：技术人员经常本能地扩展他们的系统，以增加他们从认真的用户那里获得有力反馈的机会，但这是一种相当随机的方法。您可以通过仔细构建原型制作过程来实现该目标。这最终可能会更好，因为通过制作的洞察力更喜欢拼凑而不是预先的大设计

当然，最终，您需要概括系统来回答某些问题，但至少在研究成果方面，最好让扩展_遵循_这些问题所表达的需求。从这个意义上说，它是一种工具性的目的，而不是最终的目的。