6个方面分析:B端需求思考方法
大家可能已经在各种网站上看过许多B端需求的各种分析方法,作为一个运营商合作方的产品经理,也就是乙方产品经理(笑),笔者也斗胆来谈谈相关的一些B端需求思考方法。
一、什么情况下,谁,遇到了什么问题?
这是笔者了解到任何需求时的第一反应,笔者通常与许多不懂业务、没有产品思维的运营人员、B端用户打交道。当他们向笔者反馈需求时,通常会提出一个“解决方案”,比如:要什么功能之类的;亦或会将BUG当做需求来提出。
这时笔者需要将用户的思维拉回笔者的框架:“什么情况下,谁,遇到了什么问题?”,避免需求提出人的“解决方案”掩盖了真实的问题。
二、用户的目的是什么?
当了解到用户的问题之后,可以进一步推测得到用户的目的,笔者见到最多的需求最终目的就是用户想偷懒:)
下一步需要评估这个目的是否合理。
不是每一个目的都是合理的,作为系统的维护者,通常会与用户的需求产生冲突。比如:敏感数据相关、危及安全的目的就需要谨慎考虑。对于不合理的目的,尝试是否可以通过数种合理的方案组合来达到,如果确实无法达到,则直接拒绝。
三、谁的利益会受损?
另一个需要考虑的问题是:如果需求实现了,谁会受益?谁会受损?
举个例子:现在有个请假流程,需求提出人要求新增一个需求:请假必须由人事部经理审批,这时候需要考虑到人事部经理了。这个需求将会大大增加人事部经理的工作量,导致人事部经理的利益受损,毕竟谁都希望工作能少则少,不希望自己的工作量平白无故地增加。此时人事部作为利益相关者,应当要一同评审该需求,共同评估新流程与旧流程的优缺点。
在需求评估阶段考虑利益相关者的意见,有助于减少需求上线之后利益相关者的反弹。毕竟,不论哪个产品经理都不希望需求上线之后遭到用户的一片骂声。
当然,如果利益相关者无法出席需求评审会,则需要产品经理站在利益相关者的角度上去考虑这个需求,做出准确的预估。
四、现有功能是怎么样的?能否满足需求?
针对用户的目标,系统中现有功能是否已经可以满足?
如果业已有类似的功能,或功能组合,则该需求不再需要评审,直接告诉用户具体的操作方法即可。
五、有多少种方案?
通常实现一个需求的方案都有很多种,产品经理需要列举所有的解决方案,思考每一个方案可能会涉及到的系统模块,每一个解决方案可能存在的问题以及规避方法,方案的实现难易程度等。
通常方案选择的影响因素很多,通常最重要的影响因素是时间。在时间紧迫的情况下,通常选择相对容易实现的方案,其次是要选择风险较小的方案。
通常一个需求非常紧急时,需要首先实施临时方案,以快速响应,后续需要考虑最终的方案,此时可能会存在临时方案与最终方案的兼容性问题。对于临时方案如何顺滑过度至最终方案,也是产品经理需要去考虑的问题。
六、方案的配套工作有哪些?需要谁配合?
确定完方案路线后,产品经理下一步需要考虑:除了开发工作,还有哪些配套工作?
例如:总有一些数据需要在需求上线时进行初始化,这些数据需要产品经理牵头提前收集。
哪些存量数据需要初始化?初始化成怎么样的?
这是需要产品经理制定详细的数据初始化策略等,这些工作都是功能上线时必须要做的。
题外话1:如何对需求进行抽象?
笔者现在负责的系统中,存在许多个性化的功能,比如:有些功能,同一角色的用户,用起来就不一样的,针对这类功能,需要产品经理有勇气有魄力去统一起来。
另外有些需求,例如:上交附小需要在8月25日至9月25日免费使用学生管理功能。
这类需求可以进一步进行抽象,可以将学校、时间段、功能点抽象出来,做成可以配置的模式。后续有更多的学校需要申请免费功能时,就可以使用该配置功能进行快速配置了,完全无需开发。当系统越来越多这种配置时,系统就变得越来越灵活。
本文由 @Alfred 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
其实B端服务的需求整理可以从开始和结束点两段出发,起点是那些人需要做什么,实际的需求很可能是就做成这样,这一步就需要产品经理沉淀学习相关行业知识协作相关人员将需求模型抽象出来;跟着的终点是对流程结果的影响,说人话就是做了对公司有什么好处或弊端,其次即为对于人员和所在部门的好处或弊端。
我也是TOB的产品,需求方提出来的需求,大部分都是一线操作员的偷懒需求,而且一上来就是给你说帮我做个什么功能,这个时候一定要刨根问底去问他发生了什么场景,需要这个功能,然后要解决什么问题,只有统筹一下功能与需求,才能给出正确的设计思路,保证系统稳定性以及新功能的上线。
说的很好!
本人ToB的产品,小编写的内容很赞成,
我总结下来,其实ToB的产品必须要了解客户的业务(解决方案不着急给出),了解业务才能明白真正的症结所在;了解业务也才能实现,从需求A扩展发现需求B,最终实现需求的横向和纵向扩展,以达到给出解决方案的目的;否则也只是头痛医头,脚痛医脚;
不能同意更多