《凤凰项目》
背景
无极限公司面临严重的竞争压力，内部推出“凤凰项目”，希望通过凤凰项目来赶超对手，并实现市场认可挽回估价，原有的技术领导在成本超支的情况下也未能顺利推进凤凰项目，比尔是负责中型机的团队leader，临危受命，接手运维副总裁的职务，却发现面对的是一个烂摊子，上任第一天就出现严重的系统bug，甚至影响了全集团的工资审核系统，没法正常发工资，使公司成为了业界的笑柄。
比尔一步步的去挖掘公司的问题：
1、开发和运维人员忙的不可开交，但就是无法顺利的向业务部门及时交付满意的产品，大量的紧急任务挤占了凤凰项目的时间。
2、各部门相互指责，基本无法顺利沟通，大家都在努力做自己认为有价值的事情。
分析问题
既然凤凰项目是最紧急的，为什么还会有大量的更紧急的任务出来呢？
回答这个问题之前需要给出文中列出的四类工作
第一类：业务项目，由 PMO 跟踪的正式项目；
第二类：IT 内部项目，内部生成的改建项目，例如创建新环境和部署自动化
第三类：变更 ，变更一般是由业务项目和IT内部项目这两种工作类型引起，一般会在问题跟踪系统中进行管理
第四类：计划外工作（救火工作）包括操作事故和紧急bug以及紧急业务支撑，通常由以上三种类型工作导致，往往会牺牲其它计划内的工作为代价，成本很高。
前三类工作都是可以计划的，唯有第四类火不可不救。
所以需要想办法降低第四类工作，在书中第四类工作主要表现为1、各种紧急bug修复（质量问题）2、重要领导安排任务 3、安全部门提出的任务
可以理解为流程不规范、测试不充分导致的bug问题、由于没有明确的目标和及时的沟通导致大量的任务优先级错误，再加上计划不周瓶颈存在，导致各种半成品堆积无法及时交付有价值的产品。
解决方法
书中给出三步工作法
第一步：我们要确保形成一条迅速，可预测，持续不断的计划内工作流，从而向业务部门交付工作价值，同时降低计划外工作的影响和破坏。
又称第一工作法，是关于从开发到技术运营，再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比例或运维有效性等局部目标）进行优化。
落脚点：持续构建、持续集成、持续部署，按需创建环境、限制半成品，构建起能够顺利变更的安全系统和组织。
第二步：设置和缩短反馈环路，从而在源头上尽早解决质量问题和需求问题，越往后修改成本越高。
又称第二工作法是关于价值流各阶段自右向左的快速持续反馈流，方法其效益以确保防治问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。
落脚点：
1、在部署管道中的构建和测试失败时“停止生产线”
2、日复一日持续的改进日常工作
3、创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态
4、在开发和技术运营之间建立共同的目标和共同的解决问题的机制
5、建立普遍的产品遥测技术，让每个人都能知道，产品和环境是否在按设定的运行，以及是否达到了客户的目标
第三步：建立一种文化，既能鼓励探索，从失败中吸取教训，又能理解反复的实践是精通工作的先决条件
又称第三工作法是关于创造公司文化，该文化可带动两中风气的形成：
1、不断尝试，这需要承担风险并从成功和失败中吸取经验教训
2、理解重复和练习是熟练掌握的前提 尝试和承担风险让我们能够不懈地改进工作系统
落脚点：
营造一种勇于创新、敢于冒险（相对于畏惧和盲目服从命令）以及高度信任（相对于低信任度和命令控制）的文化
把至少20%的开发和技术运营周期划拨给非功能性需求，并且不断鼓励进行改进
感想
书中给出的方法就是现在的敏捷+devops理念，敏捷让开发运维放宽了视野，去设定与公司一致的目标，遵循价值导向，devops构建了自动化的持续构建、持续集成、持续部署，并及时反馈。
用管理框架套用一下：
目标管理：每轮敏捷开发过程可以算是一轮小的OKR实践，设置目标，关键结果，工作认领，迭代实现，演示评审、回顾总结提取经验。
过程管理：第一工作法和第二工作法构造了一条不断改进，能够自我反馈的自动化流水线。
团队管理：第三工作法提出了勇于创新、敢于尝试，不断改进的公司文化。
这种构建自动化流水线的思维正好又与我构建体系然后让其自动驾驶的习惯不谋而合。
