Login Now 版本迭代规划这件事，产品经理几乎天天都在做。看着简单，但真想把规划做得让人心里踏实，能带着团队稳稳当当地往前走，而不是每次临近上线都鸡飞狗跳，其实很考验方法。
我目前负责公司一条业务线的 H5 版本规划。说实话，刚开始的时候，脑子里经常转着几个特别基础的问题：这些需求到底该从哪儿来？一个版本里塞多少东西才合适？下一个版本又该放什么？后来慢慢摸索，才意识到，一个真正好用的版本规划方法，至少得具备三个特点：稳定、全面，而且可持续。
稳定，不是说保守，而是一种节奏感。过于激进的规划，很容易把整个团队的节奏带乱。要么研发拼命赶工，大家身心俱疲；要么周期被迫拉长，项目里不可控的变量越积越多，风险也被放大。反过来，规划做得太消极，需求太少，研发资源闲置，同样是一种浪费。想做到这种稳定，就得提前把研发资源的波动考虑进去。资源从来不是恒定的，有人休婚假、离职，有人被临时抽调去支援别的项目，或者某个阶段技术基建的活儿突然变多，都会让研发资源缩水；而团队新招了人，或者别的项目收尾人员回流，资源又会变多。这些变动，项目经理那边自然会盯着，但做版本规划的产品经理，心里也得有一本账。
全面，我理解的是需求来源不能单一，需求的类型最好也丰富一些。如果整个版本的需求都只依赖某一个渠道，万一那个渠道暂时干涸了，下个版本就真的只能“干炒”了。一个健康的版本，应该像投资组合一样，有不同性质的需求配比。比如，有的需求上线后效果基本可以预见，确定性高；有的需求则带有实验性质，结果可能好也可能坏，没法提前打包票。如果把一个版本里 70% 的需求都押在实验性功能上，研发投入巨大，一旦效果不理想，公司和个人要承担的风险都太高了。
再就是可持续。一个好的规划方法，不能只在前两个版本好用，到了第三个版本就捉襟见肘。有些产品经理聊起规划来头头是道，方案听起来完美，但几个版本迭代之后就发现跑不通了。我觉得，这种不能持续输出方案的方法，称不上真的好。
那么，具体到每个版本，这些需求到底该怎么拼起来？我自己的习惯是，大致从四个方向来凑。
排在最前面的，是已明确的需求。这类需求通常优先级很高，属于 P0 或 P1 级别，是你必须做、绕不开的。它们可能来自老板的直接要求、行业趋势的硬性变化、法律政策的调整，也可能是你跟相关业务负责人反复讨论后敲定的核心功能点。这种需求往往是版本的重头戏，需要投入大量精力和时间保证质量，所以一个版本里不宜塞太多，一般 1 到 3 个就差不多了。
与之相对的，是一些带有实验性质的研究方向。很多需求你在写文档的时候，心里其实也没底，不确定它到底能不能带来预期效果。但有意思的是，这类需求往往最能体现产品经理的直觉，也是做产品最让人兴奋的部分。我建议把它们分散穿插在每个版本里，或者在没有大需求压阵的版本里，作为核心来驱动。
除了这两类，还有一种相对省心、风险也低的方式，就是借鉴优秀同行或同类产品里做得更好的功能设计。有时候写这类需求，甚至不需要艺术资源额外出力——当然这是句玩笑。但即便是借鉴，也一定要先想清楚对方为什么这么做，目的是什么，有没有更好的方案，而不是简单照搬截图。
最后，也是最容易被忽略的，是线上版本的细节优化点。每次版本上线后，你肯定会有不满意的地方。线上一定还藏着一些细节，比如某个交互让你一直觉得别扭，某个图标看着不顺眼，这些都需要优化。这就要求平时多用自己的产品，并把你那些停顿、不舒服的瞬间及时记下来。同时，也要留意身边同事怎么用你的产品。比如在测试功能的时候，我会特意观察测试同事的操作流不流畅，有没有犹豫和迟疑。用户有时候说不出哪里不满，但行为不会撒谎，这些细节需要产品经理自己去捕捉。多听听用户的声音也很重要，客服群、产品公众号的留言区、App 内的反馈入口，还有社交平台上的讨论，都是很好的收集渠道。与其在下午茶时间刷短视频，不如去翻翻后台的用户留言，往往会有意外收获。
说到底，版本规划不是什么高深的玄学，它就是把不确定性尽量降低，让团队能持续向前走的一套组合拳。方法可以慢慢打磨，但一旦成形，那种能给研发和业务都带来确定感的感觉，确实很踏实。
这些关于产品经理成长和时间管理的碎碎念，我也会在公众号「原住民自修室」里继续写，欢迎来坐坐。