系统之美
其实看这本书不用去记什么3大特征、8大陷阱与对策、12大变革方式以及15大生存法则之类的，我刚开始看的时候就这么兴冲冲的记笔记。后来发现相对于这些细节，更重要的是提醒自己认识世界的时候，除了基于现象和因果的思考方法，也可以适当采用系统化思考的方法。
以我身边的软件行业为例(当然我层次比较低)，基于现象和表层的管理比比皆是。大部分人的主要工作就是“盯人盯活”，比如算算手里有多少项工作，手头有多少人，任务分一分，然后盯着员工，看看谁好好干活了，谁混时间比较多。
要是不满意了，也会想一些办法，比如绩效考核法，末位淘汰法，时间管理法之类的，每次有项目延期迹象就开会动员一波，大家基本上也会维持几分欣欣向荣的热度。年末的时候也对员工评价一番，王工加班甚多，怨言甚少，积极靠拢，勉之；孙工常怀怨望，狡辩甚多，摸鱼不止，训之。于是自觉赏罚分明，控制得当，管理有何难乎！
是的，确实很多人这样干的不错，前提是，你所面临的不是复杂系统。人数常不过百，业务一眼到头。有没有想过，如果想更进一步，该如何去认识及管理更复杂的系统呢？系统之美这本书强调管理者所遇到的问题通常都不是彼此孤立的，而是相互影响、动态变化的，尤其是在由一系列复杂系统构成的动态情境之中。在这种情况下，管理者不能只是解决问题，而应善于管理混乱的局势。
我是学信号与系统出身的，对于软件开发体系也喜欢用这一套来看。把需求看作输入，把成果看作输出，把员工处理任务等同于工作回路。那么，对于单次任务来说，输出/输入比例比较重要，但是对于循环工作的整个系统来说，整体回路的正负反馈才最为重要。
我所认识的很多管理者，对于软件工程的态度都很微妙，有的人直接不以为然，也有的人认为软件工程有点道理，但是一直没用大家也挺好的。还有的人选择性误用，敏捷开发就是加班，对我有利则用，项目规范拉长时间，对我不利则不用。
有位经理跟我说，老板喜欢严厉，但是他希望管的宽松，不知道怎么才对。也有经理说，不知道如何去处理某个刺头员工。其实古代就有人解释了，能攻心则反侧自消，不审势即宽严皆误。与其把精力花在这些具体的表象上，倒不如思考怎么构建一个正反馈稳定运行的系统。而系统，是自发运行的。
根据我粗浅的认知，软件工程的正反馈，可以是，正确的需求理解带来可执行度高的设计，以及完备的测试覆盖；规范的开发流程带来清晰而稳健的代码，合理的工期允许有员工探索成长的余地。随着项目的一轮迭代下来，收获了可以用做基础架构的可复用的代码库，收获了经验有所成长的员工作为未来人员扩充时的导师或Leader，未来项目的成本将不会像第一个项目那么大，这些就是正反馈带来的可扩张性。
软件工程的负反馈，可能是漫不经心的需求理解带来变化多端的设计，在屡次返工变更的前提下，充斥着各种临时措施的代码也变得混乱不堪；没有或只有少量测试，频繁返修的Bug使时间评估完全失准；员工加班加点赶工期，对于学习提升毫无动力。而由此带来的人员流失和重新招人，则通常会加重上述现象，因为往往这些问题是由系统带来的而不是由人员带来的。新项目的成本几乎形同重做，完全享受不到软件行业高复制性的红利。
所以对于现有的管理任务，如果确定为一次性项目，那倒是怎么管都行。如果目标长远，则要想法构造正反馈的系统回路，毕竟如果势能到位了，不用管理每一片雪花的具体行动，滚雪球的力量也是势不可挡。
当然世界上没有十全十美，指数增长常有上限，负反馈也不会无穷探底。系统化思考也不是绝对有用的，作者本人也强调这只是认识世界的一种视角之一。不管怎样，我非常喜欢这本书的观点。我时常想象，由简单的齿轮皮带和其他零件等构造的流水线，附带一些纠错和稳定措施，不停地把输入原材料变成商品，这一模式还可以复制千百万份，这正是软件行业可借鉴的现代工业的系统之美。