凤凰项目这本书几年前就看过了，当时是当小说来看的。如今虽然还记得大概的故事情节，很多的细节已经忘却。最近又拿来重新读，本想把书全部看完之后再来写总结，按照目前的进度是来不及了。只好中止阅读，先把看过的内容做个总结。按计划是上周要完成的，这几天脑袋晕晕的，无法静下心来，一直拖到了现在。

背景 正如我上一篇文章讲的，所谓的变革，一定是到了山穷水尽的地步，不得已采取的方法。这本书也不例外，作者一开始就表明了无极限公司面临的困境：CEO辞去董事职务，股票暴跌；公司期待“凤凰项目”来提高竞争力，恢复盈利能力，但几年来项目一再延期，上线遥遥无期。董事会决定再给6个月的时间，如果再无显著改善，公司将面临拆分重组。那意味着大批的人将失去工作。

见面礼 主人公比尔临危受命，虽然很不情愿，还是被CEO说服，担任IT部门的副总裁。比尔最重要的任务就是让凤凰项目尽早上线，其他项目都得为凤凰让路。

比尔新官上任，第一个见面礼是工资系统崩溃了，而且必须在晚上5点之前解决。虽然折腾到半夜才把问题解决，但错过了时间窗口，第二天公司就上了头条。这次事故暴露出的问题是变更流程缺乏。IT部门制定了变更流程，但从来没有人遵守。不但开发人员随意变更生产系统，就是自己部门内部人员，对变革流程都有很大的分歧。比尔的第一个改善就从变更流程开始。

凤凰登场 凤凰项目开发部门抱怨IT部门没能及时配置好测试环境，向高层汇报，说IT在拖整个项目的后腿。会议上开发主管声称下周就可以部署上线。在IT看来，目前连测试环境都没开始部署，下周要上线简直是天方夜谭。同时指责开发提交的产品性能连要求的一半都没有，IT不得不部署更多，性能更高的机器来弥补性能缺陷，这又导致工作量的增加。会议上，双方你来我往，互不相让。不幸的是，为了让项目尽快上线，扭转公司困境，CEO站在了开发这边，决定下周5部署上线。

火上浇油 为了应付外部审计，审计人员列出了厚达200页的问题，将近1000条。并要求下周给出整改方案。IT部门已经忙的焦头烂额，谁还能抽出空来应付审计？讨论中，比尔发现居然没人说的清楚IT到底有多少工作，很多工作都没有记录在纸面上，都在大伙的脑袋中。天哪，如果连自己部门有哪些工作都不清楚，凭什么去向领导要求援助呢？比尔要求马上整理一份工作清单出来。幸运的是，比尔的左膀右臂开始相互合作了，两人一起合计着如何来整理这份清单。这是一个好的开始。

变更流程改进 第一次的变更管理会没有一个人参加，比尔只得动用行政命令，在周五重新组织变更会议，缺席人员将受到行政处罚。周五的会议上，大家纷纷吐槽现有的变更流程，看来要按照现有流程是无法展开工作了。比尔拿出一堆卡片，让大家把变更写在卡片上，然后贴到画着日程表的白板上。一开始大伙有点蒙，这是什么玩意？有用吗？但还是有好奇的人把自己的变更贴在白板上，随后大伙也纷纷开始效仿。2个小时的会议，虽然只通过了5个变更，但重要的是，大家开始开始积极的参与讨论，讨论变更的风险，讨论变更是否必要等等。当各部门开始沟通了，我相信问题已经解决了一半。

导师降临 其貌不扬的往往都是高手，这点东西方认知还是一致的。未来的董事会成员埃里克要见比尔，比尔一开始把他当成送甜甜圈的服务员，和他聊起了自己和夫人是多么喜欢这家店的甜甜圈。等埃里克表明身份后，场面显得有点尴尬。

埃里克听了比尔关于如何改善IT效能的想法后，说你还没弄清楚什么叫工作，又怎能提高IT的效能？这让比尔很不爽，接着埃里克又拿工厂做比喻，向比尔灌输了在制品（WIP），瓶颈，三步工作法等概念，最后又让比尔回去找出四种类型的工作。比尔觉得IT工作不能和工厂类比，埃里克的话虽然记在心里，却也不以为然。

确立变更优先级 实施变更看板以来，不仅墙上贴满了卡片，会议桌上也小山似的堆了起来。要在变更会议上评审这堆卡片，估计得花几天时间。为了提高效率，团队调整了变更流程，首先按照优先级对变更进行分类。常规性的变更，因为经常在操作，基本无风险，无需讨论可以直接通过。高风险的变更通知业务部门，并告知相关的风险，由他们决定是否实施变更。中等风险的变更需要通知可能受影响的人，并得到他们的认可。由于事先准备充分，变更评审会议变得极为高效。白板的引入，让变更变得透明，透明又促进了沟通，协作。新式的变更流程让各部门都参与进来。合作，已经从IT部门内扩散到部门外。

未完待续………

优化瓶颈 变更流程跨出了良好的一步，Patti花了很多的精力整理变更卡片，却发现计划本周完成的工作实际只完成了40%，其他的不得不拖到下周。而下周有 会有更多新的变更。进多出少，Patti意识到自己将被卡片淹没了。这样的场景让Bill联想到了工厂的生产场景，大量的半成品堆积在车间。原因都是一样的，是瓶颈制约整个流程。这个瓶颈就是brent。优化瓶颈，首先得知道哪些工作会流向瓶颈。Bill让Patti把涌向布伦特的变更任务先揽下来，过滤处理，并在变更卡片上表示出来，甚至可以要求在所有新卡片上都标注这一信息。等我们知道和布伦特相关的变更是什么、有多少，就把结果反馈给你，还要确定它们的优先级。

