产品经理业务问题的诊断。由简入繁，渐进成长

Posted 2022-11-06 壹叁零壹

 产品设计方案

产品的价值在于解决了一定范围的问题，让整体的业务运转、参与角色都能收到因为产品的贡献而产生的价值或便利。微信解决了熟人之间的沟通问题，支付宝解决了个人、商户之间的资金流转问题，滴滴解决了打车的不便和接送任务获取不易的问题...

要能较好的设计产品，就得清晰产品要解决的根本问题是什么！

进行业务问题诊断，发掘问题的根本本质。

业务问题的诊断就显得尤为重要！

一、业务相关信息的整理（思维导图） 三次握手原理  （ 聊现状，说问题 ）

要解决问题，就需要先明确问题。

做一款产品，需要有明确的定位及产品规划，用于指导产品的成长周期。而明确问题，明确业务情况就是进行规划的先决条件。

要明确问题，就需要找对关键的人，问对关键的问题。

1，干系人员的选择

在人员选择上，建议按照金字塔的情况选择，选择关键岗位的人员。一线最优秀的成员多选择几个，用于挖清楚他们各自不同优秀的方式；基层管理选择多名，梳理管理的视角和问题；中高层领导选择1到2名，主要梳理管理的方式及战略规划，明确其达成目标的管理方式。

中高层领导特别需要了解关注的重点，以及通过几个信息检核很多方面的归纳方法，明确业务中的关键点。

在这个信息沟通中，首先需要做到尽量不主观引导，尽量记录真实的信息情况；其次需要就问题本身多发问，为什么，还有什么，什么时间，有哪些人...持续就问题本身去获取更多信息；再就是信息记录尽量详尽，初始不做任何加工。

信息的采集决定信息是否完整，是否存在重大信息的遗漏。在信息整理的基础上，基于信息整理本身进行信息再补充；也可以基于信息整理，再找相关的业务人员进行信息再沟通。

2，信息的整理

信息的整理，将信息进行有效整理，是为了厘清业务流程，挖掘业务问题做准备的。信息整理为发现问题服务，推荐用思维导图进行信息整理和梳理。

思维导图是一种信息记录和整理的方式。

一是没有信息的逻辑顺序，优先只是信息的记录，软件本身支持信息的扩展；二是信息的顺序、前后，都可以依据需要来进行调整，逐步符合真实的需要；三是信息本身是可以进行分层级的，可以对每一个层级进行信息的检查，从而实现查漏补缺。

另外信息整理也可以根据5W2H（what ，where，when，why，who，）来跟进，检查信息整理是否完善。

3，信息的确认和延展

基于信息整理，再和对应沟通的人再确认一下。首先是，明确他说的信息，自己这样整理理解是和他一致的；其次是，把其他人的信息再沟通一下，看看作为另外的人看其他人的信息是否是一致的；最后是，沟通过程中，再发掘一下是否还有更多信息或者之前没有想到的地方。

信息的沟通并不是一次性的，需要多次沟通，多次确认。尽量确保信息的完整性、理解一致性。信息需要备份记录，用于后续的检查检核。

信息整理的结果需要包含，业务的流转，业务中的异常情况，当前的痛点，当前的解决方式。

二、梳理业务现状（明确业务的痛点）-- 需求层次（伪需求、兴奋需求...）（说痛点，寻通点）

1，最小闭环，自检核问题，发现真实的问题

信息的沟通主要达成了解用户当前的痛点，基于痛点解决问题，最快速实现产品的价值。MVP，最有价值产品设计方案，也是产品实现的重要方略。

在自有的经验里，常出现的情况是，最常见的是没有达成最小闭环。

没有达成最小闭环，也就是当前工序没有做成该工序的成品。示例，医药代理第三方记账时，销售代表按照负责关系把具体的货物销售金额分摊到具体个人，会存在销售代表离职、换市场、缺岗等情况。更甚是出现，知道卖出了金额，没有完整的客户档案，也不能确定该客户由谁负责。

如上述的情况，需要先处理未建立客户档案的客户，并指定给具体人员负责；然后按照离职、换市场、TBA情况处理对应的销售金额。

