“针对产品负责人的分析技巧”在线课程的问答

要点

• Kent McDonald 针对产品负责人（Product Owner）提出了一些分析技巧，帮助我们构建和维系共识并且要优先考虑结果而不是输出；
• 在深入到具体解决方案之前，为何要首先阐明问题所在；
• 关注结果而不是产出，即关注满足需求而不是交付解决方案；
• 区分人物模型和用户角色以及它们如何映射到问题和解决方案中；
• 提出正确的问题如何能让分析技巧事半功倍。

在“针对产品负责人的分析技巧”的视频课程中，Kent J McDonald 分享了一套技巧，帮助我们构建和维系共识并且要优先考虑结果而不是输出。

《 Beyond Requirements:Analysis with an Agile Mindset 》一书的作者展示了多种方法以更好地：

• 理解项目干系人；
• 理解组织的情况；
• 评估需要满足的需求；
• 构建和适当地交流待交付的解决方案；
• 组织和持久化解决方案信息。

InfoQ 采访了 McDonald 以进一步了解这些话题以及演示的技巧。

InfoQ：众所周知，产品负责人（Product Owner）是敏捷过程的参与者。你为什么觉得需要给他们整理一个相当广泛的分析技巧集锦？

McDonald：这个问题似乎暗示了一个我经常碰到的误解，认为分析与敏捷是不相干的。我认为这是一个误解。

不管你采用什么方法，适时、适度、适当地使用技巧进行分析都是非常有用的。分析技巧对理解复杂领域（参见 Chris Matt 关于使用 Cynefin 理解业务分析适用场景的文章）和集中信息辅助决策尤其有用，比如如下决策：

• 需求值得满足吗？
• 满足该需求的最佳解决方案是什么？

这些都是产品负责人需要做的决策。由于背景不同，产品负责人可能有使用相关分析技巧的经验，也可能没有，所以我想通过整理这套技巧集锦，让他们在工作中能快速上手使用。

另一个目标观众是业务分析师。他们有关于分析技巧的知识，但是对敏捷工作方式可能知之甚少，需要一些关于适时、适度适当地使用技巧方面的建议。他们可能就是做上述决策的产品负责人，也可能是帮助产品负责人收集做这些决策所需要的信息。

InfoQ：你的课程以 IIBA 中的核心概念（Core Concepts）开头。你能详细介绍一下这些概念并解释一下它们是怎么帮助交付最有价值的解决方案的吗？

McDonald：我之所以在第一堂课上引入关于 BACCM 和其它一些概念（结果、产出、发现和交付）的讨论，是因为我发现这些概念十分有用，它们能说明我为什么在接下来的课程中引入这些分析技巧。

在分析领域，BACCM 定义了一组很好的术语，因此能帮助团队建立一套用于协作满足特定需求的通用语言（ubiquitous language）。

InfoQ：需求识别应该先于解决方案的实现和交付。倘若在评估问题之前就尝试描述解决方案会怎样呢？这样做会带来什么风险？

McDonald：这样本末倒置有如下几个风险：

1）该解决方案并没有满足组织的任何需求。当有影响力的人突然遇到一个炫酷的新软件工具、业务流程或者方法论的时候，不明就里就坚持让组织实现，这时候就会发生这种事。轻则组织浪费了时间和金钱，甚至可能对组织的结果产生负面的影响，也会影响该方案实现团队的人心，他们会意识到他们没有为组织创造价值。

2）组织没有解决它们的实际需求，因为人力和资金都耗费在了实现无价值的方案上了。

3）方案虽然与组织需求相关，但是实现团队不理解需求是什么以及什么才叫满足了需求。这种情况下，团队可能过度工程化（over-engineer）解决方案，或者错过最有效的交付时机。这也导致了时间和金钱的浪费。
如果 IT 部门反复经历这样的风险，那么就会失去组织中其他部门的信任。这些业务单位将转向其他 IT 合作方。这会导致产生大量的“影子 IT （shadow IT）”，后续也会带来更大的支持和集成负担。

为了与其他部门保持良好的合作关系，IT 部门必须竭力厘清组织存在的需求以及它们的优先级。IT 部门不一定是做决策的，但是应该确保进行必要的讨论，因为他们控制了方案实现的时间和方式，所以他们占据着很好的决策点。

