前年，Wikispeed团队掀起了一场业界风暴。它们把敏捷实践应用到了最传统的行业：汽车制造业。它们在3个月的时间里就研发了一款绿色汽车，而这原本需要经历10-25年的产品生命周期。

而且，得益于独立组件的测试驱动开发，这款新车的设计具有很高的质量标准。这款车还遵循了非常高的安全标准。他们只用了3天的时间就研制出了一个漂亮的车体。这款车采用了业内能够达到五星安全等级的最轻的底盘。他们在迭代中快速应对变化。这些全都不是什么问题，因为他们在设计中非常注重模块化。他们可以把它由一辆敞蓬车改装成敞蓬的小型卡车，而这只需要改装一下底盘。

团队创始人Joe Justice说，下面几点是他们最重要的成功因素。WikiSpeed团队：

1、使用了很少的材料

2、积极把变更成本降到了最低

3、在士气高昂的分布式团队上的协同工作

4、用结对的方式去削减培训和写文档的时间

5、可视化了工作流程，发现不需浪费时间就可以创造性地解决问题

虽然Wikispeed最初的成功对敏捷社区来说还不算什么太大的新闻，但它却对敏捷有着重大的意义。特别要提的是，它把敏捷应用在了软件开发之外的领域中，证明了那些产品管理模式是多么缺乏效率。它揭露出令人难以想象的低效。

Wikispeed把产品生命周期从10年降到了3个月，他们的团队效率比汽车制造业的产品研发团队快了40倍。虽然产品相同，但为了节省开支他们只使用了常用的工具和高中生。这些高中生并不是专业的汽车设计人员，但他们是乐于奉献、充满幻想的业余爱好者。

他们的成绩表明流程和敏捷文化的重要性。特别要提出的是，他们为了创造性地解决问题而持续不断地消除任何障碍。他们的成绩表明流程债对汽车制造业（乃至许多其他行业）的影响。

对于产品研发人员来说，流程虽然有用但也是无可避免的灾难

比方说你要解决一个特定的问题。你并不在乎是否已经交付了如下的这些解决方案：

1、软件

2、遵循的流程

3、具备某些功能的实物产品

你知道自己头痛（偏头痛）。你只想治好它，并不太关心治疗方式。

你要的是一个解决方案。像Ted Levitt讽刺的那样，“人们只想要个4分之一英寸的洞，而不想买台4分之一英寸的打孔机”。他们只想要一个特定规格的洞。以此类推，从本质上说流程就是企业家为了交付解决方案而创建的“业务系统”。

产品研发本身就是一个流程。通常它由团队来执行。产品研发最终可能产出流程、软件或满足特定需要的实物产品。如果一切顺利，这个产品的研发流程就为该企业家和其他将来的企业家赢得了经济效益。

简单来说，对于许多产品研发人员来讲流程是无可避免的灾难。流程是为了满足需要的交付机制。它组织我们的工作。经过一段时间以后，一个好的流程不仅能够创造价值，而且它本身也是盈利性公司的财富。这些公司产生利润并持续增值。所有人都希望产品开发流程能保持轻量级。我们希望流程是易于管理的，尤其是我们自己的公司。如果我们在这个流程下工作，就希望流程更贴近于实际的工作。Wikispeed证明了轻量级流程可以大幅提升生产力。

流程债

如前文所述，Wikispeed团队积极地试图消除流程债，因为他们要把变更成本降到最低。流程债是已有流程中慢慢形成的捷径、变通方法和死锁。经过一段时间以后，所有这些东西都会纠缠在一起。它就像盘意大利面，你拉出一根，就会有半盘也跟着动。流程债相当于商业层面的技术债。它是无用的复杂度。最重要的是，流程债破坏了有效的沟通。人们躲在流程、“最佳实践”和“首选供应商”的身后，而不去讨论和解决问题。使流程制度化是“行不通”的。它使团队成员觉得被疏远了，权利被剥夺了。

如果你们已经积累了数年古怪的变通方法，从没有真正地考虑过做事的工作效率，那么现在就要付出时间的“代价”，因为你们过去走了捷径。这种捷径就是一种时间上的转换。问题应该在早期解决。应该通过彻底“根治”杜绝此类问题的再次出现。反之，它就会在将来一次又一次地出现，你们必须要不断地花时间去弥补。更糟糕地是，它还可能会影响到其他相关的部门。这反过来又会进一步引发更多的问题。最终，这会影响到客户，无论他们知不知道。

