版本管理，是B端产品最容易忽视的环节

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