像做工程一样量产软件，是人们的一种愿望，
但实际执行起来，却异常困难。
这些年我参与过的项目中，
几乎每个项目都有这样或者那样的工程问题，
阻碍着效率的进一步提高。
要么需求有问题，要么工期有问题，要么代码有问题，
要么文档有问题，等等等等。
不同的团队会遇到不同的问题。
而且，同一个团队，只要不进行较大规模的人员调整，
再多的反思，也不会从本质上解决这些问题。
因此，我们有理由相信，工程问题是团队相关的。
团队文化看起来会对任何变化造成一种阻力，
导致某些改变永远无法完成。
要做出改变
在讨论为什么无法改变之前，
让我们先谈论一下为什么要进行改变吧。
Eliyahu M. Goldratt提出了一套企业管理方法，称为约束理论（theory of constraints）。
他认为，非瓶颈资源的利用程度，并不是由其生产潜力来决定，
而是由系统中的其他制约因素来决定。
他指着NCX-IO机器说：
你们系统的主要制约因素就在于这部机器。
当你们给非瓶颈的工作量超越了这部机器的工作量时，
你们不但没有提高生产力，反而制造出过多的存货。
因此，也就和目标背道而驰。
—— 《目标：简单而有效的常识管理》
在企业管理中，要想系统性的提高效能，
就要识别并设法减少瓶颈因素，直到瓶颈因素不再对效能产生约束。
消除一个瓶颈之后，又会涌现出另外一个新的瓶颈，如此循环不已。
该理论在实际应用中是很有效果的，
类似木桶原理，只有桶壁上的所有木板都足够高，才能盛满水。
假如可以改变
不幸的是，像很多方法论一样，约束理论也忽略了一个事实，
那就是，现状实际上是无法立即改变的，甚至是无法改变的。
就像一列冲向悬崖的火车一样，我们甚至没有办法让它停下来。
有些看起来有效的方法论，其实很难执行成功。
我们来看一个常见的例子，例如，
我们都知道敏捷开发的好处，敏捷开发也有很多成功的案例，
但是我们经历的项目中，有几个改造成了敏捷形式呢？
另一个例子，
开发者们都厌恶脏乱的代码，人们也知道代码评审以及设计评审的重要性，
但是又有几个团队，能坚持做这样的事情呢？
所以，并不是人们意识不到改变，
也并不是人们从主观意愿上不接受这些改变，
而是从经济学角度来讲，人们并不会为改变买单。
改变对一个系统的影响
我看过《大明王朝》这个电视剧，所述年代里国库亏空严重，
于是内阁想出了一个办法，那就是将浙江的稻田改成桑田，
桑田产的蚕丝织成绸缎，会比原来的种稻利润更高。
这看起来是利国利民的好事情，
而且站在改稻为桑已经落实的基础上，有百利而无一害。
可是，到实际执行时，却又不容易了。
因为，将稻田改成桑田，当地的农民就没粮食了，
于是，必须去别的地方买粮。
而粮食需求旺盛，也会导致粮价上涨。
粮价上涨了，当地农民就买不起了，必须把土地卖了才行。
农民担心自己的土地，所以改稻为桑的国策就无法推行下去了。
所以，要想推行国策，就得先解决粮食问题。
可是哪有多余的粮食呢？谁肯借出这些粮食呢？
这就形成了一个死局。
不是方法出现了问题，而是方法无法推行的问题。
就好像囚徒困境中的两个囚犯一样，
每个人都有自己的小算盘，谁都不肯损害自己的利益，
当然也就无法达到全局最优了。
为何无法改变
我们看到，将改变的决策落地执行，才是最困难的地方。
任何改变都需要消耗资源，
而这些消耗，都必须从当前系统中的其他地方“借”出来。
想要做出改变的团队，也是如此。
一个好的工程实践看起来行之有效，
但是人们一旦意识到，要想改变就必须先付出代价时，
就推行不下去了。
人们都知道问题在哪里，可是仍然无法扭转局面。
结语
我们一线开发者，很容易会将工程问题归结为项目经理的失职，
这是很不专业的行为。
因为从人们意识到改变，到真实的做出改变，还有很多的路要走。
会遇到团队文化所带来的无形阻力，
会遇到资源分配方面的种种问题。
驱使自己做出有挑战的事情，已经很不容易了，
何况驱使别人，驱使一个团队，
我们只能根据团队成员的心理诉求以及利益得失，制定出可以执行得下去的方案。
所以，不要怪项目经理了，
毕竟谁也不想加班。