“针对产品负责人的分析技巧”描述了怎么用目标描述待满足的需求以及满足这些需求的方案是什么样的。这样交付团队就能借助他们对可用技术的理解，制定出合适的方案。

InfoQ：你强调了关注结果而不是产出的思想。你能解释一下二者的区别吗？

McDonald：结果是你团队的工作给组织和相关方行为上带来的改变。你也可以把结果看作是满足需求。

产出是你的团队在项目中交付的任何东西。例如，软件、文档或者流程。你可以把产出看作你交付的解决方案。

我做每一件事的时候，我都想弄清楚怎样用最少的产出赢得最大的结果，即我是否能只简单地改变一下流程就能满足需求。这比完成同样的事情开发一大堆软件要好，因为我没有引入更多要维护和更新的软件。

不幸的是，大多数工程都是基于产出来衡量进展和成效的（完成的用户故事数、速度、挣值管理）而不是结果（达到目标）。这加剧了我之前提到的风险，即一些解决方案过度工程化了或者交付了不必要的解决方案，因为这就包含在了最初的口径内。我要指出的是，口径就是在工程的人员对工程了解最少的时候识别的。

InfoQ：根据你的描述，在需求发现到交付的持续改进周期中，并没有将设计单独拆分出来。你能解释一下它的原理吗？

McDonald：基本上我引入的关于设计的讨论都基于《 Beyond Requirements:Analysis with an Agile Mindset 》早期草稿时某位审校者的问题。他问我为什么不采用如下的三步：发现、设计和交付。我略加思考，意识到分散设计并没有任何价值，因为设计和分析一样，贯穿发现和交付的始终。

在发现阶段，设计发挥作用的方式就是通过使用设计思考技术来更好的理解用户，通过使用模型、样例和验收标准来描述解决方案。

在交付阶段，设计是团队在选定技术和架构约束下找到用户故事的技术实现方式。该活动是和开发与测试交织在一起的，因为团队最开始会有一些关于设计的讨论，但是后来会随着经验的累积修改设计。

将设计拆成一个单独的活动并不会给流程带来价值，反而会导致无意义的争论，争论某项任务是属于发现、设计还是交付。然而发现（厘清交付什么）和交付（交付交付物）的区分明晰多了。

我喜欢让我使用的流程和技巧相当简单。简单的实践更可能被使用，你也能避免上面提到的无意义的争论从而专注于当下团队应该做的事情，以更好地搞清接下来怎么办以及要做什么决策。

InfoQ：提到利益相关者分析，你讨论了一种叫承诺量表（Commitment scale）的技巧。你能展示一下它给典型的影响 / 利益分析带来了什么吗？

McDonald：有一节课讲到了利益相关者映射表，它可以用来做典型的影响 / 利益分析。该分析（以团队内的对话进行最有效）能帮助我们弄清各个项目相关人在项目中的利益多少和影响大小。项目相关人落入哪块为我们和他们打交道提供了指引。

承诺量表补充了该分析，它正视组织内政治的存在并提供了讨论项目相关人对项目的态度的方式。我们团队讨论各个项目相关人当前位于量表的哪一部分，从热情地支持到敌对，中间还有几种状态。然后，我们讨论如果想让项目成功的话，那么我们需要项目相关人处于哪种状态。我们不需要每一个人都是热情的支持者，但是一旦有一个项目相关人是敌对的并且比较有影响力，我们可能需要做些事让他在承诺量表上提升一个等级。

需要注意的是，不应该发布承诺量表。与其作为特定的制品，它更应该作为一个讨论的话题。它的关键目的是帮助团队搞清怎样更好地与项目相关人打交道以及在项目进行过程中是否有需要额外努力的地方。

InfoQ：用户故事的目标是最能从项目的实施中获益的用户、个人或者人物模型（Persona）。你能解释一下用户角色（User Role）和人物模型之间的区别吗？能举几个例子吗？

McDonald：我觉得关于人物模型和用户角色人们有一些混淆，我甚至怀疑我也曾经混淆过，还加剧过这种混淆。二者的区别在于你是要识别需求还是描述解决方案。

人物模型尤其适合识别需求，识别和描述待满足需求的关键人物。它的关注点是发现。我们不会覆盖到所有有特定需求的人，仅仅那些关键的人。

