创建敏捷产品蓝图的十个技巧

原文： 10 Tips for Creating an Agile Product Roadmap
作者：Roman Pichler，产品管理专家，有15年的产品经理培训经验，帮助很多公司提高了产品管理能力。
翻译：孙薇
责编：陈秋歌，关注前端开发、敏捷开发等领域，寻求报道或者投稿请发邮件chenqg#csdn.net。研发心得、项目实战、前沿技术、外文翻译……，只要是技术干货，十分欢迎投稿至chenqg#csdn.net。人人都是主编，这里就是你的舞台。

产品蓝图（Product Roadmap）是描述产品可能的发展方向，统一利益相关者的意见，计算产品开发预算的强大工具。但是，想要作出切实有效的蓝图并不容易，尤其是在意外变化频频的敏捷环境中。本文分享了在制作可执行的敏捷产品蓝图时能够利用的十项实用技巧。

1. 关注目标与收益

面对变化频繁的敏捷环境时，无论是因为产品较新，正在经历重大转变，还是因为有新的竞争者或技术出现，而导致市场变化频繁，我们都应当做出一份以目标（Goal）为导向的产品蓝图，这样的蓝图注重客户获取、市场占有率增长、避免技术债务（注：开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务）这类目标，虽然功能也是关注点，但并非第一要务——首要目标是蓝图的目标所派生出的那些。

为了协助大家作出敏捷产品蓝图，我创建了一个以目标为导向的蓝图模板GO Product Roadmap，其基础理念是：目标比功能更重要。这个模板共包含五个元素——日期、名称、目标、功能和指标，如下图所示。可以在romanpichler.com/tools下载免费模板，也可以在《The GO Product Roadmap》这篇文章中找到如何使用该模板的更多信息。

2. 完成必要的准备工作

在创建蓝图并确定战略的最佳实现方式之前，需要先对你的梦想实现之路——即产品战略进行描述与验证，如下图所示。

我喜欢用产品愿景板（Product Vision Board）来生成有效的产品战略，在上面记录愿景、目标群体、要解决的问题或者要提供的好处，产品的主要功能，以及商业目标。该模板可以免费在romanpichler.com/tools下载。

3. 讲述连贯的故事

产品蓝图应当能够就产品的成长讲述一个连贯的故事。每次发布都应当建立在之前发布的基础上，并向工作朝着愿景目标推动一些。要搞清楚对应的目标群体：内部产品蓝图面对的是开发、推广、销售、服务团队，还有其他推动产品成功的相关团队，而外部蓝图面对的是现有及潜在的客户群体。要保证蓝图切合实际，不要凭空猜测，也不要过分夸大产品。

4. 保持简单

避免添加过多细节，保持蓝图简单易懂。抓住真正重要的东西，专注于目标，省去其它。只在蓝图中记录大致的功能，并根据目标来细化。包括epics、用户故事、场景、UI设计等细节都属于产品backlog，不应当放在蓝图中，如下图所示。

5.确保蓝图获得高度认可

如果开发、推广和销售团队无法接受的话，即便最好的产品蓝图也是毫无价值的。而达成一致的最佳方式就是与主要的相关利益者合作来创建并更新产品蓝图。这样一来，就能利用大家的观点和知识，来创建大家都愿意接受的蓝图。组建协作构建蓝图的团队小组是个好办法，这样能让所有人都参与进来，以创建共享的产品蓝图。

6. 要有勇气说不

如果想要获得主要利益相关者的认可，就不能不加分辨地采纳所有的理念与请求，这样的做法只会让产品成为功能大杂烩，随机功能的合集。乔布斯曾有言：“创新并非采纳所有的功能，而是仅留最关键的功能，删掉其它。”根据愿景与产品战略来进行正确的决策，勇敢拒绝不必要的部分——要记得：合作需要领导力！

7. 了解何时该标注日期

有人建议不要在蓝图上明确日期，还有人建议要始终标注日期。本文的建议是：在开发、推广、销售与支持团队等内部利益相关者用以执行的内部蓝图上，标注上日期或时间表，特别是对于跟日期密切相关的产品，比如必须在圣诞促销前准备好上市的智能手机，或者必须在暑假开始前更新的旅游应用来说，日期是非常重要的。但对于经常用作销售工具，为客户和用户所提供的外部蓝图来说，本文建议不将日期和时间表放在上面，但可以标出发布的时间，按照距离现在还有多久这样的格式来排序。

8. 让蓝图可以衡量

在使用目标导向的蓝图时，请确保所有目标都是可衡量的，这样我们就能判断出某个目标是否达成。举个例子，如果你的目标是获取客户，那么可以给出具体要达成的新客户数量；如果你的目标是减少技术债务，那么就确定出应当删除或重写的不良代码数量有多少。

如果没有明确标注出目标，想要确定是否达成目标就会非常困难。不过，要确保这个目标是可以实现的，蓝图的总目标也是能够实现的，然后再选择能够帮助我们确定目标是否达成、发布的内容是否达到了预期效果的指标。

9. 采用自上而下的方式来确定成本

如果产品比较新，变化比较频繁，我们建议不要采用自下而上的方式，而要采用自上而下的方式来确定开发成本，想要从蓝图的功能中获得正确的epics和用户故事几乎是不可能的，应当让团队给出正确的估算，再通过产品backlog准确估算速度与变化率。否则，即便勉强通过自下而上的方式算出来了，最终的产品backlog也会因为过于复杂而难以调整，难以维护。而且想要将这些功能转化为定义清晰的需求，并据此得出详细的估算也很耗时，需要数日甚至数周的时间。

相反，我们可以确定要按期完成蓝图，需要拥有何种技能的人才多少，再根据开发类似产品或该产品之前版本的经验进行估算，考虑公司中具有合适技能的人才是否足够，还是需要再雇。这样，我们就能得出所需的大致人力成本，然后再加上设备、基础设施、材料、证书等相关内容所需的成本，就能与开发团队一同完成这项任务了。

10. 定期回顾审查，并调整蓝图

最后但并非最不重要的：如果处于敏捷环境中，很可能时有变化发生。因此，我们应当定期回顾审查，并更新产品蓝图，周期大概是每四周到每三个月，具体取决于产品有多新，市场变化有多频繁。

---

更多内容请关注CSDN敏捷知识库。该知识库包含了三大敏捷专家精心绘制的知识图谱，及由特邀编辑（领域专家）从海量数据中层层筛选出的精华内容和资源（学习视频、实践Demo、图书）。

扫描二维码，获取敏捷知识库全部内容

同时诚邀您参与敏捷知识库构建 提交优秀内容拿奖品