如何创建产品路线图／Roadmap？

　　笔者根据自身学习和实践经历对Scrum框架的流程做了总结，共有7篇，本文是Scrum框架的第2篇：建立产品路线图。 　　 　　笔者根据自身学习和实践经历对Scrum框架的流程做了总结，共有7篇。做这个总结的原因，一来是想梳理出一个可以帮助新人将Scrum落地执行的实践手册，二来是想通过分享自己的经验引发大家的思考并指正笔者的不足。本文是Scrum框架的第二篇：建立产品路线图。 　　 　　产品路线图是产品需求在时间轴上的总体视图，它是产品需求与其完成时间的概览，可以使用产品路线图来对需求进行分类、排定优先级，然后确定发布时间表。产品路线图宏观的展示了产品的发展方向以及开发团队何时实现目标。有效的路线图不仅是一个强调产品发布和功能的时间表：它是一个动态的文档，产品负责人会在项目进行过程中根据实际情况不断更新，所以在创建产品路线图的初期，对需求、工作量、优先级、完成时间的估算不要求也无法很精确，这些内容都是随着项目进行不断细化调整的。 　　产品路线图是产品负责人推动项目发展的重要工具，它告诉我们每个阶段应该做什么。在下图中，可以看到两个并行的产品路线图涵盖了12个月的开发时间范围。产品路线图的第一行是时间轴，第一列是项目名与版本号，版本号与时间轴的交叉点描述的是对应的版本涵盖的功能特性。这样就能直观的看到，要在什么时间做哪个版本，以及该版本所含哪些功能了。 　　 　　如果产品负责人计划在2017Q2末期启动设计进程，那么就在二月时知道是时候开始考虑设计所需的开销和资源。有了这个远见，就可以提前开始去实施这些计划，以便资源能够及时地准备好并保证任务的完成。简言之，产品路线图应该能够让产品负责人和项目团队长远地了解产品计划，并提供关于实现这些目标和时间节点的指导。 　　的服务对象可以是某个单一产品，也可以是一组产品。 　　 　　 　　产品愿景由许多产品特性所构成，产品的需求分为内部需求和外部需求，内部需求来自产品战略，外部需求来自市场调研，具体方法这里不展开讨论。在产品路线图中显示出的需求可能存在不同的层级：主题和特性。主题是需求的逻辑上或业务流程上的分类，特性是指某一具体的功能。比如在设计工具Sketch中，编辑属于一个逻辑上的分类，编辑就是主题。而对图层进行放大、缩小、合并等具体功能，就属于特性。因为放大、缩小、合并等功能从逻辑上分类都属于对图层进行编辑，所以特性和主题是从属关系。总之，这一步要求产品负责人和项目团队梳理出并确定产品需求（主题和特性），创建最初的产品代办列表（Product Backlog）。 　　确认了产品的需求之后，需要对需求进行整理归类，即：按业务流程或功能逻辑把这些需求分成特定的主题。对需求分组时要考虑的问题包括：产品的使用方式和使用流程？哪些特性是客户要连续使用的？哪些特性是用户低频使用的？提供某一特性后，会对用户的使用造成什么影响？项目团队能否识别出需求的技术相似性或依赖性？用这些问题的答案来确认产品应有哪些主题（分类），然后根据这些主题把特性归类。 　　 　　上图是用MindManager梳理需求的一个例子，文件管理是一个主题，属于这个主题的特性有：文件导入、文件导出、文件保存和文件删除四个特性。当然，也可以用Excel进行 梳理。 　　大致估算实现需求所需的工作量，并且对产品需求进行优先级排序。为需求的价值和工作量估算或者评分是对需求排序的第一步，也是关键的一步。 　　第一步，评估每一项需求的价值，并进行量化（给需求的用户价值和商业价值打分） 　　在评估需求的优先级时，可以根据自身能力和资源选择合适方法。因为我做的是智能硬件的而不是纯互联网产品，所以在项目的概念验证阶段，会通过面对面访谈和问卷的形式进行目标用户调研并建立用户画像。然后对用户画像进行优先级的初步排序，优先级高的用户画像中的需求一般优先级就会高于其他的需求。还要考虑需求的商业价值、研发成本、紧急程度、与产品目标的契合程度，还可能用到马斯洛需求层次理论、KANO模型、雷达图等。 　　总之，对需求的价值有了判断之后，要和项目干系人确认并获得支持，一定要把需求的价值进行量化，给需求的价值打分，这里的分值只是相对分值。 　　*篇幅所限，评估需求优先级的方法在本文中不详细展开，因为重点是讲述敏捷框架，这里只做简单概述，如果想了解的人比较多，后面会单独写一篇* 　　第二步，评估每一项需求的工作量，并进行量化（给完成需求的难易程度打分） 　　这里需要获得开发团队的支持，由他们来判断完成每项需求所需要的工作量。和需求的价值量化一样，需求的工作量也是相对的，选择一项团队认为工作量适中的需求来评分，然后将这项需求作为参考系，再通过判断其他需求与这项参考系需求在实现上难易程度的差距，进而得到对其他需求的工作量分值。估算的准确性，基本上取决于开发团队的经验和能力。 　　这里经常用到的方法是斐波那契数列方法，斐波那契数列又称为黄金分割数列，指的是这样一个数列：1、1、2、3、5、8、13、21、…，这个数列从第三项开始，每一项都等于前两项之和，随着数列项数的增加，前一项与后一项之比越来越逼近黄金分割的数值。开发团队中的每个人用斐波那契数列中的数字给主题或特性打分，先就一个参考系需求的工作量达成一致，然后每个人再根据参考系需求来为其他的主题或特性打分。 　　比如开发团队就“放大”功能的工作量达成一致为5，那么“缩小”功能的工作量也会是5。当开发团队成员给出的分数存在很大差异时，最好让打最高分和打最低分的人说明原因，可能是对需求的理解出现了偏差，这时要进一步细化需求，让开发团队明确功能后再次重新打分，如果这次分歧不大，那么出现频率较高的分数即可作为最终分数。 　　第三步，确定需求的相对优先级 　　相对优先级是指一项需求相对于其他需求的优先程度。相对优先级=价值/工作量。这个公式可以让高价值低工作量的需求具备较高的优先级，使低价值高工作量需求具备较低的优先级。这样用价值的分数除以工作量的分数就得到优先级的分数。确定了优先级的需求列表就称为产品待办列表，有了产品待办列表之后就可以向产品路线图中添加发布目标了。 　　第一次创建产品路线图时，产品需求发布的时间框架是比较粗略的，要思考一下路线图上各个分组的大致时间框架。然后为项目的发布选择一个合适的迭代周期（时间增量），比如一周、两周、一个月、一个季度或固定的天数。然后将产品代办列表中的需求分配到每个迭代周期中去。随着项目的进展，要及时更新产品路线图。 　　 　　上图为UXPressia在2017年底发布的产品路线图，UXPressia将迭代周期设为3个月：Q4 2017、Q1 2018、Q2 2018、Q3 2018、Q4 2018，然后将产品待办事件一条一条的分配到各个迭代周期中，产品路线图就这样完成了。 　　国外有很多专门制作产品路线图的工具，大多收费，这里推荐几个，感兴趣的同学可以自己去了解一下： 　　ProductPlan：https://www.productplan.com/ 　　RoadMunk：https://roadmunk.com/ 　　Trello：https://trello.com/ 　　Craft：https://craft.io/ 　　Aha：https://www.aha.io/ 　　如果发现本文有不足之处欢迎留言指正，如果对本文内容有疑问请留言提问，笔者看到会马上回复或者补充更多内容，谢谢。 　　敏捷实践01：如何确定产品愿景？ 　　  　　本文由 @ 少穻 原创发布于人人都是产品经理。未经许可，禁止转载。 　　题图来自unsplash，基于CC0协议