网站内容策略( 后端需求调研，产品经理该如何完成方案设计？(组图))

　　网站内容策略(

后端需求调研，产品经理该如何完成方案设计？(组图))

　　

　　前后端分离使得每一个完整的产品系统都收录前后端部分。

　　相对而言，B端产品更依赖后端部分的支持。

　　

　　一些公司也习惯将这些后端配套件称为“后端产品”。

　　后端产品甚至没有可视化，只有一些中间件等。

　　后端产品就像冰山下的冰山，但它们承担着相当重要的幕后工作：支持、计算、监控、调度、分发、统计分析、决策……

　　

　　由于后端产品部分的复杂性，负责这部分的产品经理在完成方案设计之前，需要做越来越深入的需求调研。

　　一、后端需求研究

　　需求研究是需求分析的前提。

　　需求分析是产品计划决策的前提。

　　从需求调研到产品决策，占据了产品经理80%的工作能量。

　　由于研究和分析往往是一起做的，所以在本文中，我们将两者替换为“需求研究”。

　　根据一般模型表达式，我们可以简单画出：

　　

　　如上图：需求研究是一个过程，其产品是一个解决方案。

　　后端需求研究与前端需求研究有很大不同。比如用户的角色、业务的全面还原、场景的穷尽、新旧逻辑的兼容等等。

　　

　　下期我们简单聊聊用户、业务和兼容性的话题：

　　1. 用户

　　后端产品的用户不是最终的价值用户，而是服务人员（如客服、运营）。

　　因此，这些用户具有垂直业务，被格式化为具有戒色和行业属性的“人”。

　　不同的职位有不同的权重，他们关心的是价值目标、决策权和用户数量。

　　不同用户的具体使用场景不同。

　　

　　前端产品的用户画像更容易获取，因为我们或者我们熟悉的人在扮演前端的角色，这意味着在设计过程中角色替换也很容易。

　　获取后端用户画像通常要困难得多。最快的方法是与公司的业务层沟通。业务部门与客户打交道最为直接。他们熟悉大量的典型客户案例，可以帮助我们快速高效地描述用户。肖像。

　　由于我们与后端用户的分离，用户画像的作用就显得尤为关键。它总能提醒我们为谁设计，每一个关键诉求在产品设计上都有相应的把握。

　　2. 商业

　　了解业务的最佳方式是轮流参与业务流程。此外，更方便快捷的方法是研究访谈。

　　在进行调研之前，最好对业务有一个大致的了解，安排好被访者，提前准备好问题，让面试更有效率。

　　研究方法：访谈、数据分析、问卷调查、头脑风暴、Delphi、观察，完成用户需求的采集；通过亲和图、提示列表等方式整合需求信息。

　　研究目标：

　　对于后端产品来说，场景往往很多，需求的逻辑大于故事。需要远近规划业务场景图，勾勒业务结构，最终聚合产品生态。

　　在这个过程中，可以使用用户故事地图等手段。

　　

　　通过整个业务的架构，明确了整个平台的用户对象和业务关系，确定了整个产品的业务边界范围，确定了整个团队内部的业务语言。

　　3. 新旧逻辑兼容

　　掌握后端产品逻辑真相的密码通常掌握在开发者手中，但开发者往往需要临时检查代码。

　　在这种情况下，旧功能的所有迭代都充满了风险。

　　同时，无论是集成的大系统还是拆解的烟囱服务，各个系统之间总是存在逻辑调用。比如接口、公共数据等。

　　后端产品中大约 60% 的 bug 来自于这种影响全身的逻辑耦合。

　　确保系统安全的唯一方法是对可能的影响进行深入研究。

　　为了避免空谈，我们结合《后端产品经理大全》一书，介绍了需求调研和落地的常用方法，以及需求的种类。

　　二、需求研究方法1.过滤需求的方法

　　作为一个后端系统，首先要学习的技能是削减需求。即过滤要求。

　　这不是贬义词，而是体现后端产品价值判断的依据。

　　过滤需求的方法是通过一定的手段判断需求是否是伪需求，是否应该被过滤掉。

　　1）用户场景模拟

　　后端产品的出发点是帮助业务用户。因此，在研究需求时，需要模拟业务场景，分析业务用户提到的需求是否能解决他的问题。

　　如果它不能帮助用户，那么这个需求可能是一个伪需求。

　　以下案例说明：

　　因此，该需求是一个伪需求，应该被过滤掉。

　　2）功能归因分析

　　专业化系统做全时功能，有利于构建合理的产品体系。

　　因此，在需求研究的过程中，可以通过对系统的定位来判断需求是否应该在系统中完成。

　　如果不属于系统范围，则直接说服需求方更换程序。以下案例说明：

　　因此，短信应根据cms提供的基本标签数据自行二次推导。

　　这样做的原因是为了避免未来对更多语言版本的扩展需求或对更多系统的类似需求；

　　其次，CRM系统已经完成了“接力赛”的第一根接力棒，创建了基础数据，所以其他系统需要专门化使用，可以自己专门化，不用回耦合到CRM系统。

　　结语：案例本身的需求是真实的需求，实现起来也不难，但是这个功能的定位超出了这个系统的范围，专门系统做的是全职的功能，衍生的需求应在下游实施。

　　否则，过度耦合只会增加系统的复杂度，难以维护和扩展。

　　2. 拆分和聚合的方法

　　1）拆分需求方法

　　收到的需求很可能只是一小段。

　　不过不要太高兴，也许这句话暗示了很多线索，所以要善于拆分：

　　先找到他要解决的核心问题，然后围绕核心点梳理出前、后、左、右、上、下的附带需求点。

　　然后将每个需求点作为子需求进行调查，最后汇总在一起。

　　以下案例说明：

　　自营订单、第三方订单、*敏*感*词*订单、*敏*感*词*订单、部分退货订单、完整退货订单、服装事业部订单、电子事业部订单等，每个维度相当于一个小的需求。

　　这里就不一一列举了。

　　2）聚合需求方法

　　拆分方法是将单个需求分解为几个小的需求进行研究。相反，聚合法是找到许多相互关联的小需求的共同点，然后将它们整合成一个大需求来完成。例如：

　　由于业务用户分散在不同的部门，每个人管理自己的事务，所以张三、李斯可能对一个业务流程有相同的需求，或者对相同的功能有相同的优化期望。. 那么产品经理一定要找到两者背后的关联和交集。

　　然后进行整体规划，将它们汇集在一起​​作为研究需求，最终输出整体需求研究结果。

　　3. 使用辅助功能来研究需求

　　考察产品已有的功能可以用来确认原功能的逻辑，或者判断新的需求解决方案是否可行。

　　例如，业务用户需要更新功能。为避免更新中出现错误或遗漏，产品经理需要了解修改前后是否能正常工作。

　　最基本的方法是自己设计一个测试用例，记录运行模式、状态变化、数据流向等。看看下面的例子：

　　因为我们知道订单信息贯穿整个订单流通过程，涉及订单编辑、审核、取消、配送、配送等，而这些链接跳转的触发条件可能是信息更新（可能包括邮件更新） .

　　因此，很难确切知道更新邮箱是否会影响过程中的一些环节。

　　因此，我们可以采用预测试的方法设计测试用例，在测试机上运行一些命令，观察邮箱变化对各个环节的影响，然后采集分析对策。

　　测试方法类似于探雷，主要用于解决未知风险点。该方法的重点是记录和分析操作前状态、操作现场、操作后状态、操作后触发的连锁反应、数据流向等。

　　4.“拔萝卜带泥”方法的研究需求

　　产品经理在研究需求的时候，要拔萝卜带泥，挖掘用户没有看到的需求和价值观。例如：

