系统思考的法则

我们都是解决问题的高手，遇到各种问题时总是会本能的想到各种“理所当然”的解决办法，这是我们的优点。但是，当站在整个系统角度去观察时，这些符合常理的解决方法是否就是最合适的？答案是否定的！事实上，如果我们不能站在系统层面来思考并采取行动，我们的解决方案变成祸害的概率要远高于得到其他结果。

在彼得.圣吉的巨著《第五项修炼》中，提出了十一项系统思考法则，我们今天就来重读一下：

1.今天的问题来自昨天的"解决方法"

很多问题解决办法只是把问题从系统的一部分转移到另一部分，但这种"解决办法"仍然经常会获得欢呼，因为这里继承了新问题的人并不是原来那位"解决了"第一个问题的人

案例：一位地毯商，有一次他无意间发现，他最漂亮的一块地毯的中央鼓起一个包。为了弄平地毯，它就用脚去踩那个包－－果然踩平了。但是地毯上离原来不远的另一处又鼓起来。于是他又去踩，包又不见了。过了一会，包又在另一个地方出现了。他垂头丧气的一次又一次踩踏碾蹭，直到最后他掀起地毯的一角，看见一条蛇摇晃着身体愤怒的爬了出来。

案例：几年前为了“按时完成”计划，经理们逼迫员工加班赶工，于是员工启动“程序员秘密工具箱”快速搞定任务。最后任务是按时完成了。但今天的项目却必须把60%以上的时间投入在应对外场故障上。

2.你越使劲推，系统的反弹力越大（更努力工作的危害）

也称为补偿反馈：愿望良好的措施介入后引起系统的反应，结果抵消了介入行动所带来的好处。更糟糕的是，作为个人和组织，我们不仅常常陷于补偿反馈中，还经常赞美随之而来的痛苦。当最初的努力不能奏效时，我们就加劲儿，坚守努力工作将克服一切障碍这个信条，殊不知我们一直在蒙蔽自己，使自己无法看见，我们自己其实一直在帮助制造障碍

案例：在《动物农庄》中有一匹叫“拳击手”的马，它在任何难题面前总是给出同样的回答：“我会更努力的工作”。开始时，这种愿望良好的工作态度激励了大家，但渐渐的，它的勤勉引起了微妙的反弹。它越是努力工作，要做的事就越多。它并不知道，其实经营农庄的猪正在利用所有的动物来获取私利。“拳击手”努力工作的结果，是使其他动物更难以察觉猪的动机。

案例：公司在某个产品突然失去市场吸引力的时候，开始使劲的促销，增加广告费、降价，这类措施可能会暂时吸引一些顾客回头，但也使公司资金外流，而且由于送货速度和质量检查跟不上，结果，从长远看，公司更狂热的促销，反而会失去更多顾客。

3.情况变糟之前会先变好

低杠杆效益的措施在短期内有效，长远来说反而造成反效果。补偿反馈会有一段时间的延迟，而现在职场换人速度又快，由此造成击鼓传花效应

案例：需求按期交付压力大，于是通过降低质量管控来保证按时交付，眼前的危机解除了。但半年以后产品外场故障增多，外场支持压力变大，大家大部分精力开始放在救火上，在需求上人力投入开始不足，于是需求按期交付的压力变得更大。

4.选择容易的办法往往会无功而返

假如解决办法真的能那么轻易地被发现，或对每个人都那么明显，那它可能早就已经被发现了

案例：想做款热卖的产品，但迎合客户的每句话比分析用户的真正需求容易多了，往系统上增加功能也比裁剪功能容易多了。于是产品越来越臃肿，又由于同等的人力投入下，维护的功能越多，在每个功能上花的心思也越少，最后，做出的是一款功能复杂，却缺少亮点的产品，客户也并不买账

5.疗法可能比疾病更糟糕

非系统的解决办法会带来长期的更具潜在危害性的后果，那就是对该方法的需求将会越来越大。这种短期改善引起长期依赖的现象非常普遍案例：模块壁垒现象，把模块交给某甲开发，后续再有此模块的需求和故障，由于某甲最熟悉这块，为保持效率，还是交给他维护，久而久之，这块代码成了某甲的专属区域，形成模块壁垒

6.快就是慢

几乎所有自然系统都有天然固有的最佳成长速度。因此，面对一个复杂系统简单介入其中，贸然展开修补行动，可能不会带来任何帮助。

案例：特别关注效率，专门投入时间对代码进行优化，使得某些子函数执行效率从10毫秒提升到了0.01毫秒，效率提升达一千倍，但事实上，该子模块用户每10天才手工触发一次，1毫秒和0.01毫秒对用户感受来说，完全没有差别

7.因和果在时空中并不紧密相连

"果"是指问题显现出来的表面症状；"因"是指系统中造成那些症状的相互作用；如果能发现这些相互的因果作用关系，就可能导致有持久改善功效的变革。大多数人默认都假设，在大部分时间里，因和果在时空上紧密联系，但是，在复杂系统中，这个观点是完全错误的。

案例：你们最近三个月投入不少时间在加强代码走查上，但近三个月外场故障数不降反升，这种走查有意义么？但事实上，外场用的版本一般比团队现在开发的版本要落后六个月左右，近三个月的外场故障数只能说明在代码走查开展之前团队的质量保障有问题，不能说明近三月开展的次活动没有意义

8.微小的变革可能产生很大的成果，但最有效的杠杆常常最不易被发现

微小的，集中的行动，如果选对地方，有时会带来可观的，持续的改善（杠杆作用），寻找杠杆，必须学会观察事件背后的结构模式，而不仅是事件本身

案例：每天让团队成员一起走查代码，每周让团队成员一起放松回顾加吐槽，让开发人员和测试人员在一个社团中定期交流，所带来的效果并不是简单的代码改善或者得到些改进措施，而是通过活动加强了人员间的连结，这也是一种teambuilding

9.鱼和熊掌可以兼得，但不是马上

"非此即彼"的刚性选择往往是因为我们处在固定的时空点考虑问题，但真正的杠杆效益在于，看清如何逐步使两者都得到改进，为此，需要有意识考虑事情随时间的变化过程

案例：太多的市场案例说明，关注质量提升，最终会降低成本。

10.把大象切成两半得不到两头小象

要理解大多数最富有挑战性的管理问题，我们必须看清产生问题的整个系统。但现实中，组织的设计方式（严格划分和强化部门界限）阻碍着人们去观察重要的互动关系

案例：这也是敏捷强调从组件团队往跨职能特性团队转型的内在原因。

11.不去责怪

分立的"他人"并不存在，你和那个被责怪者都是同一个系统的组成部分，疾病的疗法，就在于你和你的"敌人"的关系之中

案例：以前我们总认为故障泄露多是测试工作不力，或者开发不重视质量，但现在我们知道，质量问题必须得开发和测试互相配合来解决，由此产生了实例化需求等一些有效的协作方法。