《基于场景的工程方法》作者问答录-InfoQ

《基于场景的工程方法》（Scenario-Focused Engineering，本书中文版正在翻译中）一书描述了在开发与交付基于软件的产品时，一种以客户为中心的精益与敏捷方法。本书所描述的思想能够帮助你基于端到端的体验理解客户的需求，并通过一种快速的反馈循环，以一种专注于客户的方式进行产品设计。

你可以下载本书的一个样章，对本书有一个初步的了解。

InfoQ 有幸与本书的作者 Austina De Bonte 和 Drew Fletcher 进行了一次采访，问题包括为什么端到端的客户体验比特性更重要、将基于场景的工程方法与精益创业与敏捷方法进行配合使用、通过特定的用户故事设计场合、获得快速的反馈、使用多种原型，以及如何在组织中实施基于场景的工程方法。

InfoQ：对于两位来说，编写这本《基于场景的工程方法》的动力是什么？

De Bonte：市面上关于以用户为中心的设计书籍已经有很多了，但其中的大多数都是由设计师编写、并且以设计师为受众的。而本书可以看做是一个“秘密解码环”，它能够说明在以用户为中心的设计中最本质的概念与技术，并且它的表述方式更适合于具有高度分析能力的思想者。在微软内部，我们用了五年以上的时间将这些主题内容传授给多个团队，这也让我们学到了如何解释这些思想背后的逻辑与科学性，而这对于受众来说是至关重要的。我们也相信，通过将这些知识分享给整个业界，我们能做出一件重要并且独一无二的贡献。

Fletcher：我们两位对于在微软的工作都感到十分自豪。我们直接地感受到 SFE 对微软的许多团队所产生的影响，通过将与专注于客户相关的词汇表与流程分享给团队，不仅影响了他们所创建的产品，而且更重要的是改变了这些团队的文化，使他们实现了以客户的需求为中心的协作方式，对此我们都看在眼中。如果你曾经在这种环境中进行过工作，你就会了解到这是多么有价值的体验。我们也希望能够帮助其他人拥有这种体验，让全世界更多的团队能够共享的自主权，即为客户交付杰出的产品。

InfoQ：本书解释了端到端客户体验的重要性，你们是否能具体举例说明一下这种体验？

De Bonte：将端到端的体验换一种说法，也就是“客户想要通过使用你们的软件完成什么样的实际工作？”。这就需要你专注于从头至尾的整个使用场景，而不是专注于与特性和功能相关的工程实践。工程团队因此能够保持对客户需求与期望的关注，而不是创建无数个无法相互关联的单一特性的孤岛，

客户的端到端体验或许是非常简短的，比如某位家长在食品店排队时阅读一位来自某个朋友的文本信息；某个开发者编写了几行代码以修复某个 bug；或是某个活动的计划人员发送了一封邮件以策划一次慈善拍卖。但端到端的体验也可能包括许多可变的部分，从而变得相当复杂。例如某个活动计划者使用数据库、电子表格、邮件、在线会议、移动电话以及 Word 处理程序以组织一次慈善拍卖活动；或是某个项目团队中的软件开发者使用 bug 跟踪工具、源代码管理系统、API 文档以及某个开发环境修复了某个 bug、签入代码、并将其标注为已修复。或者假设有一位年轻人在线购买了一些音乐、他想首先在手机中听音乐、然后是膝上电脑、并在晚间当他在打 Xbox 游戏时作为客厅中的背景音乐播放。

但以下的场景绝对不是一种端到端的体验：例如某人把他的 Word 文档的视图从草稿改为打印布局；在 Apple 的 App Store 中单击某个按钮以购买应用也同样不是一种端到端的体验。完整的购买体验必须包括如何找到这个应用、选择应用、并使它能够在客户的设备中进行使用。这些行为中的每一点从范围来说都太小了，它不足以捕获客户实际应用场景的本质，只能说它们都是一个大的客户场景中的一部分。

