“这个需求什么时候上线”

听过一个说法，如果你经常被人问到一个问题，并且每次都要给一样的回答，最好的方式是把你的回答写成文档，之后用「发文档」这个工作，代替你的回答就好。
“这个需求什么时候上线”这个问题，我作为产品经理会经常被问到。所以我在内部写了一篇文档，之后在工作中，就会用这篇文章来代替我的回答。

从业到现在，作为产品经理，我被问到过最多的问题就是：这个需求时候可以上线？
写这篇文档就是跟大家介绍一下一个需求是如何上线的，以及，面对这个问题，我能给到的回答是什么。
这样，以后再有小伙伴问我这样的问题，我就可以把这篇文档发给TA看了。
首先想强调一点，从主观上，产品，研发和设计，都希望每一个需求早点上线，而这肯定不现实。
但我想写这篇文章，就是想告诉所有人，我们此刻不能告诉你什么时候上线，不是因为我们不想去做这件事，或者对你的需求不上心。
恰恰是因为，我们尊重一个需求的全流程，所以需要按照客观的规律去做事情。
先回答大家的第一个问题，一个需求的流程是什么样的。
这里会分成两个阶段：
首先，我们要确认一个业务诉求，是否在当前阶段要成为一个产品需求；
其次，我们要把这个产品需求，变成一个在工作流中的任务。
一、先说说从业务诉求到产品需求的流程
有一点很重要，就是产品对于需求的理解，和业务对于需求的理解，可能是不一样的。业务看需求，就是看我需要什么样的产品能力，来帮助我解决一个当前棘手的问题。
这里的不确定性在于，这个产品能力，是否就是解决这个问题最好的答案。而好又包括：是否是最经济的，即是否现在就要做；是否能解决这一类的问题。
举个例子，很多业务跟我表达过，想要一个裂变工具，然后问我什么时候上线。
对的，“我想要一个什么，这个东西什么时候能上线”这可能是我遇到过频次最高的提问了。然后呢，我就会问，WHY，为什么要，现在就要么，你要的这个东西真的是解决你问题最好的答案么。
放心，我们产品绝对不是想要抬扛，或者是变相拒绝。因为我们只关心一点，解决办法是否是这个问题最好的答案，背后就是一点：资源该如何最优配置。
所以呢，如果业务和产品在某个问题上达成了共识，即一件事就是解决一个问题目前看来最好的答案，那我觉得，这时候业务诉求就变成了产品需求。
再说回那个需求，裂变工具什么时候上线。
那我会问，为什么要做这个需求。然后我会得到一些业务的输入，没问题，我认可这些输入，但仍然不够。我会初步去判断，裂变工具不是一个小需求，是一个小系统，所以我需要更多的输入。
接着我会问，那为什么要现在做这个需求，之前没有做的时候，你们是怎么解决的。然后我了解到，之前用的是第三方工具。
但会有一些问题。比如不支持二级转化数据的拉取，比如无法基于低转高做激励。
那聊到这里我就明白了，要做裂变工具的原因是什么，以及，到底需要产研投入资源解决哪些核心的问题。这时候，共识就算达成了。
当然，如果有一些数据，说明拥有裂变工具的潜力和价值，那是更好了。
二、再说说从产品需求到功能上线的流程
1、产出需求文档（即我们常说的PRD）
没错，如果你问一个产品经理每天在做些什么，那么他大部分的时间可能都在写需求文档。
需求文档是给研发看的，方便将需求从一个想法，变成一个可以落地的操作手册。
而要写一篇合格的需求文档，又会经过这么几个步骤：
1）需求的调研：关于需求的收益量化和可行性，会有更进一步的调研。比如跟研发的沟通，给数据分析提需求看某个数据等等，这都是为了把这个需求想得更明白。
2）画原型图：为了更清楚地说明一个需求，需要用Axure等原型工具，将需求可视化的展示出来。3）写需求文档：用飞书文档，将需求的背景、目标、模块划分、功能的详细说明，都说清楚。
有时候，对于特别重要的需求，在画完原型图之后，我们会有一个内部评审的流程，这是为了让产品经理之间互相提建议，确保没有忽略什么重要的点，或者有更好的想法迸发出来。
有时候，产品需求和业务诉求之间会有一些出入，毕竟想法从产生到具体落地，本身可能就会有一些变化。所以我们还会看需要，拿着原型图跟业务方去做一个业务评审，这也是为了保证我们产出的东西，是满足业务方需要的。
如果是涉及到客户端的改动，我们还会在这个阶段额外做两件事：准备AB测试的方案，完成页面的埋点，这两件事也需要跟数据分析部门一起准备。
所以你看，单单是产出需求文档这一步，就会有这么多事情要做。
2、进行需求评审
需求评审，就是产品会召集研发一起，跟大家讲讲这个需求的具体内容，解答研发的疑问。最终目标，都是从实现角度考虑，看看这个需求要做些什么样的事情。
理想的需求评审，是大家一起开一次会就结束了，然后开始拆任务，做分工。但现实中，经过评审后，往往有些事情是不确定的，需要下来确认，有些事情经讨论是不能做的，会将功能暂时砍掉，或者再返回去跟业务做沟通。
所以，实际的需求评审，可能不止一次（要看需求的复杂度）
接着，将所有可能影响排期的不确定因素都解决之后，研发内部就可以做排期了。我单独讲讲排期吧，毕竟排期在很大程度上决定了：
“这个需求什么时候可以上线”
3、排期
影响排期的第一个因素是估时，意思是：大家将任务做拆分，然后每个人评估下自己那一部分的任务需要多久。
但还有一个因素会影响，那就是耦合程度。一个人的工作，需要在另一个人完成之后，才能做完。
比如说，客户端如果要开始自己的工作，那前提条件是设计稿基本确认了。
而设计稿确认的前提是，设计师的排期是合理的。但设计这个工作，对于大的需求来说，又经常会发生改变。
所以呀，如果需求变更了，设计稿就要改，设计稿改了，客户端就要改，客户端延迟了，连调就延迟了，连调延迟了，测试测功能就要延迟。
因此，尽管很多需求能够给到一个预估的工时和排期，但如果需求频繁变更，或者某个角色的估时不准，都会导致最终的功能上线时间往后延迟。
这时候就需要产品经理去判断，到底准时上线是必须的（就意味着有些变更来不及做），还是这一次100%完成是必须的（就意味着需求会延期上线）
无论是质量有损，还是交付延期，都是我们在日常工作中会面临的。我们都希望又好又快，但现实就是求取平衡的艺术。
说到这里，你就会明白：
“这个需求什么时候可以上线”，即使我给你回答了，也是一种概率层面的回答，在排期结果出来之后，有很大可能会按照这个排期来交付。
但是如果在整个流程中出现任何变动，都会影响最后的结果。产品经理要做的，就是跟业务一起，保证准时上线，又保证上线的功能可以满足业务的诉求。
4、给不出排期，那能给什么呢
最后，从产品经理的角度也应该思考，业务方问我们要排期的时候，就只是关心什么时候上线么？
当然不排除只有这样想法的业务方，那我就给他们看这篇文章就好，解释了我们接到需求的时候，还不能给出排期的原因。
但是不是也包括，业务想了解我们有没有在推动这个需求，有没有一些关键的进展，可能他们也是需要用来向上做汇报的。
所以，如果给不出排期，能做什么呢？
把我们能确定的时间点给到，比如什么时候开始做方案设计，比如什么时候进内部讨论，比如预计什么时候可以写完prd等。
能把控的流程，越公开越好。
其次，当流程有任何重要的进展时，跟业务同步，同步是一个可以带来安全感的动作。即使资源突然出现了意外，或者是一些负面消息，也及时同步。
最后总结一下：
如果以后业务问我，这个需求什么时候上线，我会希望他们说明一下：1、为什么要做这个需求2、为什么现在要做3、你想解决的问题是什么4、有没有现成的数据或者分析，给到一些参考
当然，我也会尽自己的能力，做好信息同步和推进。
最后，我希望他们可以理解，从需求文档的产生到功能上线，是一个复杂的系统，我会跟你们站在一起保证最好的结果，但也希望你们理解这其中的不确定性。
大家是一个球队，把产研设的协作流程与大家分享，也是多求一些理解和支持。

这篇文章我挂在了自己在公司内部的blog里，而灵感来源于飞书听友群里的一篇文章《我为什么要写blog》。

我觉得有一点说的好，如果频繁面向不同人回答同一个问题，影响了你的效率，那就把它变成知识，沉淀下来，然后下次再遇到同样问题的时候，可以给提问者先看看。

当然，如果你想要成为产品经理，或者正在跟产品经理对接工作，我也希望你了解产品需求的上线流程。

而实际工作，也远比我描述的复杂得多。