在微软的Project中，“结束后开始”（FTS）任务依赖隐藏着许多瀑布模型中的流程债。它也是微软Project里默认的任务依赖。使用FTS的时候，你必须在特定的时间内完成特定的任务，所以你要指定所有的依赖任务必须要尽早地开始，以保证其他任务有充足的时间可以按时完成。
　　虽然这听起来像是个很有水平的好主意（比如时刻记得“以终为始”），但它在任务的层面增加了很多不必要的硬性要求。你用FTS承诺了确定的期限，你要在截止日期之前完成这些工作。如果有很多任务，很难识别出重要的任务或特性。承诺日期掩盖了优先级。经过一段时间之后，你们忘记了优先级。每个人只记得承诺的日期。
　　在软件专业人才之中，已经展开了一场#不估算的运动。它反对任何工作量估算。”#不估算”的支持者们声称，强迫开发人员估算会导致企业陷入这种FTS的思维方式。它终会妨碍开发人员的工作，因为这种预期经常带来不必要的压力。过度的压力不利于创造性的解决问题。它终会让企业和开发人员之间产生一些不必要的矛盾。
　　不必要的承诺不仅影响开发，对流程也具有深远的影响。由Hope和Fraser合著的《超越预算》极力反对传统的预算流程。虽然预算是上世纪50年代大型汽车公司履行财政纪律的有效方法，但同时预算也造成了大量的浪费。人们花数月的时间去辩论未来可能看上去会如何发展，他们需要什么财政资源，但他们实际上根本看不清未来。反之，他们可能非常清楚现在的工作重点。
　　与此相反，还有类似于作业成本核算（ABC）的方法。ABC定期（理想情况下是每天）从本质上计算每项作业、每个客户和每个产品的损益。这让每个人都有了可以做出良好财务决策的工具，因为他们可以迅速得到与决策相关的财务影响。信息没有藏在门后，而是已知的。这涉及每个人的利益，包括每一个一线员工。即时反馈影响员工的决策，他们的决策又影响公司的赢利能力：这形成了良性循环。
　　使问题解决者专心地倾听
　　很多时候，为了在极为繁杂的流程里“控制”复杂度而人为地设立了壁垒和边界。很遗憾的是，这通常意味着那些重要的信息永远不会被真正地传递。没有人行动，因为大家不了解全局。你要给他们发言权，让他们谈谈严重的挫败。通常底层员工很清楚公司出现了什么问题，但公司恰恰忽略了他们的意见。他们只会在小范围内讲这些事情。因为他们害怕一些负面的后果。他们可不愿意成为那种大煞风景的人。
　　如果你觉得很难提供一个公开场所，可以试试创造一个只有几位同事的场合。虽然这看起来可能有些怪，但这实际上是一套精练的即兴演讲技能。由于开始之前没人知道具体话题，所以每个即兴演讲者必须与台上的每个人做深入地沟通。
　　因此，他们为每个提议寻找理想的回应，发现其中的矛盾。这件事自然而然地开展，然后推向高潮。通常（但不一定），当场能完成提议的论证。系统化的创新来自于认真的倾听。
　　这是一个协作创新流程的理想示例。在Tom Salinsky的《即兴演讲手册》中阐述了即兴演讲的原则，即以“不错，然后”推动团队的创新流程。当开发一个课题时，两位即兴演讲者同时登台。他们只需要带着自己的想象力。一旦其中一个开始演讲，另一个要对“提议”做出直接地反馈。这台短剧的目的是把这份提议变成“现实”。事实上，听众必须从内心深处认可提议的“创造力”。每个演讲者并不清楚对方会有什么提议。这种不可预测性正是现场的魔力。每位演讲者都要认真倾听其他人在台上的演讲，只有这样才能正常运行下去。这需要高度的紧张和信任。
　　在开始对话的时候，即兴演讲者要永远认可上一个人讲过的观点。如果说“不行”或“还行，但是”会扼杀创新的动力。这会使他人的动力骤减。与之相反，“不错，然后”能推进协作。如果这个环境要求每个人都在其他人的基础上去想其他的创意，那么会迸发出很多好的想法。
　　在即兴演讲中，要格外关注互动本身的质量。一步一步向前推进，你们要用“不错，然后”推进团队的想法。你正在快速向前推进。随着这种互动发现你们正在做什么（想想Dan North的刻意地发现）。这种互动需要充分地重视。当你想要实行同事们的提议时，需要把它充分融入到同事们正在做的事情里。
　　如果设计一个新的特性或是软件架构，也可以使用“不错，然后”，它也可以带来同样的生产力。起初理想的结构还只是未知数，因为这依赖于要解决的问题。团队这些问题展开讨论。首先，他们发散性地思考软件终可能会做成什么样。这会是一系列“不错，然后”的提议。终，它们都会体现在解决方案中。好的解决方案浮出水面了。有些想法之间可能会有矛盾之处，但是每个参与者仍要始终坚持一种“不错，然后”的态度。
　　流程……阻碍了发展。流程经常强调“不行”或“还行，但是”，这扼杀了解决问题的创造性。当某些流程必不可少时，它们会阻碍解决问题的创造性，延缓你整个企业的发展。
　　@theagilebastard：“人和交互优于流程和工具” 1985年Nelson Mandela在狱中说。#哲理 #敏捷 #看板法
　　好消息
　　通过减少流程债，你可以：
　　加快你交付产品的能力
　　减少出错次数
　　使公司充满活力，具有高昂的斗志
　　理想情况下，你的研发和生产流程可以像软件一样融入到公司里，比如，灵活编写自动化构建脚本，让它能够根据客户独特的需求组合你的产品。你们可以用持续集成中运行验收和单元测试套件去驱动发布的流程，然后由甲方签收。你们甚至还可以直接发布，当然，这取决于你们做的是什么类型的软件（比如网页软件）。某些团队，比如工艺品批发商Etsy.com每天会发布30到50次。
　　好的流程是没有流程，只是一段写得很好的脚本。它找出问题的本质。它所提供的解决方案是按一下按钮。它解放了人们解决问题的创造力。团队成员能以好的状态完成工作，不需要被迫重复那些相同的单调的乏味的任务。
　　尽管人们（尤其是那些刚接触敏捷的新人）关注敏捷流程，但却容易忽略为什么会有敏捷流程。敏捷已经特意地简化了流程。一旦你步入职业生涯，可以专注于个体和交互。因为你用敏捷减少了无谓的流程，那些了不起的人推动了敏捷的效率。这可以向Wikispeed团队咨询。
　　如果你想减少企业中的流程债，可以去克服流程债下载一本免费的工作手册。