超越敏捷：以用户体验设计方法驱动成功的迭代

小标题–敏捷已成为软件的代名词。虽然在最初的宣言基础上又增加了很多内容，但即使没有 Scrum 认证、没有研究丰田之道，或者没有在维基百科上查找 “精益 “一词，每一个在这个行业工作了几个月以上的人都能理解今天实践的基本概念：我们通过可运行的软件向客户交付价值，因此缩小交付范围能更快地将软件交到用户手中，进而创造更多价值。

这个简单的概念之所以能坚持下来，是因为它对程序员（避免守门员问题和范围蠕变）和项目经理（缩短收益时间）都很有吸引力。现在，每个产品组织都会告诉你，他们是敏捷组织，或者至少在过去十年中经历了敏捷转型。但是，敏捷是一种开发方法，而不是产品设计方法，让 “敏捷 “主导产品的构思方式造成了一个明显的矛盾，这个矛盾持续了十多年，一直没有得到解决。

从设计师的角度看敏捷，很容易就能发现问题所在：教条式地快速交付小东西，以便更快地收集反馈，确定下一步该做什么。敏捷主义者认为，完成软件不仅是交付价值的最佳方式，也是学习和迭代的最佳方式。

实际上，这可能是最糟糕的方式。

虽然软件是实现价值的先决条件，但只有当用户使用软件来实现他们的目标时，才会产生价值。只有符合目的的软件–正确的软件–才是有价值的。但我们学习的方式就是犯错。如果试图同时实现价值（正确）和学习（错误），我们最终将一事无成。

要想在学习和交付两方面都取得成功，我们必须在设计方法的帮助下，将它们彼此分开。

敏捷迭代，或增加步骤的瀑布式迭代

“永远没有足够的时间做对，但总有足够的时间重来”。- 约翰-伯格曼

迭代也许是最著名的泛敏捷最佳实践。垂直切片、精益滑板或蒙娜丽莎素描的大体思路都是一样的：集中精力快速解决一个问题，并利用该版本的反馈来指导下一步的工作。

虽然迭代确实能让代码更快地投入生产（因为从小处着手），但在为客户提供价值方面，迭代并没有多大帮助。敏捷口口声声说要 “构建–测量–学习”，但在实践中，对话总是围绕着构建速度（我们如何才能更快地完成任务），而不是测量速度或学习速度。

换句话说，敏捷忠实地再现了瀑布式方法的核心原则：即衡量进展的唯一标准就是生产出可以交付的产品（对于开发团队来说，就是交付给客户的软件产品）。迭代框架强化了这一理念：我们可以勾勒出蒙娜丽莎，但不能抹去它的任何部分，只能增加细节。

遗憾的是，虽然 “前期大设计 “阶段已经取消，但这些垂直切片模型并没有提供任何替代设计阶段。它们将整个对话集中在开发过程中一个非常狭窄的部分：在我们定义了问题和大体的解决方案之后会发生什么，并且只讨论解决方案的交付顺序。我们是否理解问题的问题被掩盖了：重要的是构建，然后我们所有的问题都将由数据来回答。

对于任何研究人员来说，这种数据收集方法的弱点都是显而易见的：无论我们的 MVP 有多精益求精，我们仍然是在按顺序测试一个想法。虽然推出一个失败的 “滑板 “肯定比推出一辆失败的 “汽车 “更便宜、更快捷，但它仍然比几乎任何其他数据收集方法都要慢得多，成本也高得多。原型设计只能回答 “我们在哪些方面是对的，哪些方面是错的？”这个问题，而在现阶段，你想回答的问题是 “有哪些方面可能是对的，有哪些方面可能是错的？”

要回答这个问题，并真正利用迭代的优势，团队必须愿意把学习而不是产出作为主要目标。他们不应该只画一张草图，然后在此基础上逐步推进，而是应该画上百张草图，学习哪些地方不能画，然后愿意放弃所有草图来应用这些学习成果。

在业界，敏捷方法创造了一种激励制度，其结果恰恰相反。

验证崇拜

“当一个人的薪水取决于他是否理解一件事时，很难让他理解这件事”。厄普顿-辛克莱