实现最小闭环，就需要各个场景处理之后的销售金额之和应该等于未处理前待分配的总金额，并且每个处理场景的处理方式要完善。其中需要注意细节是，未建档客户建档之后，会不会存在离职、换市场、缺岗的情况。处理流程要通畅完整。

数据作为检核，在实际的业务中，可以具体到货物的流转、钱的流转、票的流转。还可以拆解和互相检核。例：饮料百货货物的发货、出库、装车、运输、配送、确认、签收，发货的数量 = 路上损耗的数量+签收的数量，其中损耗可能包括出库错误、路上摔坏、临期退货等情况。坚持数据的平衡，可以在长业务链中检核业务问题。

2，业务中出现的问题 -- 真实问题的发掘

在上面的过程厘清具体业务的处理方式，并通过数据的一致性检查业务的完整性。就会逐渐发现问题，以上举例的部分就需要特别关注“未建档客户”的处理。

问题的处理方案，首先可参考当前业务的实现方式，线下是如何解决的，线上也依旧如此处理。次之的方案是，追踪出现的具体场景，在当时的场景下解决问题的出现，从根本上解决问题。在最后的处理方式就是处理方式上更简洁有效，做好交互，再出现问题时能够直接处理。

在这个厘清的过程中，梳理处理的流程，尽可能缩短处理流程，提高易用性。

3，相关处理人员的期望

在整个处理过程中，要紧着重要问题优先解决。有些业务的现实问题，并非是线上运行就能解决的，尽量达成使用效果，尽量优化交互效果就已足够。

问题追踪、调研询问了具体的人员，在最后的处理效果上，也可以询问相关人员。对于出现的问题以及想达成的解决方法，在实际的执行人员身上已经有一个初期的答案。询问清楚，将解决方案实现就已经达成初期的期望。

在这里，若存在需要改变认知，进行创新就需要提前引导。给出新的方法和当前解决方案的优劣势，然后加以说服，实现产品的品质提升。

基于三次握手原理，在问题整理、问题梳理、解决方案的给出，都需要再和相关的人员进行确认。确定在初期的信息沟通中没有偏向。

三、业务流程图（明确业务参与角色，业务的流转，挖掘解决方案）（挖根本，明方案）

基于了解的信息，按照标准的方式进行梳理，进行专业的输出便于成果的检验和漏洞的避免；降低理解难度，便于和业务确认，和研发讲解，和培训引导，降低初始使用的学习难度。

业务流程图，就是很好的标准。

1，对象描述世界

现实世界是复杂的，用计算机语言来描述复杂的事务就需要寻找一种模式、方法来模拟世界的运转。提取有效信息，应用关键信息的有效组合是抽象方式的一种具体表现。

面向对象的思想提供了一个很好的思路，把任何事物都描述为一个对象，如：一辆车，一个订单，一瓶水，一个节目。对象、对象间关联、对象生命周期，用相对较为模式化、简洁化的方式来实际描述复杂的世界及运转。

在不同的场景下，对象本身的属性（描述信息）不同。如苹果，在水果的范畴里，属性应该包含颜色、口味、香型、单价...在手机的范畴里，属性应该包含尺寸、内存、机型、版本...

世界的运转就是对象之间的信息关联，以及对象本身的生命周期。多瓶水可生成一个订单；一个订单的货物可以由一辆车运送；一辆车运送的过程可以做成一档直播节目...这就是对象之间的信息关联。订单的生成、付款、配送、签收、退货、完成、关闭...这就是一个对象的生命周期。简化按图表示则如下图所示：

按照如上图展示，用现实案例来进行解释。

现实生活中，我们会遇到“问题”，问题本身有：什么问题，关于什么，问题的难度，问题的详细情况，和哪些人相关，可能的后果，发现人，发现时间，负责人，处理紧急度...等一系列的基础属性。问题的发现、创建、转换、解决、关闭，就是“问题”本身的生命周期。“问题”可以转换成为“需求”，也可以转换成为“缺陷”，也可以根据“问题”创建“任务”...这就是“问题”的关联。

2，参与角色及功能需要

在整个业务运转下，都是由于人的参与促进整体流转起来的。各个人员是不同的，但在系统使用中，很多人员的参与情况是一致的，也就是角色的来源。一般的系统参与角色主要包含系统管理员、管理员、执行人员；有根据系统的不同，对具体角色进行细分，常见管理员区分为基层管理与高管；执行人员又区分为销售、人事、内务等。

厘清一个费用报销流程，就需要同行人确认、直接主管确认，人事行程确认，审计审查确认，财务确认及打款。其中涉及的角色就有同行人、主管、人事、审计、财务；同行人是系统中的用户，可通过通讯录或者组织架构选择；主管是组织架构的层级，就需要考虑多层级问题，及主管的主管；人事是一个岗位，可通过职务或者角色，配置相关信息（基础档案、出差信息、行程安排）的查看权限；审计则是另一个岗位，对于事件的真实发生及发生过程的实际信息进行合理的怀疑和确认，需要有更多数据权限和功能来支撑其决定是否审计通过；财务则是另一个岗位，需要确认该同事是否有其他的财务问题，根据最后审核通过的结果来进行打款处理。

报销审批业务流程（当前为简化理解，更合适的描述为：功能流程图）

由简渐渐进入繁杂了，小伙伴们，别只是看看哈。动动手，你也来试试~我知道很简单，但是罗马不是一天建成的呀~这个里面往深里挖掘也不少，后续我肯定给你证明证明 [小嘚瑟]。看到这里了，知道你比较累，点个赞，收藏一下别走失啦~~

在整个系统的实现中，为了确保信息可追溯，需要记录更多额外的信息。例如：同样是审计审核的，需要记录具体由谁处理的，在处理发生错误的时候，可以找到谁审计错误的，进而挖掘出错误的原因以便于根治问题。

互联网因其信息传播的快速，在很大程度提升了工作效率。在工作中，难免出现错误，需要增加容错机制，错误操作可以撤回。在系统设置上不能无限回退，对于很重要或者易出错的地方，进行二次确认，也能够很大程度的减少错误的发生。

3，业务流程流转

拆解对象的方法描述整个事情，然后通过角色决定对象的流转及各个角色所需要的功能。当前就需要让对象在各个角色之间流转起来，从而模拟业务的实现方式。

按照上面的方法拆解，归结到功能的粒度，会有很多的功能流程图，易导致信息过多。业务流程图是为了说明整个业务的信息流转情况。（当前情况，缺少产品架构的环节，直接进入业务流程，容易进入细节点，而忽略宏观点）在现实中，业务是为了说明一种具体模式的整体方案，如平台加盟模式，如下图所示，展示类淘宝电商平台的业务模式。

如图所示，展示了用户、商家、物流、平台之间的业务关系。确定的是整体的业务流转，而随着业务发展，用户会有更多的体验要求，需要评价反馈、需要视频或三维查看商品；商家会有更多需要，多种活动模式的支持，店品质的展示，商品良率、反馈优质的show；物流也会有更多需要，物流信息的及时同步（别再催促），货物装车的合理搭配，特殊包装的物流分拣；平台也会有更多的需求，商家的管理、假货的管理、刷单的管理、店家展示公平性的管理等。

先梳理业务模式，依据当前可执行的情况，来决定系统参与的环节。并在分析的模式上，优先确保最小闭环，实现业务能够完全上线运转。然后再根据优先级，依次强化各个环节。

本身的梳理过程，也在检核系统设置的合理性，以及业务运转的合理性，为后续的问题发掘以及解决问题的优先级提供支撑。

4，挖掘解决方案

基于以上的情况，可梳理出来具体角色的具体功能点，并按照功能点的执行，检查是否能够达到客户初期期望。这个图形的整理并不是最终结果，再和客户沟通的过程中，可以对图形再做优化，以符合现状。如实确定要按照图形描述修改，请深度思考修改的原因，以及可带来的优势。

当然，个人的知识面和经验丰富度都有限。在厘清业务流程的情况，完全可发挥信息收集能力，扩展竞品信息，借鉴类似问题的解决方案。同时，也借此明确，竞品分析是在明确要达成什么目的的时候来进行竞品分析。

同时，人和路途都不是一个人的旅程，可以和其他人讨论，可以在产品群里面发问，也可以在各个论坛里吸取营养。总是会有解决办法的，总是解决问题的方式比问题多一点的。

