导语
《凤凰项目-一个IT运维从传奇故事》全书，从一个企业IT副总裁的角度，描述了该企业一系列IT相关工作调整从而让企业起死回生的故事。抛开技术层面，值得思考的是，书里展示的工作方法和思维方式，其实是可以运用在任何业务类型的公司，任何层级，无论是部门或是个人。读完不禁想梳理一下书里bill面对的问题和做出的调整。
阶段1 - 无人遵守工作流程，项目一片混乱
小说的开始，bill在工作的这个阶段，书中描述了几个主要场景：
- 没人遵守工作流程，很多项目没有报备
- 出了问题无根可寻，根本不知道是哪项调整导致了问题的发生
- 毫无根据的、错误的修复尝试整甚至引发了更多问题
- 整个部门没人能准确说出具体在负责哪些项目
- 项目优先级没有判断标准，先做后做纯靠喊得响亮，工作进度完全无法把控
- 某些关键人承载了太多工作，导致很多项目工作一直处于排队等待状态，影响项目进度
- 糟糕的项目安排和进度控制，让很多东西都只是在赶进度，毫无质量可言
- 部门之间只考虑自己的指标，完全不从项目整体出发，各干各的，互不信任，互相推卸责任
- 各个工作环节间的工作交接敷衍了事，互相丢锅
- 一大堆来自不同部门的不知目的，为了做而做的需求
- 领导为了实现业绩目标，无视存在的问题，或者说从领导的角度，就算这些问题客观存在，也要完成目标，因为有可能完不成目标就以为着公司活不下去
看到作者描述这些场景，真是觉得无比亲切，很不幸，本人在工作中也经历了这里头的所有情况，无穷无尽的需求，无穷无尽的问题，很多时候得花大把的时间救火，艰难前行。
相信很多人，在工作中，或多或少都会碰到这样的情况，最常见的也许是你觉得某个中间环节处理的很慢，这个时候大家都试图想法设法的绕过他，殊不知确破坏了其他环节的工作安排。或是多个不同部门都说自己的需求紧急，到底谁的需求才是真正重要且有价值的。
阶段2 - 试图终止混乱局面，重新规范流程
首先，bill总裁通过各方取证，花了九牛二虎之力。终于找到了系统宕机的原因，解决了燃眉之急。然后寻思出现这种出了问题，得花半天时间找原因的根本问题在于无序的项目工作。所以开始了整理现有工作，重塑工作流程的步伐。
其实公司本来是尝试过流程化的工作体系，甚至尝试通过系统来管理工作。但是，实际推行情况，用书里的话来说就是：
我们用的那个应用软件简直就是垃圾，为了申请一个5分钟就能搞定的简单变更，得花上20分钟才能填完全部字段！
简而言之，繁杂的登记审核流程让原来的系统没有带来便利反而增加负担。
bill用了画板的方法，让大家在便利贴上写下工作内容，在画板上画上日程表，在日程表上安排每一项工作。每项工作都需要提交申请，通过画板安排执行，这是书里最初的画板版本。
画板以什么形式出现也许并不重要，结合工作实践，重要的大概有以下四个方面
- 足够轻，大家能接受，不会增加额外负担
- 可视化，直观反映工作分配状态
- 参与感，让团队每个人感受到能参与其中，并推动项目往前推进
- 形成习惯，好的东西如果不能坚持，工作记录不完整，到最后只会回到混乱局面， 一定得通过制度和氛围让大家形成习惯
阶段3 - 尝试解放约束点
继承上个阶段，工作安排下去了，却发现有60%的工作没有完成，原因是多项工作都需要某个超级员工 ‘布伦特’ 的参与，而布伦特的时间是有限的没有办法同时处理完所有工作，于是工作就不断堆积。也就是说，员工布伦特是一个制约工作进度推进的约束点，他的工作效率决定了各个项目的进度。
这个时候，bill的解决方案是，把布伦特手上的工作能标准化的进行标准化，交给其他工程师，给布伦特减负；把需要布伦特的工作标示出来，按紧急程度安排给布伦特。
但是在减负实现效果之前，一堆拥挤的任务，以及阶段1出现的部门间的问题，导致了公司的核心战略项目-凤凰项目上线失败，甚至演变成一场公关丑闻。
阶段4 - 专注核心项目，冻结额外项目，偿还债务
上阶段由于工作安排不妥当，IT部门无法完成工作目标，董事会怀疑IT部门存在的意义，甚至考虑外包IT事务，导致了开发和运维两个部门的老大有了一次难得的沟通，这是一切转变的开始。
大家理解了相互之间的工作窘境，领导不顾工作能力，不断派发的工作任务，导致每个部门都在赶工，因而生产出了很多脆弱的软件应用，计划外的状况越来越多，每天除了救火，已经没有精力处理其他事情。
bill总裁受不了他们加变态CEO辞职完回来后，第一件事情就是暂停接收新任务，除了核心项目外的工作一律暂停。这项举措，促使部门工作聚焦，效率提升，工作可输出的成果增加，部门间的摩擦减少。
实际上这种理想情况在现实生活中很难出现，往往老板会说，我底下的人每个月还要开工资啊，所有业务线都要保持运作，我需要一部分人做这个，一部分人做那个，又要芝麻，又要西瓜。。。
当然，这时候需要考虑的另一个问题出现了，如果解除项目冻结，大量待处理项目涌入工作计划中，这时候应该怎么处理，怎么区分工作的轻重缓急。就像bill总裁说的：
当多条工作流同时进行时，如何决定在某个给定时间里应该做什么？
这是工作中更常遇到的问题。
阶段5 - 控制流入的工作项目
这个阶段bill总裁要解决开放流入更多工作项目的问题，经过扫地僧 ‘艾瑞克’ 的点拨，问题变成了：
（1）项目冻结解除后，发布哪些项目是安全的
（2）启动项目监控是否安全
第一个问题的答案是，需要梳理出每项工作需求需要的工作资源，发布尽量不需要依赖约束点（布伦特）的工作，以减缓工作（半成品）堆积。
第二个问题的答案是，项目监控是安全且必要的，通过把每个项目需要的工作中心，或者说工作节点区分出来，跟踪各个节点的工作情况，适时优化调整每个节点的工作。
实施的时候，‘ 帕蒂 ’（只是一个人名而已）对看板做出了优化，从日程表的形式，改成了三栏形式，即待办、在办、已办，当每项工作需要的环节步骤梳理清楚后，就只可以准确的跟进每项工作每个环节的完成情况。同时，为了更好的安排工作，‘ 帕蒂 ’用不同颜色的卡纸标示不同类型的项目。让不同类型项目安排情况一目了然。
而面对各种基于工作目的划分的不同类型的项目，需要怎么安排优先级呢？
bill总裁的做法是，针对业务需求，根据业务重要性安排，针对内部优化需求，找出能提升约束点的改进项目，优先优化。
还需要考虑的是，因为各项工作资源保持忙碌而让工作出现的排队等待的时间，和工作节点之间交接工作的交接时间，避免工作交接拖沓，或者某个环节出现问题，这也就是项目监控的作用体现。
阶段6 - 从企业顶层目标出发考虑问题，做真正有用的事
在这个阶段bill总裁和其他员工开始去了解，对于公司而言，什么才是重要的，对于业务部门而言什么IT服务才是他们做需要的。
从而再去思考，哪些工作能够满足业务部门的需要，进而实现公司的目标，自上而下的考虑问题，明确自己的位置和价值，有目的的安排IT部门所要做的工作。
这样一来，不仅工作目的性强，效果好，业务部门也从原来的排斥抵触嫌弃，变成了极力支持IT部门开展工作。
值得学习的还有bill总裁在访谈中提的问题：
（1）谈谈你的评估指标（了解对于他们来讲什么是最重要的，进而业务负责人说出了难处）
（2）你觉得糟糕的一天是什么样的？（了解业务部门关注什么问题）
（3）如果你能挥舞魔杖，你会怎么做？（了解业务部门的期望）
阶段7 - 优化流程和工具，创建反馈回路，形成文化
在上一阶段实现做正确的事情后，这个阶段bill总裁实现的事，如何让正确的事情持续的发生。
他们优化部署流程和构建环境的方法，实现部署自动化，开发极大减少发布周期，增加发布频次。快速验证功能是否符合市场需求，持续迭代。本质上讲是先解放了 ‘ 布伦特 ’ ，让布伦特不在是那个约束点，而如何实现快速部署的环节称为了另一个约束点，通过自动化部署，又极大提升了约束点的工作能力，实现了生产力的提升。
同时，他们建立反馈回路，一直往回通向产品定义、设计及开发的最初环节。从每个项目一开始大家充分沟通，明确各个环节要怎么做，随后执行，然后通过快速部署上线，效果很快的从一线反馈回各个链条，很快的知道问题和执行结果，又能进行下一轮调整、开发、部署，把容易出问题的部分明确标准化，通过文档防止错误再次发生。
并不是有了好的流程就一定不会出问题，问题依然会不停的跑出来，只是大家已经形成了好的习惯，在不断的定期演练和实战的过程中，所有人已经形成习惯，对该做什么事情已经熟练的掌握，哪怕bill总裁换岗了，这个部门依然能够流畅的运作下去。
以上就是小说的大致演化过程，从演化过程中，还有值得抽象出来的东西。
四类工作
小说最后总结了四项跟IT相关的工作类型，其实把这四种类型从IT工作抽离出来，每个部门或者个人的工作也能划分为以下四类：
- 业务项目
由公司对外业务需求产生的工作 - 内部项目
为了完善、优化内部工作所产生的工作 - 变更
由上述两类工作引起以及工作实践效果引发的调整工作 - 计划外的工作
由上述三类工作引发的计划外的问题
明确划分不同的工作类型，有利于更好的对工作进行合理安排
三步工作法
第一工作法
是关于工作从执行部门再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标进行优化。
第二工作法
是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题，这样，我们就能在所需之处获取或嵌入知识，从源头保证质量。
第三工作法
是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承当风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。
高德拉特博士的约束理论（Theroy of Constraints）
每个大的工作项目都可以拆分成很多小的工作环节，而每个工作环节对整个项目推进的影响力各不相同，但往往其中有些环节决定了整个项目流程的产出，那么这些环节就是整个项目或者工作流程的约束点。
那么要实现工作效率的提升就不应该是想到哪个环节能提升就提升那个环节，应该找出真正决定工作产出的约束点，提升约束点的工作能力，甚至想办法摆脱约束点的束缚。
简单来说，原文中的5个约束点优化步骤分别是：
- 识别约束点
- 利用约束点
- 让所有其他活动都从属于约束点
- 把约束点提升到新的水平
- 寻找下一个约束点
除了这些，书里的延伸阅读推荐的书籍也有继续深入研究的意义。