用户角色更适合描述解决方案。其目的是描述使用解决方案的不同类型的用户，提供用户的相关信息以及辅助方案的开发。这样的描述也可以用来做特别的分析，识别出特定用户使用解决方案会采取的行为。

因为我们考虑了人们使用应用时所面临的一些环境因素，那些对描述人物模型有用的技巧对描述用户角色同样有用，往往就是这样。

拿我在在线课程中举的例子评审人 Reed 为例。我使用了 Jeff Patton 建议的一个人物模型模板来描述 Reed。收集的信息很好地反映了 Reed 工作的方式和环境，让我们有了深刻的理解，这对提交系统的开发十分有用。Reed 很可能不是提交系统的关键人物模型，因为他和提交系统的交互是推动满足需求的其他动作。提交系统的关键人物模型很可能是提交者 Sam 和大会主席 Connie。

如果我从零开始处理提交系统，我很可能为提交者 Sam 创建人物模型，也可能为大会主席 Connie 创建，这样我就理解了关键需求。一个人物角色代表了提交创意的人，另一个人物角色代表了选择项目的人。我们然后很可能识别出几个其它的用户角色来细化解决方案，但我们更多的是使用它们来描述解决方案，而不是识别问题。

InfoQ：决策过滤器（Decision Filter）是一项合理识别需求的技术。你有没有关于如何建立有效决策过滤器的技巧与我们分享？

McDonald：识别出一些问题，这些问题涵盖了我们希望通过组织、产品、版本发布或迭代完成什么任务。借助这些决策过滤器，能够指导我们做出决策，确定要做什么以及如何实现。
根据决策类型的不同，决策过滤器可能重述其他一些关键理念，例如目标、满意的条件或者关键成功标准。不论如何，决策过滤器通常都是使用同样的方式创建的，这种方式就是对话。

有关决策过滤器的对话通常会包括所有提供过滤器的人（目标、满意的条件或者关键成功标准）和部分执行决定的人。为了形成更具有可行性的决定，对话会包含更多执行决定的人。对话能为团队提供大量的背景信息，但是最终没有参与讨论的人需要使用通过这个对话所得到的决策过滤器。决策过滤器正是为这些人创建的，帮助指引他们每日的决策。

InfoQ：课程中几次提到了问问题的技巧。你认为这种方法为什么如此有效呢？

McDonald：我喜欢问问题是因为问题往往能促进讨论，使人们拿出脑海内对于风险、假设和约束的思考来与团队分享。将这些信息公开能帮助团队所有人在别人的创意上更上一层楼。问题对设定对话的主要内容也非常有帮助，它使对话焦点集中在特定的话题上。我也发现以恰当的方式提出合理的问题有助于激发困难但是必要的讨论，这种讨论及早进行能预防大量时间和金钱的浪费。这种讨论最合适的问题就是：“这样做值得吗”。

InfoQ：我们首先会使用项目机会评估（Project Opportunity Assessment）预防组织浪费时间和金钱。其实，这就是一种敏捷的做法，能消除开发前的完整全面的设计。要做这样的评估需要做什么？

McDonald：“敏捷宣言背后的 12 准则”之一是“以简洁为本，它是极力减少不必要工作量的艺术”。这条准则能消除开发前的完整全面的设计，因为“预先做的大而全的东西”在很多方面并不会产生价值。这主要是因为我们的假设从“我们能预先知道所有事”变为了“我们不可能预先知道所有事，但是我们需要掌握足够的信息，保证工作能够继续下去，然后确保我们能从正在做的事中学到更多”。

项目机会评估与开发前的完整全面的设计没有关系。它是一种看待创意并最终决定“这样做值得吗”的方式。讨论不需要花费大量的精力，只要团队意识到他们可能需要多次回答这些问题。第一次回答这些问题的时候，我们要试着回答这个项目是否值得去做。通过这些努力，能够帮助我们构建一些内容，这些内容会提供更多的信息来详细回答这些问题。

我曾经在多个团队中参与项目机会评估，这通常会是一整天的计划会议。问题基本上会提供一种引导对话的方式，帮助团队获取必要的信息，以此来决定活动是否要继续。在其他的情况下，资助人和产品经理会提前准备好这些问题的答案，然后和团队讨论，这两种方式都能用于构建项目共识并有助形成结论。一种情况下，产品经理不会回答这些问题，因为她可能会感觉没有足够的信息。团队认为信息缺乏是项目当前不应该启动的一个明确的标志。

