我曾经公开分享过一个数据，团队 1 周大致要迭代 3~5 个版本，大部分都要求有需求文档才开发。
有人就说了，按这个速度，敢情比撕日历都快？
经别人这么一说，我才意识到，这频率确实有点异常。
我个人觉得其实还好，之前有幸目睹过，某笔记工具刚上线那会 ，基本保持 1 天/版，甚至1 天/ n 版的疯狂迭代。
最近总结和复盘了这事，发现要想提升版本迭代效率，关键有 2 点：持续交付、降低熵增。
展开来说，与产品经理相关的，有需求文档、版本管理等。
篇幅有限，这次主要围绕版本管理，讲讲如何通过 3 个发版策略，来进行研发提速。
版本拆分
版本拆分主要指的是，将一个大版本拆分为多个小版本，进行持续交付。
例如你现在需求池中有 200+ 功能，常规的发版思路是，将大概 30+ 当期的较紧急需求，打包成一个大版本开发上线，预计 3 周交付。
而版本拆分则是将这 30+ 需求，再细分拆成多个小版本，每个版本花 1~ 3 天上线。
这样做的好处是，同样是花 3 周时间，后者由于进行了版本拆分，大大提高了功能交付速度。
所以业务方的需求实现感知，是一波接一波，持续达到理想期望的。
而前者，随着等待时间越久，业务方的怒气值也就越高，随时都有可能在老板那，小声蛐蛐并告你一状。
模块分期
模块分期和版本拆分有点像，都是把同样一件事情，拆开来持续完成。
不同点在于，模块分期是针对一个大功能模块进行的。
比如老板突然说，要立刻上线积分体系，来达到 XX 目标，限期 2 周上线。
按这个期限，你我都知道不太可能实现。光是弄个简单的积分任务，那都至少要好几天时间。
这个时候就是考验一名产品经理，综合能力的时候了。
产品经理的其中一项能力，就是把不可能成为可能，把几率 0% 变成 80% 甚至更高。——好夕雷
遇到这种较棘手的情况，要咋办才好？
NB 的产品经理要做到这 3 点：向上管理预期、把控业务节奏、模块合理分期。
就拿积分来说，一个完整的积分体系至少有：积分任务、积分记录、积分商城、积分兑换、积分抵扣等。
你需要做的是，和业务方进行需求澄清，告诉他如果正常开发一个积分系统，要 N 月搞定，按这个期限有技术难度。
然后再搞懂为什么要求 2 周内上线？是因为配合营销节点，还是老板随口一说，亦或者其他问题导致。
以及在这当中，哪些要做、哪些延期、哪些不做，确定个优先级。
拿到了以上关键信息，或许问题已经解决了 80%，把积分拆成 X 个版本，剩下就是分期上线了。
至于你 X 期什么时候完成，留给下位接盘侠去想吧~
谁知道那会这功能还是否重要，或许当事人都不记得了。。
功能分级
功能分级，一般用在排期紧张、系统重构的时候。
具体指的是，在项目验收阶段，根据 DDL 对功能和缺陷进行分级处理，并降低部分验收要求。
例如
-
P0：必须解决，保证核心功能闭环
-
P1：视情况而定，降本增效功能，不影响核心功能使用
-
P2：可忽略，提升用户体验的细节，可延后处理
-
P3：直接忽略，边缘功能使用频率极低
当你验收时完成了功能分级，那么就可以视情况，把一些不重要的内容延期处理了。
这个发版策略，用在系统重构尤其好使，它能帮你省一大半时间。
总结
作为产品经理，如果嫌团队迭代频率太慢。
不妨试试我原创的 3 个发版策略，来进行研发提速。
-
版本拆分：将一个大版本拆分为多个小版本，进行持续交付；
-
模块分期：针对复杂功能，根据业务节奏，合理分期上线；
-
功能分级：在排期紧张、系统重构时，对功能和缺陷进行分级处理。