摘要: 前年，Wikispeed团队掀起了一场业界风暴。它们把敏捷实践应用到了最传统的行业：汽车制造业。它们在3个月的时间里就研发了一款绿色汽车，而这原本需要经历10-25年的产品生命周期。 而且，得益于独立组件的测 ...
| 流程债与技术债相比是有区别的 它们最核心的区别在于，流程债是业务流程中过多的复杂度，而技术债是代码中过多的复杂度。它取决于讨论问题时以哪种层次的抽象去映射实际的问题域。假设你能以较少的复杂度做到完全相同的事情，你正在慢慢感受着流程债的影响。它正在勒紧你脖子上的绳索。假设你曾经尝试脚本化一个已有的流程，不料却从公司内不同的派系中发现拜占庭式的、多余的和前后矛盾的需求，你会发现它不是完全相同的。代码都没出现，怎么会是技术债呢？ 在工作流程中，这两种债有着截然不同的逻辑矛盾。 技术债，包括变量和成员函数的作用域不佳、关注点分离得不够清晰、意想不到的负面影响。 流程债，就意味着不清晰的目标、状态和组织职能，混乱的企业特性，由于部门间缺乏交流沟通而带来的一些意料之外的负面影响。 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的刻意地发现）。这种互动需要充分地重视。当你想要实行同事们的提议时，需要把它充分融入到同事们正在做的事情里。 如果设计一个新的特性或是软件架构，也可以使用“不错，然后”，它也可以带来同样的生产力。起初最理想的结构还只是未知数，因为这依赖于要解决的问题。团队就这些问题展开讨论。首先，他们发散性地思考软件最终可能会做成什么样。这就会是一系列“不错，然后”的提议。最终，它们都会体现在解决方案中。最好的解决方案就浮出水面了。有些想法之间可能会有矛盾之处，但是每个参与者仍要始终坚持一种“不错，然后”的态度。 流程……阻碍了发展。流程经常强调“不行”或“还行，但是”，这扼杀了解决问题的创造性。当某些流程必不可少时，它们就会阻碍解决问题的创造性，延缓你整个企业的发展。 @theagilebastard：“人和交互优于流程和工具” 1985年Nelson Mandela在狱中说。#哲理 #敏捷 #看板法 好消息 通过减少流程债，你可以： 加快你交付产品的能力 减少出错次数 使公司充满活力，具有高昂的斗志 理想情况下，你的研发和生产流程可以像软件一样融入到公司里，比如，灵活编写自动化构建脚本，让它能够根据客户独特的需求组合你的产品。你们可以用持续集成中运行验收和单元测试套件去驱动发布的流程，然后由甲方签收。你们甚至还可以直接发布，当然，这取决于你们做的是什么类型的软件（比如网页软件）。某些团队，比如工艺品批发商Etsy.com每天会发布30到50次。 最好的流程是没有流程，只是一段写得很好的脚本。它找出问题的本质。它所提供的解决方案就是按一下按钮。它解放了人们解决问题的创造力。团队成员能以最好的状态完成工作，不需要被迫重复那些相同的单调的乏味的任务。 尽管人们（尤其是那些刚接触敏捷的新人）关注敏捷流程，但却容易忽略为什么会有敏捷流程。敏捷已经特意地简化了流程。一旦你步入职业生涯，就可以专注于个体和交互。因为你用敏捷减少了无谓的流程，那些了不起的人推动了敏捷的效率。这可以向Wikispeed团队咨询。 如果你想减少企业中的流程债，就可以去克服流程债下载一本免费的工作手册。 |
