如何做到一周迭代3-5个版本？试试这个策略！

我曾经公开分享过一个数据，团队 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 对功能和缺陷进行分级处理，并降低部分验收要求。

例如

1. P0：必须解决，保证核心功能闭环
2. P1：视情况而定，降本增效功能，不影响核心功能使用
3. P2：可忽略，提升用户体验的细节，可延后处理
4. P3：直接忽略，边缘功能使用频率极低

当你验收时完成了功能分级，那么就可以视情况，把一些不重要的内容延期处理了。

这个发版策略，用在系统重构尤其好使，它能帮你省一大半时间。

总结

作为产品经理，如果嫌团队迭代频率太慢。

不妨试试我原创的 3 个发版策略，来进行研发提速。

1. 版本拆分：将一个大版本拆分为多个小版本，进行持续交付；
2. 模块分期：针对复杂功能，根据业务节奏，合理分期上线；
3. 功能分级：在排期紧张、系统重构时，对功能和缺陷进行分级处理。

欢迎关注作者微信公众号：「产品之外」