这是一个活生生的案例，也是一个惨痛的教训，它给相关参与者都上了一课 - 范围是如何失控的。
事情是这样的，有一个客户找了一家软件公司为他做项目，这个团队正做着项目A，此时客户手头有了另外一个相对独立但跟A有关的项目B。为了避免原计划受到干扰，客户想把项目B做为另外一个独立于A的项目外包，而且还想用固定报价，协价一致后，该公司就为这个客户分配了对应的资源去做项目B。
结果做的时候发现项目B跟项目A的很多底层是公用的，而此时项目A正在对这些公用部分不断进行升级演进。问题来了，项目B到底要不要因为项目A的底层更新而进行升级呢？由于当时该团队认为是同一个客户的项目，代码库也有共同的基础，就没有对代码进行分离，这使得项目B不得不因为项目A的底层变动而持续进行更新。这导致了一个非常不好的后果就是做项目B的团队，其工作内容无形中被大大增多了，直接结果就是项目延期了很久，而且由于是固定报价合同，这些额外工作的报酬变成了争议性的话题。
当团队B跟这个客户沟通此事时，客户也强调项目延期很久让他很不满，迟迟不愿正面回复底层变动的费用到底应该由谁承担的问题。最终团队B单方面决定冻结当前的底层，对代码进行分离，才把项目的范围最终稳固下来。虽然最后项目是结了，但是合作的双方都铩羽而归。
这个案例告诉我们，底盘不稳的情况下，不应该做固定报价。而且当底层演进的问题暴漏之初，就应该当机立断停止继续更新，等与相关人员（经理、客户）协商一致后再处理。希望大家能从这个案例中吸取教训。