不过，这些示例也表示你或许可以从多个角度来思考同一个用户体验。你可以将目光放远，以看到完整的、端到端的应用，也可以将目光放近，关注于某个特定的端到端任务。但要注意的是不要将目光放得太近，以至于无法看到客户的实际场景、上下文和动机。重要的是要让你的观点与客户理解这一任务的方式保持一致。如果客户认为某个任务是相关联的，或者很希望它是相关联的，那么你也应当按照这种方式进行思考。

Fletcher：端到端体验背后的关键思想在于：团队应当专注于客户试图完成的实际工作，而不是关注于用哪一种特定的技术完成工作，或是专注于交付某个特性集或需求。我在这里将为你展示三个例子，它们的专注粒度层次会逐渐提高。

在第一个示例中，我将描述我此时此刻的一种端到端的体验，也就是对本次采访的问题进行解答并且格式化。在整个体验中，我在文字处理器中使用了大量的特性以完成这一工作。但是作为一个用户来说，我完全不想专注、仔细考虑、甚至意识到我正在使用的这些特性（我确信这些特性背后有着非常复杂的技术、代码和算法）。我真正在乎的只是最终的结果 —— 尽早地将这份文档发送给 InfoQ（并且希望你能喜欢它）。我只希望我使用的文字处理器能够正常工作，并且当我需要某些功能的时候能够为我提供，而无需大动干戈。看待这种体验的一种方式是考虑我所做的每一件事 —— 打开（或创建）某篇文档、输入、格式化、拼写及语法检查、保存并与 Austina 进行协商，最终发送给 InfoQ。

而当我再仔细考虑一下我在回答这些问题时的整个体验时，我意识到这个端到端的体验已经超出了文字处理器的使用。如果我将整个过程看作一个完整的端到端体验，我还必须加入与 Austina 和 Ben 互发邮件以及将写作内容送给出版社的过程。我与 Austina 共同创建、共享以及共同编辑文档的过程是一种协作式的体验。最后的体验是将这些问题的回答提交给 Ben、让他们发布在 InfoQ 网站，之后还要打开并控制一些社区内的讨论。从更高的角度来看待这一体验，可以将其称为一次完整的用户旅程，或是一次“轮回”的体验。

最近在我身上也发生了一次这种完整的体验，就是我需要横越整个国家，跑到波士顿去看我女儿在一场演出中的表演（她是波士顿大学戏剧专业的一位学生）。而我必须在几天内赶回这里以准备我个人的某场演出（我可是一颗摇滚新星呢）。为了这次体验，需要许多表演者和许多软件的协作。整个体验包括了查找与预订行程、在机场停车、检查行李、登机、在飞机上进餐、记录并跟踪我的飞机里程数、失物招领、客户服务、租车并到达酒店、或许甚至包括为我下一次旅游寻找某个动机、或是联系客户服务，以保证一切顺利。这也是一次完成的用户旅程的示例。你可以想象，在这次旅程中的每一站都包含了多个较小的、更细粒度的体验（例如登记租车、或完成整个付费流程）。

在思考用户体验时，重要的是首先要确定你（或你的软件 / 系统）所试图完成的工作是什么，随后要理解并确定你将如何分析整个体验的分镜头。你可以将一次体验视为通过一些软件特性的共同配合以执行某个简单的任务，也可以将其视为某个完整的用户旅程，它包括了一个完整的体验。随着整个产业的成熟度提升，我们看到许多企业已经成功地为大型的端到端体验交付了完整的解决方案，我们也希望这种趋势能够随着时间的推移不断发展。

InfoQ：是什么因素使得端到端的体验比特性对客户更有价值呢？

Fletcher：在我看来，我之前所提及的这些高层次的端到端体验之所以非常有趣并且充满挑战，是因为他们几乎总是需要多个团队的参与。可以公正地说，当组织中的不同团队共同负责一个完整的端到端体验时，很少有机会看到这些不同的团队能够努力合作，为那些不属于他们负责的领域的用户创建一个内聚的体验。是组织结构、自我意识以及团队文化等因素使得协调地专注于客户变得非常困难。这就带来了问题。因为最终用户所期望的是一种内联的、有趣的体验，其中的每一部分是如此美妙地结合在一起，使用户能够简便地、无缝地完成他们的任务。无论这种任务是编写一份文档，还是及时赶到 Boston 以参与某个演出 —— 客户的期望就是能够完成任务，他们并不想知道这一任务包含了哪些技术和哪些团队的参与。