在这种情况下，这种债务是用时间来计算的，特别是员工的时间。一个捷径最终导致重大返工。这通常被认为是标准的“技术债”，这已经得到了充分地证实。技术债本身是大规模“时间转移”商业问题的一个子集。它使你丧失主导权。

如果你把技术捷径带到产品中，就会使运维工程师执行浪费时间的变通方法。为了处理那些额外的复杂度，他们还需要一些额外的培训和文档。如果开发团队欠下技术债，就会随后影响到整个公司。于是它将不再只是技术债，而成为更加普遍性的问题。

就像Steve McConnell所指出的，技术债的影响要看具体的环境。从这层意义上来说，流程债很像金融债。有时，贷款还是有很多好处的。负债能帮你达成战略目标。例如，你按揭购房，再把房子租出去，然后用租金还清利息和按揭。在这个例子里，贷款帮你创造了财富，否则你没有其他的办法。与此相反，某种类型的负债会快速瓦解财富。虽然你可以选择办理一张新的信用卡，用它来做15个月零利率的余额转账，但这可不是一个什么好主意。

许多开发人员都清楚，流程通常都可以被自动化。像流程一样，软件也可以被用来作为交付机制。脚本可以有效地替代一项服务和自动化一项服务。假设需要很多人月的工作量才能投产，你能做到哪种程度的“敏捷”呢？在最近人气很旺的DevOps活动中（特别是在那些要求持续交付的敏捷实践中）就采用了这样的假设。

如果你可以用脚本实现发布流程，你的敏捷完全就是另外一个层次的概念了。虽然持续交付看起来是关于代码的，但它实际上却是关于拥有非常简单的、合理的和自动化的流程的。它还把产品开发团队解放出来去讨论更多紧急的问题。

作为一名客户，过多的流程债阻止你得到那些想要非常快速得到的东西。于是，偏头痛又发作了怎么办？

流程债与技术债相比是有区别的

它们最核心的区别在于，流程债是业务流程中过多的复杂度，而技术债是代码中过多的复杂度。它取决于讨论问题时以哪种层次的抽象去映射实际的问题域。假设你能以较少的复杂度做到完全相同的事情，你正在慢慢感受着流程债的影响。它正在勒紧你脖子上的绳索。假设你曾经尝试脚本化一个已有的流程，不料却从公司内不同的派系中发现拜占庭式的、多余的和前后矛盾的需求，你会发现它不是完全相同的。代码都没出现，怎么会是技术债呢？

在工作流程中，这两种债有着截然不同的逻辑矛盾。

技术债，包括变量和成员函数的作用域不佳、关注点分离得不够清晰、意想不到的负面影响。

流程债，就意味着不清晰的目标、状态和组织职能，混乱的企业特性，由于部门间缺乏交流沟通而带来的一些意料之外的负面影响。

Melvin Conway在1968年提出：“一个设计机构……不自觉地设计出反映自身组织结构的产品。”按照Conway定律，复杂度会以涓滴效应深入到代码之中；而且，它是破坏人们之间的沟通和缺乏信任的根本原因。流程债导致技术债。

大多数公司能够容忍某种流程债。企业可能基于战略意图会接受某些流程债，就像之前讲的那个按揭购房的例子。然而，大多数流程债并不是战略性管理级的，只是因为公司并没有把它当成是个问题。举个例子，即使在你的软件里没有欠下技术债，但是如果你的发布流程还没有完全脚本化，那么你也欠下了流程债。

如何处理流程债

大多数建议都属于那种“我知道了，以后再处理吧”的情况。我们应该立刻处理它，尤其是那些会降低效率的问题。这么做能让你更加快速地前进。你们会提高客户的满意度，特别是当他们不满意你们的弹性或速度不够快的时候。

反复澄清战略，直至人人皆知

Fortune Magazine指出，超过70%的公司无法成功执行战略。在《聚焦战略的组织》中，Kaplan和Norton发现大多数公司在每个月要花大约一个小时的时间来讨论战略，而他们大多数的时间都花在了无用功上。当公司讨论战略的时候，只会由很少的资深决策者秘密地开展。这种方式不利于战略的实施。它必定无法得到一线员工的认同，事实上他们需要改变这种工作方式。

