6个方面分析：B端需求思考方法

　　大家可能已经在各种网站上看过许多B端需求的各种分析方法，作为一个运营商合作方的产品经理，也就是乙方产品经理（笑），笔者也斗胆来谈谈相关的一些B端需求思考方法。
　　一、什么情况下，谁，遇到了什么问题？
　　这是笔者了解到任何需求时的第一反应，笔者通常与许多不懂业务、没有产品思维的运营人员、B端用户打交道。当他们向笔者反馈需求时，通常会提出一个“解决方案”，比如：要什么功能之类的；亦或会将BUG当做需求来提出。
　　这时笔者需要将用户的思维拉回笔者的框架：“什么情况下，谁，遇到了什么问题？”，避免需求提出人的“解决方案”掩盖了真实的问题。
　　二、用户的目的是什么？
　　当了解到用户的问题之后，可以进一步推测得到用户的目的，笔者见到最多的需求最终目的就是用户想偷懒：）
　　下一步需要评估这个目的是否合理。
　　不是每一个目的都是合理的，作为系统的维护者，通常会与用户的需求产生冲突。比如：敏感数据相关、危及安全的目的就需要谨慎考虑。对于不合理的目的，尝试是否可以通过数种合理的方案组合来达到，如果确实无法达到，则直接拒绝。
　　三、谁的利益会受损？
　　另一个需要考虑的问题是：如果需求实现了，谁会受益？谁会受损？
　　举个例子：现在有个请假流程，需求提出人要求新增一个需求：请假必须由人事部经理审批，这时候需要考虑到人事部经理了。这个需求将会大大增加人事部经理的工作量，导致人事部经理的利益受损，毕竟谁都希望工作能少则少，不希望自己的工作量平白无故地增加。此时人事部作为利益相关者，应当要一同评审该需求，共同评估新流程与旧流程的优缺点。
　　在需求评估阶段考虑利益相关者的意见，有助于减少需求上线之后利益相关者的反弹。毕竟，不论哪个产品经理都不希望需求上线之后遭到用户的一片骂声。
　　当然，如果利益相关者无法出席需求评审会，则需要产品经理站在利益相关者的角度上去考虑这个需求，做出准确的预估。
　　四、现有功能是怎么样的？能否满足需求？
　　针对用户的目标，系统中现有功能是否已经可以满足？
　　如果业已有类似的功能，或功能组合，则该需求不再需要评审，直接告诉用户具体的操作方法即可。
　　五、有多少种方案？
　　通常实现一个需求的方案都有很多种，产品经理需要列举所有的解决方案，思考每一个方案可能会涉及到的系统模块，每一个解决方案可能存在的问题以及规避方法，方案的实现难易程度等。
　　通常方案选择的影响因素很多，通常最重要的影响因素是时间。在时间紧迫的情况下，通常选择相对容易实现的方案，其次是要选择风险较小的方案。
　　通常一个需求非常紧急时，需要首先实施临时方案，以快速响应，后续需要考虑最终的方案，此时可能会存在临时方案与最终方案的兼容性问题。对于临时方案如何顺滑过度至最终方案，也是产品经理需要去考虑的问题。
　　六、方案的配套工作有哪些？需要谁配合？
　　确定完方案路线后，产品经理下一步需要考虑：除了开发工作，还有哪些配套工作？
　　例如：总有一些数据需要在需求上线时进行初始化，这些数据需要产品经理牵头提前收集。
　　哪些存量数据需要初始化？初始化成怎么样的？
　　这是需要产品经理制定详细的数据初始化策略等，这些工作都是功能上线时必须要做的。
　　题外话1：如何对需求进行抽象？
　　笔者现在负责的系统中，存在许多个性化的功能，比如：有些功能，同一角色的用户，用起来就不一样的，针对这类功能，需要产品经理有勇气有魄力去统一起来。
　　另外有些需求，例如：上交附小需要在8月25日至9月25日免费使用学生管理功能。
　　这类需求可以进一步进行抽象，可以将学校、时间段、功能点抽象出来，做成可以配置的模式。后续有更多的学校需要申请免费功能时，就可以使用该配置功能进行快速配置了，完全无需开发。当系统越来越多这种配置时，系统就变得越来越灵活。