虽说创建一个解决方案，在其中包含用户完成工作所需的全部特性并非不可能实现。但只有在使用这些特性时的端到端体验会让客户强烈地感觉到：这个产品似乎能够阅读他们的想法，这就是为他们量身订做的。在你的产品与客户之间打造这样一种情感纽带，这正是提高客户满意度、回头率、客户忠诚度，以及在竞争中取得先机的关键要素。

专注于端到端的用户体验的另一个好处在于：由于对于你的客户旅程有一个高层次的理解，就有可能为这次旅程描绘出这样一副图画，让所有参与开发的团队能够分享一个共同的见解，他们就会理解，一旦所有的功能片段最终结合在一起，这种成功会是一种怎样的感受。我并不是说要创建多达几千项细节需求的列表并且完成分配与编码，恰恰相反，我的意思是创建一种高层次的描述，以表现客户的真实情况，以及为客户带来成功的关键因素和对整个过程进行评估的指标。在本书中，我们详细地描述了如何使用一系列场景以建立一个成功的业务的机制，这些场景能够指导团队为客户的共同目标而努力。如此一来，整个解决方案的所有特性与功能都关联在一起，为客户实现一种内聚的端到端体验。

InfoQ：如何将基于场景的工程方法与精益创业与敏捷方法糅合在一起，可否在这方面给出一些示例？

Fletcher：SFE、精益创业与敏捷方法之间是高度相容的。它们本质上都是迭代式的过程，以一种共通的科学方法作为它们的根基，首先提出一个假设，然后对其进行测试、评估与结果分析并进行调整，然后不断地重复这一过程。为了弄清楚如何最大限度地从这些方法中受益，最重要的是理解每种方法的闪光点。

我在此要冒一个小小的风险，对几种方式进行一下概括。精益创业的本质是在为成立某种业务而投入巨大的金钱与精力之前，先通过迭代方式鉴别出一个可行的业务模型。而敏捷方法的本质是通过迭代方式保证编写正确的代码，提高质量与效率，同时尽量减少官僚作风。而另一方面，SFE 的本质是通过迭代方式找出客户的需求，建立一种衡量系统，并专注于客户的满意度。

如果你的目标是通过尝试不同的商业创意找到客户的需求所在，同时真实的用户也愿意为此需求而掏钱。那么我们在 SFE 中所描述的多种技术都能够在早期的尝试过程中找到用武之地，尤其贴合精益创业的环境。这些技术包括：观察与理解客户尚未表达出的需求的技术；创建草图（sketch）、视觉稿（mock up）与快速纸上原型的技术等等。等到你对于适合自己的业务模式已经心中有数，就可以开始描述你的目标客户与客户价值主张。在这一阶段就可以自然地过渡到全部采用 SFE 的技术，创建特定的产品与特性的概念，并通过客户进行测试。