虽然你可能听说过 “敏捷中的设计”，但你很难找到 “敏捷中的业务”：任何敏捷转型都不允许公司以两周为周期做出决策。在收集数据的过程中，每个冲刺阶段都可以自由调整的愿望与每个季度的路线图和年度预算的现实不谋而合。团队不能只推销 “滑板”，还需要展示 “汽车 “版本的路线图。

现在设想一下，团队的提案已经获得批准，他们已经花了几个冲刺和全职时间开发了一个 MVP。他们将其投入生产，并开始收集数据–但路线图已经为他们准备好了下一组功能。他们很可能还在跟踪需要很长时间才能充分反映在仪表盘上的跟踪指标。

团队的学习速度远远低于他们的反应速度，这意味着他们无法采取有效的行动。当团队收集到足够多的数据并得出结论认为他们构建了错误的东西时，他们可能已经完成了下一阶段的几个冲刺。现在，他们要么必须加倍努力，同时修复问题并交付承诺的功能，要么就违背对利益相关者的承诺（这就是所谓的职业生涯限制）。

团队的学习方法非但不能提高敏捷性，反而将他们禁锢在过时的承诺中，任何解决方案都必须与之相适应。如果该承诺严重偏离了目标，他们就会遇到 “从这里到不了那里 “的问题–除了从头开始，或者永远维持一个僵尸项目，别无他法。

在任何没有极度心理安全感的组织中，敏捷理想都无法实现。团队最好的办法不是找出错误并加以修正，而是悄悄地忽略它们。为了掩盖由此造成的用户体验欠账，团队将用户研究换成了验证–寻找他们正确的方法，以证明一切正常。

有一个简单的两问测试法，可以看出你的团队是在做研究还是在做验证。在开始开发新产品之前，问问自己：

• 我们如何知道自己是否错了？
• 如果我们错了，我们该怎么办？

在工作已经完成之后进行的验证，其设计方式使得唯一可能的答案是 “我们不能 “和 “什么都没有”。不管研究本身有多诚实，验证的背景（开发受功能路线图的约束）确保了从数据中得出的唯一见解就是 “我们做的是正确的”。

设计中的敏捷

“绘画的技巧在于画出成千上万的铅笔痕迹，然后擦掉所有痕迹，只留下少数几个”。- 琼娜-韦伯

敏捷不是我们前进的速度有多快，而是我们转身的速度有多快。回想一下敏捷的双重目标：为客户创造价值，为团队提供学习机会。只有帮助客户实现目标，交付的代码才有价值，因此我们必须从后者入手：学习、犯错。为了确保 “出错 “不会让我们丢掉饭碗，我们必须以组织能够接受的方式 “出错”：低成本、快速、安全。

一旦我们放弃将 “完成代码所需的时间 “作为衡量成功与否的标准，转而关注 “实现客户价值所需的时间”，设计过程的反馈回路就会成为实现我们目标的理想方法。设计人员不受软件工作/不工作二元论的限制，也不需要最低限度的概念保真度。而且，由于这些人工制品价格低廉，因此也不要求它们看起来与成品有任何相似之处。用户体验方法的保真度范围很广，从故事板到保真度更高的原型设计（provotyping）或非最终原型设计（non-finito prototyping），这些方法都能催生思考问题的新方法，而不会过早地对某一概念做出承诺，从而限制探索的进程。

这也意味着我们需要重新思考如何将我们的反馈回路融入我们的时间框中。在一个时间框架内，可能会有很多失败点：发现没有正确把握机会的大小，设计没有很好地解决机会的问题，交付与设计不够匹配。为了依次识别和避免这些陷阱，我们需要在单个时间框内建立多个反馈回路，跟踪明确定义的领先指标，以了解何时需要停止并尝试不同的方法来实现预期结果。

无论你有多少开发人员，如果你按照线性路线图开发软件，这种灵活性都是不可能实现的。但是，通过用户研究方法，每次测试十几个选项就变得相对简单，从而独立地确定问题框架、解决方案假设和必要的能力，这样敏捷交付团队就可以做自己最擅长的事情。

这与当今大多数组织所采用的软件开发方法截然不同。但是，将设计（一种决策过程）融入敏捷（一种交付过程）是无法实现真正的 “设计投资回报率 “的。

将敏捷融入设计的公司将比那些没有将敏捷融入设计的公司更胜一筹。