相比之下，在《像CEO一样激励》中，Suzanne Bates指出CEO的任务就是要不断地宣传战略，努力地把它融入到每天的工作中。理想情况下，战略应该简洁明快、朗朗上口。战略是由大家共同探索出来的，这包括公司中的每一个人。它找出所要完成的最重要的一件事。理想情况下，CEO要帮助员工在每天的日常工作中运用战略。当你知道战略是什么的时候，实现就没那么难了。因此，如果你想让大家根据战略采取行动，就必须让战略浅显易懂。

我在负责本地非盈利性俱乐部的时候，已经认识到了这项任务的复杂性。我通过和每个人单独谈话，帮助集团确定了最重要的组织目标。一旦这些都明确下来之后，我的主要目标就变成了以新颖的、适当的方式去交流优先级，以便志愿者们能够感受到自己的贡献是有价值的。与盈利性环境不同的是，我不需要向那些为我提供帮助的志愿者们支付费用。他们主要是想要一种精神上的满足，他们完成了这些事，他们帮助了其他人。通过以合作的方式识别最高优先级并有计划有步骤地交流沟通，我帮助组织在一年之内把规模扩到了两倍。

混乱的战略思维导致混乱的执行。搞清楚战略的“拐点”能让它发挥更大的作用。如果你有正确的战略，就很容易取得成功。带有充分理由的理性思维能让你事半功倍。

如果你没有澄清战略，处理流程债就没什么意义。你的战略将定义哪些流程是战略性的，哪些流程是可以被淘汰的。如果你对效率没有一个清晰的认识，那么提高效率也没什么意义。换句话说，如果你行驶在错误的方向上，跑得再快也没什么作用。

使用软件自动化工作流程

你只要澄清战略，就可以简化或替换那些没用的流程，自动化那些有用的流程。对于软件公司来说，自动化的工作能产出最大的收益。

作为一名面向客户的开发人员，我曾经遇到过这样的一位客户，他让会计师每个月花一周以上的时间为投资人做报表。这位会计师要先从数据库里手工提取数据，随后修改成精确的格式。随着投资人的不断增加，他不得不提供越来越多的预定义报表。

我在参加极客之后使用脚本语言编写了几个VBA，用几个动态下拉框组织SQL查询语句，它们可以在几秒钟之内生成完全相同的报表。从投资者的角度来看，软件生成的报表也可以一样使用。它们提供了完全一样的价值。

他们让开发人员把报表制作过程降到了几秒钟，会计师再也不用花上一星期的时间了，实际上以前那种报表制作过程是繁重的手工劳动，很容易出错。这样就把时间从最少1星期降到了最多5秒钟：一次12,096,000%的生产力提升。而且，如果最终客户和他的投资人认可报表的逻辑（比如不存在逻辑上的错误），那么这个过程就是有效无误的。这还可以把会计师解放出来做其它的事情，去处理那些更需要思考、讨论和分析的问题。这使他们非常地激动。

消除依赖

在一个流程里，当一个特定的资源被多人使用时我们往往会引入依赖。资源的竞争成了瓶颈。这就大大减缓了整体的进度。

多线程软件开发是一种很好的类比。就像两个线程间的冲突一样，当它们访问同一个资源时，你用互斥锁确保线程不会覆盖数据。在某些特定环境下，这种做法可能会产生死锁。死锁使这些代码永远挂在那里，消除这种死锁通常能让代码即时执行。

假设你正在开发一个多线程应用程序，开发新特性时遇到了性能问题。你可以轻而易举地找出原因。实际上，这种情况通常意味着你该查查哪个线程被锁住了，你要防止应用的其他部分等待一个漫长的执行过程。如果线程锁住了，通常你要把消息发送给线程反馈队列，等着这个线程被释放。

《产品开发流程》的作者Don Reinersten认为半成品和未发布的特性会严重影响大多数软件开发的积极性。 “可以凭借工作量观测产品开发清单：增加的周期时间、延迟的反馈、不断调整的优先级和状态报告。”如果列表中堆积了一堆未完成的特性显然是一种极度的浪费，罪魁祸首往往都是项目死锁。项目之中的依赖慢慢地搞砸了一切。