我对结合使用精益创业、SFE 与敏捷方法的看法是：首先要弄清楚你的业务是什么类型的，然后确定你的目标客户群体，当然这种看法有些过于简化了。实际上，在我们的 SFE 研讨会中，我们通常会表明：了解以上观点只不过是你的进入成本（进入 SFE 研讨会的成本）。精益创业方法提供了大量的工具、建议与思想，使你了解如何迭代、鉴定并证实某个可行的业务方向。因此我在启动某个项目时会应用精益创业的思想与方式，对众多的思想保持谨慎、通过实验与测试找出某个可行的业务方向。在这个早期探索阶段中，我会利用到某些 SFE 的技术（尤其是那些专注于观察客户，理解他们的真实需求的技术）。我也可能会参考 SFE 中如何对新的点子创建原型、测试以及快速评估的方法，这些方法对于测试高层面的主意非常有效，同样也适用于对非常特定的使用场景进行测试。一旦确定了业务模型与目标客户之后，我会通过 SFE 技术进一步观察这些客户，然后再开始一些创新性的流程，创建并测试一些特定的解决方案的点子。我会通过敏捷方法中的 sprint 作为整体的项目管理方式，以管理所有的活动。与传统的 sprint 方式的主要区别在于，这种方法在早期的几个 sprint 中的产出很可能并非软件代码，而是对客户的理解、视觉稿与原型，或者是对场景与用户旅程的描述。在流程中的某个时机，此时你已对客户和他们的需求有所理解，并且对于怎样的用户体验才能够打动他们有了一个较高层面的概念（并且已测试过），此时你就可以继续通过敏捷 sprint 方式有效地编写代码，以最终交付这些体验。

最后一点也非常重要，你需要创建一系列的度量指标并进行跟踪，以时刻了解你是否正走在正轨上。我们所合作过的大多数工程团队都已经建立起了一套业务指标，以及一套健壮的指标用于跟踪开发进度。我们建议你再添加一套指标，以跟踪了解你所开发的产品在多大程度上得到了客户的共鸣，这就是一种客户体验的指标。为了成功，你需要在以下领域具有良好的表现：业务、技术与体验。你可以充分利用精益创业、敏捷与 SFE 方法帮助你实现成功。

InfoQ：你在书中提到通过使用故事的方式设计场景，以此让团队对于需要完成的工作达成共识。你能否说明一下，为什么特定的故事通常比起一般性的故事更具实用性呢？

De Bonte：为每一种一般性的问题都创建一个最优的解决方案是不可能的，不同类型的客户其需求往往也是相互冲突的。一位每天收到五封邮件的家庭妇女很倾向于以一种非常直观的方式以了解需要阅读哪些邮件，而不受铃声与提示音的骚扰。而一位每天收到 150 封邮件的知识工作者为了应对每天的工作量，常常会使用文件夹、自动排序规则与标注等方式。对于这两种截然不同的使用模式，你如何能够让你的邮件服务同时对这两者做到最优的用户体验呢？

如果你确实想让某位客户做到眼前一亮，就必须保持专注。因此你要选择对哪种目标客户进行优化，并为这些所选择的客户创建特定的故事，以解决他们在实际应用中最紧要的问题。如果你仅仅告诉你的团队“创建一个电子邮件客户端”，这个需求是非常含糊不清的。你其实是将问题丢给了团队，让他们去弄清楚要对哪种客户和哪些场景进行优化、以及哪些特性对于这种场景来说是最重要的。而实际上，不同的团队成员对于什么是最重要的持有不同的观点，因此你最终所得到的产品很可能是一种四不象，它对于任何一种用户来说都不是最优的。反之，如果你为团队描述了一种特定的客户与一个特定的故事进行优化，那么团队成员就能够达成一致，减少争吵的时间，而专注于为客户提供一个真正优秀的方案。

值得一提的是，你应当战略性地选择你的目标客户与目标场景，这一点是至关重要的。你应当尽可能让这一方案在邻近的群体上得到沿用，这些群体具有与目标群体非常相似（但并不完全相同）的需求。选择了适当的目标客户，可能会使你实现极大的沿用性，甚至是跨入另一个具有巨大商机的市场。可以选择一些不同的目标客户，这些客户的需求互为补充，通过沿用性，你或许会在市场上获得令你吃惊的覆盖率真。而如果选择了错误的目标群体，虽然你的部分客户或许会对你提供的方案感到非常非常满意，但你仍然无法获得更广阔的市场群体。

InfoQ：能否请你描述一下，当你们的产品随着迭代而不断发展时，你们所期待的反馈是怎样随之变化的吗？

Fletcher：从创造力、创新到令客户满意的过程并不是线性的，理解这一点十分重要。怎样的点子才能够让客户感到满意，这方面没有一种固定的步骤能够让你照抄。如果创新是如此简单的事，那么每个人都会这么做。在发展的道路上存在着无数的决策、调查、反应与弯路，这些过程是无法以一个线性的规程进行概括的。虽说如此，但还是有一种可预言的模式存在的。

