分布式团队产品开发-InfoQ

本文要点

了解如何在分布式团队进行各项与产品开发相关的活动。

理解分布式产品开发所面临的问题，这些问题就是我们所面临的挑战。

了解远程团队开发产品需要的基本“品德”。

了解多个进行用户调查、产品愿景、故事映射、backlog 细化和计划会议的在线工具。

提供分布式产品管理的实际案例。

现如今许多组织中都存在分布式团队。由于公司是全球性的，现代化的通信手段可以让人们不拘泥于在“办公室”工作，许多新的劳动力因而会选择游民化的工作方式。分布式团队要成为高绩效的团队是非常有希望的，只是需要付出更多努力来克服距离带来的内在挑战。

这篇文章是系列文章《分布式敏捷：如何与分布在全球的团队合作》的第一篇，这一系列的文章对文化差异给分布式团队带来的影响进行了探讨。你可以通过订阅 RSS 接收通知。

在如今全球化趋势增长的大背景下，应运而生了分布式商业模式。在世界各地我们都能找到应用分布式模型工作的人，但同时，分布式团队在日常活动中确实会遭遇许多挑战。

一方面，敏捷实施的基本原则是团队在同一地点工作。

“在同一个地点工作是关键。”

作为敏捷教练，我总是鼓励我的团队可以在同一个地点工作，因为

面对面交流比任何其他交流方式都好。

尽管大多数人都承认在同一个地点工作更方便，但现实往往截然不同。公司的办公室总是分布在不同地点，同时合作伙伴也遍布全球，因此执行项目的人必须找到最合适的远程合作方法。

我和其他三个人一起着手开发分布式敏捷框架，他们分别是： Hugo Messer 、 John Okoro 和 Arjan Franzen 。

我们还在初始阶段。我们认为把这个框架的大部分内容开源出来是有必要的。我们开发的框架包括八个“板块”：

文化
组织
产品
团队
架构
工程实践
沟通
工具

每个板块都有三个元素：

A、问题：组织可以用来评估当前状态的一系列问题

B、品德：促进分布式合作的行为

C、实践：已经完成的工作，由从业者进行分享的内容

在之前的文章中，Hugo Messer 和 John Okoro 介绍了有关组织和文化的内容。在这篇文章中，我将继续探索“产品”板块。

产品

什么是产品，我们要如何定义产品？不同的人对产品的定义不同，团队可以使用任何一种定义来解释他们的产品。敏捷联盟和Scrum 联盟创始人、顾问、书籍作者以及 Mountain Goat Software 创始人 Mike Cohn 是这样定义产品的：

通过特定过程创造的（可以是有实物的或没有实物的），并且能给市场带来好处的物品就是产品。

产品开发不仅仅要正确定义好产品，还要促进产品正确开发。要更好地理解你的分布式团队是否成功地管理好了产品的开发，你需要询问自己和团队成员以下几个问题：

问题

是否位于所有地方的团队成员都了解业务层面的产品愿景？
每个人对产品的定义都相同吗？
是否所有团队成员都参与到了制定产品愿景、创造路线图和 backlog 细化研讨会中？
产品愿景和路线图是否对无论在哪里的所有团队成员都可见？
是否所有团队成员直接与业务相关者和用户紧密合作？
我们的分布团队是否相当于多个跨功能、在同一地点工作的团队？

品德

为了有效地管理产品，我们开发了一系列品德。基于这些品德，帮助促进合作的分布式文化可以得到发展。

让所有团队成员可以和用户直接沟通
产品透明度：路线图、愿景和目标对所有人可见
从用户角度思考

我们在分布式团队中遇到的最大挑战之一，是和软件用户之间的距离太远，因此无法正常沟通。在传统模型中，项目经理与利益相关者和用户沟通交流，并将需求反馈给团队。在敏捷模型中，我们的理念是让利益相关者、用户、产品负责人和团队定期会面。正如 Spotify 和 Lego 的敏捷教练、作者和 Crisp AB 的共有人 Henrik Kniberg 在他著名的“简单描述敏捷产品所有权”视频中所述一样，理想状态下合作大约是这样的：

但是如果距离太远就不可行了。由于地域和时区的不同，产品负责人通常要兼任项目经理的角色。他们负责与用户和团队的交流，扮演“中间人”的角色。我们相信无论使用什么方法，保证团队成员定期与用户的沟通是非常重要的。

