在B端产品的作业傍边，常常要与不同的事务部分打交道，他们的人物许多、诉求各有差异，造就了后台事务产品的杂乱性，下面介绍一下我在国内排名榜首的房产中介公司作业以来总结的一套产品方法论。

　　咱们常常收到来自用户（事务部分）或老板，以一句话高度归纳提出的需求：“我需求对挂牌房源进行回访，并进行断定”、“我需求一个对网站400来电录音进行打分的渠道”……因而，需求一个结构有序、完好的与用户一同整理需求非常有必要。

　　在面临分工精密的企业内部，咱们能够从“现在是怎样的？”去下手了解当时的部分架构、岗位分工。

　　由于一切事务线，不管它现在怎样低效或咱们看来是剩余的，但也是多年来一向优化，被证明有用的才得以保存和运作至今。所以即便新产品依据新流程、新技能，能够节约某些功用人物的参加，也只需从了解现有架构开端，了解现时为何这样装备，每个岗位有何意图和效果，才不至于在产品上线后，才发现一些事务部分躲藏的需求。

　　即：在什么场景下，有什么需求，要完结什么方针。把每个人物的场景、需求、方针都逐个列出来，然后把需求打碎、重组，即可定义出相关的功用。

　　这一步能够结合思想导图，选用发散思想方法，与用户一同彻底尽头各种或许发生的状况，再结合事务的考虑，提出对应的处理方法，与用户敲定。

　　怎样尽头一切或许？这儿有个小技巧：把问题拆解为一个个小问题，对每个小问题诘问下去，直至无解、清楚停止

　　400来电录音检核渠道的需求：来电录音选用轮循机制随机分配给AE（Agent Energize，生意赋能师）检核，以提高生意人接听来电的服务水准和规范

　　1.AE的职位架构取自哪里？K3人事体系？尽管从知识能够知道人事数据来历于人事体系，但刚好本例是特例，由于前史原因，受限于K3体系的约束，“AE”这个的职位数据来历二手事务体系。所以假设新触摸一个新人物，特别在前史悠久的公司，最好先与开发交流，承认数据的来历，乃至假设当时不存在此架构数据，怎样进一步处理。

　　2.录音来自于哪里？本例中，录音来自于北京总部每天会发送前一条的录音数据文件给咱们，咱们作为分公司再进一步导入处理。这儿涉及到两地技能对接、洽谈处理。

　　假设离任录音重新分配，录音是否有时效性，比方只分配当月未检核的录音？不然将会影响到报表周期的数据

　　假设总部没有依照约好，在特定时点发送前一天录音给咱们，后备计划怎样处理？

　　这儿略微提高一下思想高度：不管何种方式的图表，意图是与事务部分和团队成员交流，所以挑选的图表只需咱们看得了解，完成高效交流即可。

　　经过以上三个需求剖析结构，咱们现已能够明晰与用户交流，了解用户所需的需求，并经过进一步开掘、整合想象出产品的结构和主要功用。

　　B端的事务体系，往往需求与许多其他根底服务（OA工作、人事、财政、通讯等）、不搭档务体系间的对接。由于这些对接往往决议了新产品的数据来历、完成约束和接口规范，在动手写需求文档之前，无妨先与开发交流一下各关联体系的对接要求，以便能够写出更规范完好的需求文档。当然，一些根底性服务，假设团队间默契现已构成，能够节约这个进程。

　　在事务上，除了在产品内部的操作，还有许多是线下或对外部体系的操作。怎样简略表述出参加者完好的事务活动？这儿引荐运用——UML用例图。

　　网签预定体系项目：接案专员在网签预定体系（内部产品）收到生意人的预定案子后，需求在房管局的“存量房预签约体系”进行相关操作，把导出的成交合同上传到网签预定体系（内部产品）以持续后续的承认签约流程。

　　运用用例图即可明晰表达区分以上主体及其主要功用（使命），最大优点是以最简练、高度归纳的外部视角与用户（事务部分）交流承认需求，保证对杂乱的事务进程了解共同。

　　需求理应没有鸿沟，但假设要完成需求，则存在资源等各种客观原因，使需求有了优先级——即版别规划。咱们能够依据B端产品的特性，结合事务的火急程度，划定优先级的断定规范，假设你的公司习气项目时刻由老板决议，我这儿主张其间一种方法是：在产品开始策划阶段，拓展思路，尽或许规划完好的产品，向老板、决议计划者展示完好的方针效果。然后，列出各种功用的主张优先级和所耗资源，提请老板依据时刻期限决议完成的优先级，定下此版别的项目规模，即交给老板做减法。

　　假设咱们规划的是管帐、人力资源等专有职业的体系，咱们就不能天马行空，体系的规矩离不开职业的法律法规，比方管帐就像一个正方形，法律法规现已设好鸿沟，咱们所做的是在鸿沟内规划；人力资源的HRBP体系则像一个水桶，半开放式，有其自由性。所以咱们规划产品的时分，榜首是要深化开掘公司事务的需求，了解事务，经过产品、技能去提高公司效益；第二是了解职业相关法律法规，明晰产品的底线要求。为什么自己也要了解？由于事务人员很或许会以为一件在TA看来显而易见的工作，而你作为职业外的规划者，底子不知道，发生需求盲点，直至产品上线、体系鸿沟

　　一个产品，只应该为处理一个（类）问题而生。咱们最常触摸的事务体系，尽管事务多变，形状千变万化，每间公司有其特性，但只需找准主心骨，产品才能够有序健康地开展，咱们能够用鱼骨型去比方它。没有规划的体系，将会越来越变得臃肿难用，或会有一天体系不足以支撑而溃散。要防止这个问题，有几点心得：

　　最终，共享一下在实践作业中，产品上线真实的运用者和需求提出者很或许不是同一个人，需求咱们想方法触摸到实践操作搭档，了解一下他们的主意，考虑到产品中去；需求交流开始阶段，也很或许没有事务部分的主管（有决议计划权）或一切关连部分参加，所以当已有开始计划，一定要找一切与产品有关连的事务部分的主管执行计划，达到一致，防止上线后才发现交流存在问题。