产品规划，说容易又复杂。
容易是每个人都会有深度使用的应用，看多猪跑会有错觉认为自己也能养猪。复杂是它不是我们看到的一个个推送更新的版本，透过表层，内里是需要从高层的战略到底层的表现、从核心板块迭代到板块间关系等多个层面去考虑。
这么复杂可能用一张图就说清楚吗？可以。
看这张图的时候要特别虚线方框和箭头，可能会有点难懂～

有一定经验特别是参与规划过的话，就能明白图中概念及其关联。当然，可能基于产品发展阶段和资源限制，会有部分特别复杂又或会省略，都需要根据实际情况来调整的。这里，仅是我对以往经验的总结。

关于这个图，稍微解释一下几个概念和关键问题。最好是对照图一起看。

首先是概念

|版本规划

版本规划，是针对产品目标，围绕产品路线在各个阶段所做的规划。

产品路线也叫roadmap，road和map。所谓road，就是通向某个地点的行走路径。而map，就是把要去的点、过程中会经过的点、点和点之间点关联、关系、路径标记出来而形成map。

所以，roadmap就是明确目标后，把达成目标的各个点标记出来，挑选出最合适的路线走过去。

|产品架构

产品架构，后面专门总结一下产品架构怎么画，怎么修正。这里先说下概念，这里的产品架构是说产品功能产品业务层面的架构，它由产品的目标和业务流程导出，非指技术架构和信息架构。

|产品规则

产品规则其实是对产品定位的显化，有了产品定位，就有了定位之下做产品的原则，这个原则就是去定义清楚产品是什么，不是什么，做什么，不做什么，以及去说明利益冲突的时候以谁的利益优先。有了它，我们在对产品模块进行梳理导出MVP版本时、梳理迭代版本时、对需求池需求整理为版本时，对版本中的功能需求的取舍、优先级，就会有明确的原则去指导。

|技术反馈

产品发展中，特别是产品前期，一定是产品思维主导的，但是对技术的反馈需要特别的重视，这里的反馈是指技术实现难度和技术对产品架构的反馈，这些反馈是否能达到理解一直将决定技术架构的搭建和完善，否则一定会导致技术重构。没有技术会想做架构重构。

|数据反馈

数据反馈非常重要，但在数据量不足和人力资源不足的情况下，无视它吧。

然后是注意事项

目标先行

大大小小的规划，一定要定位清楚目标，花多一些时间，自己把这个目标理解足够透彻，然后能做到能解释到足够清楚。
面向不同对象分享。一定一定一定要把版本规划针对不同的对象去分享。不同的部门人员关注的点不同，所以需要稍微调整下表达、表现方式。当然，时间不足的情况下，就一个版本多种讲法搞定吧，时间允许的情况下，尽可能去做。

版本数量要规划3个

不多也不少，就规划3个。太多会因为后续不确定因素导致变化，可能会浪费精力。太少没办法更好的统一不同部门的共识，一个版本需要不同部门做不同的事情，没有后续规划或后续规划太少会导致过多中间成本或时间来不及。

技术开发周期

这个虽然很多时间，技术不太愿意提供，但是没有这个，意味着进度管理必然失控。

大版本和小版本

大版本是基于产品架构和业务流程导出的板块，小版本是一个板块的优化迭代。一定要分清楚这两者，很多时候，这两者需要结合在一起去规划和实现。而他们的取舍和排序，就需要上面说到的产品规则。

架构是需要调整的

产品的架构是需要不断去调整的，不是设计好之后就再也不需要去理睬了。

最后说下认识

1. 产品是演化出来的，不是规划出来的。所以版本规划的流程必须更加的抽象，抽象到只剩下流程和关键点。
2. 敏捷是元素的迭代，不是功能的优化。譬如想做小程序的分销，迭代应该是：识别小程序-转发小程序-基于业务创建小程序。

版本号命名规则1

版本号是用来识别当前版本唯一性的命名方式。
标准的版本号采用 VX.Y.Z 的格式。例如V5.3.2
其中 V表示版本号 ：version number ，简写为 V；
X、Y、Z 为非负的整数。X 是主版本号、Y 是次版本号、 Z 为修订号。
首次发布的版本命名为v1.0.0。后期每更新一个版本，就在版本号上+1。
更新规则：
1.当修改Bug和优化功能时，修改叠加第三位数字，即Z+1.其他不变。例如：v1.0.0——V1.0.1。
2.当新增小功能时，修改叠加第二位数次，即Y+1.其他不变。例如：v1.0.0——V1.1.0。
3.当新增大功能或者对原有功能有大改动时，修改叠加第一位数次，即X+1.其他不变。例如：v1.0.0——V2.0.0。
4.前面的位数叠加后，后面的位数从零开始计算。

版本号命名规则2

Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug 较多，需要继续修改。
Beta 版: 该版本相对于α 版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC 版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(R)。

版本命名规范

软件版本号由四部分组成：
第一个1 为主版本号
第二个1 为子版本号
第三个1 为阶段版本号
第四部分为日期版本号加希腊字母版本号
希腊字母版本号共有5 种，分别为：base、alpha、beta、RC、release。例如：
1.1.1.051021_beta
常规：完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如1.0.0
版本号定修改规则
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。举例：淘宝增加商家直播模块，就可以在原主版本号增加1
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。举例：钉钉沟通增加澡堂模式，可以在子版本号+1
阶段版本号(1)：一般是Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug 即可发布一个修订版。此版本号由项目经理决定是否修改。如：QQ 未读消息可以通过滑动红点删除
日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

文件命名规范

文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。
如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告1.1.1.051021_beta_b1.xls。
当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls。