客户提了一个新需求，他们要造一条船：
我们想造一条船，可以带几个人出去钓鱼
开发团队把它开发出来了，完美地满足了客户的需求：
客户看到以后，提了一些修改意见：
我们想在船上保存钓上来的鱼、饮料和食物
开发团队轻松地扩展了原来的设计，给船增加了一个冷藏箱
客户又说了
刚才增加的冷藏箱不能保证长时间的低温，我们想要一个真正的冰箱
开发人员不确定“长时间”到底是多少时间，于是他们增加了蓄电池和一个冰箱
客户：
出去钓鱼经常需要很长时间，太阳晒得难受，需要一个遮阴的设备
因此，开发团队在船上增加了一个顶篷。这会在较高的速度下增加一些风阻，但鉴于船的大小和小型电动机，应该业没啥问题。
客户说：
现在天黑得很早，船上得安装一个灯，这样天黑的时候我们才能照亮回家的路
这个对开发来说，改起来太容易了，蓄电池上还有一个插头，连上灯就可以了
客户：
我们现在有了冰箱和灯，那个蓄电池很快就没电了，我们要个大的蓄电池，这样才能在船上呆一整天
开发团队需要偿还技术债了，去掉小的蓄电池，换一个更大容量的
客户：
船上加了这么多东西，船跑得太慢了，要快一点儿！
开发团队安装了一个舷外的发动机，船跑得更快了，不过导致了顶棚的快速震动，让顶棚的灯也晃来晃去。
客户：
我们整天都在水上，需要一个洗手间！
这是个超级高的要求！但是在技术上是可行的
客户：
船太小了，得能载更多人才行
开发团队非常沮丧，因为想满足要求，必须得大改，他们通常会抱怨：你怎么不早说？！
但是这是一个紧急需求，必须满足
于是一个临时的解决方案来了
客户：
我们整天在船上，需要有个地方能小睡一会儿
一些程序员无法忍受客户的“无理”要求，跳槽去了另外一家公司，剩下的人只好在系统上修修补补，安抚客户：
。。。。。。
故事讲完了，程序员什么时候跑路合适呢？
其实没有合适的时机，因为无论什么时候跑路，只要你进入另外一个项目，面对的问题大概率是相似的，这也是软件开发的现状：需求很难清楚的表达出来。
原文的观点是“很多团队都希望聘请一个救世主般的架构师，然后解决他们所有的问题，但这是不现实的。良好的架构最重要的是良好的规划，你需要知道去哪里才能到达那里！”
具体到这个例子，你能想到客户的需求到底是什么吗？
实际上客户想要的是这个东西：
有人可能说了：如果一开始客户就告诉我们开发需要一个游艇不就结了？！
实际上，在软件开发中，这种能描述完整需求的客户极其罕见，大部分客户都是看到实际可以运行的系统以后才会提出新的建议和需求。
所以Mark Beare建议：快速行动并且做出良好架构的最佳方法是产品和开发团队就路线图和未来可能的发展方向进行头脑风暴会议， 让开发及早地了解产品可能的发展方向，就可能设计出一种灵活的方式来构建它。
在这个阶段，有这些通用的问题来帮助决策：
1. 该产品3~5年内将会走向何方？
2. 为了让第一个版本推向市场，我们允许有多少工作可以被扔掉？
3. 有哪些决定会严重限制产品的扩展和产品的灵活性？
4. 能不能在基础稳定的时候，对某个领域进行快速迭代（如UI）?
5. 站在工程师的角度，哪些地方在未来可能会被替代掉？能不能把它们从核心的基础设施中隔离开？
-END-