　　背景：公司入驻销售平台后，销售平台将对入驻门店的违规行为进行*敏*感*词*。

　　需求：业务用户提出需求，将销售平台的精细数据采集到订单系统中，关联订单数据进行人工分析。

　　分析：

　　第一步，先拆分需求，确定什么是精品数据，总共有哪些类型的精品，需要连接哪些类型的精品，精品数据与订单系统的连接方式如何，是否可以关联，关联不了怎么办，销售平台是否提供了公开*敏*感*词*接口，如何获取Token（请求权限），爬取的频率，增长多少数据，什么展示和搜索获取后要做，如何设置用户权限，如何与订单系统交互，那需要的价值是什么……

　　第二步，挖掘需求：是否需要分析函数，分析函数的规则是什么；是否需要监测预警，是否需要指定负责人；其他业务人员是否有类似要求，其他平台是否有类似要求……

　　通过“拔萝卜带泥”的方式，带出更多的需求点。将上述调查结果重新组合，得到系统完整的需求。

　　列出需求要点和对应的验收目标，做到需求可视化，不遗漏细节，内部丰富，外部闭环，价值挖掘，做到管控阈值、预警、责任人员分配、趋势分析、损失分析等高价值功能超出业务预期。

　　5. 要求分数加权

　　这种方法的思路是对需求质量的维度进行加权，然后对需求进行打分，按照最终打分排列顺序。

　　可以使用五个维度：重要、紧急、收益、成本和风险，其中成本和风险被赋予负分，五个维度的权重分别为30%、30%、20%、10%和10%分别。

　　然后一旦对要求进行评分，就可以使用分数*权重得到最终分数。

　　注：负分将被扣除。并且为了计算方便，分数最好设置在0.5-5.0之间，或者0-10之间。这避免了评分跨度的大偏差。

　　

　　如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。要求 2 得分 3.5，要求 3 得分 -0.1。

　　由此可以判断，需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以剔除。

　　上述维度、分数和权重可以根据实际情况设计，但更合理的是检验和验证什么样的参数。而且你不能只使用权重分数，而只是将其用作辅助工具。

　　6. 其他需求研究工具

　　需求研究适用于核心环节，这个过程涉及到很多工具或分析方法，以保证高效、高质量的需求研究。

　　示例包括问卷调查、访谈、名义小组会议、头脑风暴、观察、亲和图、蒙特卡洛技术、鱼骨图、提示列表等。

　　三、需求的类型和态度

　　作者对B端或泛后台产品的需求进行了定性划分：表面需求、噱头需求、足球需求、过剩需求、建设性需求。

　　1. 被动的肤浅需求

　　无论系统兼容性和业务兼容性如何，这些要求都是理所当然的。

　　例如：电商场景，要求库存为0时，果断下架；如果库存变为非零，将果断自动上架。

　　这种威压，自然是非常危险的。而且库存为0也有曝光的价值；非零也有退市的场景。两者不等价。

　　在这种情况下，实际上是“概念窃取”的谬论，没有库存=下架。

　　对于这种需求，产品可以采取保留的态度，继续观望，从用户那里采集更深入的数据反馈。但不要轻举妄动。

　　2. 需要战略噱头

　　这很好理解，很多公司其实都是这样玩的。

　　例如：如果我们看到竞争对手拥有的功能，我们必须拥有它们；如果我们的竞争对手没有，我们也必须拥有他们。这可以使产品显得更强大。

　　还是强行“组合创新”：一个医药电商，你让他做直播带货，不说合规不合规，你能想象一个药师在店长面前当网红吗？

　　这实际上是本案中的“感觉谬误”。理论上，产品经理需要用数据来证明。

　　所以产品经理能做的就是放慢速度，预留资源。寻找机会慢慢将意见渗透到高层并尝试止损。

　　3. 隔壁踢球者的需求

　　在多组织的团队中，这种随叫随到的需求相当普遍。