下载掌阅APP，畅读海量书库
立即打开
“所以，我们的提议是停止估算、停止计划，还要他们相信这样能神奇地让所有需求都在30天内交付？”
“是的！你认为他们会同意吗？”
在华盛顿州雷德蒙德的微软园区115号楼办公室里，我和杜米特留大眼瞪小眼。当时是2004年秋天，我还记得那天下着雨，天色暗沉、阴云密布。
“不，可能不会同意！”
杜米特留的改进成果已经成了一个传奇：变更需求的交付速率提高了230%，而前置时间从平均5.5个月减少到仅12天，准时交付率达98%，远超过SLA要求的25天。本章将介绍杜米特留推行了哪些改进措施，又是如何落实的。
由于团队效能的大幅提升，杜米特留得到了提拔，后来戴尔·克里斯蒂安从XIT的总经理调任埃维诺的CIO时，又将杜米特留挖到了新公司。在两年内连续两次调动后，杜米特留从微软一个6人团队的程序经理，晋升为埃维诺的全球IT运营高级总监。要知道，程序经理这一职位仅比大学毕业生高两个薪资等级。在微软IT团队中，XIT维护工程团队的客户服务纪录从最差变为最好，杜米特留因此获得了该部门2005年下半年的流程改进奖。
团队要遵循很多过程要求，其中就包括各级管理人员做出的不合理决策，这些决策往往是孤立的，没有充分考虑对整个服务的影响。将一类服务及其工作流视为用来管理行为的一套规则，是一种很重要的视角。高层有权力否决或改变规则。例如，使用PSP/TSP的规则是在执行副总裁层面确定的，该层级仅次于比尔·盖茨，因此该规则很难改变，或者可以说，不会改变。会计和预算划转的规则由财务部门的中层制定，也很难改变。关于优先级和用ROI进行业务评估的规则由项目管理办公室（program management office，PMO）制定，并要求产品经理照此执行。虽然不是完全不可能改变，但我和杜米特留尚未有足够的职级和影响力。然而，也有很多规则是由团队内部的直接管理者共同制定的，例如估算工作优先级高于研发编码和测试工作。这些规则在制定时可能是合情合理的，但当情况发生变化，却没能检视和更新这些管理团队运行的规则。尽管存在其他限制，但在一些规则上仍然有改变空间，我们将通过这些改变来促进效能提升。
在与同事和经理进行一番讨论后，杜米特留决定先推动两项管理变更举措。第一项举措是停止估算。他希望将浪费在估算活动上的产能，重新投入到软件开发和测试中。这样一方面能消除估算导致的交付计划不规律，另一方面也提高交付的可预测性，他希望二者结合能显著提升客户满意度。
然而，直接取消估算会带来一些问题。首先，这将会影响ROI的计算，客户可能会担心因此做出不合理的优先级决策。其次，估算结果也被用于部门间的成本核算和预算划转。此外，估算还被用作实施管理规则的依据，即只有成本较小的需求才被允许纳入系统维护，开发或测试工作量超过15天的大需求必须提交重大项目流程，并通过正式的PMO投资组合管理审批。后面我们也将重新审视和讨论这些问题。
估算具有干扰性，影响按承诺日期交付的能力，而交付日期的不可预测影响客户满意度。如果杜米特留仅仅是要解决这个可预测性问题，也许他会做出不同的选择。取消估算是为了将用在估算上的至少占1/3的产能收回来用于交付，提高交付的可预测性。我们有4个备选方案：第一个，完全停止估算；第二个，将估算活动与承诺的工作交付分隔开；第三个，用“估算师”这样的专家角色将估算工作切分出去；第四个，建立一种混合机制，以固定节奏让团队成员轮流担任估算师，比如每周轮换一次。
· 方案1：完全停止估算。这是最激进的选择，需要我们引入一个SLA。这样虽然能够收回浪费的产能，但也需要与客户达成新协议、新合同。这是最大胆的选择。
· 方案2：将估算活动与承诺的工作交付分隔开。将估算、确定优先级和计划工作分配到固定的时间段中，在客户价值交付类工作和计划类工作进行任务切换，这是敏捷SDLC方法论Scrum
中使用的方法。如果在XIT维护工程团队中采用这种方法，杜米特留每月需要安排8天时间用于估算和计划工作，然后将团队的其余时间用在开发和测试上。此方法将提高可预测性，并极大地提高客户满意度，但还是无法解决约1/3的产能被估算工作占用的问题。
· 方案3：用“估算师”这样的专家角色将估算工作切分出去。沿用Scrum，指派专家的选择也可能在此奏效。杜米特留可以告知TCS在海得拉巴当地的管理人员，让团队中的1名开发人员和1名测试人员长期负责分析和设计工作，以提供估算数据。这是一个比较简单的规则变更，还可以防止另外2名开发人员和2名测试人员被打扰，并显著提高按时交付的能力。不过，这样显然还是有1/3的产能被用在了估算工作上。
· 方案4：以固定节奏让每个团队成员按周轮流担任估算师，可能比指派专家更容易被团队接受，但它依然没有收回在估算上浪费的产能。
由上可见， 只有彻底停止估算才能释放产能。 虽然客户对不可预测、不可靠的交付和违背承诺感到不满，但他们对前置时间也同样不满。而前置时间不断延长是因为需求超过了供给能力。因此，他们需要提升产出量。恢复1/3的产能就能有效提高产出，可以直接解决待办列表不断增长和前置时间持续延长等问题。这带来了一个有趣的权衡：用SLA取代单个估算和交付日期承诺，将多完成50%的工作，同时有机会控制不断增长的待办列表。随着交付时间得到控制，产品经理和人力资源等共享服务客户部门可能会发现，这样的举措是契合目的的。
在XIT维护工程团队所做的改变中，不做估算是根据具体情况而做出的选择，同时也综合考虑了其他3种方案。其他方案也是可行的，并且都将有助于解决客户满意度低下这个重大问题。无论他们做出哪种选择，都要使用看板系统，这个故事仍然是看板方法的原型。
在早期，看板方法经常被称为“无估算”方法。这在传统项目管理领域引起了一些恐惧和忧虑，同时也在Scrum社区引发了内部争执，因其已经将计划扑克
和其他估算技术固化了下来。在制定服务优先级规则时，就应该把是否估算纳入考虑。与工作相关的风险决定了是使用已知信息进行工作更好，还是收集更多信息后再做出承诺更好。估算需求的目的是获取完成一项工作所需成本或时间的推测信息。在某些情况下，这些信息可能对风险管理有用，而在其他情况下，它对企业的良好治理几乎没有什么影响，因此可以直接避免。对于XIT维护工程团队来说，他们的客户习惯于由SLA定义的IT服务。而杜米特留在此向客户提出一个简单直接的替换方案：“如果换成一个有明确前置时间预期的SLA，作为回报，我们每年将为您多完成约50%的需求交付。”
杜米特留还决心限制WIP，在当前工作完成后再从输入缓冲区中拉入新工作。两次填充会议（replenishment meeting）间有一周时间差，输入缓冲区的大小被设置为团队在此期间的最大预计交付量，也就是说，其大小刚好能够确保开发人员手里一直有活干，永远不会闲着。杜米特留决定将开发中的WIP限制为每个开发人员1个需求，对测试人员也使用类似的规则。这是个体软件过程（Personal Software Process，PSP）推荐的做法，实际上，团队已经在这么做了。他在开发和测试之间插入了一个小缓冲区，用于接收PTC类需求，并使开发和测试之间的工作流保持顺畅，如图3-1所示。该缓冲区的大小粗略设置为5个。我们并不知道应该设置成多大，所以先猜测一个数值，并根据观察到的情况来调整其大小。如果来了大批量的PTC类需求，缓冲区很可能会满溢，阻塞上游开发工作。开发人员必须等到测试人员清理了这批PTC类需求，即看板信号在缓冲区中重新变得可用后，才能让完成的开发工作向前流动。
图3-1 XIT维护工程团队工作流对应的看板系统
在任何给定时间，每个开发人员只对应一个变更需求，这是一种策略选择。当然后续也可以对此进行修改。将一个服务视为一组策略的集合，是看板方法的一个关键点。
杜米特留还准备放弃每月的计划会议，改为更频繁的看板填充会议。同时取消甘特图，也不再对计划中的所有事项提前做出承诺。工作需求的待办列表将保持未承诺状态，等到填充会议上，4位产品经理和程序经理杜米特留达成共识后，将选中的需求拉入看板系统，才算做出了承诺。
杜米特留不得不考虑与产品经理互动的节奏。看起来每周开一次会议来填充看板系统较为可行。他计划以电话会议的形式展开，会议主题聚焦于填充空着的看板展示板，具体说来就是从待办列表中选出需求，填满输入缓冲区中的空位。一般情况下，输入缓冲区每周可能会空出3个位置。因此，讨论将围绕一个问题展开：“在接下来的25天里，你最希望交付的是待办列表中的哪3项？”这是一个简单的问题，应该能让会议变得简短。
杜米特留希望提供一个确有保证的交付时间，即从需求纳入看板系统的输入缓冲区开始，在25天之内完成交付。实际上完成工作所需的平均工程时间是11天，25天的服务保证期远远超过了这个时间需求。统计上的此时间数据极端异常值是30天左右，但他预计这种情况很少出现。与现在约140天的前置时间相比，25天听起来已经很有吸引力了。他期望能够稳定达成这个目标，从而与产品经理和客户之间建立信任。
传统的计划方式是通过甘特图规划每个需求预期的开始和结束日期，为每个项目做出具体的交付日期承诺。这种详细计划的方式被弃用，转而使用一个简单的SLA，保证服务水平为从承诺到交付不超过25天。
我们坐在杜米特留的办公室里，一起分析问题所在，并设计出了解决方案。我们看着彼此，杜米特留笑了起来。
“所以，我们的提议是停止估算、停止计划，还要他们相信这样能神奇地让所有需求都在30天内完成交付？”
“是的！你认为他们会同意吗？”
“不，可能不会同意！”
要让人们支持这个想法，需要的不仅仅是一个有力的逻辑论点。
让我们依次考虑每项变革举措，并分别思考这些提议如何才能被接受。
首先是开发人员和测试人员，他们发现估算工作具有干扰性，会影响他们优质高效地完成本职工作。此外，他们的专业能力是软件开发和测试，也拥有相关的学位和专业资格认证，并没有人要求他们去学习、参加考试或获得估算方面的认证。估算能力并不是他们岗位的核心能力，也不是他们职业自豪感或自尊的来源。如果我们告诉海得拉巴的团队，以后不再需要做估算工作了，相信他们将会举手庆贺。
其次是程序经理。程序经理负责推动制订计划，并在Microsoft Project中用甘特图构建计划。如果我们告诉程序经理不再做估算，也不再需要甘特图，可能会出现一些阻力。程序经理很可能将自己看作项目经理，而且在这个位置上的许多人都是项目管理专业组织，如项目管理协会（Project Management Institute，PMI）的成员，并通过考试取得了类似项目管理专业人士（Project Management Professional，PMP）这样的资格认证。想要取消制订计划和制作甘特图的建议，可能会被解读为对他们岗位价值的否定，是一种不被尊重的表现，并暗示他们的技能甚至他们个人已不再被重视。然而，我们的程序经理是杜米特留，一个前奥运会运动员、特技替身演员、保镖兼精神病院管理人员。他并没有获得任何专业项目经理的身份。所以我们很幸运，杜米特留是变革的主导人，他是一名推动者，而不是反对和阻碍变革的人。如果不是这样的话，一切可能在那时就失败了。也许看板方法就不会诞生，更遑论其作为一种管理方法被全球各地所采用。也许就不会有“小蓝书”，也不会有关于这个主题的其他书籍。
最后是产品经理。他们的角色职责主要体现在3个方面：代表客户和业务方管理预算；协助客户进行需求分析并细化需求内容；通过业务评审和基于最大化ROI的工作优先级排序，做好预算管理。 [2] 他们采用的公式如下：
ROI=业务价值 / 成本
成本=每小时费率×预计工时
没有估算值，ROI计算公式就缺少了分母，无法进行计算。停止估算让产品经理无法完成业务评审，也不能根据ROI对需求进行优先级排序。
这正是我们认为他们不会接受如此举措的一个关键原因。
第二项举措是采用一个看板系统，从未曾承诺过的待办列表中拉取工作。我们的打算是延迟承诺，而非像以前一样早早做出承诺。
在这种情况下，开发人员和测试人员不受影响，因此我们预计在他们那里不会有任何阻力。杜米特留是程序经理和变革的主导者，接受起来自然也没问题。但对于每个业务单元的产品经理及其客户而言，这是一项较大的改变，他们习惯了在提交需求后的几周内就获得明确的计划。尽管他们也知道计划毫无意义，XIT维护工程团队从未在承诺的时间内交付任何东西。
我们的方法是先向他们展示被放弃和丢弃的需求数据。数据显示，只有52%的需求被交付，剩下的48%中，有些从未进入开发环节。那么，何必要对这些需求做出承诺呢？这种技巧在许多变革实施中都被证明是非常有效且有说服力的。当你让那些受影响的人去进行数据挖掘，当他们发现自己有多少需求从未被实现时，效果尤甚。有时，我们有必要对“被放弃”做出明确定义。被放弃意味着什么？如果一个需求自提出以来已有6个月、12个月或24个月都没被处理，那么它算是被放弃了吗？组织对于“如果我们还没有着手处理它，可能永远也不会处理”这种情况的容忍度和阈值在哪里？当你将这些数据明确呈现出来时，将成为非常强有力的支撑。
结合拉取系统变革与SLA变更，可以有效汇总并展示所有需求的交付风险，而不是基于推测做出难以实现的单个承诺。业务部门在获取IT服务时，习惯了按合同、按SLA（包括对前置时间的保证）进行管理的模式。所以我们建议他们切换模式，换个角度看问题，不要纠结一些分散的小需求，而要管理一项连续的服务。这个提议似乎奏效了，几乎没有反对意见。反正事情已经糟糕了这么久，为什么不试一试这种另类却又熟悉的方法呢？
最终，我们提出不再制订计划。这对开发人员和测试人员依然几乎没有影响。他们原本就习惯于按照项目计划中定义的顺序进行工作，现在只不过换成从缓冲区中拉取工作，该缓冲区在他们现有的跟踪工具Product Studio中进行定义。程序经理是杜米特留，所以他这里同样不会有阻碍。那么产品经理呢？他们现在要每周参加一次填充会议，而不是每月一次的计划会议。只要我们能够解决ROI计算的问题，产品经理负责的其他和计划相关的工作，比如准备业务评审和按优先级给待办列表排序，都不会受到影响。
实际上，计划会议往往漫长而烦琐，桌子上有一张很大的甘特图，大家用铅笔在上面做标记。这些会议对任何人来说都很无聊，且花费时间很长。只要我们的其他建议能有效运转，大家在各自的职务中仍专业、能干、高效，改成每周一次、每次15～20分钟的简短电话会议，听起来是一种极大的解脱。
最后，我们需要考虑杜米特留的上级的意见。他们会怎么看？
参考了大家的意见，杜米特留的直接上级对我们的做法存有疑虑，并担心带来不好的结果。而再往上两级的反应则是哈哈大笑：“你要停止计划、停止估算，然后觉得这样一切就会好起来？”不过，一旦他们稍微冷静下来，就能够理性地思考：“这项服务的问题已有很长时间，连续几任经理都未能解决，将服务外包到海外也没有解决问题。虽然这些举措听起来非常疯狂，但我们把你安排到这个职位就是为了做出改变。如果这就是你想要做出的疯狂改变，那么至少我们应该试试看。”所以，高层将拭目以待。
然而，仍存在一个问题：如何让产品经理在没有估算的情况下，继续完成业务评审和优先级决策工作？为解决这个问题，杜米特留提出了一个天才般的想法，加上他的社交才能和人格魅力，最终促成看板系统在微软的首次落地。
杜米特留逐一去到各位产品经理的办公室拜访，然后再去拜访他们的直接上级。他希望每个人都接受我们的提议，避免受其他产品经理的意见影响，或迫于社会压力抱团拒绝提议，保守地坚持现有做法。逐一说服他们之后，杜米特留召开了一次集体会议，正式启动变革，并推出看板系统。
杜米特留带着简要的变革方案去和产品经理沟通，介绍了工作流和我们提议的看板系统草图（见图3-2），同时也说明了填充会议的想法，并展示了过去一年的需求的工程时间分布图（此前在图2-5展示过，方便起见，这里再次进行展示，见图3-3）。
图3-2 XIT维护工程团队工作流的完整解决方案
图3-3 平均每个变更需求的实际开发和测试时间示意
杜米特留向每位产品经理展示，变更需求实际的工作时间分布在一个相对较窄的范围内：大多数需求的开发和测试工作时间为3～10天，平均不到6天。考虑到现在的需求量以及未来需求量的大幅增加，杜米特留建议用最近历史数据中的实际花费时间来计算平均值，以替代原来虽具体且确定却仍是推测性的估算值。毕竟实际花费时间的平均值有事实依据，而对于任何单个需求的估算值都只是推测。
从本质上讲，只要产品经理愿意接受成本的小范围波动，并愿意忽略这种波动，那么就能得到其他好处，比如提高生产力和可预测性。我们并没有要求他们改变自己的工作内容或工作方式。他们的身份、自尊、社会地位、在组织内得到的尊重和专业水平也没有受到任何质疑或威胁。相反，我们只是要求他们接受用平均成本来计算ROI，并认同其足以支撑他们做出有效的优先级决策。
ROI=业务价值 / 平均成本
实际上，当问题存在明显的不对称性时，这种方法的效果很好。也就是说，当所有业务价值显著超过所需成本时，ROI的排序结果其实对成本的变化不太敏感，成本的差异可以忽略不计。如果这种不对称不存在，成本与业务价值相对接近，成本估算才有真正的价值。讽刺的是，这种收益和成本相对对称的情况在财务、人力资源等共享服务和后台职能的IT系统中非常普遍。因此，在管理后台系统的IT投资组合时，项目成本估算很重要。然而，对于系统维护和维护工程团队来说，部署新财年的税收表这种小需求常会产生巨大的影响，这肯定满足不对称收益要求。当然，在2004年，我们还没有现在这么老练，产品经理也一样，他们都接受了我们的提议。
2004年10月，看板方法被准许应用到微软的XIT维护工程团队，这也是第一个已知并有记录的用于无形产品和专业服务工作的虚拟看板系统。
我们的变革举措最终在团队中逐步落地。杜米特留通过Product Studio，使用存储在数据库中的存储过程来强制执行看板系统的WIP限制。当有空闲槽位时，它会发出拉取工作的信号，并且触发系统自动发送电子邮件。杜米特留取消了每月的计划会议，改为每周召开电话会议来填充看板系统。新的研发需求也不再发送到海得拉巴进行估算。
这些措施逐渐生效。需求得到了交付，并被发布到生产环境中。新约定的25天交付时间承诺也得以保证。周例会运行顺畅，输入缓冲区每周都会得到填充。渐渐地，XIT维护工程团队开始与产品经理建立信任。到2005年第一季度，客户开始看到在承诺的SLA约定范围内，需求会被快速交付并部署到生产环境中。
进化遗迹指的是生物在进化过程中遗留下来的东西，它们不再发挥任何实际的作用，但依然存在，生物学家称之为退化器官。人类就有几个退化器官，比如我们脊柱末端的尾骨是已经消失的尾巴的连接器官；我们的阑尾是从食草动物进化到现代人类的过程中遗留下来的；有些争论认为胆囊可能也是一个类似的进化遗迹。我们似乎不太确定胆囊的作用是什么，可就像阑尾一样，如果它出了问题，可能会产生严重后果甚至危及生命。由此可见，进化过程留下了一些难以解释且毫无意义的器官和行为。
保罗·克利普（Paul Klipp）来自芝加哥，目前居住在波兰的克拉科夫，是看板软件工具Kanbanery的创始人。在参加了看板教练专家大师班后，他在2013年3月6日的博客中对进化遗迹这个概念进行了解释。
克利普将以一头长颈鹿为例来帮助读者理解进化遗迹。这头长颈鹿叫弗雷德。
像所有哺乳动物一样，弗雷德的喉部由大脑控制，它是进化的产物。弗雷德的喉部和头都在颈部靠上的位置，喉部距离他的大脑只有十几厘米。我们假设弗雷德现在开始变得不耐烦，怒吼着让人赶紧讲重点。首先，他的大脑会做出反应，紧接着将怒吼的冲动传递到他的喉部。你以为这一传递只是个“短途旅行”吗？实际上并不是。愚蠢的进化导致从他颈部顶端的一处到靠近颈部顶端另一处的“最佳”神经通路，居然是在主动脉周围绕一圈。
那么，是什么决定了这一切呢？
是进化。至少从长颈鹿的角度来看，这比做条鱼要好得多，但是从鱼到长颈鹿的进化过程中存在一些约束。上述的神经传导路线在鱼类身上是说得通的，从鱼的大脑到鳃之间，如果走直线会穿过心脏，所以其神经在心脏后面交叉，这非常合理。问题在于，进化是从现有的过程和系统开始，逐步地进行改变。重新建立神经路径则并非一种渐进式变革，而是一个演进式变革。
如果是真正的进化过程在发挥作用，那些一开始不成熟的解决方案将会随着时间的推移而逐渐演进。就像长颈鹿一样，你不会故意设计一种神经，让它沿着长颈鹿的脖子下来再绕回去，这既不符合逻辑，效率也不高，但却很稳健。在进化生物学中，“适者生存”的概念说明每一种进化结果都是适合其环境的。对企业来说也是同样的道理，需要其发展出能契合目的的业务服务。契合目的意味着具备生存和持续发展的能力。对环境中的压力做出反应，并持续进化以适应不断变化的环境，这样的能力就是纳西姆·尼古拉斯·塔勒布所说的反脆弱性。看板方法作为一种将业务与进化基因联系起来的手段，提供了一种反脆弱性的方法。
如果你走进一家公司，发现一切都过于整洁，所有流程都是高效的、精益的，没有任何看似无用、无价值或可能已被新技术所淘汰的工作产物或活动，那么你看到的便是一个设计好的环境。流程顾问已介入，设计了新流程，并可能通过职权施压促成其落地启用，随后离开。这种设计出来的解决方案是脆弱的，使用它们的企业可能也是脆弱的。为什么呢？
当通过职权压力消除阻力时，员工很可能会屈从，但他们的行为实际上是一种消极抵抗。当管理者的注意力转向其他事务时，他们又会悄悄恢复到以前的模式。大家没有以主体身份参与这些变化，也没有将其内化。变革举措并没有真正成为“我们在这里的做事方式”，既没有获得个人认可，也没能成为团队的一部分。
演进式变革是稳健的，而精心设计并严格控制的变革是脆弱的。 看板方法的基本信念是，在现代企业中构建具有演进式变革手段和机制的体系，以拥有能够应对不断变化的环境和期望的进化基因，实现进化并让组织持续契合目的，从而为组织提供生存和发展所需的适应性和稳健性。看板方法帮助组织适应变化，保持能契合目的的状态，以便在不断变化的环境中生存下去。
回到杜米特留的故事，回顾一下，他并没有要求产品经理改变工作方式：他们将继续进行业务评审，并根据自己对业务价值的估算、IT工程师对成本的估算来计算ROI。他们也将继续使用电子表格的列排序功能，按ROI从高到低的顺序对变更需求进行排序。他们已经接受了使用平均成本的方案，这实际上意味着所有变更需求都是按其业务价值排序的。与此同时，他们接受了延迟承诺，也不反对从耗时耗力的月度计划会议改为每周的填充会议。
然而，一旦我们开始使用看板方法，他们的优先级工作立即变成了一个进化遗迹。为什么呢？在填充会议上，他们可能会被要求“选择在接下来的25天内你最期望被交付的一个需求”。这不是要选择最高ROI的需求，而是根据紧急性或及时性做选择。被选中的需求很可能是一个被认为很重要但ROI并非最高的项目。例如，“在雇员记录系统中支持波多黎各的地址格式”，就不是一个ROI特别高的需求。我们甚至都不知道该如何计算这样一个需求的“业务价值”，并为其赋予一个现金价值，即便我们能够想出一些方法来确定一个数字，它也不太可能产生最高的ROI。然而，该需求会被选中。为什么？因为波多黎各的办事处计划在下个月底开业，我们需要记录新雇员的详细信息。
看板填充与需求的紧急性和及时性有关，而不是与ROI有关。产品经理可能有一个满是数据的电子表格，并已按照ROI计算结果进行排序。但到了紧要关头，即在通过电话召开的填充会议上做出决策时，他们会发现，自己在25天或更短时间内最希望交付的项目，很可能不是电子表格第二行的那个，且情况总是如此，首选项目往往来自列表靠后位置的某个需求。
产品经理之前确定优先级的方法已被潜移默化地取代了。现在他们根据项目的延迟成本来从可选需求池中优选。举例来说，波多黎各项目的延迟成本就是因无法让员工入职而导致办事处推迟开业的成本。延迟成本不同于ROI。虽然延迟成本和ROI这两种方法现在都可使用，但从需求优选的角度来说，前者已取代后者。计算ROI的做法仍然存在，但它已经成为一个进化遗迹。
这种在引入新做法来替代旧做法的同时，保留（部分）原有做法的方法，是演进式变革的标准手段。实际上，ROI和延迟成本是用于确定优先级的两个“物种”，或者更精确地说，用于给工作排序的两个“物种”。现行方法和新出现的方法之间会进行竞争，就像两个生物物种间互相竞争，以成为最适应环境的那个。
在工作中使用演进式变革方法是为了减少阻力。我们不要求个人或团体放弃他们原有的特定做法，比如基于ROI确定优先级，因为“我们认为他们不会同意这样做”。相反，我们会让旧做法继续存在，同时在环境中引入期望替代它的新做法。如果新的做法，比如通过了解延迟成本，基于紧迫性和及时性对需求进行排序和选择，并取得了成功，那么我们预计基于ROI排序的旧做法将会逐渐消失。然而，在具有保守和厌恶风险文化的顽固环境中，对于一个存在紧密联结和高度凝聚的社会团体，或者在一个做法与个人身份、自尊、自我或社会群体地位特别紧密相关的情况下，旧做法往往会被保留下来。尽管旧法实际已经被摒弃，不再发挥作用，即使在上面花费时间是一种浪费，它也仍然存在。这就是一个进化遗迹，即一个由演进式变革留下的、难以解释的东西。
对于那些从未被视为足够重要或足够紧急的事项，即那些在填充会议中从来没有被选择的事项，会如何处理呢？在推出变革举措几个月后，杜米特留意识到需要一个新策略：任何超过6个月的事项都可以从待办列表中清除，标记为“放弃”并进行关闭。现在，有了一个明确的作废机制。如果一个需求在提出后的6个月内都没有被选中开发，就可以推断它根本不重要。这种规则基于一个假设，即每个工作需求都有一个“母亲”，即发起该需求的人。如果“母亲”真的关心自己的“孩子”且事项确实重要，那么它将会被重新提交。
在上一章中提到了一项有关经营性支出与资本性支出的管理规则：花费时间超过15天的需求必须转为重大项目组合中的项目，并作为资本性支出进行会计核算。可如果我们不做估算，怎么知道某项需求是否“太大”呢？
这个问题的解决方案是，接受实际会存在一些这样的项目成为“漏网之鱼”的事实。我们称之为“信用卡安全”解决方案。信用卡公司并不会试图完全阻止信用卡欺诈交易，因为这样做会让信用卡的使用变得困难，可能导致很多人回归使用现金或寻找其他支付方式。所以信用卡公司在其业务模型中建立了欺诈的容忍度，并通过向商户收取信用卡付款保证金来覆盖这一成本。当任何人使用信用卡付款时，通常有3%～4.5%的付款金额会支付给信用卡公司，而不是都给了商家，这其中的一部分资金就会用于购买防范欺诈交易的保险。信用卡公司认为，与其完全消除可能性，不如接受一些坏事发生的风险，否则反而会显著削减他们的业务。
历史数据告诉我们，所谓“太大”的需求只占需求总数的不到2%。因此，保留估算工作以消除这2%的风险是不划算的，毕竟我们在估算上花费了30%～40%的工作产能。如果会计治理规则是保留估算的唯一理由，那么这将是笔非常糟糕的交易，谁愿意花40美元来防范2美元的潜在损失呢？因此，我们决定让这些“太大”的需求进入系统，之后再进行处理。
开发人员被告知要保持警惕，如果他们开始处理的新需求看起来非常庞大，以至于他们估计需要超过15天的工作时间，就应该告知当地经理。如果确认该需求确实过大，那么它将被重新转到重大项目组合中。这样做所承担的风险和成本，不到可用产能的0.5%。这是一个很好的权衡策略，通过取消估算，团队冒着浪费低于1%产能的风险，收回了超过30%的工作产能。这项新策略授权开发人员来管理风险，并在必要时发出提醒。
上述内容是看板方法中的一个常见主题。明确的策略、透明性和可视化三者的结合，使各个团队成员能够自主做出决策并自行风险管理。当高层理解了过程管理是由各项策略构成的，他们就会开始信任这个管理系统。这些策略的设计意图，是管理风险并交付用户所期望的价值。策略明确，工作透明可跟踪，所有团队成员就会理解并知道如何使用这些策略。
前两项变革在6个月内得到了有效落实。在此期间也进行了一些微调。就像前面提到的，先是增加了待办列表的作废策略；其次，与产品经理的每周会议也取消了。整个流程运行得非常顺畅，于是杜米特留对Product Studio工具做了修改，使其在输入缓冲区有空闲槽位时，能自动发送邮件通知他。然后他再通过电子邮件通知产品经理，由他们决定下一个需求选项。在出现空闲槽位两小时之内，待办列表中的某个需求便会被选中并补充到看板系统中。
杜米特留开始寻找进一步的改进机会。他研究了团队测试人员生产效率的历史数据，并与XIT部门中同样来自TCS在海得拉巴当地的其他团队进行比较，结果他认为测试人员负载较轻，有很多闲置产能。由此推断，开发人员是一个重要的瓶颈。他决定前往印度对团队进行实地考察。杜米特留在那边的办公室进行了为期两周的观察。回国后，他指示TCS调整人员配置，将测试团队从3人减少到2人，并增加1名开发人员（见图3-6）。该调整让生产效率得到了近乎线性的提升：那一季度完成的需求从45个增加到56个，并且都成功部署到了生产环境中。他对测试中存在闲置产能的评估是准确的，2名测试人员足以处理来自4名开发人员的工作量。
2005年6月，在微软的财年结束之际，总经理戴尔·克里斯蒂安及其领导团队注意到了XIT维护工程团队生产效率的显著提升和持续的交付。最终，杜米特留及其采用的技术获得了高层的认可与信任。杜米特留打电话向我告知了此事。
“大卫，我是杜米特留。克里斯蒂安对我们正在做的事情非常满意。他看到了成效。他们在制定年度预算，告诉我可以增加2名新员工。所以，我正准备给TCS发电子邮件，要求他们增加2名开发人员。”
“如果是我的话，我不会这么做。”
“不会吗？”
“我认为存在一个风险，即2名测试人员可能无法处理来自6名开发人员的工作量。基于对你的数据的有限了解，我认为再增加2名开发人员将会让测试成为一个瓶颈，你可能无法获得期望的收益。我感觉，你应该给开发和测试各增加1人，也就是变成5名开发人员、3名测试人员。我认为这样效果会更好。”
我运用自己对瓶颈与TOC制约法的了解给出了这个建议。
于是，杜米特留在2005年7月又增加了1名开发人员和1名测试人员。到了2006年冬天，效果十分显著，如图3-6和3-7所示。
图3-6 XIT维护工程团队的变更需求交付速率与每个需求的成本对比图
图3-7 XIT维护工程团队的每个变更需求从承诺到部署的平均前置时间
增加的产能足够使交付速度超过需求提出的速度。结果如何呢？2005年11月22日，整个待办列表的需求全部处理完结。这时，团队将平均前置时间缩短至14天，其中开发、测试时间为11天。在25天的承诺时间内准时交付率高达98%。 需求交付量增加了3倍多，前置时间至少缩短了90%，承诺的可靠性也大幅提升。 在此期间，并未对软件开发或测试过程进行任何更改。在海得拉巴工作的成员也感受不到有什么重大变化。团队没有改变PSP/TSP方法，完全满足公司治理、流程和供应商合约等各方面要求。2005年下半年，团队荣获微软卓越工程奖。杜米特留也因此获得了奖励，开始承担更多的职责，XIT维护工程团队的日常管理移交给了印度的当地经理，后来这名经理也得到了进一步的晋升。
能够取得这些改进成就，在一定程度上归功于杜米特留的非凡个性和管理能力，但看板方法的基本要素才是其中的关键促成因素，包括绘制工作流、分析工作流、设定WIP限制、实施拉取系统等。如果没有流程范式和限制WIP的看板方法，不可能取得如此大的效能提升。看板方法降低了政治风险和变革阻力，让渐进式变革成为可能。
到了2005年秋季，我开始通过自己的博客发布这些成果，并在巴塞罗那的TOC制约法会议上介绍了这一案例，2006年冬季又在芝加哥的精益产品开发会议上做了报告。那一年，其他人也开始采纳这个案例所用到的理念并进行复制。尤其值得注意的是，任职于汽车零部件制造商罗伯特·博世公司（Robert Bosch）位于印第安纳州南本德工厂的埃里克·兰德斯（Eric Landes），在一个负责维护内部应用程序的团队中复制了我们的方法，也取得了类似的结果。当时，我们所说的“软件工程虚拟看板系统”正在获得更广泛的应用和认知度。我在第4章中也会提到这一系统，直到2007年，它才成为如今大家所认知的完整看板方法。不过，在罗伯特·博世公司的结果已经验证了这种方法是可复制的，并不是必须要有像杜米特留这种前奥运会运动员、训练有素的保镖一样的领导，才能使其发挥作用。它需要的，是像“小蓝书”封面上的漫画人物一样，愿意说“让我们来解决这个问题吧”并采取行动的人。
XIT维护工程团队的故事展示了如何在使用跨境资源和外包供应商的分布式的IT服务团队中，实施有WIP限制的拉取系统。那时的拉取系统是通过软件跟踪工具来实现的，暂时还没有可视化看板，且本书之后描述的许多看板方法的更复杂功能也尚未出现。即便如此，也没有管理者能忽视实现类似结果的可能性。采用“从现有做法开始”的演进式变革方法来更换为看板系统，显然是值得公开报道以供其他人复制的良方，而且这也是我俩都想再次尝试的事情！
· 通过数据库中的策略和所谓的触发器来实施WIP限制。这被称为虚拟看板系统的原因是没有使用实际的看板信号卡（看板卡片），也没有可视化看板。
· 策略影响效能。一些由高层制定的政策必须被视为约束条件，无法轻易被改变。
· 防止浪费产能，除了停止估算，还可以通过分隔工作时间隔离估算的干扰；使用专业估算师隔离估算的干扰；结合前两个方案，让团队成员轮流担任估算师。其他方案的弊端是：它们虽然提高了可预测性，但无法帮助团队恢复被浪费的产能。
· 输入缓冲区的大小应为两次填充会议之间的时间段内的最大预期交付量。目标是确保工作流中的第一个环节永远不会缺少新任务，员工不会空闲下来。
· 每个活动的处理周期可能不同且存在波动，因此在两个活动之间设置缓冲可能有助于平滑流程。
· WIP限制为5个通常是一个比较好的起点。在此基础上，可以观察其使用情况并进行上下调整。
· 放弃传统的计划，改为延迟承诺和有交付预期的SLA。传统的计划通常鼓励早早给出承诺，从而导致后面又要重新规划和安排工作，常常引起客户的不满。
· 一旦为服务交付工作流设计了拟议的看板系统，重要的是要预测变革时谁可能会提出反对意见。
· 与各个利益相关者单独会面，解释变更举措。在举行团体启动会议之前，先取得个人对变革的认同和承诺。
· 直接改变现有做法会引起部分人的抵抗和防御，更可行的做法是引入新方法，让现有做法与新方法并行，并让这二者互相“竞争”。更适合的方法将生存下来并得以发展，而另一种可能会衰落并消亡。
· 对已提交的需求在待办列表中的停留时间设置限制，有助于防止待办列表增长得过于庞大且难以管理。这种时间停留限制被称为作废机制。
· 接受一些坏事发生的风险，快速检测到它们并将其影响降至最低，这比事先投入大量精力预防问题发生更为可取。风险规避可能比风险响应的成本更高且浪费资源。该理念在看板方法中被称为“信用卡欺诈”解决方案。
· 在向服务交付工作流和看板系统中增加人员或自动化设备时，重要的是要考虑资源投放的位置，避免意外地造成瓶颈，进而限制改进，反而降低资源增加所应产生的价值。