我们将交付优秀的产品的模式描绘为一个漏斗的形状 —— 它的顶部很宽阔，而越接近底部就越狭窄。看起来与下图差不多：

你可以将漏斗的顶部看做这一过程的起始，将底部看做它的终结，即最终产品的产出。在起始阶段，世界都掌握在你手中，你具有无限的可能性，可以做出无限多的选择。而在漏斗的底部，你所能够做出的改变就变得很少了。在产品的创建过程中，你已经完成了你的选择。实际上，你很可能已经完成了这个产品，只是通过迭代进行一些最后阶段的微调而已。

在这一过程中存在着多个阶段，在每个阶段中，你所创建的东西，以及你所期望的反馈都在不断变化。

客户需要些什么？在早期阶段，或许你正在应用精益创业技术，此时你最大的关注点在于：我是否已经确定了客户所关注的一系列需求，他们又是否为会了某种方案买单？在这一阶段，你无需关注菜单、UI 或客户支持等内容。你只希望从客户那里收集反馈，以表明他们是否为会某种能够满足他们的需求的方案买单。

我是否找到了正确的方案？在下一个阶段，你将为满足这些需求所想出的点子收集反馈。这种解决方案是什么形式的，是一个网站、一个移动应用、一种设备还是为某个产品设计的一个插件？你能够快速地创建一个模拟方案，以了解潜在的客户对它的反应？你所测试的方案在技术上是否可行？客户是否为会其买单？请记住，你还没有创建任何实际产品，只是通过一些非常粗略的原型（通常不包括代码），为你的基本构思获取一些高层次的反馈。

这个方案可行吗？此时你已经开始创建一些功能性的东西了，它可能是实际的代码、快速原型、或两者的结合。你的方案中已经有很大部分得到了定义或实现，可以对用户的使用过程进行观察，获取关于实践的产出和流程方面的反馈。

细节部分做得如何？到了这一阶段，你需要提供产品的细节，并收集对这些细节的反馈。当产品的各个部分组合在一起后是否可用？产品的配色方案是否令人满意？UI 中的各个部分的流动是否正确？文字是否恰当并保持一致？安装与支持过程是否顺利？

这套交付过程的目的并不是要求你以一种编排的方式让你的完整应用同时通过这几个阶段。如果你使用了某种敏捷过程，那么产品的不同部分很可能是在不同的时间完成的，它们各自经历了不同的 sprint、具有不同等级的完成度、并由不同的团队完成（这种方法也是理想的方式）。理解了这些不同类型的反馈，你就能够做到在正确的时机专注于对应程度的反馈。举例来说，在早期阶段，你希望看到客户对于你为解决它们的问题所设想的点子的真实反应，在这种时期向客户收集关于配色方案的反馈只会产生干扰，而没有任何帮助。更糟糕的情况是，如果你试图获得一些高层面的反馈（喂，你会不会买这个产品啊？），却在为用户展示一些高像素的细节，那么这些客户很可能对这些细节提出反馈……而这并不是你此时所需的。因此，重要的是要理解你所寻求的反馈的类型，根据你所处的不同阶段，了解如何获得正确层面的反馈是最为重要的。

InfoQ：你在书中建议通过创建多个原型的方式获取产品概念的反馈，通过多原型的方式，你能够得到哪些额外的益处？这些益处能够超过创建它们的成本吗？

De Bonte：你需要彻底改变你的观念，不要将原型视为可以工作的代码。没错，有时你也会通过编写代码的方式设计原型，但如果你要设计多个原型的话，那么大多数情况下都还是在产品设计的早期阶段。多数情况下你只会用一些最简单的功能进行快速的原型设计，因此可以说这些原型是非常廉价并且能够快速地创建出来的。

