旅程映射:产品开发过程案例研究

支撑每一个成功产品的是一个成功的产品开发过程. 作为Toptal的高级产品经理, 我发现，把这个过程当作一个产品来对待，会带来可衡量的改进，触及我们工作的方方面面.

我领导的团队包括一个工程经理，九人 软件工程师，一名质量保证工程师. 我们的工作涵盖了广泛的产品和功能，促进了我们人才网络的健康供需平衡. 在接下来的部分中, 我将分享我们是如何利用客户旅程地图来改进产品开发流程并提高效率的, 沟通, 和协作.

当过程是产品时，团队就是用户

不成功或无效的产品往往是由一个团队造成的, 甚至是一个人, 认为 用户想要和需要的，而不是他们真正想要和需要的. 好产品, 然而, 是建立在广泛用户的定性和定量数据基础上的吗 研究 会话. 同样的, 如果领导者认为自己知道团队的需求，那么产品开发过程本身可能是不成功或无效的.

As 产品经理 或者团队领导, 你应该进行与产品跟踪相同的用户研究, 面试, 和你的团队一起进行调查，以确保你的过程同样成功. 目标是了解您的团队如何使用 产品开发过程 并解决他们在此过程中遇到的任何痛点.

构建客户旅程地图

收集用户反馈的方法有很多，但是 客户旅程地图 是我和工程师一起使用的产品发现技术吗. 结果是一个图表，说明用户在与您的公司互动时所经历的步骤, 无论是通过产品, 在线体验, 零售经验, 服务, 或者它们的任意组合. 用户拥有的接触点越多，地图就越复杂，因此也就越有必要.

这一技术通过探索用户的行为和情感来揭示痛点和机会. 这是发现过程中问题的极好方法.

在图中，用户被描述为假设的人物角色. 每个角色都应该有一个简短的个人介绍, 包括对他们的内在动机和责任的描述, 因为这有助于使他们人性化. 每个角色都应该代表一种关键类型的用户，以提供解决方案必须满足的各种需求.

旅程地图是按用户阶段组织的. 每个阶段都代表了用户在整个过程中试图实现的一个主要目标. 对于每个阶段和每个角色，让你的团队考虑:

• 动作:用户做什么?
• 情感:用户的感受?
• 痛点:困扰用户的东西?
• 机遇:有哪些可能的解决方案?

问团队“这个产品有什么困扰你的地方，我们该如何解决它??这并不是一个有用的收集信息的方法，因为, 在提问的时候, 他们可能不记得用例或者当他们遇到问题时的感受. 要求他们将交互分成几个步骤，并询问他们用户是如何遇到每个步骤的，这有助于团队表达与旅程每个阶段相关的情绪.

将这一理论应用于我们的整体团队

来理解这个理论是如何应用于实际行动的, 考虑一下我和我的工程团队创建的产品开发过程的旅程图.

使用 米罗, 我制作了旅程地图板, 将产品开发过程分为八个主要阶段:

• 路线图规划，并确定目标和关键结果(okr)
• 产品规格
• 技术分析和工作分解
• 实现
• 质量保证和用户验收测试(UAT)
• 预发布
• 释放
• 发布后的

我选择了两个角色——软件工程师和产品经理——因为他们是参与这个过程的主要用户.

• 软件工程师谢尔盖: Sergey确保计划按时、高标准地交付, 同时维护一个健壮的代码库，并了解最新的技术和工具.
• 产品经理马特: Matt确保团队优先处理最具影响力的项目. 他还倾听涉众的需求，并定期与团队沟通更新情况.

会议前, 我帮马特填写了旅行地图, 我的角色, 为了了解完成这个练习需要多少时间, 以及设定团队对格式的期望. 下一个, 我连续两天安排了两次90分钟的训练，以确保我的团队有足够的时间在不失去注意力和精力的情况下完成练习. 因为大多数工程师都不熟悉旅程绘图过程, 我分享了链接到米罗板和YouTube教程，以帮助他们准备. 在第一次会议开始之前，我确认每个人都理解了这些概念.

