最近在读一本名为《凤凰项目：一个IT运维的传奇故事》的书，读后颇有感触，从业这么多年，的确碰到过书中的很多场景，书中描绘的故事其实就是现实工作中的各类缩影。
本书讲述了一位IT经理临危受命，在未来董事的帮助和自己经验的支撑下，改变了公司混乱的局面，最终挽救了一家具有悠久历史的汽车配件制造商的故事。
一、人物
书中出场的人物，囊括了公司中的各类岗位（有管理层，也有基层），并且性格虽然各异，但很具有代表性。下面只列出了书中的几个人物。
比尔：本书主人公，由于他的两个上司被赶走了，所以只能被CEO临危受命，直升为IT运营部副总裁。
史蒂夫：公司CEO，刚辞去担任8年之久的董事长职务，董事会给了他6个月时间，要求他对公司现状作出显著的改进。
莎拉：运营部高级副总裁，总是能让别人替她背黑锅，特别是让IT部门的人背黑锅。多年来，她一直能逃脱各种应负的责任。
韦斯：技术运营部总监，负责一千多台Windows服务器以及数据库和网络团队的技术问题。说话响亮、直率、信口开河。
布伦特：首席工程师，韦斯的下属，一直参与IT部门开展的各大重要项目。每天在疲于奔命，处理突发、棘手或没人知道的项目问题，常常因为各种原因而导致各类计划延期。
帕蒂：IT服务支持部总监，管理所有的1级和2级客服技术人员，处理故障维修事件，并为业务部门提出的需求提供支持。还掌管一些维系整个IT运维部的关键流程和工具，比如报修系统、监控系统，以及组织变更管理会议。
约翰：首席信息安全官，曾让公司很多人厌恶的人，因为大家觉得他在阻碍自己的工作，不过最终他做出了改变，适应了公司环境，和同事一起改变了公司。
克里斯：应用程序开发部副总裁，开发业务所需的应用程序和代码，现在生活完全以凤凰项目为主导。
埃瑞克：候选董事，公司主席和史蒂夫都特别关注的人，想尽办法邀请他加入董事会，经常为比尔指点迷津。
二、过程
1）工资核算故障
比尔刚任命就遇到了麻烦的工资核算故障，这个故障会影响员工的工资，这样就触犯了无数条州立劳动法，而且毫无疑问，工会马上就要大吵大闹了。
韦斯：“联系SAN供应商，因为在尝试恢复SAN之后，数据服务就完全停止了，但SAN现场工程师至少还要4个小时才能过来。”
比尔判断当前的方向是错误的，于是去找布伦特了解情况。期间查检查了昨天从工资核算数据库里导出的数据，发现所有工厂小时工的社保卡号全乱了。
这是一条非常重要的线索。数据库里只有一个字段损坏了，听起来绝对不像是个SAN故障。
再次询问布伦特，他说：“昨天开发计时应用程序的人，反馈了一个数据库表结构的奇怪问题。”
马上联系那名开发人员，但他在休假中。事情有些眉目了，也许是一个开发人员为了能去度假，塞进了一个紧急的变更。可能是约翰推进的某个紧急项目的一部分。
约翰的人从不按照我们的流程来，所以总是惹出麻烦。于是马上联系了他，他那边有一个关于PII存储的紧急审计问题，PII就是个人验证信息的简称，欧盟法律禁止存储这类数据。
约翰：“根据原定计划，差不多一年之前就该完成部署，但尽管我不断催促，它一直都没能完成。现在没时间了。支付卡行业审计师，本月晚些时候要来，所以就加快了计时应用团队的工作进度。”
帕蒂听后强调：“对产品进行任何变更，都有一套规定的程序和流程。如果绕过它们，惹出大麻烦，自己的人还得帮忙修补。 为什么不按照流程去做？”
约翰不以为然：“如果按照流程来，那么下一个可能的部署窗口期要等4个月。但审计师们可是下周就要来了！”
当比尔问约翰有没有进行过测试时，他回答没有测试环境。虽然之前已经提出过预算申请，但还是不了了之。
帕蒂抱怨道，她一直试图让大家使用变更管理流 程和工具，但就像约翰那样，没人用它。报修系统也一样，都是有一搭没一搭的。
帕蒂继续说：“变更咨询委员会，也就是CAB，会碰一两次头。用不了几个星期，大家就会说自己太忙，不再参加会议了。或者由于时间紧迫，他们不等得到授权就进行变更。不论是哪一种情况，变更咨询委员会都会在一个月内变得形同虚设。”
计时应用直到晚上7点才得以恢复。半夜11点，SAN终于恢复运行。比尔作为IT运维部副总裁的第一天表现并不太好。
2）凤凰项目批斗会
会议室里大约有25个人。很多业务领域负责人都到场了，其中有些是莎拉的下属，克里斯也在。
为了支援凤凰项目，最近两年他的团队人数增加了50人，其中很多来自外包公司。克里斯经常被要求用更短的时间、更少的经费去完成并交付更多的产品。
史蒂夫坐在会议桌边唯一一张空椅子的右侧。
上周凤凰项目第1阶段 的关键路径上有12项任务，目前只完成了其中的3项。会议室里响起一片叹息声，好几个人开始窃窃私语。
莎拉认为是比尔的团队一直在拖后腿。分不清轻重缓急，不适应去支持这样举足轻重的项目。
莎拉继续强调，已经为凤凰项目投入了超过两千万美元，而且已经延迟了将近两年。现在必须把凤凰项目推向市场。
克里斯信口开河地确定了一个投产日期，全然不理会在部署之前比尔团队需要做多少工作。
韦斯认为克里斯团队的代码性能太差，部署的技术参数也不提供，测试环境无法搭建，并且必需的服务器和网络设备的交货时间需要三周。
比尔见过类似场景，剧本很简单，首先，接到一项紧急的日期驱动项目，对外承诺发布日期不能延迟；然后，增添一大帮开发人员，用完了所有的进度时间，没时间进行测试或运营部署；随后，由于没人愿意错过部署日期，开发部门之后接手的人只得不计后果地猛抄近路。
结果从来不理想。通常情况下，软件产品实在太不稳定、太不可用，连那些曾经强烈要求这些产品的人最终也会说它不值得上市。到最后，总是IT运维部在通宵达旦地为那些糟糕的代码埋单，每隔一小时重启一次服务器。
莎拉指责比尔缺乏对于紧迫性的必要认知。追求完美是成事的大敌。当前需要建立正向现金流，如果不夺回市场份额，就无法做到这一点。而要夺回市场份额，就必须部署凤凰。
在大家争论不休时，史蒂夫最终说道，“我们已经向投资方和分析师们许诺过，会在本季度发布凤凰项目。”
莎拉驳斥了比尔的所有观点，把史蒂夫引上了一条不计后果的毁灭之路。
史蒂夫最终敲定下周六为上线时间，凤凰将在前一天下午5点部署。
3）人力资源问题
IT运维部有150名员工，平均每1.5人就有一个项目。大部分人力资源都流向了凤凰项 目。审计合规修复是第二大项目。
第三大项目是事故及故障修复工作。目前为止，它占用了员工大约75%的工作时间。由于这些工作常常涉及关键业务系统，所以事故处理的优先级比包括凤凰和审计发现修复在内的其他所有工作都要高。
几乎每个人都难以完成他们的项目工作。即使有时间，他们也得尽力优先处理所有的工作任务。业务部门的人不断要求我们的员工为他们办事，尤其是市场部的人。
公司的所有管理人员几乎都是直接去找他们喜欢的IT人员办事，不是请人帮个忙，就是强迫他们做事。
根据粗略估算，团队可能需要多招7个人：3 个数据库管理员、2个服务器工程师、1个网络工程师，还有1个虚拟技术工程师。当然啦，找到这些人需要一定时间，上岗之后他们还要经过6~12个月的时间才能完全胜任工作。
在向史蒂夫提出招人时，他回答：“凤凰项目已经超支一千万美元，我们必须马上得到正向现金流。你拥有全公司最昂贵的一些人力资源。只能好好使用现有的人手。”
他继续说道：“我给你的建议是，去找你的同事提出充分的理由。如果理由确实合情合理，他们应该会愿意转让一部分预算给你。不过我要说清楚：增加任何预算都是不可能的。如果说会有什么调整的话，可能还得在你的部门里减掉几个人。”
4）布伦特
布伦特实际上并不像我们认为的那样聪明绝顶。也可能他是个技术界的爱因斯坦，别指望能找得到和他同等水平的员工。还可能他是故意让自己显得无可或缺，以免其他人抢了他的工作。
布伦特看起来确实是在真心诚意地帮助所有依靠IT系统的人解决问题。但让我失望的是，大家似乎都把他当作免费的私人极客电脑特工。这是以损害凤凰项目为代价的。
比尔把项目管理会议上提到的五项任务拿给他看。他迅速地说：“这些我都已经完成一半了。只是需要有几个小时不受打扰，安安静静地完成它们。假如可以的话，我会在家里把这些做完的，但是网络连接太慢了。”
随后比尔让布伦特把每个向他求助的人都转给韦斯，确保人力资源完成凤凰项目的关键工作。
每一次让布伦特处理某个别人谁都无法处理的修复工作，他就变得更加 聪明，而整个系统则变得更加蠢笨。现在得终止这种状态。
可以建立一个3级工程师的人力资源库，由他们处理流转过来的工作，但是得把布伦特屏蔽在资源库之外。这些3级工程师要负责完成所有故障的处理，而且他们应该是唯一能够接近布伦特的人——在规定条件下。
如果想和布伦特讨论，他们必须先得到韦斯或比尔的批准。他们要负责记录学到的东西，永远不准布伦特反复解决同一个问 题。比尔每周都会逐项检查这些问题，如果发现布伦特就同一个问题出手了两次，3级工程师和布伦特都要受罚。
每解决一个问题，知识库里就会多一篇关于如何解决某个疑难杂症的文章，而且能够实施修复的人会越来越多。
帕蒂说，“我会定义布伦特的新流程。很乐意通过你和韦斯去找布伦特解决问题。但我们怎么才能劝阻物流部副总裁之类的人不再直接去找布伦特呢？”
比尔立刻回答：“谁要那么做了，就把他们的名单收集起来，我还会给他们的上司打电话，让他们不准再犯。然后我会让史蒂夫知道，这些人都是怎么干扰凤凰项目的。”
5）凤凰上线
周五晚上7点30分，凤凰部署工作如期启动后的两小时，进展并不顺利。
IT运维团队下午4点就在这里全体集合，严阵以待。但无事可做， 因为克里斯的团队没有发出任何指令；他们一直调试到最后一刻。
下午4点30分，威廉一阵风似地冲进了凤凰作战室，他暴跳如雷，因为没人能在测试环境下运行所有的凤凰代码。更糟糕的是，凤凰为数不多正在运行的部分也没能通过各项关键检测。
几分钟前，有个开发人员居然走进来说：“看，在我的笔记本电脑上，它已经在运行了。这能有多难？”
韦斯开始骂脏话，两个我们的工程师和三个威廉的工程师则开始仔细研究那个开发人员的笔记本电脑，设法弄明白它和测试环境有什么不一样。
威廉继续说道：“我真的毫无头绪。代码改得太快了，我们跟不上，凤凰将在投产中炸毁。我和克里斯谈过好几次停止发布的事，但他和莎拉完全压我一头。”
每次发现问题，重发一个新版本，要把所有东西都设置好并运行起来，大约需要半小时，然后执行冒烟测试又需要三小时。在那段时间里，QA可能会从开发部那边收到另外三个版本。
威廉相信每个人都得通宵加班了。并且真正的风险是，明天上午8点门店开始营业时，恐怕无法让凤凰运转起来。那是个大问题。
比尔给史蒂夫、克里斯和莎拉发一封电子邮件，看看能否推 迟部署时间。
史蒂夫说：“要是你能说服莎拉推迟试运行，那我们就谈谈。否则的话，继续努力吧。”
莎拉说：“每个人都做好了准备，唯独你没有。市场营销、开发、项目管理等部门都全力以赴地扑在这个项目上。现在轮到你了。 我们必须继续！”
与此同时，韦斯还带来另一个坏消息，凤凰数据库转换要比原先设想慢上几千倍。 几小时前就应该完成转换，但现在只完成了10%。也就是说，全部数据要到周二才能转换好。
这会导致明天所有店内POS系统都会宕机，那就意味着门店的收银机将无法工作。也就是说，得手动收银，手动刷卡。
他继续说：“我们找到了十五台服务器，但数据中心的机架上没有足够空间安置这些服务器了。只得花大力气重新布线、搭架子，把各种垃圾移来移去。我们对虚拟化投入巨资，这本该避免此类麻烦。但是，开发部解决不了性能问题，却归咎于虚拟化。所以，只能把所有东西都挪回实体服务器！”
到了周六下午2点，事态愈发不可收拾，糟糕程度不断突破比尔原本以为的底线。
使用凤凰网站的客户抱怨，网站不是宕机就是慢到无法使用。在看过电视和报纸广告后，所有原本兴致勃勃尝试新服务的客户都开始抱怨IT大败笔。
而那些成功在线订购的客户则在去门店提货时才如梦初醒。那时大家才发现，凤凰似乎会随机丢失交易，其他情况下，它又会从客户信用卡上划走两倍乃至三倍的费用。
因为可能已无法保证销售订单数据的完整性，财务部的安愤怒地驾车赶了过来。现在她的团队已经在走廊对面建立了另一间作战室，接听门店的来电，处理问题订单。中午时分，数百名愤怒客户的传真从各门店发来，已经堆成了小山。
下午4点30分，比尔又收到一个坏消息，推特上疯传凤凰网站正在泄露客户的信用卡号。他们甚至贴出了截屏。当你清空购物车时，会话崩溃，并显示出上一个成功订单的信用卡号。
到了周一，凤凰危机已经演变成了一场公关丑闻。它上了所有技术网站的头条新闻。
6）救火
那些救火的事情（计划外的工作）代替了计划内的工作，不论是项目工作还是变更工作。
埃瑞克说它是最具破坏性的一类工作。它不像其他类型的工作那样，是真正意义上的“工作”。其他三类工作（业务项目，内部项目以及变更）都是出于需要而计划去做的。
比尔想到了与埃瑞克的对话，立刻向他打电话取经。
埃瑞克说：“计划外工作是恢复性工作，几乎总是让你远离目标。因此，知道你的计划外工作从何而来就显得尤为重要。”
他认为比尔已经开始着手稳定工作环境了，已经开始可视化管理IT运维部里的半成品了，而且已经开始保护自己的约束点——布伦特了，还强化了一种严明纪律的工作氛围。
在大多数工厂里，总有那么一小部分资源，不论是人、机器还是原材料，决定了整个系统的产出。将其称之为约束点——或者瓶颈。
在建立起一个可信赖的系统用以管理通向约束点的工作流之前，约束点经常是被闲置的，也就是说，约束点可能在很大程度上未被充分利用。
那就意味着，没有向业务部门交付全部的可用资源。也可能没有还清技术债务，因此随着时间的推移，遇到的问题和计划外工作量会不断增加。
高德拉特在《目标》里描述了五个聚焦步骤，第一步是确认约束点。
第二步是利用约束点，确保不让约束点浪费任何时间。永远不要让约束点迁就别的资源而干等着，而是应该专注于 IT运维部对当前所需完成工作中优先级最高的那一项。
第三步就是把约束点置于次要地位。
7）封版两周
比尔提出IT运维部和开发部在两周内不再接受新项目，并且除了与凤凰相关的工作之外，停止IT运维部的其他所有工作。
两周后一切照常，此举的目标是提高整个系统的生产能力，不只是提高任务的完成数量。
韦斯说：“难道那不会让我们中的大部分人闲得无聊、无事可干吗？那就是130个IT运维部的人干坐着。那听起来不是有点儿……浪费吗？”
埃瑞克嘲讽地笑了笑，说：“我来告诉你什么是浪费。超过一千个变更卡在系统里，看不到完成它们的方法，这听起来怎么样？”
卡片数量一直在增加。如果那就是半成品，显然增加的速度已经失控了。恐怕用不了几周，那些卡片会堆到天花板上。
接下来一小时中大家达成的一致意见令人惊讶。IT运维部将会冻结所有和凤凰无关的工作。开发部不能让他们的二十多个与凤凰无关的项目空转，但他们会冻结所有部署工作。
换句话说，接下来两周内，不会有工作从开发部流向IT运维部了。
此外，大家将确认最主要的技术债务，开发部会对其进行处理，以减少问题应用程序所产生的计划外工作量。这些都会让我团队的工作负荷变得截然不同。
8）跨团队协交接
埃瑞克说过，等待时间取决于资源使用率。“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说，如果一个资源的忙碌时间是50%，那么它的空闲时间也是50%。等待时间就是50%除以50%，也就是一个时间单位，一个任务在处理前的排队等待时间为一个小时。”
对这个凤凰任务来说，假设有7个交接步骤，而且每一个资源都有90%的时间是忙碌的，那么任务排队等待的总时间就是9小时乘以7个步骤。
在一个部门内创建工作并确定其优先级就很难，而管理多个部门之间的工作则是难上加难。
板上的每一张纸都像是这个凤凰‘任务’。看起来似乎是一个单独人员的任务，但实际上，它是需要在多个人员之间进行多次交接的多个步骤。难怪柯尔斯顿的项目时间预排都没能兑现。
比尔补充道：“如果能够把所有的经常性部署工作标准化，最终就能达到产品配置的一致性。现在的基础架构过于多样化，就像雪花一样——没有两片重样的。布伦特之所以会成为布伦特，是因为允许他建立起只有他能理解的基础架构。”
部署就像是制造工厂里的总装配。每一条工作流都要经过它，而且缺了它你就不能发出产品。
帕蒂提出了一个新角色，兼有项目经理和稽查员的职能。让所有已完成的工作都快速有效地交接到下一个工作中心。必要时，这个人要在工作中心等待，直到工作完成并运往下一个工作中心。
9）与业务人员的访谈
帕蒂和比尔将对业务流程负责人进行访谈，主题是“理解客户的需求 与期望”、“产品系列”、“上市时间”以及“销售渠道”。
今天是星期五，计划访谈制造销售部副总裁罗恩·约翰逊。
他认为差劲的‘了解客户的需求和期望’影响了‘销售预测准确率’。他还详细地告诉我们，他手下的经理们想从客户关系管理系统 （CRM）中拿到他们需要的报告有多困难。
他继续说道：“在季末最后几天电话不能用了，客户没法下订单，或者作出临时变更！这件事延误了150万美元的订单，十个客户重新评估了他们的合同，又有500万美元的订单岌岌可危。”
下次的访谈对象是玛姬·李，她发起了凤凰项目。她是超过一半IT项目的业务发起人。此外，玛姬还负责保证每一家门店的货品都尽可能地丰富多样，她还负责确定公司的售货类别和定价方针。
她总结道：“归根结底，我对‘了解客户的需求和期望’的衡量标准是，客户是否会向朋友推荐我们。”
她继续说道，“大多数时候，我们都在盲目行动。理想情况下，销售数据会告诉我们客户想要什么。也许你认为，有了订单输入系统和库存管理系统中的数据，就能做到这一点。但这些数据几乎总是错的。”
数据质量太差，因此无法凭借这些数据来进行各种预测。现有的最佳数据，来自于两月一次的门店经理访谈，以及一年两次的核心客户群访谈。
她希望从门店和在线渠道得到准确及时的订单信息。不用像现在这样杂乱无章地运用这些数据。运用那些数据来设计市场推广活动，不断推出“A或B”产品选择测试，以发现客户认可的报价。一旦发现哪些有效，就能在全部客户中复制推广。这样做就能为罗恩创建一个巨大的、可预测的销售漏斗。
运用那些信息来推进生产计划，那样就能管理供求曲线。让正确的产品出现在正确的货架上，并一直备好库存。平均每客户销售额将会一路冲高，平均订单金额也会上升。
帕蒂插话说：“你们把产品推向市场的合理时间是多久？”
她立刻回答：“现在？产品需要在六个月内上市。最多九个月。否则， 一些其他的公司就会剽窃我们的想法，让产品出现在竞争对手的货架上，并抢走大部分市场份额。”
在竞争的时代，游戏规则就是‘快速上市，快速淘汰’。不能为推出一个产品而制定为期几年的工作计划，一直等到最后才弄清手上拿的牌是赢家还是输家。而是需要短而快的周期，不断整合来自市场的反馈。
迪克希望研发投入可以平均回报超过十个百分点。那是内部最低预期资本收益率。
九个月内向公司返回现金，这是最长时间了？而凤凰上花了将近三年时间，依然尚未创造出期望的商业价值。也许致力于凤凰项目是完全走错了路。
接着，玛姬描述了围绕IT项目资源的激烈竞争。“我们的计划周期是6~12个月。谁能知道自己三年以后应该做什么项目？”
她说了一些想法，包括招聘更多IT人员，把一些IT人员专门划拨给她的团队，更多关注那些妨碍IT项目队列的项目，等等。
离开玛姬的办公室后，帕蒂欢呼道，“我无法相信玛姬和罗恩居然这么沮丧。你能相信吗，订单输入和库存管理系统中的不可靠数据又出现了？我也不能相信，按照当前的设计，凤凰实际上不能解决数据质量问题！”
三年多来，已经为凤凰投入了两千多万美元。这个项目锁住了那么多半成品和资金，恐怕再也不能达到10%的内部最低预期资本收益率。 换句话说，凤凰原本就不该被批准。
10）访谈后的应对处理
比尔在白板上画了一张表格，其中有一列是“由于IT导致的业务风险”。
约翰说，“通过描述IT可能会出现哪些阻碍业务成果实现的问题，就能帮助业务流程负责人拿到他们的奖金。这应该会非常有说服力。业务部门也许还会为我们所做的事而感谢我们呢，那可是让人耳目一新的改变。”
对于电话和MRP系统，很快确定，预测评估指标包括遵守变更管理流程、监督审核生产变更、完成定期维护，以及排除所有已知单点故障。
但在处理“客户的需求和期望”时遇到了困难。克里斯指出，“大部分问题是在上游产生的，因为市场营销人员不断输入格式不正确的库存量单位（Stock Keeping Unit，以下简称SKU）。市场营销部也得解决他们的问题。”
对于“市场营销的需求和期望”，我们提出的评估指标包括凤凰支持每周报告并且最终支持每日报告的能力，市场营销部生成的有效SKU比例，等等。
迪克在看好演示后说道：“比尔，你是说，公司里每一个人都在做每一件正确的事，但因为这些IT问题，我们大家还是不能完成目标？”
“是的，先生。”比尔说，“和其他业务风险一样，由IT引起的运营风险也应该得到管理。换句说话，由IT引起的运营风险不是IT风险，而是业务风险。”
然后他问：“好吧，你有什么建议？我想你已经想好一个建议了吧？”
比尔开始推销自己的想法，“我想用三个星期的时间，逐一会见那张电子表格上的每一位业务流程负责人。我们需要更好地定义由IT引发的业务风险，并且达成共识，然后向你提出把那些风险纳入主要业绩指标的办法。我们的目标不只是提高经营业绩，还要对能否达成目标提供前瞻性指标，那样我们就能采取适当的行动了。”
比尔继续说：“我们的进展太慢了，还有那么多半成品和功能吊在半当中。我们应该把发布变小变短，更快地回笼资金，那样才能达到内部最低预期资本回收率。克里斯和我有一些想法，但是会和公司现行的既定计划大不相同。”
他保持沉默。然后果断地宣布：“你的两个提议我都同意。我会派安去帮助你。你需要公司里最优秀的人才。”
星期五，约翰召集韦斯、帕蒂和比尔开了个会，为了将与安全性相关的工作量减少75%，他提出了五条建议。
第一条建议是大幅度缩减SOX-404合规项目的范围。
第二条建议是要求技术部弄清楚生产薄弱点一开始是如何产生的，并要求调整部署流程，杜绝此类情况再次发生。
第三条建议是要求在帕蒂的变更管理流程中，标记出所有列入合规审计范围的系统——那样就能避免可能危及审计工作的变更—并要求创建持续记录文档，今后审计师会要求提供这些文档。
第四条建议是通过清除所有存储或处理持卡人数据的东西，来缩减PCI合规项目规模，从销售系统里那个该死的自助餐厅销售点着手。
第五条建议是用前几条建议所节省下来的时间，来偿还凤凰的所有技术债务。
11）又一次凤凰部署
按时完成了所有的应交付成果，不过和往常一样，依然有数不清的细节问题需要研究。
目前已经稳定了基础架构。一旦真的发生难以避免的服务中断和事故，大家就像一台运行良好的机器一样运作起来。大家已建立起部落文化般的工作共识，这帮助大家比以往任何时候都能够更快地排除故障，而且，一旦真的需要把工作升级，也是可控而有序的。
由于不断提高对基础架构和应用程序的产品监控，大家常常在业务部门察觉之前就知道了事故的情况。
已经减少了项目积压，一部分是通过剔除序列中的无用项目来实现的。约翰已经完成了这件事。大家已经从审计准备和整改工作中削减了很多不必要的安全项目，代之以团队全员帮助实施的预防性安全项目。
通过调整开发和部署流程，以一种有意义的、系统化的方式，加固并保护了应用程序和生产基础设施。而且，大家的信心不断增加，这些缺陷今后再也不会发生了。
变更管理会议比以往更加顺利，也更有规律。大家不仅能了解团队正在做什么，还能了解工作确实在不断推进。
大家比以往更加明白，自己应该做哪些事。员工从故障修复中获得了成就感。
改进的不只是布伦特的工作。通过减少悬而未定的项目数量，让工作流转的通路保持通畅，那样，工作就能从一个工作中心快速移到另一个工作中心，并以打破纪录的速度完成。
埃瑞克说，“我们正在制止工作缺 陷交接至下游工作中心，我们正在管理工作流，运用约束点来控制节奏，而且我们以审计部门和迪克那里拿到的结果为依据，比以往更好地理解了哪些是重要的工作，哪些不是。”
最终，比尔主导发起了回顾小结环节，对我们自身的工作开展情况以及需要改进的方面进行自我评估。
训练让伟大的团队达成最优表现。对任何流程或技能来说，训练成习惯，习惯成精通。
约翰很快获得了迪克和史蒂夫的批准，找一个外包商接管自助餐厅POS 系统，并将其替换成具有商业支撑的体系。
12）特战队
威廉走到白板前开始画方框，一边画一边讲解那些步骤。接下来的十分钟里，他证明了一共有一百多个步骤，包括在开发环境下运行的自动测试、创建与开发相吻合的QA环境、朝其中部署代码、运行所有测试、部署并移至与QA相吻合的新模拟环境、负载测试，最后再把接力棒传给IT运维部。
威廉弄完后，白板上有了三十个方框。
布伦特站起身来，开始画方框，这些方框表示要部署的代码包，准备新的服务器实例，载入并配置操作系统、数据库及应用程序，对网络、防火墙及负载平衡器开展各种变更，随后进行测试，确保部署大功告成。
有无数的配置需要正确地设定，系统要有足够的内存，所有文件都要安装到正确的位置，所有代码和整个环境也需要正确地操作。
哪怕是一个小小的失误就能让一切崩塌。这显然意味着，大家应该比生产制造领域更加严格，更守纪律，更有规划性 。
帕蒂指出：“在现有流程下，有两个问题不断出现： 在部署流程的每个阶段，在我们需要的时候，部署环境却总是没有就绪，即使已经准备就绪了，也需要大量返工才能让它们彼此同步。”
她继续说：“返工和准备时间过长问题的另一个显著来源是代码打包流 程，在此阶段，IT运维部对经过开发部检查的内容进行版本控制，然后生成部署包。尽管克里斯和他的团队尽可能地记录代码和配置，总还有东西会遗漏，这些东西只有在部署之后，代码无法在环境中运行时才会被发现。”
比尔问道，“布伦特，我们要怎么做才能建立一个通用环境创建流程，从而在同一时刻同时构建开发、QA和生产环境，并让它们保持同步？”
他站起身来，画了三个方框，分 别叫作“开发”、“QA”和“生产”。然后他在它们下方画了另一个叫作“构建过程”的方框，这个方框有三个箭头，分别指向上方的三个方框。
比尔对克里斯说：“这看起来很有希望。如果能把环境标准化，并把这些环境投入开发部、QA和IT运维部的日常使用，我们就能消除大部分在部署流程中因差异而导致的悲剧。”
帕蒂看着画满方框的第一块白板说：“如果我们重新设计流程，就需要让正确的人员事先介入。这就像是制造工程组确保所有零部件都设计得有利于生产，而生产线也规划得有利于零部件的流转，理想状态下达到单一工作流。”
威廉走到白板前，指着一个名叫“代码提交”的方框说：“我会改变这个步骤。不再通过源代码控制从开发部获得源代码或编译代码，而是希望拿到准备部署的打包好的代码。”
他继续说，“我迫切地想要这样的代码包，我很乐意主动接管创建包。我也完全知道应该派谁去做这件事。她将负责开发交接。 一旦代码被标记为‘准备测试’，我们就要生成并提交代码包，那会触发一个QA环境的自动部署。今后，也许连生产环境也能自动部署。”
未完待续.......