需求分析是产品经理的日常工作之一，也是基本技能。对于大型需求，一般不会出现太多问题，而对于中小型需求，却因为过于自信、疏忽等原因容易出现各种小问题，这篇文章，我们尝试解决一下。
在处理中小型需求时，因为内容过于简单，所以总自信满满，三五两下就弄完了。
但提交研发后却发现这个逻辑漏了一点，那个逻辑漏了一点，虽然是细节问题不影响，但也容易拖慢工作进度，还惹研发抱怨。
痛定思痛后，再仔细研读了一遍杨堃老师的《决胜B端》和徐锋老师的《有效需求分析》，也结合自己的经验将过往处理中小需求的全流程整理成一张图，每次有需求都拿出这张图对着思考一遍，果然妈妈再也不用担心我需求梳理遗漏了。
今天把这张SOP图分享给大家，并详细说明使用步骤，希望对大家的工作也能起到帮助。
1）原始需求
直接将对方提到的所有与需求相关的内容CtrlC+V复制到这个框框内，接下来我们围绕着这个需求拆解就好。
2）提出人、使用人、关联影响人
直接将提出人的名字和岗位填上，然后将功能直接使用人、关联影响人填上。
虽然每个公司组织架构都不一样，总得可以分为这4类：
3）用户遇到了什么问题？
我们常常遇到上来就讲：“我们需要一个xxx功能”的业务方，但解决方案≠问题，这一步就是督促我们要询问：“你们遇到了什么问题？”
相信产品经理们道理都懂，但容易犯错的是：自以为自己懂了。我就曾自作聪明地从解决方案推断问题，最后发现自己根本就是瞎猜。
所以无论有多了解业务，还是不能自满，多问问业务具体遇到了什么问题。
4）现在怎么解决？
用户现状是如何解决问题的？这不仅能给我们的设计方案一个参考，也能判断该需求目前的优先级。
下面是一个例子：
1）是否存在同类问题？
很多时候我们容易陷入“点状思维”，也就是对方提出一个问题，我们解决一个问题，这样容易导致我们刚上线完需求，第二个需求紧接着就来了，不仅让工作效率变低，也更容易让我们陷入“原型仔”的境地。
最好的办法是举一反三，当对方提出自己遇到什么问题时，可以问下对方是否有遇到同类型的其他问题。
例如退款时除了补偿金额外，还有没有其他特殊退出金额的操作？
2）上游关联者、下游关联者、协作者、管理者
盘出这几个角色原因是为了盘出下面的关联行为。有时候我们遗漏了需求并不是需求本身有问题，而是因为这个改动影响了上下游的另外一个环节。
例如当改动退款功能时，虽然使用人是财务，但是沟通退款细节的客服人员也会被影响到。
这时候我们需要盘出这一整条链路的关联者，并写出它们在这个链路上的工作内容是什么。
这里举例退款功能：
梳理好后，下一步才是最关键的。
3）关联行为
根据上面梳理的关联人，捋出这个链路上所有的关键行为。
1.财务人员根据客诉人员的记录来操作具体退款金额。
2.学生退款后，班主任会避免与学生再次沟通，在备注中备注该学生已退款。
3.…………………………
例如学生接收钱款、销售人员提供退款诉求，当然也是关联行为。但是如果在本次需求中不是那么重要，则可以略过。
1）是否存在更简便的解决办法
挖掘该问题下可能存在的更简便的解决办法。
对问题解决思路的穷举，可以采取金字塔思维、结构化拆解的方式，遵循MECE原则（Mutually、Exclusive、Collectively、Exhaustive，相互独立、完全穷尽）
2）是否存在关联的改动功能点
如果我们在设计时只是实现了一个点，那么接下来总会有接二连三的补充需求出现。作为产品经理，需要提前将这些可能的优化点、相关的补充场景都考虑周全，能避免很多紧急需求的出现。
例如刚才的退款功能，关联改动点梳理后如下：
1.财务人员根据客诉人员的客诉记录中也应该对相关字段进行记录更新来操作具体退款金额。
2.学生退款后，班主任处的会避免与学生标签需自动更新再次沟通，打上“在备注中备注该学生已退款”标签。
3.……………………
诸如此类，就能将链路上所有被关联到的功能点捋出来，避免刚做了A功能，紧接着发现B功能又要改的局面。
3）评估需求优先级
最后将捋出来的需求方案拆分功能点，划分优先级就大功告成啦。
自从用了SOP，确实感觉工作效率变高，且省了不少思考精力，最重要的是减少了重复返工，避免自己的工作时间又被碎片化切割。
希望今天的分享能对你也有帮助，也欢迎大家留言分享更好用的需求分析法，一起交流和进步。
参考资料：
杨堃-《决胜B端2》
徐锋-《有效需求分析》
作者：Thea小里，公众号：小里产品手册
本文由 @Thea小里 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。