一个运营人初次做产品需求后，对实现需求全流程思考进行梳理

小脑壳大思想 2023-07-28 15:32:28

作为首次做产品需求，在需求实现中遇到一些坎，于是把实现的全流程进行思考整理后，才有此篇文章；撰写此文也是为了加深需求实现全流程过程，方便后续如何去避坑，在整个过程能够更加高效实现需求方案。

一、需求前

1. 为什么做这个需求？

做任何事情之前，我们就需要明白一个目的，就是为什么要做这件事情？只有对事情目的足够了解，才好判断这件事情，到底该不该做？以及如何做才能做好的问题？

为什么做需求，一般都是来几个地方？老板、运营、产品、用户反馈，竞品，需求的来源大致从这几个角色中获得；就拿竞品来说，竞品上线一个新功能，我们不能说直接去copy，而是需要弄明白，竞品为什么做这个需求？

但是，需求上来之后，我们就一定要做这个需求吗？不是的，此刻而是要弄明白这个需求，为什么做？就算老板让做这个需求，那也得弄明白需求因何原因去做。

以加班为例，某公司经常加班导致员工下班太晚无公交可做，这个时候大家就需要打车，为了迎合这个需求，而产出一个深夜加班打车的需求；其实打车线下是可以打车，只是在大家在报销的时，特别麻烦，希望能解决报销麻烦的事情；而此刻推出打车功能，就需要考虑如何更高效处理打完车后报销的问题，不是简单打车这么简单。

2. 这个需求面向的用户是谁？

从打车为例，我们面向的用户是经常加班的公司，而这些公司的特征是什么？具体是哪些公司？

一看是哪些互联网公司，因为互联网公司经常要为某个项目赶进度，会经常有员工加班；然后又去招聘网站上看一看这类公司写明的信息，发现这类公司招聘上都会有些加班相关字眼，就足以证明这个需求存在，且还非常多。

3. 用户在什么场景使用？

前面也提到了，用户都是在加班后使用，也就是经常到深夜，推出这个功能之外，我们还需要调动司机资源，在深夜配合，才能将功能推动正常运行。

4. 这个用户群体有多大？

通过在招聘网上扒一扒，看到了许多公司都提到加班，可以再对这些公司的HR进行深入的定性采访几家，就能验证这个公司群体的大小，从而好估算这个市场空间的大小。

需求脑暴会议：

需求脑暴会议，作为功能推动者，需要做足了相关调研，尤其是面向用户的调研，然后拉上能提供点子的相关人员可以进行脑暴，这样他们能提供很好的实现思路，从而能够更快找到好的解决方案。

需求脑暴会议的目的，就是为了找到能够解决问题的方案，虽然会议可以发散，但是作为主持者，还是需要控制，当跑题时，需要将大家拉回来。

有的时候没有这样的机会，主持脑暴会议，就需要靠自己思考了。

需求预期目标：

当我们确定要做一个需求功能时，就需要定下预期目标，当然这个不是随便制定，而是经过深思熟虑，通过多维度的理论、相关数据证明，制定出合理的预期目标。

因为有了预期目的，才能更好的判断该功能是否值得去做。

二、需求中

1. 需求实现前的技术方案调研

技术实现方案，决定着该需求能否实现，是比较重要的环。

有没有技术方案可以复用？

因为一个新的需求要满足时，如果发现实现这个新的需求时，发现技术方案特别难，那可以往以前旧功能看下，有哪些可以复用？

在《腾讯产品法》一书中李立老师分享到，当初微信要做“摇一摇识别歌曲”而摇一摇中识别就是语音识别技术，如果真要重新做一个摇一摇识别歌曲，这个应该就是有一定的成本了。

包括在需求时，有些组件是在产品中哪里实现过？如果重新在开发一个组件，那无意就增加成本。所以，除了要思考需求给用户带来好处之外，还需要思考实现的成本是否可以更低？

需要哪些新的技术方案？

如果发现无法复用旧的技术方案，那就需要调研新的技术方案，技术方案的实现成本，包括技术方案实现出来后是否可以有拓展性？

同时是否除了想到A技术方案之外，还有其它的技术方案？可通过反推的方式，跳跃思考的方式，来找到其它的技术解决方案，争取选择最优的技术解决方案。