从角色出发，然后抽象对象，之后厘清对象之间的关联，之后是对象本身的生命周期管理，在之后就是根据业务复杂度拆解成为不同的系统，逐渐丰富整体。这是实际做事的方式，也是当前文章落定的思路。而另外的顶层设计思路才是更好的思路。只是在攀爬梯子的过程中，我们首先看到的是我们当前的处境，更贴切地说，实际上我们忽视了对我们指引最强的“太阳”。要了解更好的方式，记得看接下来的产品定位和产品规划哟  [手动比心]

5，业务流程图的实现注意

业务流程中，最好确定的是角色，毕竟会很少，也是最明确的。只是在角色上，别忽略系统管理员。只有管理员赋予每个使用者权限，才能通畅的走完整个流程。同时，对于各个使用主体可能会有不同方案的部分也可以放置在这里，通过配置来达成不同的细节区分。既有配置项，记得勿忘默认值。

业务流程中的各个对象可能是最难定下来的，存在理解不一致，存在取名不一致，存在细节功能划分不一致...

业务流程是为了辅助沟通的双方达成一致理解，可以对对象进行关键信息备注，以及扩展的功能细节。示例，下订单，本身包含信息，需要包含谁在什么时间下的什么商品多少数量的订单；下订单涉及的功能有订单生成、自动取消、付款提醒。这样表述下来，虽然沟通对方对“下订单”这个对象不太理解，但是对于这一块要做什么就很清晰了。（ 哈哈哈，不小心被你发现了，这个“下订单”确实取名有点没那么严谨哈。嘿嘿，不是说来着，对于整体框架搭建的稳，细节出点小差错并不影响~~~   好的好的，实际上每一个细节的优化都会不自觉的提升质量哟，可是，我还没改 [偷笑] ）

四、总结业务问题（确认业务痛点，确定解决方案的整体正确性）（达成共同目标，构建预期）

1，归纳总结问题

终于终于到了理清楚了问题了，并且还初步确定了解决方案。现在就需要再做归纳和整理，明确切切实实解决问题了。

莫急莫急，步步检核。去看看前面定的目标：信息整理的结果需要包含，业务的流转，业务中的异常情况，当前的痛点，当前的解决方式。

一一对照把问题记录及解决确定下来。然后，再找干系人确定当前的梳理和解决方案是否符合他们的预期。当获取他们的认可的时候，专业的表现，就是需要各位甲方爸爸签字画押一下。哈哈，没那么严重，就是跟他们确认一下。签字过于正式，那就邮件发送一下，记得提醒人家查阅和和回复哟。

2，优势讲清楚，坏处说透 -- 试用、数据兼容、待做功能、分期计划（ 和业务部门统一目标 ）

问题找出来了，解决方案也明确了，但毕竟还没有完全落实，就需要业务部门的同事辅助辅助，打打助攻。

在对外交接的时候，需要给业务部门预期，明确排期计划，明确后续的安排，千万别少了验收和试用环节。需要跟业务部门沟通，当前可进入需求池，会有排期计划的影响，并沟通清楚，后续有进度进展会通知相关部门。有问就有回答，让业务部门得到付出的“初期”回报。

产品投入使用，还需要经历验收、试用的环节。为更好的顺利过度，需要做好试用环境准备，万不可因为其他功能、数据问题等破坏了新功能的验收，否则整个设计、研发阶段的付出就真的很有风险。并且，团队经历新功能还未使用就推翻重来的话，会极大的降低对于产品的信任度，也会受到较大的打击，不利于团队的和谐。（很不幸，我的团队在之前经历了两个核心模块的超过三次重构，现如今对于执行这一块费了老大鼻子劲，才有一点点改观，过去的很长一段时间，步步有些如履薄冰感觉。哎，可怜如我~）

另一块需要注意的就是，完全是新功能还好，处理好前值依赖项就好。而若是功能升级，就需要做好数据兼容处理了。

业务问题的诊断，细节拆分理解了业务，发觉了问题，明确了解决方案。之后还需要执行力，对于执行部门来讲，执行力就是一切。（哈哈哈，捡个嘴说一下，我现在团队的执行力还是嘎嘎的，尽管前面偏差了两三个版本，还是依旧躺过来了。如果没有这些偏差，或者减少一些这些偏差，是不是团队的价值会更不一样呢？！）

​

作为产品经理，是管理产品一切的人，相比较执行力，正确的方向会更重要。看住产品，拟定太阳朝向，实时勤验证。