读完整本书，可以从两个方面分析这本书的价值：1，工作方法的重要性 2，管理层的自我蜕变
比尔升职为无极限零部件公司IT运维部副总裁，可谓临危受命，烂摊子已经到了随时坍塌的程度，部门员工整日处于救火状态，支持公司业务的几乎所有系统都处于不可控状态，数据不准确、经常性宕机、交互体验差、更新频率跟不上等问题，导致公司无法正确预测市场趋势，无法向客户及时提供所需产品，无法完成财务指标等致命问题，一度将IT部门推至被砍掉、业务完全外包的境地。
部门人员失控，负责维护的系统失控，还要完成公司已经投入巨大、对公司有重大意义的凤凰项目，对于没有任何管理经验的比尔，面临的挑战难以想象，但他只能迎难而上。经过几个突如其来的系统服务中断，几周没日没夜的挣扎分析，比尔终于摸索出了问题的所在，不凑效的变更管理流程，让公司其他职能部门对IT部门的提的任务变得失控，部门每个员工都被其他部门的临时任务占用，还是好几个部门同时占用，半成品（即未完成工作）堆积过多，每个人对系统做的改动也都互不相告，直到系统服务突然中断，无法修复，然后又开始上演惊心动魄的紧急救火。这明显就是个死循环，救火次数越来越多，每次的解决方案又都是临时解决方案，技术债越来越多，无暇偿还，久而久之，所有系统都被牵连是必然。凤凰项目不能如期交付也是必然。
没有不凑效的变更管理流程，就没有人员失控，没有系统失控，没有凤凰项目的失败。说到底还是管理的失控。
艾瑞克一直在充当比尔实现管理的导师，他一次次的以工厂生产为例，让比尔不断体会IT工作与工厂生产的共通之处，让他总结出了IT的四种工作类型和三步工作法。
IT的四种工作类型：业务项目、IT内部项目、变更、计划外工作
三步工作法：
第一步工作法：形成自左向右的工作流
第二步工作法：形成自右向左的反馈
第三步工作法：形成公司文化，敢于冒险和尝试，高度信任。
本书最后还揭秘了“开发运维”这个思想。
整本书吸引我的还有另外一个方面，就是公司内各管理层领导层之间的交锋，CEO的不妥的安排，逼迫比尔辞掉了工作，比尔辞职之前在部门内实施的办法的凑效，激起了CEO的反思，他不仅请回了比尔，还借鉴《团队发展的五大障碍》里的思想：想要在团队达成相互信任，你需要展现出自己脆弱的一面，主动带领管理层进行了一次亲密分享，赢得了团队的信任度，为以后更好的开展工作打下了基础。
还有约翰，一个执着于通过修改系统来解决财务审计问题的信息安全官，由于公司对系统信息安全的忽视，多少年来，他始终对公司报以彻底消极的态度，无时无刻不在等待公司崩塌的那一刻，然而公司却避开了一个个看似非常严峻的审计问题。直到他被艾瑞克严厉地训斥了一顿，经过几天委靡不堪的痛苦思索，他才完全醒悟。艾瑞克指出他并没有理解为什么公司能避开外部财务审计问题，不理解就没资格在评论别人的做法是无效的，还指出他并没真正理解公司现在面临的问题是生死存亡，而不是应付财务审计。这使他重新理解IT系统存在的根本意义是为了实现业务目标。沿着这个思路，IT部门从迪克手中拿到了业务指标，并对对业务指标负责的部门就IT系统给他们造成的影响进行了调研，他们分析了局势，并形成了解决方案：先偿还技术债，并将开发运维运用起来，把安全问题融入到日常工作，而不是部署完成之后再思考如何保护他们。
再次强调我对比尔、史蒂夫、约翰三人的蜕变过程非常感兴趣。
本书还揭示了如下事实，摘抄如下：
1，训练让伟大的团队达成最优表现，对任何流程或技能来说，训练成习惯，习惯成精通。不断重复可以建立起信任感和透明度，对需要团队合作的事情来说尤其如此。
2，信任度高的小团队，加上小的批量规模以及更小、更频繁的软件发布，能够极大地提高开发部门的生产能力。