在软件组织中，消除依赖是提升交付速度的最快方法。理想情况下这意味着项目会变得更小了。你可以专注于以产品和客户优先。

这容易提升客户满意度。从根本上来看，特性可以被更加快速地发布。它们不必浪费时间去排队。

通过移除不需要的细节来减少变数

如果你已经欠下了流程债，如果你在每天的工作中减少“符号”、变量或数据点，那么你会极大地提高生产率。这能增加沟通中的信噪比，让你能够更加地专注于感兴趣的问题，而不必时常去处理那些“错综复杂的遗留问题”。

在九十年代末，流行记录每个单独的文件版本的源代码版本控制资源库。但是今天，大多数源代码控制系统会把系统作为一个整体去跟踪它的版本。对于一个拥有许多文件和可移植组件的大型系统，你只需要管理系统大的版本号，这就显著降低了大多数流程的复杂度。这让你能更容易地讨论那些具体的问题。你只需要写少量的文档。一旦你的版本控制合理化了，测试、发布和运维就会得到简化。

当然，使用这个具体方法会遇到很多困难，比如数据库包的版本控制或者不同组件之间不一致的发布计划。在这种复杂的局面下，你要减少所有的“阻力”，避免它们引发过于复杂的流程。

尽可能地消除默认情况下的承诺

缺乏信任会导致许多问题，比较常见的是会让管理者引入一些在早期强加承诺的方法，这会破坏价值。许多工具（比如微软的Project）试图以大量依赖和截止日期去创建详细的日程表。虽然这种粒度的出发点是增加计划的可信度，但对中间的截止日期做出不必要的承诺往往使你忽略了本质上更加重要的优先级。充其量，你只能花费巨大的整体代价做做局部优化。保证一个项目按时交付，就得把其他项目往后排。这反而降低了详细计划的可信度，然后就意味着更多的详细计划。

在微软的Project中，“结束后开始”（FTS）任务依赖隐藏着许多瀑布模型中的流程债。它也是微软Project里默认的任务依赖。使用FTS的时候，你必须在特定的时间内完成特定的任务，所以你要指定所有的依赖任务必须要尽早地开始，以保证其他任务有充足的时间可以按时完成。

虽然这听起来像是个很有水平的好主意（比如时刻记得“以终为始”），但它在任务的层面增加了很多不必要的硬性要求。你用FTS承诺了确定的期限，你就要在截止日期之前完成这些工作。如果有很多任务，就很难识别出最重要的任务或特性。承诺日期掩盖了优先级。经过一段时间之后，你们忘记了优先级。每个人只记得承诺的日期。

在软件专业人才之中，已经展开了一场#不估算的运动。它反对任何工作量估算。”#不估算”的支持者们声称，强迫开发人员估算会导致企业陷入这种FTS的思维方式。它最终会妨碍开发人员的工作，因为这种预期经常带来不必要的压力。过度的压力不利于创造性的解决问题。它最终会让企业和开发人员之间产生一些不必要的矛盾。

不必要的承诺不仅影响开发，对流程也具有深远的影响。由Hope和Fraser合著的《超越预算》极力反对传统的预算流程。虽然预算是上世纪50年代大型汽车公司履行财政纪律的有效方法，但同时预算也造成了大量的浪费。人们花数月的时间去辩论未来可能看上去会如何发展，他们需要什么财政资源，但他们实际上根本就看不清未来。反之，他们可能非常清楚现在的工作重点。

与此相反，还有类似于作业成本核算（ABC）的方法。ABC定期（理想情况下是每天）从本质上计算每项作业、每个客户和每个产品的损益。这让每个人都有了可以做出良好财务决策的工具，因为他们可以迅速得到与决策相关的财务影响。信息没有藏在门后，而是已知的。这涉及每个人的利益，包括每一个一线员工。即时反馈影响员工的决策，他们的决策又影响公司的赢利能力：这就形成了良性循环。

使问题解决者专心地倾听

