课程目录
1.产品经理和框架的角色
2.市场细分和竞争分析
3.用户角色
4.假设测试
5.产品定位
6.产品路线图 <-您在这里
7.开发要求起草
8.业务模型和业务-计划
9.财务计划和定价
-待续
制定路线图对于管理产品开发非常重要。但是，为了正确地制定路线图，有必要系统地解决这个问题。不要混淆路线图和愿景，这是非常重要的，尽管为了正确构建路线图，必须有愿景。
联合国的座右铭：放眼全球，就地采取行动。”有趣的是，在为优质软件产品创建路线图时，它也适用。为此，您需要具有全局眼光，以便您的愿望不会在此刻结束。在愿景的框架内，设定了目标-它们也是相当全球化的，路线图应该针对这些目标。当您按照准备好的地图进行移动时，发布将成为此移动的里程碑和阶段-产品开发特定步骤的体现。
您应该如何规划？可能会有所不同，但一开始最好将自己限制为6个月。如果您确切知道产品的移动方向，则可能是3年或5年。没有限制。例如，在他最近的演讲中亚马逊创始人杰夫·贝佐斯（Jeff Bezos）宣布了“蓝色起源”太空计划，该计划的规划期限为50到100年。也就是说，一个人创建的公司将在他的一生中大部分时间都在工作。这怎么可能？
只是在这种情况下，我们正在谈论全球视野-蓝色起源必须提供激烈的太空飞行的可能性。贝佐斯说，亚马逊依靠现有的快递和邮件基础设施。如果不存在，亚马逊将无法工作或变得如此成功。今天，蓝色起源计划为未来的太空旅行创建基础设施-火箭，太空港，卫星，轨道站等。 Blue Origin的全球目标是到2025年建造一艘宇宙飞船。
了解您的全球目标有助于制定路线图，在其中显示具体步骤，并制定切实可行的计划以在不久的将来实现既定目标。作为一家有雄心勃勃计划的公司，Blue Origin正在努力履行其使命-组织全球服务，以方便人们和货物的移动。
从天堂到地...
考虑一个更现实的例子。如果一家建筑公司从事高质量的建筑，其工作理念可能如下所示：
●愿景-在莫斯科北部（SAO）建造最佳住宅区。
●目标-5000套公寓，现代建筑，一流的舒适度，便捷的布局，无车庭院。
●路线图-开发和美化队列。
●发布-混凝土成品建筑物，道路，公园（在完成阶段可以划分）。
●功能-版本的组件。例如，操场，植树，有盖停车场，坡道。
如何创建软件产品路线图？
该软件路线图包括发行版，每个发行版必须包含某些功能。考虑可用的功能和资源，按日期计划路线图非常重要（稍后会详细介绍）。例如，这就是其中一个社交应用程序的路线图。
请记住，应该立即为所有部门计划路线图。如果公司规模较大且销售经理有自己的路线图，则需要将其链接到开发部门的路线图。否则，例如到了在亚洲市场上推广产品的时机，您可能会发现您还没有现成的本地化语言……实际上还没有中文支持。
对产品中应包含哪些成分的要求来自许多不同的领域。我们已经在之前的一篇文章中谈到了这一点。...他们需要精心组织和计划。重要的是要理解，不可能准备和发布1.0版中的所有功能，因为实际上没有足够的资源来实现所有想法（如果不是这种情况，那么您的想法就很少，您需要考虑更多）。
使用正确的方法，路线图是将产品开发过程划分为多个阶段并在迭代中降低优先级和重要性的同时推出功能的机会。
让我们看一下另一个控制软件开发的软件产品开发框架（Software Product Management Framework）：
下表确定了在特定框架下生存的公司的成熟度矩阵。而且，如果您正式遵循路线图的准备过程，则公司会立即达到第二个成熟度级别：
通常，此框架是产品开发任何课程的独立分支。我们现在不再赘述。如果有人有兴趣阅读有关此主题的其他文章，请对此文章发表评论。
在这里，对于我们自己，我们将只接受，如果在软件开发中遵循某些正式程序，同时构建这些流程，则公司本身会改善提供更好软件的文化。路线图是这种文化的一部分。
如何收集和处理产品需求？
当我们从不同方面收到需求时，需要将它们输入某种系统中。例如，Acronis使用了Jira，它是一个非常强大的工具，但是对于初创公司，您可以使用简单的公司，包括免费的公司（例如Redmine或Asana）。
最主要的是，所有想法都已注册，因为没有不好的想法。如果该想法尚不值得实施，那么它的优先级将保持在较低水平。因此，即使没有详细描述“它应该如何工作”，也必须将每个句子输入系统。只有使用这种方法，您才能计划所需功能的实现-即创建真实的路线图。
所有想法都被归结为所谓的“传入积压”，它们可以被形式化或“原始”化，而无需评估和了解谁需要这些功能。在解决了请求并添加了详细信息之后，其中一些可以转到下一个版本。其余的将发送到待办事项列表，我可以在这里待很长时间。
史诗
敏捷或Scrum方法论蕴含着“史诗”之类的术语。为了尽可能简单地解释其本质，我们在讨论一些重要功能，其实现需要所有参与者（开发人员，测试人员，界面设计人员，技术作家等）的参与。
通常，创建史诗时，会从业务角度评估其重要性，计算人工成本，然后决定是将其包括在当前版本中还是将其发送到积压中。
对于已经分级的史诗，您可以在系统中分配优先级。例如，在同一个Jira中，您可以设置“高”，“中”或“低”。但是，例如，在我们的Acronis积压订单中，有数百甚至数千个功能。在这种情况下，简单的优先级是必不可少的。
计算特征分数
一种更复杂的评分方法称为功能评分。这个想法是将所有影响发展的因素归为一个单一的等级。然后，基于归一化的等级，做出有关在发布中包含功能或暂时放弃开发的决策。因此，积极的指标会为要素添加点，而消极的指标则以相反的比例起作用（更多的值-更少的点）。一些积极的指标包括：
1.紧迫性。
2.需要它的客户规模。
3.由于新客户的出现，市场份额不断增加。
4.离开现有客户的潜在损益。
5.战略成就（使我们成为愿景的体现的目标）。
负面指标：
1.人工成本。
2.潜在风险。
功能得分必须为数字。这不是定性评估，而是某种等级，其计算方法必须在开发特定产品的框架内统一并批准。
积分是根据标准化值，公司的市场目标和其他参数确定的。 “功能评分”中考虑的第一个参数是客户因素。所谓的客户因素定义为紧急程度和客户规模的乘积。您可以在下图中看到一个计算示例。
市场渗透定义为吸引新客户的可能性，取决于您扩展客户群的计划。例如，对于那些不会吸引新客户的功能，此参数可以等于0，对于那些可以给您带来500个客户的功能，该分数将为20。
下一个问题是策略合规性。要评估该战略，您需要检查该功能是否有助于您沿着战略发展方向发展。并且它覆盖的方向越多，得分将越高。
收入是功能实现可以提供的潜在利润。此参数的估计取决于公司的规模，产品的特性以及您期望获得的收入。下表显示了此指标的评分示例。
但是，现在让我们来谈谈相反的因素，这些因素给一个要素的得分越少，体现的就越多。例如，您的公司的开发成本也可以固定在某些估算水平，具体取决于您愿意花多少钱开发某些功能。
风险是第二个方面。您对评估的信心越低，风险越高，这意味着功能得分公式中标准的值越低。
在考虑了所有提及的因素之后，“特征分数”公式可能看起来像这样：
如果分数基于特定因素是客观的，那是很好的。但是，如果您只是进入市场，仍然要进行功能评分。总比没有主观更好。
出租车应用程序示例的路线图
在先前的一篇文章中，我们已经讨论过创建用于呼叫出租车的应用程序。假设我们需要对该产品的以下功能进行排名：
具有优先级的表可能如下所示：
考虑“按时订购”功能。汇总所有参数，得出56。这个数字是什么意思？没有！这是一个相对等级，我们需要计算所有9个功能，并遵循相同的标准和等级。结果是优先级列表。在我们的应用程序中，我们显然需要在Android上制作移动应用程序。第二步是“儿童”关税。
系统的方法不允许执行对业务不那么重要的事情，也不允许选择“随机特征”进行实施。分阶段和分阶段工作的回报会更高。这一点非常重要，因为每个项目的开发始终会受到约束：时间，成本，数量。两者的结合为您提供质量。
不只是优先事项
发布计划考虑了开发团队的能力。一些产品具有多个这样的命令。例如，要创建出租车订购服务，至少应该有后端，QA，Android，iOS命令。
但是除了确定优先级之外，我们还必须估计开发人员可以分配多少小时来处理每个下一个功能。为此，您需要将团队中的人数乘以为其准备工作分配的天数。了解下一个版本（作用域）的可用容量将有助于避免浪费资源。
一个发布周期内不同团队的能力：
如果您看下表，您会发现，iOS的移动应用程序需要大量资源，不仅iOS开发团队，而且后端和质量检查专家也需要大量资源。这就是为什么管理层决定在第一版中不包含iOS移动应用程序是合乎逻辑的原因，因为该团队无论如何都没有时间制造它，但是另一方面，他们将在“正确的时间完成出租车订单”。
因此，如果我们按照所有已排序功能的优先级排序，那么通过订购出租车来开发应用程序的路线图将如下所示：
每个后续版本都将包含下一个优先级功能，这些优先级功能将由开发团队承担。
路线图-作为产品开发理念
请记住，路线图不是承诺，而是预测。我建议将路线图视为当前计划。一个月内有一个新客户可能会要求新功能。当我们将她添加到待办事项列表中时，她的优先级可能会比以前计划的要高。通常，在产品上工作时，重要的是要在每时每刻都有一个路线图，但是您不应使其保持静态，因为今天您需要适应不断变化的市场条件。
路线图的拟议工作（根据一般规则对功能进行优先排序）需要一种内部文化。所有利益相关者都必须遵循相同的评分原则，因此第一步是讨论计算公式，然后遵循此规则。当然，如果了解如何改善优先级，则可以更改所有内容，但是有必要重新计算整个待办事项的优先级。
对于大型产品，建议为与定制功能开发不直接相关的事情分配不同的开发团队能力。）在旧版本上维护现有的生态系统”。为了解决此类问题，您可以例如将团队能力的25％分配给与赢得新客户相关的功能，45％的保留现有客户，20％的技术债务和重构以及10％的留空作为缓冲，以便为功能留出空间。他们突然或间接地来负责与产品开发没有直接关系的活动（部署新的构建系统，实施CI \ CD等）。
结论
为了成功计划开发并调整路线图，您需要定期查看积压的积压工作，并重新计算您计划开发的功能并希望它们在发行范围内的功能得分。但是，如果我们已经决定下一个版本，则有必要在管理人员和开发人员之间建立交互。
为此，在下一篇文章中，我们将研究为需要提交给开发部门的功能创建需求的机制。这对于开发功能很有必要，最好以您希望看到的形式进行。我们将讨论为什么要弄清楚需求，应如何将需求形式化以及存在与开发人员一起使用需求的实践。
→可在YouTube上观看课程所有讲座的录像
关于路线图和开发要求的讲座：