《凤凰项目-一个IT运维从传奇故事》，本书整体上，描述了一名中型机部门运维负责人，被临危受命，担任汽车零件公司IT运维部副总裁。从刚接手的项目工作混乱，到逐步梳理工作，进行一系列工作调整，优化流程，使IT工作起死回生，步入正轨，走向平台化、智能化快车轨道。书中的，一些工作方法和思维方式，很值得我们日常工作中，借鉴与学习。
书中，第一部分，IT运维工作的状态：
工作流程混乱不堪，没人遵守工作流程；全是救火紧急事件
项目变更无优先级，全靠人嗓门大或搬出来的领导级别高来实施变更，工作进度无法控制和度量；
部门之间只顾自己的利益和目标，遇到问题互相踢皮球，使问题越来越糟糕；
变更，找不到需求来源，即很多不知名的变更等待实施；
高层领导，不管员工的意见，一意孤行，只为完成市场目标；
IT运维副总裁采取的措施：
沟通协调，重新梳理流程规范，引入画板方法；
分析现装，找到方向，梳理IT资源；
改进工作方法，引其它部门入局；
着手解决关键人员(布伦特)，梳理关键人员参与事项，着手解决约束点；
对IT运维工作学习工厂的生产模式进行深入思考：工作三步法的认知；
其中，在怪人“埃瑞克”的指导下，明确了运维工作的四种工作类型：
四种工作类型：
业务项目
这是多数开发项目所包含的业务举措，通常隶属于项目管理办公室。项目管理办公室跟踪管理公司内的所有正式项目。
IT内部项目
包括可能由业务项目衍生出的基础架构或IT运维项目，以及内部生成的改进项目（例如创建新环境和部署自动化）。这些项目经常并非集中跟踪，而是属于预算所有者（例如数据库经理、存储管理经理和分布式系统经理）。
当IT运维成为瓶颈时，这会导致问题，因为不能轻易查明已经在内部项目中投放了多少生产能力。
变更
经常由上述两种类型的工作引起，往往在报修系统中被跟踪（例如IT运维补救、用于开发的敏捷计划工具）。事实上，在价值流的两个不同部分中存在两个工作跟踪系统，这会引起问题，尤其是在交接工作的时候。
偶然情况下，在一些兼具功能开发和服务交付职责的专门团队中，所有工作都处在同一个系统之中。这样做有一些好处，因为操作层面的故障会和功能缺陷以及新的特性功能一起，在存量工作和现行工作过程中显现。
计划外工作或救火工作
包括操作事故和操作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。
决定公司生死存亡的凤凰项目失败，IT运维副总裁与CEO分歧，CEO强势特立独行，
IT运维副总裁被迫放弃工作离公司。
在怪人“埃瑞克”指导下IT运维副总裁生回公司主持IT工作。分别总结过失，共同商讨未来。
其中，总裁在打造一个伟大的团队时的做法，很有借鉴意义：
一个伟大的团队并不代表他们拥有最聪明的人，使团队变得伟大的因素，是每个人都互相信任。当那种神奇的动力出现，就会让整个团队充满力量。合作需要信任，想要在团队中达成相互信任，你需要展现自己脆弱的一面。
让每个人，当着所有人的面，讲述自己的人生经历，爆漏出每个人脆弱的一面，想团队中的每个人相互了解，然后达成相互信任。
在对凤凰项目失败总结之后，IT运维副总裁进行了如下调整：
专注核心项目，冻结其它项目，偿还债务
在接着，开始解冻其他项目，进行了如下操作：
梳理出每项工作需求需要的工作资源，发布尽量不需要依赖约束点（布伦特）的工作，以减缓工作（半成品）堆积；
进行项目监控，区别项目工作节点，进行实时优化调整：其中，画板的优化很好：从日程表的形式，改成了三栏形式，即待办、在办、已办，当每项工作需要的环节步骤梳理清楚后，就只可以准确的跟进每项工作每个环节的完成情况。
按照项目重要性，安排项目实施的优先级；
最后，运维实现工具化、平台化、自动化、智能化发展：
通过工具、平台，优化部署流程和构建环境的方法，实现部署自动化，减少发布周期，增加发布频次。在平台上，创建了反馈回路，使需求、研发、测试、运维一体化发展，相互沟通更顺畅。突出了DevOps(研发运维一体化发展)的重要性。
