产品版本规划，敢不敢细点、方法论何在产品经理对于

产品经理对于如何做版本迭代计划，有时候总会有些无力感，要么是计划难以确定下来，要么是制定好的计划无法执行下去，这个问题产生的原因有很多。在项目初期，我们缺少对产品的全局概念和整体把握，内部意见很难统一；再者，没有一个完整的用户体验或者价值流导向，对于每个迭代无法合理定制出可交付产品增量。
之前我们讲过如何构建产品路线图，路线图可以给PO和团队整体方向的指导，但更具体的内容，需要用户故事地图的方式，通过横向的框架和纵向的任务，将一个产品完整的展示出来。然后，再通过故事点估算和优先级的排序，来确定版本迭代计划。
版本迭代其实是一个路线图，展示了将要实施哪些功能以及何时完成这些功能的期望。通常遵照团队自己的节奏，有的是一个Sprint 一个Release，有的将多个Sprint归为一个Release中，如下图所示。还有的在每个功能完成后立即发布，这也通常被称为持续部署或持续交付。

Release Planning根据产品开发的策略，它可以由功能驱动，目标是一旦开发出预期的功能模块就发布; 或者由日期驱动，过了预定的检查点就发布。
具体如何做呢？我们可以分这个步骤来完成。
Step1：创建用户故事地图
和客户一起，厘清产品的用户角色，并尽可能多地写出用户的行为，以及每个用户行为下需要做的事情，然后按照用户行为从左到右讲故事。当大家把自己所能想到的故事地图都放上去之后，再合并增减故事，最后会形成一个二维故事地图。

User Story Mapping

Step2：构建产品发布路线图
整个故事地图会包含很多创新点，但在一定时间完成所有功能是不太可能的，团队要综合考虑商业价值、市场现状、实现难度等方面因素，确定接下来几个发布的内容，以及每个发布预期能产生的成果。

Product Roadmap?Step3：快速估算
用户故事创建好后，我们可以对地图中的所有任务进行快速估算，以便于能够知道我们整个Release要发布产品的所需大概工作量。不同于Sprint中对故事的估算，这里更粗略更快速，可以用故事点或者T恤size（S, M, L , XL）来制订我们的估算标准。下图是Worktile敏捷估算小程序。

Step4：制定Release计划
前面工作完成后，我们对于整体产品和开发时间会有一个大概的估计，那么就可以设计Release计划了。我们可以按照我们的估算，设计一个Release需要发布哪些特性，然后包括几个Sprints，下图为Release计划示例。?

再将故事按照优先级和价值进行排序放回到每个Sprint里，可以借助Worktile敏捷工具，把右侧产品Backlog的内容，自由拖动到左侧的Sprint中。

Step5：进度把控
产品规划完成，进入到开发阶段，我们可以用故事板和燃尽图，把控每个Sprint的进度。

Worktile还有测试管理、持续交付、团队协作等多种产品，可免费试用→Worktile官网
■网友的回复
谢邀
可参考我的另一个回答
如何做好产品的版本规划？ 【产品版本规划，敢不敢细点、方法论何在】
■网友的回复
分享一个最近小组的版本划分的规则--------------------------------------------------------------------------------------------------------------------------------------------为了确保本组文档命名的正确性、统一性，确保各方面内容受到保护和修改控制，确保各项工作顺利进行，特制定本组文档命名规范，凡本组对外的文档均应符合本规范。文档一般有文档类型，名称，版本号三种方式的标识。标准如下：文档类型_系统英文名称中文名称_版本号eg.操作手册_XXX系统_V1.3名词解释：1、文档类型：表明该文档为何种类型的文档，例如PRD，BRD，操作手册等2、系统英文名称：除英文缩写组合外，英文单词都采用首字母或关键字母大写的方法版本号命名格式：主版本号.子版本号 eg. V1.3版本号修改规则:主版本号：1位数字，有项目上线，功能模块有大的变动，或者系统分为多期实施，每一期完成后主版本号递增。（当主版本增加1，子版本归0）子版本号：2位数字，有一个或多个小需求上线，功能有一定的增加或变化。与主版本相对而言，次版本号的升级对应的只是局部的变动。仅供参考！