远程团队成员通常和在总部工作的成员待遇不同。他们不能享受午休时间、周五晚上啤酒聚会和喝咖啡聊天。他们也不能看到实物的产品路线图、愿景和策略等。尽管想象中可能很理想，现实中我们还是发现很多远程团队对他们正在搭建的产品完全不了解。产品透明度是说，我们需要使用在线工具、维基、白板、云端绘图工具将产品内容和分布式团队成员共享。这也就是说，非常有必要定期召集所有分布式团队成员来更新修改所有产品文档。

为了让开发团队搭建好的产品，他们需要充分了解自己在为谁搭建产品。他们需要从用户的角度来搭建产品。远程团队通常“仅仅搭建功能（由在很远地方的人发明的）”。产品经理可以有意识地让远程团队成员了解更多有关产品和用户的信息。团队可以使用研讨会、框架（比如精益创业）、交互和工具来更好地了解是谁在使用他们的产品，如何使用他们的产品以及为什么要使用他们的产品。

实践

有许多组织可以采纳的实践方法来帮助克服分布式团队产品开发带来的挑战。我根据自己曾经和几个团队的真实合作经验来介绍：

激发对产品的感同身受

要想让分布式团队有效地工作，同理心是非常重要的一个品德。几年前我为分布式团队开发了一个同理心计划。在文化方面的讨论中，我在“管理分布式团队的文化差异”一文中已经介绍过它的使用。该计划想要激发四种不同层次的同理心。现在说到产品这个方面，我们希望团队能表现得比较狂热，希望他们能热爱自己创造的软件。如果团队能没日没夜地考虑他们的产品、他们的用户以及需要做什么提升，那创业公司和（新）产品势必会成功。产品负责人可以通过像创业公司一样运作产品的方法来激发“对产品的感同身受”。如果可以清楚看到产品愿景和路线图，并定期和用户交互，那么团队成员能得到更多鼓舞。让他们去采访用户，让他们走出办公室，去街上观察软件的使用情况，让他们参加到用户出席的会面和会议。如果（部分）团队成员需要远程工作，那有意识地激发产品同理心就更加重要了，因为这些远程团队成员不能参加到总部的活动中来，少量的商旅预算以及强大的视频音频会议工具都能实现这一目标。用户与开发团队之间一个简短的Skype 通话，甚至可以让用户体会到与外国开发团队之间交流的乐趣。

分布式环境中的用户调查

产品成功与否取决于我们对用户需求的理解。如果团队在不了解他们的用户的情况下搭建产品，业务方面可能会发生很大的问题。

要建立对用户问题的共识，就需要邀请团队中的每个人参加会议。亲眼看到用户使用产品中遇到的问题可以激励团队中的人立刻针对它进行专门修复。

我特别喜欢 Christian Rohrer 的总结（如下表所示），他总结了一种三维决策框架，并列出了不同产品开发周期的不同内容。

如果团队是分布式的，你可以简单地远程操作用户调查活动，通过视频通话的形式进行远程可用性测试。你可以在Quicktime 录屏的同时观察用户脸部的反应。使用 ethnio.com 或 usertesting.com 这样的工具招募用户，尽可能快地让真实用户开始使用你的产品。利用好 Optimal Workshop 提供的树测试、卡片分类、调查等等。

远程团队也可以使用 Atlab ：Atlassian 的在线用户研究室，用于向客户以及非客户进行采访并进行可用性测试。这可以帮助创造用户的同理心，也能使设计团队汲取独特的洞察力，帮助产品变得更加可用、更加实用。

团队可以使用在线调查收集数据，比如说 SharePoint 调查、讨论板和社群聆听。在过去的几年里，许多公司使用互联网进行了各种各样的用户调查，以便进一步了解客户需求。在线调查和其他调查方式（如纸笔方式调查和个人采访方式）相比，能够更快地从受访者手中采集数据。

下面展示了旅游公司在线调查的例子。它包含了一系列了解旅客旅行计划行为的问题。

与整个（分布式）团队的产品愿景研讨会

在产品开发的最初阶段，团队和业务部门一起参加研讨会制定产品愿景。邀请位于任何地方的团队成员一起制定产品愿景是非常重要的，否则，成员永远不可能理解产品的目的。

