在很多产品经理的头脑中，需求调研、需求分析、产品设计、上线后的迭代，和产品计划等，是大家的主要工作内容。
但是在B真个产品迭代中，有1件非常容易被忽视，但又异常重要的事，那就是“版本管理”。
作甚版本管理？版本管理的本质是要管甚么？怎样管？
在制定1个版本的具体需求内容时，我们需要慎重斟酌以下4点：
- 版本目标；
- 版本需求和目标的匹配关系；
- 需求研发工作量（难度和体量）；
- 模块对应的研发人员工作排期。
只有妥善了斟酌了这4个问题，我们才能真正制定1个“科学”的版本。
1、为何版本管理很重要？
1. 对客户来讲
不管是To C 还是 To B，每一个版本都代表着你的产品外化。
新版本发布上线后，你的用户们都会去使用、体验，对他们来讲，1个新版本如果能解决他们之前遇到的问题，给他们带来新的意想不到的好功能，用户便会感到欣喜和满意。
产品是公司连接客户的核心关系链。产品好不好，客户会直接代入到这家公司、这个品牌好不好的印象中。
所以每一个版本是不是能够真正解决用户最痛的问题，决定着这个版本的口碑，乃至影响到产品整体的口碑，乃至是公司和品牌的口碑。
因而可知产品版本的重要性有多大。
2. 对团队、产品来讲
1个科学有效的版本能够给团队带来正反馈的效应；客户在这个版本的基础上能提出更多有效需求和好的产品建议，逐步构成正循环效应。
而1个糟的版本只会引来客户的吐槽，乃至谩骂，这些除对团队有很大的自信心打击之外，更会让大家忙于在下个版本中加塞修复性需求，来解决这个版本所引发的问题。
在这样的情况下，结果可想而知：原计划下个版本的高优先级需求就会被影响，或搁置，或延后，从而带来1连串的连锁反应；若是碰上多个版本需求制定不公道的，那基本1个产品在短时间内会堕入无停止的做了改，改了再改的泥潭中——这对公司和团队来讲，都是1种资源浪费。
即没有用充足的资源产出有效的价值。
3. 对市场来讲
我非常喜欢1个词叫：卡位。
甚么叫卡位？
简单来讲就是你比他人早做出来1个产品，并且取得了市场的认可和No1的市场份额。
举个例子：
面对1个核心大功能（以连锁系统为例），你落后你的竞品2个版本才上线，而竞品在2、3个月前已上线该功能并打出广告：“市场上最好用的连锁系统”。
竞品的连锁版本推出后，产品口碑爆棚，那些具有多家店的连锁机构喜出望外，争相采购，由于困扰他们的连锁管理的问题，终究有产品可以实质性地解决它了。
本来属于你的客户会由于对手新版本的巨大优势而转投竞品家，而你本可以在3、4个月前就推出这个核心功能——这就是版本的机会本钱：你推出需求A的方案，就会延后需求B的方案，而到底这个版本该先解决A，还是先解决B，决定着产品在阶段性的市场竞争力。
在面对这类高度成熟的市场竞争时，每期版本选择甚么功能上线是产品能否成功卡位的关键。
2、优先明确版本目标
首先我想指出1点毛病的是：很多人上来就开始制定版本内容了，根据需求优先级高到低开始列，得出这个版本要做A、C、E、G。
这些高优先级需求，对吗？
选择最高优先级的需求集合到1个版本中，看似是对的，其实不然：
A属于模块1，C属于模块2，E属于模块3，G属于模块；从整体来看这些需求分属不同的模块，受益不同的业务，解决的是不同人群的需求，且这些需求基本都是平级的，仿佛并没有针对性？
1个版本，就好比1个产品，产品要有自己的优势，版本也要有自己的目标和优势。
比如我们定义这期的版本就是为了解决：连锁客户的后台统1管理多店的问题。
用1句话说清楚版本目标，就像用1句话表达产品优势1样，这是首先要明确的；没有1个清晰的版本目标，所有的行动都是弱目标感的，极易产生偏离。
3、制定版本内容
接着就要斟酌需求池中哪些需求应当被安排到这期需求中，而这件事就要以版本目标作为根据。
如果版本的目标是解决连锁客户的后台统1管理多店的问题，那末与之强关联且符合高优先级的需求应当需要被优先斟酌。
这其中你要明确：为了达成这个目标，你需要完成哪些需求才能真正意义上建立这个连锁的优势，是A、C、E、G这些需求吗？这些需求是不是引发共振？它们是不是能够匹配版本目标？
这些优先级也很高的“非版本目标需求”需要酌情调剂排期，为“版本目标需求”进行适当让路。
4、需求研发工作量
这里主要包括研发难度和研发范围（体量），常常B端产品1个版本适合的搭配是：1⑵个相对独立大功能+1些小功能。
为何这么搭配？
这其中是有道理的。
1般saas系统的版本时间会控制在：
- 大版本：1～1.5个月；开发时间：15～30天；
- 小版本：15～20天；开发时间：7～14天。
而这么多开发时间差不多能包进去的功能就是：1～2个相对独立的大功能+1些小功能。
固然我们知道每一个需求对应的研发难度和范围边界都不1样，具体需要研发人员准确评估后才能肯定下来，但是1般经验成熟的产品经理大致能估算自己的需求设计所对应的大致开发时间。
即基于工作量这个维度上，产品自己就能够大致公道地安排版本的功能；但是将每一个版本的时间设置到2⑶个月及以上，实际上是不合时宜的。
目前全部市场的节奏都是偏快的：竞品的迭代速度很快；客户的业务发展很快；新需求的爆发很快，所以2⑶个月的版本速度其实不能很好地适应现在的市场环境。
5、关于研发人员的工作排期
随着现在微服务化大行其道，很多saas系统的研发团队都会根据产品进行模块拆分，并安排相应的研发人员专门负责1～N个模块地开发和保护。
这就带来1个甚么问题？
核心模块，或和其他模块多耦合的模块，在每一个版本、每一个需求设计中，几近都会触及到。
——这就致使了业务关系较为复杂的模块的研发工作量非常大，而其他1些非核心模块的研发工作量就会来的比较间歇性，相对较少。
如果1个版本的需求对应的模块都集中在了A、B两个模块，那末负责A、B模块的研发就会忙死，而负责C、D、E模块的开发就会空死——这其实也是非常不公道的，不利于资源的优化配置。
所以在斟酌完上述3点后，还要斟酌这个比较现实的下游团队的工作安排问题。
可能很多产品经理觉得：这不是开发做的事吗？跟我有甚么关系？
换个角度：如果版本需求提交给研发后，由于这个缘由致使需求被打回，你再重新进行版本计划，无疑是double了工作量。
6、敏捷迭代
敏捷迭代，换个通俗易懂的词来讲就是：小步快跑——通过1⑷周小版本的迭代来快速地完善产品，并投放市场进行验证，继而搜集市场需求再进行快速迭代。
其实这个好处大家是比较容易理解的，说白了就是我先不投入全部精力，我把1个长周期拆分成1个个小周期，做完1个小周期，看1下效果，再做完1个小周期，再看下效果，不断地去修正上个小周期的假想，终究让产品逐步走向正确的方向。
相比那些动不动做上1年半载的版本迭代，敏捷迭代可让全部迭代进程更加可控，让每一个小周期的沉没本钱变得更小，这非常像马克思主义哲学中的理论和实践的关系。
固然敏捷迭代之所以非常火，还有1个很重要的缘由是：时期变快了。
快速发展的时期致使快速变化的需求，继而对产品的变化要求也愈来愈快，而敏捷恰恰逢迎了这样1种市场节奏。
那末，我们每一个版本都该用敏捷迭代吗？
其实这个问题没有唯1答案，可能不需要用，可能每一个版本都用，可能穿插着用——对每家企业、每条业务、每一个团队来讲都需要综合考量。
如何决策？
版本的目标是第1缘由，如果这个版本目标非常宏大，必定需要聚合2⑶个大功能，那末就不可能把版本周期紧缩的很小，而为了敏捷丢失版本目标，实际上是非常笨拙的。
7、结尾
在制定1个版本的具体需求内容时，我们需要慎重斟酌以下4点：
- 版本目标；
- 版本需求和目标的匹配关系；
- 需求研发工作量（难度和体量）；
- 模块对应的研发人员工作排期。
你学会了吗？
文章来源于司马特小分队
查看更多关于【产品设计】的文章