最常见的早期方式包括在纸上画出 UI 视图（或任何一种你选择的界面）作为一种纸面原型。对于服务来说，可以以短文的形式表达。还可以通过 HTML 以及 JavaScript 的方式创建一种视觉稿，以展现某些数据集。目的在于能够通过几个小时的努力将你的方案概念展现在客户的面前，因此能够早早地通过客户的反馈对你的方案进行修正。之所以要展示多种思想，是因为你并不知道哪种方案能够产生最大的共鸣，并且心理学表明：如果为人类（即你的客户）提供少量的东西进行比较，他们就能够更好地为你提供有效的反馈。

在最早的几个迭代中，你的目标是确认你要解决的问题确实是至关要紧的，并且你的方案中最少有一种是有意义的，因此可以说你已经处于正确的方向上了。这一切过程都远远早于你开始实际地编写规格说明、设计实际代码或进行其它任何时间密集型的工作。对于多数项目来说，我们的经验法则是在三个快速的迭代内进行快速原型设计，并且对于这些原型在三个快速的周期内收集客户的反馈，即使这些反馈是非正式的。之后再决定具体的解决方案的方向。

如果没有投入足够的时间对你的想法进行验证，那么很有可能你所选择的解决方案会因为某种原因而无法产生效果。等到你意识到这一点之后再来修正你的方案，代价将变得十分高昂，甚至是完全不可能的。如果这种后果会导致项目失败、产品被取消甚至是公司倒闭，那么你必须在前期过程中投入几天的时间以确保你的方向是可行的。可以将这种方式想象为为了规避每个项目所面临的最大风险 —— 创建错误的产品而设立的保障政策。

InfoQ：为了从快速的反馈循环中受益，应保持较短的迭代周期。你能否举例描述一下这种迭代，以及这种迭代能带来的益处？

Fletcher：不久前，Austina 和我一同参与了某个团队的工作，他们当时正面临着一个新的商业问题 —— 拥抱移动计算。架构师们齐聚一堂，共同推出了一个绝妙的计划，能够实现在远程运行所有的软件功能，包括交易、安全性、通常功能……一切功能都优化在一个小小的屏幕上。“太完美了！”当时他们都是这样想的，而且从技术上来说确实是相当明智的选择。在经过了一次 SFE 研讨会之后，团队决定让某些客户来检验一下他们的革命性的功能。由于这个想法是如此明智、如此酷炫、如此独一无二，团队非常确信客户绝对会喜欢上它的。因此他们创建了一个快速的原型（使用 HTML 在一天内就完成了），然后为几位客户展示了这个原型。你知道客户们是怎么说的吗？

“啊？为什么要这样做？我从来不会这样子使用我的手机。你只要给我发送一条短消息，告诉我有某个订单正等待付款就好了。如果你能够立即用短消息通过我发生了某桩交易，那就太棒了，我会非常非常开心的。”

团队开始重新考虑他们的设计了，而直到从客户那里获得反馈为止，团队仅用了一天时间创建了一些模拟的 HTML 页面，以及数天的时间用于评审过程，避免了将时间浪费在无意义的开发活动上。而如果开发团队没有在早期过程中得到这些反馈意见，他们很可能已经开始按照架构师们所想象的方式打造那个所谓的高智能新移动科技平台了。如果情况真是这样，那么他们可能一直不会意识到客户并不在意新的平台使用怎样的解决方案，直到通过某种“beta”版本将经过调试后的代码发布给客户。而通过一种早期的快速反馈循环，他们就能更容易地改变自己的思维方式，以一种完全不同的方式对他们试图为客户所解决的问题进行思考。当然，一旦他们想出了一些新的点子以解决客户的“客户平台的问题”，他们会马上搭建一个新的快速原型。这一次，客户的反馈表明团队已经走在了正确的方向上，新的设计很可能会令客户感到满意，同时在架构上又简单得多。

InfoQ：在本书中，你提到为了推出一套解决方案，可以成立一个 sketchfest，也称为专家研讨会（charrette）。你可否详细地谈一谈这个 sketchfest是怎样运行的吗？