最佳的业务选择是邀请来自世界各地的团队成员飞到一个中心地参与产品愿景的制定。如果有些人不能实地参加，可以用任何其他方法让他们加入到制定中来。

有些团队不喜欢邀请在其他地方的成员，因为他们习惯于在墙上贴即时贴来决定愿景，如果不把所有成员集中在一个房间内讨论，那使用这种即时贴的方法就会产生问题。在这种情况下，我建议使用在线板，比如 Realtime Board ，配合召开视频会议就可以和远程团队更好合作。

如果团队使用一些简单的技术，如 Elevator Pitch 或 Business Model Canvas，那每个地方的成员可以创造属于自己的愿景，并向所有人展示最终版本。然后在视频会议上讨论所有提出的版本，并从中挑选一个。

几年前我参与了一个新产品的搭建，一开始我们的团队就是分布式团队。我们做的第一件事情就是创造我们分布式团队的商业模式画布。我们团队分布在世界各地（两个人在荷兰的家里工作，四个人在印度还有一个人在土耳其）。每个团队成员通过观看商业模式画布的视频先做准备，大家都会记下有关画布上每个块的内容的笔记。我主持了会议，这个会议持续了约 3 小时。在会议中，我试着一个块、一个块地介绍画布，穿插引导所有团队成员的想法。通过了解商业模式画布，大家对于我们需要搭建的产品都有了深入的理解（我们改变了很多次产品需求）。我相信这是一个良好的开端，让整个团队参与到构想阶段，所以我们都能理解产品相关的想法、市场、现金流，而不仅仅只是知道“功能”的内容。我们的画布搭建在 Canvanizer ，如下所示：

在线用户故事映射

通常团队会使用用户故事地图做发布计划。用户故事地图中会排列好每个用户故事，形成的有用的模型可以帮助团队理解系统的功能，确定backlog 中的漏洞和缺失内容，并有效地计划整个发布过程，以确保每次发布都能向用户和公司交付有价值的产品。

用户故事映射研讨会非常需要合作，也是一个非常愉快的过程。团队需要每个人的投入，保证任何种类的功能都能添加到backlog 中，避免遗漏。

远程团队可以使用在线工具（如 StoriesOnBoard ）创造故事地图。我大多数时间都会推荐分布式团队使用这个工具，它非常有效，使用感就像在同一个地点工作的团队使用的实物的故事地图一样。下图举例介绍了使用 StoriesOnBoard 在线工具创造的故事地图。

定期和整个团队进行 backlog 细化和计划会议

只要是产品开发的成员，就需要和业务联络人员共同参加 backlog 细化会议。在 backlog 细化会议上，团队通常需要讨论以下内容：

理解用户故事
产品 backlog 排序
将较大的用户故事拆分为几个小的用户故事
编写验收标准
预估

非常明显，整个团队无论身处何地都需要参加这个列表内容的讨论。

要想在分布式团队顺利进行细化会议，和产品愿景制定类似，团队可以使用视频会议和在线板。除此之外，团队还可以使用在线产品 backlog 管理工具，如 Jira 、 Version One 、 Trello 等。

同样的，团队需要使用相同的在线工具和整个团队举行计划会议。

除了以上提到的实践，团队还应该重点关注以下的重要活动：

用户反馈沟通节奏：邀请用户参与产品演示，鼓励整个团队和用户沟通。或者拍下用户给出反馈、使用产品的视频，和整个团队分享。
使用像 confluence 这样的工具完整了解和你的产品相关的内容，比如愿景、目标、路线图、人物角色、市场营销资料等。
找出最适合举行产品回顾和计划会议的时间段。
Scrum Master 需要确保开发团队和业务代表之间的高效沟通。

请分享你是如何在分布式团队中开发产品的。

有关作者

Savita Pahuja拥有 Scrum、Lean、kanbanareas 和其他可视化探索方法的知识。她以一名开发人员的身份进入了 IT 行业，并帮助组织采纳了敏捷方法。之后她渐渐开始转型进入敏捷领域工作，担任敏捷顾问和培训师。自此以后，她帮助不同的客户采用敏捷方法，并进行 scrum 和 kanban 的培训。