大家好，这里是 TCC 翻译情报局，我是张聿彤。当我们研发一个产品时，从愿景出发，制定目标，再到项目落地，根据项目体量和企业规模的不同，项目的实施流程跨度可以从一年（小公司项目）到100年（亚马逊蔚蓝计划）不等。这时为了从宏观角度清晰的对项目整体有一个清晰的认知，尽可能规避风险，最高效的利用现有资源，就需要制定产品线路图。产品线路图将产品生命周期数据化可视化，从研发，市场，合作伙伴等不同背景的部门分析产品进度和状况。本篇文章详细分析了如何制定产品线路图，对于那些还在创业阶段的创始人，在推进项目的项目经理会有一定启发和帮助。
建立产品路线图有利于管理产品生命周期。然而，我们需要系统的解决这一问题：如何正确的绘制路线图，是非常必要的。虽然根据愿景来建立路线图是非常必要的，但是我们要避免将路线图与愿景混淆。
本文中，我们将重点介绍一些数字系统，这些数字系统可以帮助您了解现在要构建的内容、要跳过的内容以及以后要保留的内容。路线图的规模和局限，如何从愿景中提出解决方案/功能，软件产品线路图的举例，如何为产品集资，如何对它们进行整理和优先排序如何计算特征的权重值，以及公式和计算示例。
这看起来是一个篇幅较长的文章，但我认为，保留文章的主要思想在阅读过程中会是一个加分项。
联合国的座右铭是“放眼全球，立足当地”。
有趣的是，当这句话放在给一个好的软件产品创建线路图时也同样奏效。为了完成这一任务，你需要有一个全球视野，这样期望与计划就不会在开头就很快落空。作为愿景的一部分，确立的目标应该是全面整体的，并且应当由线路图推动落实。当你由线路图引领前进时，项目立项就是这一阶段的 里程碑和行动的重要阶段，开发产品的具体步骤的体现。
这对于每个人来讲是不同的，对于初始者来讲，最好把企划限制在六个月以内。如果你确切知道产品将如何落实，那么时间甚至可能在 3-5 年。所以没有具体的界限。
例如，亚马逊的创始人 Jeff Bezos 最近发布了一项名为 蔚蓝起源 的项目，而这项目的计划展望期则在 50 年-100 年之间。
也就是说，一个人创建了一家公司，在他有生之年的大部分时间里都在工作。这怎么可能？
在这种情况下，我们讨论的是一种 全球愿景 —— 蔚蓝起源计划要为频繁的太空飞行给予可能性。Bezos 声称亚马逊一直依靠其现有的邮递和快送框架。没有这些，亚马逊不能如此成功。而今天，蔚蓝起源项目计划创造未来太空旅行的框架、火箭、太空站、人造卫星、轨道站等等。而蔚蓝起源在 2025 年的全球计划就是制造太空飞船。
理解全球计划有助于绘制线路图，我们在其中展示具体的步骤，制定一个真正的计划，以便在短期内实现我们的目标。而蔚蓝起源，对亚马逊公司来讲是一个雄心勃勃的企划，企图实现他的任务，整合一个全球性的组织为客户提供能够承担的起的服务和货物。
我们来思考一下贴近生活的真实案例。如果一家建筑公司要进行高质量发展，那么他们要做的工作可能看起来是这样的：
好了，现在我们来看我们更熟悉的商业板块。
软件路线图包括多个版本，每个版本都必须包含某些功能。考虑到可用的机会和资源（稍后详述），按日期绘制路线图 非常重要。例如，这是一个社交应用程序的路线图。
请记住，线路图的绘制需要同时考虑到所有部门。如果一家公司规模很大，而销售经理手中也掌握着这份图纸，那么你需要将图纸和发展部门建立联系。不然，当来到时间节点时，例如，要在亚洲市场对一个产品进行营销的时候，你也许会发现你们没有做好本土化，没有中文支持。现在你看到了一个公司的垂直分布有多重要。而路线图就是愿景和使命的反映。
关于产品中应该有哪些内容的需求来自于不同的群体。我们在之前的一节中已经讨论过这个问题。这些需求需要被细致的管理和计划。重要的是要明白一点，准备好的和已将发行的第一个版本可能行不通，因为实际上没有足够的资源来落实所有的想法（ 如果你没有发生这种情况，那么说明你想的还不够多 ）。
通过正确的途径，线路图可以将产品的开发分成不同的阶段并根据优先级和重要性在迭代中推进功能性。
我们来看另一款管理软件开发的产品的 开发框架 ：
根据此开发框架管理进度的公司的业务熟练程度评估在下表中有所显示。未来我将列举一个 产品成熟度矩阵，在那之前你可以在这里参考阅读。
当公司细致的根据产品路线图度过准备阶段，那么他们就进入了业务成熟的第二个阶段：
对于我们自己来说，我们能承载的仅仅是在软件开发中正常的开发步骤，当建立这些过程的时候，公司本身还要通过传递更好的产品来完善公司的文化。而产品线路图正是文化中的一部分。同时还要记住，线路图并不只是一份承诺文书，它还是调整利益相关者的 沟通工具。
当我们从多方收集到不同需求时，他们需要被系统的规划起来。例如，Acronis（瑞士一家科技公司）使用的 Jira，一种非常强大的工具。但是对于初学者来讲，我们可以从更简单的入手，包括一些免费的软件，例如 Redmine 或者 Asana。
最主要的是，需要记录下所有的点子，因为没有想法是糟糕的。如果一个想法还没有成熟到可以执行，那么它的优先级就是靠后的，因而，每一个提议都有必要被纳入系统，即便它们不具备该如何施行的细节。
只有用这样的方式你才能做出受欢迎的功能 —— 即制作真实的线路图。所有的想法都会变成所谓的“输入积压”，他们既可以是完整的也可以是完全没有被加工的，不需要有所谓的评估或理解哪些用户需要这些功能。当需求清晰明了并添加适当的细节，有些想法也许会直接进入到上线阶段，而剩余的可能会被送回“储备端”并存留相当长一段时间。
敏捷或 Scrum 法包含着一个词“Epic”。如果我们尽可能简单的解释它的本质，那么我们就要讲到一些大的特点，需要所有人都参与才能推动落实 —— 开发者、测试者、界面设计师、技术写作人员等等。
通常情况下，当创作一个长期项目时，从商业角度上看其重要性是被评估好的，人力开支，以及是否在近期上线或者放到后备储蓄中也是提前决策好的。
系统中已经被评估过的项目可以定为最佳优先级。例如，在 Jira 中，你可以评定“高级”、“中级”、“低级”三个优先级。但是，在 Acronis 中，我们在后续储备库中有成百上千个功能。这时，简单的优先级就无法满足我们的需求了。
功能打分是一个复杂的分数评定机制。这一想法的理念是 将所有影响开发的因素都放在一个独立的评估系统中。后续可以根据常规化的评分标准来决策是否应该将功能添加到即将上线的版本中，还是放弃继续完善。因而，正向的评分机制添加功能点，而负向的则相反（具有更高价值和更少的功能点）。
正向评分点包括：
负向评分点：
功能打分制的结果必须是数值。这并不是定性评估，而是一种等级评分，其计分的方法必须统一，且在某一产品的研发过程中被证实是重要的组成步骤。
得分是根据常规化价值，公司的市场目标，以及其他参数确定的。功能评分制中第一个要考虑的就是客户因素。所谓的消费者因素跟消费者群体大小和产品的紧急程度有直接关系。你可以参考下图的计算方式。
市场渗透的定义为，吸引新消费群体的可能性，以及你的规划如何拓宽基础消费群体。例如，对于无法吸引新消费者的功能，那么这一参数的评分可以设定为 0，而可以给你带来 500 个用户的功能，我们可以给 20 分。
下一个问题就是策略布局。首先，评估战略，你需要检验该功能是否有助于战略方向的发展。覆盖的领域越广，那么对应的分值也就越高。
收入就是一个可以落地的功能，可以提供的潜在利润。这一参数的预估范围取决于公司规模的大小、产品的功能，以及你的预估收入。下表是该指标的评分示例。
现在我们来讨论一下反响影响的因素，那些有着更少功能点但是更有竞争力的案例。例如，开发成本也可以固定在特定的范围之内，这完全取决于你在特定的功能上投入多少预算。
风险—— 这就是另一个角度了。你在评估中对项目的信心越少，风险就越高，那么功能评分中的标准价值就越低。
将所有上文提到的因素全部考虑在内，那么功能评分公示大概像以下这样：
在具体情况下，如果所有的预判都是客观的，那这是非常理想的。但是如果你才进入市场，并一定要使用功能评分机制。那么就算是主观的判断也比什么都没有强。
如果我们要给这个产品的一下功能进行排列，
那么任务优先级表格大致是这样的：
在具体情况下，如果所有的预判都是客观的，那这是非常理想的。但是如果你才进入市场，并一定要使用功能评分机制。那么就算是主观的判断也比什么都没有强。
如果我们要给这个产品的以下功能进行排列：
那么任务优先级表格大致是这样的：
让我们来思考下“在预定时间内预定出租车”这个功能。如果将所有参数加起来，我们会得到一个数字“56”。这个是什么意思？
啥意思也没有！
这是一个相对评级，我们需要把所有 9 个功能全部算进去，并根据相同的规则和等级打分。而结果就是一份优先级清单。在我们的应用中，我们需要在安卓系统中开发一款移动应用程序。而第二个行动就是“初级+”关税。
一个系统的处理方式能够让你在商业层面避免做一些无用功，并且在执行的过程中避免选择一些无用随意的功能。而这种循序渐进，分段式的工作方式会给你更高的回馈。而在每一个项目的开发过程中都有很多约束和限制：时间、成本、价值等等，这些因素结合起来会决定你最终成品的质量。因而这非常重要。
并不仅仅是优先级！！！当计划即将上线时，必须要考虑到开发团队的能力。有些产品可能包含以下几个命令。例如，开发一个出租车预定的服务系统，至少应该有后端、QA、Android、iOS 命令。
但是除了优先级以外，我们必须要计算开发者在下一个功能上能够贡献多少时间。为此，你需要大幅增加团队中的人数以及为其分配的时间。还要了解可以用于下一个阶段能用到的人力，以此避免资源浪费。
不同团队能力与上线之间的关系图：
如果你仔细研究下方图表，你就能清晰的了解一个 ios 移动端的应用需要耗费多少资源，而这不仅仅限于 ios 开发团队，还有后端和 QA 专家。这就是为什么管理层决定在第一个版本中不包含适用于 iOS 的移动应用程序是合理的，因为团队并没有时间完成这一任务，而是搞定“在预定时间订购出租车”。
因而，如果按照优先级分化顺序来搞定功能，那么一个预定出租车功能的开发线路图看起来是这样的：
每个更新版本都将包含下一个优先级功能，这些功能也在开发团队的能力范围之内。
有一点我们必须要铭记的就是，线路图并不是一个保证，但是更像是预判。我建议将路线图视为当前计划。一个月后，一个新客户可能会来要求一个新功能。而当我们把它添加到后续储备库时，它可能比之前我们所有的规划享有更高的优先级。大致的规则就是，当开发一个产品的时候，全程使用线路图是非常必要的，但是你不能让它一成不变，因为今天你需要适应不断变化的市场。
对于那些有线路图的提案项目（根据基本规则给上线功能排序优先级），内部文化是有必要的。所有的利益相关者必须按规定遵循相同的打分标准，因而第一步就是商讨计分公式并遵循规则。当然，在理解了如何完善优先级的条件下我们可以接受变动，但那样的话就必须重新计算整个后备系统中内容的优先级。
对于大型产品来讲，需要根据能力给不同的团队分配任务，而不是直接根据功能的开发来决定团队任务，是非常有必要的。例如，开发团队的领头人可能会告诉你，我们需要移植到新的 python 上，不然我们会花费更多的时间（财力）在现有的生态系统，旧版本上。为了解决这样的问题，例如，你可以将团队 25% 的精力放在能够吸引新用户的功能上，45% 的经历来维护现阶段用户，20% 则用来解决技术难题和架构重组上，剩下的 10% 则作为缓冲，为产品开发中的其他事项留出空间（部署新的构建系统，实施 CICD，等等）。你可以阅读更多有关技术赤字的内容。
要成功的规划产品开发并适当调整线路图，你需要定期核查后续储备库并随时为你要卡发并计划上线的功能重新计算功能打分。但如果下一个上线日期已经规划好，那么就有必要在管理者和开发者之间建立联系。
在未来即将发布的文章中，我会搜集更多有关基于 KR 的产品线路图，多种优先级排序的方法，以及成功线路图的指标。当然，我们也会涉及到以下话题—如何把握功能评分制的反馈和变化，以及若不能为功能给出相关评分我们该如何继续。
此处引用一句话进行结尾：
“人们认为专注意味着对你必须专注的事情说是。但这根本不是它的意思。这意味着对其他一百个好主意说不。你必须仔细挑选。我为我们没有做过的事情和我做过的事情一样感到自豪。创新是对 1000 件事情说不。”
——史蒂夫·乔布斯
原文作者：Dr. Hakan Mutlu Sonmez（本文翻译已获得作者的正式授权）
原文：hthttps://medium.com/@h_17318/how-to-create-product-roadmap-and-how-to-prioritise-solutions-2ac2b5698fed
译者：高畅；审核：李泽慧；编辑：孙淑雅、李莉好；微信公众号：TCC翻译情报局（ID：TCC-design）；连接知识，了解全球精选设计干货。
本文由@TCC翻译情报局 翻译发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。