特别是在硅谷，当一个人有了一个原型或一点运作良好的模糊念头时，就面临将其扩大的诱惑：让它为更多的人和更多的用例工作，把它变成一个平台，让业绩折线图向右上角奔跑，等等。这个剧本显然威力巨大，但它的部署应该有谨慎的时机，因为它往往会让整个系统的概念架构冻结在早期。
为什么
你要花时间建设通用的基础设施。需要仔细设计接口，写文档和测试，并且确保系统能处理负载。这些工作和做实验是对立的，不仅因为要占用时间：这套系统会更加固化。
一旦用户和用例增加，做出改变或者进行大胆的实验就变得很困难。你要保证现有的功能不被破坏，否则需要小心地沟通并管理变化。
这些不同的用户每天都要消耗大量的时间：在一个小的原型中，1% 的人出现的故障不会带来真正的问题，但当你有 10 万个用户时，它就会成为高度优先的问题。
一旦这个剧本成为主要目标，你的动机就会改变：你的目标自然会变成使业绩图表上升，而不是回答关于你的系统的基本问题。
关于保持小规模
扩大规模的一个巨大的好处是，实践出洞见[1]的过程能得到更多的反馈。诚然，有效的系统设计需要从真刀真枪的使用情境汲取洞见[2]，但是创造小规模的真刀真枪的使用环境是可能的，你同样能将其用于回答关于你的系统的许多核心问题。事实上：技术专家经常本能地扩大他们的系统，以增加他们从严肃用户那里得到有力反馈的机会，但这是一个相当随机的方法。你可以通过精心组织你的原型设计过程来实现这一目标。这最终可能会更好，因为实践出洞见时，建议摸石头过河而不是先画蓝图[3]
当然，最终你会需要对系统进行归纳，以回答某些问题，但至少在研究成果方面，最好是使规模遵循这些问题所表达的需要。在这个意义上，它是一个工具性的目的，而不是一个终极目的。
链接至本文（已汉化）
声明
此内容发布由 Andy Matuschak 许可。未经允许，不得转载或修改。保留所有权利。
Thoughts Memo 汉化组译制
题图 by A2017laite
原文：Premature scaling can stunt system iteration (andymatuschak.org)
参考
1. 实践出洞见 ./521844479.html2. 有效的系统设计需要从真刀真枪的使用情境汲取洞见 ./552263007.html
3. 实践出洞见时，建议摸石头过河而不是先画蓝图 ./484620977.html