不幸的是，对于正在采用“敏捷变革”的组织来说，能够对所有的项目或产品坦诚地反思“是否值得去做”的还为数不多。他们将注意力集中在了采用更流行的“框架”上，忘记了敏捷的原则之一就是不做不该做的事。如果项目一开始就不应该做，就算不做开发前的完整全面的设计，这种敏捷真的有效吗？

InfoQ：你在解决方案课上描述了故事映射（Story Mapping）。它不也是问题空间的一部分吗?

McDonald：不是的。

你需要对要满足的需求有一个清晰的理解才能专注于特定的流程、产品或者功能，然后才能使用故事映射来理解它们。如果你想用故事映射来尝试理解问题，那么你就陷入了为了描述问题而创造的解决方案当中，这样的话，很快就会面临上述的风险。从清晰地理解需求和知道怎样才算满足了需求（最好是通过可衡量的目标）出发，再使用故事映射来探索不同的可选方案。

最初，Jeff Patton 将故事映射描述为一项有用的启发技术，用于理解具备大量用户交互的解决方案。创建故事映射能指引团队讨论业务流程，识别关键活动（以特性的形式）并将它们按照逻辑序列进行排序。

有许多场景，解决方案并不是内在地支持单一流程或者逻辑的步骤并不清晰。但是在这些场景下，故事映射仍然有用，能让功能和用户故事的关系可视化，也能展现出针对某个特性的用户故事何时能够交付。

InfoQ：你认为前端设计是分析的一部分吗？

McDonald：我也不太拘泥于某事是设计还是分析，因为我发现斤斤计较随意的分类并没有太大的用处（另一种形式的简洁）。

当然，在与项目相关者和用户交谈时，绘制用户界面原型能够帮助他们确定希望通过系统收集、记录和展现什么信息。例如，通过讨论我应该为给定的窗体绘制哪一种 UI 控件（单选框还是复选框，还是下拉列表等等），我能识别出与解决方案相关的业务规则。

用户界面是一个有用的启发工具，因为大多数项目相关者都熟悉它们并且与它们相关。将绘制用户界面作为讨论的一部分，我们可以得到额外的交流渠道，更可能建立共识。

InfoQ：维护最新且有用的项目信息相当难。对此你有没有一些技巧可以和观众分享呢？

McDonald： 我喜欢使用系统文档的概念来持续地维护项目信息。系统文档是关于已构建的解决方案的信息，并作为未来维护或更新工作的参考。它是基于系统功能而不是对系统进行更改的时间组织的，从而使维护解决方案的人更容易快速地找到他们需要的信息。

虽然解决方案本身（和针对它的测试）可以提供大量的信息，但总会需要额外来源的信息，特别是对于不明显的方面。这些信息可以有多种形式，但我通常 喜欢使用下列形式的组合：

• 术语表：系统运行领域常用术语的定义
• 业务规则目录：规则描述。它没有表明规则是怎样实施的（这些信息通常标注在其它制品之中或通过测试来表述）
• 元数据：关于数据的数据，描述了系统收集、存储和提供哪些数据
• 处理流：系统支持的业务流程的描述
• 用户界面：幕后操作的描述或与用户界面相关的业务规则的实施的描述
• 权限：描述哪些角色可以执行系统中的哪些功能

只要系统还在维护和更新，系统文档都是有用的。广义而言，这适用于由 IT 部门构建或实施的大多数系统。如果系统不是由原先构建它的团队维护和更新，系统文档尤其有用。即便是由同一个团队来构建和维护，系统文档也有它的价值，在解决方案的预期寿命很长的情况下（比如，超过一年），更是如此。

创建系统文档都有一定的目的，如果知道了这个目的，那么我们就可以根据这个目的来组织文档。就系统文档而言，我们希望它反映的解决方案的当前状态和构建的一致，并且希望它以直观的方式组织——最可能的方式就是根据解决方案本身来进行组织。

关于受访者

Kent McDonald帮助组织理解和解决所面临的问题。他活跃于业务分析和敏捷软件开发社区，帮助人们分享一些有行之有效或无效的故事。他是敏捷联盟会议提交系统的产品负责人。他写了一本新书《Beyond Requirements:Analysis with an agile mindset》。

查看英文原文： https://www.infoq.com/articles/analysis-techniques-product-owners

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。