编辑导语：在日常工作中，一些岗位会进行产品的需求分析，对于产品需求来说，用户占到了很大的比重，因为产品最终是服务于用户的；从用户提出的需求出发，挖掘用户内心真正的目标，并转为产品需求的过程；本文作者分享了关于实现需求全流程思考进行梳理，我们一起来看一下。

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

一、需求前

1. 为什么做这个需求？

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

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

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

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

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

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

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

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

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

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

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

需求脑暴会议：

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

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

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

需求预期目标：

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

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

二、需求中

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

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

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

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

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

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

需要哪些新的技术方案？

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

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

技术方案的难度？

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

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

技术方案的优劣势？

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

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

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

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

技术方案实现周期？

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

技术方案是否有多种？

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

数据储存是怎样的？

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

测试验收

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

2. 产品需求方案

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

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

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

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

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

需求是否需要拆分？

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

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

3. 需求会议

会议是必不可少，足够的讨论会议，才能确保实现的需求方案是可行，缺少讨论光是执行，有可能会让实现的方案变得以后拓展性空间变少，以及实现过程出现很多遗漏点等等。

技术方案会议

当进入技术方案会议前，已经确定该需求是大致把握可以做，或者说从产品层面是可以做，技术方案需要相关技术人员，或者技术负责人进行前期的调研，整理技术方案。

有的时候，在产品做之前，产品就可以先和技术进行沟通，先初步了解技术实现，这样确保该需求在技术实现上不会有难度，至少能解决问题，不会因为各方面都准备好了，到了技术方案实现时才导致有个技术难题无法攻破。

技术方案会议，需要相关相关技术人员以及产品经理同时参与，由技术来演讲，而产品经理在旁边听和提出异议，需要做的就是帮助技术，检查是否有漏洞，如果不懂技术，可以从业务逻辑进行思考提问。

产品需求评审会议

进入到这个阶段，是产品经理主导，拉上相关技术人员，开始宣讲自己的产品需求文档，针对重要的必须要再三强调，确保信息同步到位。

当然，因为这个时候是给技术安排任务，所以技术肯定会灵魂拷问，产品需要做的就是——提前将需求思考的特别仔细，面对每一个问题，都能是提前已经思考、想好的，避免一问答不上，会在技术面前失足，造成大家的是浪费。

三、需求后

1. 数据监测

需求监测需要在产品实现方案时候，就需要提供需要埋点的，因为有了埋点，才有现在数据监测，在很多招聘JD都能看见针对产品经理有一个要求，就是数据的重要性；当上线一个功能之后，数据监测是必不可少的。

监测数据有需要注意的点，当数据上涨后是直接性、还是相关性，比如：朋友圈改了一个表情评论功能，这个时候朋友圈发布条数突然上涨了，会认为是这个功能刺激的吗？

不一定，因为这个时候有可能刚好是某个热点导致，很多人突然感概，发朋友圈的数量激增。

还有另外一种情况，也就是数据刚上线后，数据暴跌几个点，是否要将功能马上下线，回退版本呢？

遇到这种情况，也不一定，只要是在可承受的范围，如果时间较短，就应该对数据持续观察，没有发现异常，那也可以再进行尝试优化，也许可能是引导没有做好，导致数据不太乐观。

2. 用户反馈

功能上线后是用户使用，不管数据好和坏，都需要看用户的反馈，如果有条件，可以直接准备相关问卷，或者访谈的方式，做用户反馈收集，为的是确保功能上线后能够持续带给用户好的体验。

持续稳定的良好用户体验，产品才能走向正循环，前期的使用数据达到预期，后续留存也需要保证不失足。

四、总结

对于需求首先需要思考清楚收益，也就是实现的成本和回报，有的时候功能可能是增加体验，那也需要思考该功能影响多多少人使用；如果是实现增收的、用户增长相关，需要思考预期目标，通过分析用户群体、使用场景、该类型群体的数量、以及使用频次、历史相关数据进行多维度分析，来确保需求面向的使用用户是能支撑开发成本。

当需求确定之后，需要确定实现方案、技术方案，重要的几个维度，就是如何更低成本、更稳妥、对未来拓展空间无束缚等，让需求保质保量完成。

需求上线后，数据和用户反馈尤其重要，因为这个时候是验证假设的时候，需要注意的不是单维度观察，而是要从正面、侧面，不同角度来观察当前数据和用户反馈，有必要的时候必须要主动向用户收集反馈，确保后续能够做好持续好的使用留存。

每个人思考的方式不一样，有些人确定了要做该需求时，会优先从技术实现方案来思考；因为有的一个需求动到原本的其他的功能，导致实现的逻辑和约束增多，这个时候考虑的就更多。

总之细致细致再细致，思考思考再思考。

本文由 @大刘小飞 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议