De Bonte：这个想法本身很简单，也可以按情况做一些调整。基本方式是将与项目相关的一群人集中在一起，这些人各自代表了项目的不同角色，包括设计师、项目干系人、客户、合作伙伴以及任何可以邀请与会的人士。首先对客户的问题进行陈述，让大家对此有一个基本的认识，可以选择一些场景进行描述，然后交给每个参与者一叠纸与一支笔。然后让每个人待在一间房间中，随意地写下一些对于这个问题可能的解决方案的点子。在一段简短的时间内，整个小组将从多种不同角色的视角对这些创意进行头脑风暴，这种方式能够尽量使你考虑到实现一个成功的方案相关的各种视角与制约。最好的方式是让参与者结对或分组，对其他人的构思进行评审，让他们相互借鉴与学习，最终得出一种“集大成”的思想，这是任何一个人都无法独立实现的。这种方式能够有效地开展一个新的项目、让对于解决方案来说一些不容易发觉的重要制约能够浮出水面、使所有的项目干系人保持一致的目标，并让每个人都能以一种切实的、富有成效的方式提出他们的创意。

InfoQ：你是否能够描述一下，团队通常是通过什么方式实施基于场景的工程的呢？他们又采取了哪些步骤以展开这种工作方式呢？

Fletcher：当我们首次与某个团队开展 SFE 的实践培训课程时，首先总是与团队进行几次会议。以确保领导们了解团队的培训目标，也为我们提供了更多的背景知识，让我们为团队推出一些定制化的内容。在这些会议中，我们会向领导们了解他们对于团队在交付具有高客户价值产品的执行方面有什么感想，并要求他们对团队的创造力与创新能力在 1 至 5 分的范围内进行评分（我们会为他们提供一个简单的模型，帮助他们进行评分）。随后我们将向他们提问，看他们希望团队在一年之内能够达到什么水平。可以想象，多数的领导都会声称，“1 到 5 分都不够看，我们要达到 6 分才行，我们要在一年内成为史蒂夫乔布斯与苹果公司！”，这对于我们来说毫不意外。

而事实上，要改变团队的文化与最佳实践，需要付出大量的时间、辛勤的工作以及有意识的专注力，这不是一个晚间就能够实现的。对于你的问题，我可以告诉你的是，我们看到团队在实施某种迭代式的设计实践，例如 SFE 时，有一些通用的模式正在慢慢浮现。我们在书中也收录了两个学习案例，详细地描述了两个团队在这个成熟过程中的旅程。我们还在附录中提供了一个自我评估工具，以帮助团队评定他们目前的能力，并帮助他们思考与量化改进的机会。

在团队学习专注于客户的文化时，他们通常会经历几个典型的阶段，以下是这几个阶段的简单描述：

策略阶段。我们首先注意到的一个变化在于，团队与领导对于他们所追求的商机有了一个更清晰的了解。如果领导们在我们的研讨会之后没有马上说明这一点（或者在会议之前），那么团队就很可能向领导提问，要求了解他们将创建的产品背后的商业策略，以及目标客户群体。事实可能会让你感到吃惊，我们合作过的许多团队与领导无法清晰地表达出他们所交付的商业价值，或是他们的目标客户群体的划分，以及为什么要这样划分。这种情况尤其常见于一些团队中，他们所开发的产品在市场上已经存在了一段时间，而他们的团队策略则类似于“再做一次这个产品，但这次要做的好一点。”

一致阶段。在我们所经常看到的下一阶段中，团队将从领导者们那里了解业务的方向，随后进行大量的客户调研与观察，并设计出产品的场景，从一个高层面描述怎样的产品才是成功的，以及如何对其进行评估。这个阶段非常重要，它让整个团队对于重要的工作，以及如何进行评估方面保持一致。而如果所创建的产品与服务需要多个不同的团队进行协作，那么这一步骤的价值就更明显了。