很多时候，为了在极为繁杂的流程里“控制”复杂度而人为地设立了壁垒和边界。很遗憾的是，这通常意味着那些最重要的信息永远不会被真正地传递。没有人行动，因为大家不了解全局。你要给他们发言权，让他们谈谈最严重的挫败。通常底层员工很清楚公司出现了什么问题，但公司恰恰忽略了他们的意见。他们只会在小范围内讲这些事情。因为他们害怕一些负面的后果。他们可不愿意成为那种大煞风景的人。

如果你觉得很难提供一个公开场所，可以试试创造一个只有几位同事的场合。虽然这看起来可能有些怪，但这实际上是一套精练的即兴演讲技能。由于开始之前没人知道具体话题，所以每个即兴演讲者必须与台上的每个人做深入地沟通。

因此，他们为每个提议寻找最理想的回应，发现其中的矛盾。这件事自然而然地开展，然后推向高潮。通常（但不一定），当场就能完成提议的论证。系统化的创新来自于认真的倾听。

这是一个协作创新流程的理想示例。在Tom Salinsky的《即兴演讲手册》中阐述了即兴演讲的原则，即以“不错，然后”推动团队的创新流程。当开发一个课题时，两位即兴演讲者同时登台。他们只需要带着自己的想象力。一旦其中一个开始演讲，另一个要对首个“提议”做出直接地反馈。这台短剧的目的是把这份提议变成“现实”。事实上，听众必须从内心深处认可提议的“创造力”。每个演讲者并不清楚对方会有什么提议。这种不可预测性正是现场的魔力。每位演讲者都要认真倾听其他人在台上的演讲，只有这样才能正常运行下去。这需要高度的紧张和信任。

在开始对话的时候，即兴演讲者要永远认可上一个人讲过的观点。如果说“不行”或“还行，但是”就会扼杀创新的动力。这会使他人的动力骤减。与之相反，“不错，然后”能推进协作。如果这个环境要求每个人都在其他人的基础上去想其他的创意，那么就会迸发出很多好的想法。

在即兴演讲中，要格外关注互动本身的质量。一步一步向前推进，你们要用“不错，然后”推进团队的想法。你正在快速向前推进。随着这种互动发现你们正在做什么（想想Dan North的刻意地发现）。这种互动需要充分地重视。当你想要实行同事们的提议时，需要把它充分融入到同事们正在做的事情里。

如果设计一个新的特性或是软件架构，也可以使用“不错，然后”，它也可以带来同样的生产力。起初最理想的结构还只是未知数，因为这依赖于要解决的问题。团队就这些问题展开讨论。首先，他们发散性地思考软件最终可能会做成什么样。这就会是一系列“不错，然后”的提议。最终，它们都会体现在解决方案中。最好的解决方案就浮出水面了。有些想法之间可能会有矛盾之处，但是每个参与者仍要始终坚持一种“不错，然后”的态度。

流程……阻碍了发展。流程经常强调“不行”或“还行，但是”，这扼杀了解决问题的创造性。当某些流程必不可少时，它们就会阻碍解决问题的创造性，延缓你整个企业的发展。

通过减少流程债，你可以：

1.加快你交付产品的能力

2.减少出错次数

3.使公司充满活力，具有高昂的斗志

理想情况下，你的研发和生产流程可以像软件一样融入到公司里，比如，灵活编写自动化构建脚本，让它能够根据客户独特的需求组合你的产品。你们可以用持续集成中运行验收和单元测试套件去驱动发布的流程，然后由甲方签收。你们甚至还可以直接发布，当然，这取决于你们做的是什么类型的软件（比如网页软件）。某些团队，比如工艺品批发商Etsy.com每天会发布30到50次。

最好的流程是没有流程，只是一段写得很好的脚本。它找出问题的本质。它所提供的解决方案就是按一下按钮。它解放了人们解决问题的创造力。团队成员能以最好的状态完成工作，不需要被迫重复那些相同的单调的乏味的任务。

尽管人们（尤其是那些刚接触敏捷的新人）关注敏捷流程，但却容易忽略为什么会有敏捷流程。敏捷已经特意地简化了流程。一旦你步入职业生涯，就可以专注于个体和交互。因为你用敏捷减少了无谓的流程，那些了不起的人推动了敏捷的效率。这可以向Wikispeed团队咨询。

如果你想减少企业中的流程债，就可以去克服流程债下载一本免费的工作手册。