风暴来临

计划5：30开始部署，4：30还没有通过关键节点测试，而开发已经下班回家了，只好全部叫回来修复问题。没人告知防火墙还需要开放端口，导致前端无法访问数据库。总之，快到晚上8点了，情况还是一团糟。 bill叫来了wes和patti，同时把负责测试的william也一起叫上，讨论当前的情况。 开发版本提交太快了，往往上一个版本还没测试完毕，下一个版本就来了。而且为了防止弄坏别的东西，提交的都是增量更新包。现在已经没有一个稳定的发布版本了。明天8点门店营业之前，恐怕无法让凤凰正常运转起来。 凤凰好歹上线了，但系统无法和门店pos机对接，所有的交易都得手工完成，财务部门不得不抽调大批人手来处理。系统还有泄露银行卡号的风险。性能问题严重，不得不隔几个小时重启。直到周一晚上，门口终于可以使用收银机了。虽然只是个临时解决方案，至少没有了信用卡号泄露的风险。

鉴于这次凤凰上线的失败，让董事会很是脑怒，CEO把责任都推给了开发部和IT部，计划拆分公司，并外包I T业务，这意味着很多人包括bill自己都将失业。

开发部的chris和bill一起吃了顿饭，现在火收到他们上了，他们得想想如何来应对，饭桌上，两人谈了各自的难处，开发部疲于应对各种问题，没有时间开发功能，项目部署需要的时间越来越长，技术日新月异，让人有点跟不上了。 chris说的代码完成时间，sarah认为上线时间，导致目前这样的局面。chris对此感到抱歉，应该听取william的意见，推迟上线时间。 最后，两人达成统一战线，共同对付sarah。

变更流程取得了一定的效果，有两个团队的变更都涉及同一个数据库，变更流程让他们看到了潜在的冲突病很好的解决了。因为凤凰上线导致几百个变更延迟，引出第四种工作：计划外工作。

优化瓶颈，没有围绕瓶颈做的优化都是幻觉。找出IT运维和工厂之间的对应关系。 不要让约束点迁就别的资源。 不惜一切代价消灭计划外工作 相比于向系统中投入更多的工作，，将无用的工作剔除出系统更加重要。为此，你应该知道，与实现企业目标息息相关的是什么，不论它是项目、运营、战略、法律法规合规、安全性，还是其他别的什么。” 他继续说：“记住，重要的是结果——而非过程、管理，或者你完成了哪些工作。” “别心烦意乱的。等你知道了怎样有效控制发往布伦特的工作量，就给我打电话

发票系统故障，盲目的行动可能导致更大的错误。这次重点在分析故障原因，没有许可，不允许对系统做任何的操作。晚上9点多了，问题原因还是没有找到，ceo坐不住了，让bill赶紧叫上所有人，行动起来，而不是像现在干等着分析结果。bill坚持认为他的作风是正确的，和ceo大吵一通，一怒之下，辞职不干了。

场外会议 如何建立团队信任，展现脆弱的一面。 当每个人都讲了自己的经历，bill甚至流泪了。生活中每个人都有自己的不如意，在会上分享，让大家相互间更好的了解。 ceo谈到IT的人不懂得如何去承诺，安排给IT的工作总是延误。chris认为自己总是完成了工作，wes马上反驳，如果是这样，凤凰也不会搞的一团糟了吧。chris红着脸说，代码确实按计划完成了。bill插嘴道，我们对完成的定义理解不一样。开发部总是没有吧运维工作考虑进去，或者即使考虑进去了，也耗尽了所有的时间，没有留下空间给运维。chris也承认这一点，并说我们有一大堆程序等着部署，我们的工作都被部署工作延误了。 bill谈了下目前运维的工作，除了35个业务项目，还有75个运维项目，有几千个变更需要实施，同时又有很多的计划外工作，大多是由于脆弱的应用程序故障造成的，包括凤凰。基于目前的工作量，大大超出了人力负荷。

IT运维部和开发部在两周内不再接受新项目，并且除了与凤凰相关的工作之外，停止IT运维 部的其他所有工作。

你其实是在构建一份资源清单。也就是材料清单以及所需工作中 心和工艺的清单。一旦有了这个，再加上工作订单和你的资源，你最终就能够理解你的生产能力和需求是 什么。这将让你最终明白，是否可以接受一个新工作并对其作出实际安排

改进的内容几乎是无关紧要的，关键是你要不断改进

研究表明，每天训练五分钟比每周开展一次为期三小时的训练更有效。如果你想 要营造一种真正的改进文化，就必须把那些习惯建立起来。”

通过监控项目，减少问题流向brent的可能性。 弄清楚整个工作流程，哪些工作的是安全的，哪些需要经过约束点。以此作为安排工作的依据。

“在我们离开之前，把你的注意力从工作中心转到工作中心之间的那些空间上。 与控制工作发布同等重要的是管理好工作交接。一个给定资源的等待时间，是那个资源忙碌时间的百分比除以空闲时间的百分比。因此，如果一个资源使用了50%，等待时间就是50/50，或者说1个单位。如果这个 资源使用了90%，那么等待时间就是90/10，或者说9倍时长。那么如果这个资源使用了99%呢？” 尽管还不太理解其中的关联，我还是在心里计算着：99/1。我说：“九十九。” “正确。”他说，“当一个资源使用了99%，那么等待时间就是该资源使用50%时的99倍。”

‘第二工作法’的一个关键部分是让等待时间可视化