让整个团队参与 SFE 研讨会还有另一个好处，那就是团队对于他们所创建的实际产品建立了一种共通的语汇表与理解（例如每个人对于某个场景的期望功能都有一种相同的理解），同样也对所浮现的文化规范建立了一套词汇表（例如：我不是客户；只把一些功能做好；编写 SPICIER 的场景等等）。

迭代阶段。在这一阶段，团队将制定迭代流程的特性与细节。当然，如果团队已经在应用敏捷实践，那么他们已经走在这条路上了。但是许多团队只是将敏捷挂在嘴边，而经过仔细的观察后却发现他们更像是“敏捷式瀑布流程”而已。要真正地将迭代的节奏与常规的反馈带入他们的每日工作中，还有很长的路要走。对于他们来说，下一个重要的里程碑是确定基础设施，并在工作日程中建立起真正的迭代的节奏。

适应阶段。我们所见的某种模式能够包含所有的这些阶段，这就是适应。团队开始着手实现某些目标（例如以上阶段所列举的一些目标），在过程中他们会发现自己不断地去适应一些对他们来说最优的方法与心态。SFE 中提供了大量的选择，而成功的团队通过对自身应用 SFE 的方式进行不断修正与发展，以找到最适合他们的方式。

文化阶段。创造力、设计、创新以及创建用户喜爱的产品，这些任务都是一种团队活动。为了实现这些目标，自然有许多要学习的技艺，但真正成长迅速的团队对于如何进行专注于客户的产品开发有着非常独有的、非常强烈的文化，并且是不断发展的。在整本书中，我们列举了一些更为突出的价值，而这些价值都是有研究支持的。我所说的价值包括对快速失败进行奖赏；在决策前必须考虑多种思想的规定（更好的做法是将多个好点子的优点结合在一起）；拥抱多样性（意指通过多种不同的思想角度能够得到更好的结果）；以及让领导者表现得更像是一种促进者，而不是决策者或任务管理者。以上只是部分例子，我们在书中还列举了许多示例，并且在这一主题方面已经有许多优秀的书籍了。总的来说，经我们观察，团队从实施迭代式设计的早期阶段直到实现深度的文化变革为止，需要大约两年左右的时间。

InfoQ：本书的最后一个章节专门讲述了你在进行面向场景的工程授课时所学到的东西，你能否举例说明一下你所学到的内容呢？

De Bonte：或许对我来说最好的一点就在于认识到让团队接受这些思想是多么困难，这并不是因为哪一门技术特别难学，而是因为专注于客户的迭代式过程与传统的工程方式是完全相反的，而大量的团队多年来都在以传统的方式工作，即使是那些声称采取了敏捷方法的团队也不例外。我们发现，领导一个团队完成这种转变，更多的取决于领导力与变更管理，而不是流程、工具或技术。毋庸置疑的是，能够最快地完成整个过程，并实现最大收益率（ROI）的团队必然有着最坚决、最有决心的领导，他们坚定地将专注于客户的迭代作为一种业务方面的战略优势。

关于本书作者

Austina de Bonte是一位培训师、教练、顾问以及变革推动者。在微软的 16 年职业生涯中，她曾参与微软首次向在线服务发起冲击的过程。期间内她领导了著名的 MSN Messenger 服务的早期版本的项目管理，并在这一过程中深刻地体验到了以用户为中心的设计方式的价值。Austina 在 2008 年设想并创立了基于场景的工程方法这一思想，以加速微软向专注于客户、迭代式的设计与产品开发方法的转变。这一思想最终通过培训传授给了 2 万 2 千名以上的微软工程师以及他们的领导，并投入实践。Austina 拥有 MIT 计算机科学专业的本科与硕士文凭。

Drew Fletcher 是一位教育家、演讲者以及顾问，他目前居住在西雅图。Drew 在微软任职 20 年，领导团队交付了许多创新型的产品，包括 Visual Basic、Visual J++、Visual C++ 和 Visual C#的早期版本。Drew 拥有波士顿大学国际管理专业的工商管理学士（BSBA）学位。出于对登山及滑雪运动的喜爱，Drew 自愿加入西雅图登山救援队，并担任了董事会的董事。