技术方案的难度？

技术方案的难度决定是否可以实现需求？有些原本思考的需求，但是在技术方案调研时不够严谨导致需求执行了一半，无法完成，因此卡在一半时就不断的找技术解决方案从而导致需求上线时间耽搁。

还有的时候，技术实现方案在前面调研时，没有考虑周全，在实现后经常出现BUG，从而导致返工的成本，这些都是需要提前思考到，这样能确保需求顺利进行。

技术方案的优劣势？

优势就是实现了这样的技术方案得到了什么好处？劣势就是实现后会导致什么样的弊端？

举例，实现后该需求能很快上线，但是劣势就是上线后稳定性不确定，或者上线后导致后续可拓展性变低，产品容易进入死循环，这些都是大忌。

另外，该方案实行后，对原有相关的功能技术方案，是否存在不支持和需要重新调整？如果是，则需要调研该需求的影响严重程度，因为一旦实现该需求，就会造成不止该需求的研发，还需要拆解原有的功能，重新写或者拆解技术方案，来支持新的需求。

不过反过来说，我们需要思考清楚，目前实现的技术方案，是否会支持以后可拓展？比如：我们做一个拼团功能，正常的一般都是2拼团，但是如果在技术方案上写的时候，直接写死了，后续如果要做一个百人拼团，或者万人拼团，那开展起来就特别麻烦；但是，在写拼团方案时，早就考虑此后可拓展，这个技术方案就是非常灵活，对后续发展有帮助。

技术方案实现周期？

也就是执行该技术方案后，要多久才能完成需求上线？这些都是需要技术方案讨论时，就需要敲定好，这样深入讨论才能对需求实现更加的可控。

技术方案是否有多种？

技术方案多种，是为了能选择到更优的那种技术方案，一切需要从更加全面的思考来选择技术方案，不单单只考虑现在实现的速度，还要考虑实现后的可拓展性，以及需求上线的安全和稳定性；只有上线后能顺利进行，且后续能够更好的新增需求，才是做合适的技术方案。

数据储存是怎样的？

如果有可能我们还是需要考虑数据储存，该功能的相关数据如何存储？是保存现有的某个数据结构中？还是另存数据？作为一个产品，需要提前思考，并且和技术进行确认，让技术拿出解决方案是最好的。

测试验收

其余的地方都思考到位了，最后上线需要测试给力，测试越给力，才能保障产品上线稳定，减少BUG出现率；所以这里涉及到测试对需求的思考，最重要是测试编写用例。

2. 产品需求方案

需求实现的场景都有哪些？

需求实现的场景，也就是指该需求用户会在什么场景下使用？需要把所有场景下使用全部梳理出来，才能把业务逻辑梳理清楚，比如：用滴滴打车，每当输入的出发地址与定位地点不同，这个时候产品就会提示是否为他人叫车？再比如：用户在早上打开滴滴，那可以判断基本都是上班打车，这个时候滴滴就会从以订单往记录给用户选择终点，只需用户确认即可。

梳理清楚场景，就能很好的提升用户体验，产品逻辑也能很好的梳理清楚。有的时候不同场景使用，调用的数据库、包括其他资源都会有不相同。

还是以打车为例：如果在高峰期打车，当用户打的是特惠快车，如果此刻用户定位周边XX公里内没有特惠快车司机，当等待XX分钟后，如果还未有匹配的司机进入该范围，就会调用快车资源完成该笔订单。

另外，如果需求梳理一点之后，然后又想起一点，再去完善文档，这样会导致增加很多无用功；如果产品文档已经给到技术进行研发时，再去和技术说补充文档时，技术又需要重新理解一遍，会产生成本，技术也会反感；所以，在思考产品需求场景时，一定需要再三思考，深度思考清楚，把所有想到的都罗列出来，才能避免后续尴尬事情发生。

需求是否需要拆分？

需求拆分的情况下，一般是看需求的大小、以及目前的技术任务量、还有需求需要上线的时间节点；如果着急使用的需求，会进行拆分，拆分后的目的是为了能够快速上线需求，验证需求效果，这样也能做一次成本控制，保证项目整体的上线进度。

但是在拆分需求时，也需要将需求文档全部写出来，能让技术有个前提了解，这样对需求拆分后，后续实现有很好的帮助。