作为主持人, 我让团队提出行动建议, 情绪, 痛点, 也为谢尔盖的角色提供了机会. 一些团队成员一开始很害羞, 但有一次，几个人分享了他们的想法, 会议开始进行. 我根据他们的输入填写了米罗板上的卡片.

从旅程绘图过程中获得的关键经验

旅程地图绘制过程得出了五个主要结论:

1. 保持会议的简短和集中. 如果有多个阶段在 我建议将工作分成两到三个阶段来最大化 生产力和防止团队成员失去重点.
2. 做一个榜样. 填写 产品经理 泳道前的会话设置 诚实和开放的语气，并展示如何表达这些问题，鼓励团队 会员更容易分享自己的情绪和痛点.
3. 创造情感安全感. 团队成员可能会觉得分享他们的想法很吓人 挣扎——很可能是因为害怕被评判——但尽量不要干预. 迟早会有一个更勇敢的团队成员打破僵局，事情就会开始 移动. 当这种情况发生时，表现出同情和感激. 这将使其他成员国放心 他们在一个安全的环境中，他们会更舒服地分享他们的 的想法.
4. 和你的团队一起制定一个后续计划. 有些问题可能很难解决，尤其是 如果解决方案涉及其他团队或部门，但计划让您的团队更新 与可能产生影响的责任方的任何相关沟通或变更 旅程绘图过程的结果.
5. 以行动步骤结束. 创建一个行动项目列表，并指定所有者和截止日期 这将帮助你从会议中获得切实的成果. 举几个例子 我们案例的结果如下表所示:

​​

为什么旅程地图练习有效?

在展示潜在的改进机会和培养团队精神方面，旅程绘图工作非常成功. 它在以下方面帮助了我们:

1. 它揭示了我认为事情运行顺利的问题，并强化了不做假设的重要性. 例如，我假设每个人都有足够的培训 Jira但事实并非如此. 在光谱的另一端, 我认为要求工程团队为新功能录制演示视频会给他们带来负担, 事实上，他们很重视这个练习，因为它帮助他们提高了演讲技巧，减轻了他们在镜头前的焦虑.
2. 这说明我可以做一些改进, 例如重组计划封面，使其更易于工程师访问.
3. 它授权工程团队对他们控制范围内的结果负责，因为他们是提出他们可以测试和进一步迭代的变更的人. 这主要是一个自下而上的过程.
4. 它揭示了痛点热点主要围绕路线图规划和实施.
5. 它通过承认共同的挑战，在团队之间建立了更牢固的工作关系. 例如，我们团队中的许多人认为他们是唯一在与 CI / CD管道 对于一个特定的子系统，事实上，大多数团队都在努力.

扩展的考虑

如果每个产品经理或 工程部团队领导 和他们的团队一起经历这个过程, 可能会出现一系列常见的问题, 指出应首先解决哪些问题. 团队应该遵循更新后的流程几个月, 然后必须再次访问反馈循环. 这个循环应该持续下去，直到产品开发过程变得自然和容易, 并支持用户构建高质量软件产品的需求.

就我的团队而言，我们的新流程在几个方面带来了切实的改进:

• 票务审核的平均时间减少了22%.
• 在过去的三个季度中，产品OKR完成率上升到90%以上.
• 针对高优先级bug的服务水平协议时间在100%的情况下都得到了满足.
• 没有由于部署问题而导致的发布失败.
• 发布后报告的bug的平均数量减少了37%.

如果你的团队参与了 建筑产品，那么你的过程应该受到持续的审查和改进. 如果一个函数没有很好地执行, 或者它的产品开发过程较弱, 这将影响最终结果. 当我在一个工程团队中使用这种实践时，它可以很容易地转换为 用户研究、设计、 UI / UX，以及内容团队.

你的产品开发过程是你最重要的产品. 使用这个练习来帮助完善它，看看它对你的团队制作的每个产品有多大的提升.