如何将一个复杂的业务，从头拆解转化成产品需求？.docxVIP

如何将一个复杂的业务，从头拆解转化成产品需求？ PAGE 8 如何将一个复杂的业务，从头拆解转化成产品需求？ 当一个产品经理接到一个复杂且自己完全陌生的需求时，要怎么将一个复杂的业务，从头拆解转化成产品需求？本文主要讲解该如何拆解，一起来看看~业务导向型产品，每个功能背后都隐藏着复杂的业务逻辑，作为此类产品的产品经理，当接到一个复杂且自己完全陌生的需求时，如何一步步拆解搞清楚它里面隐藏的逻辑和细节规则，并成功转化成产品功能和输出清晰的产品文档？本文复盘一下自己的实施步骤和过程，为以后处理类似复杂需求积淀思路和方法论。一、理解名词每个业务领域都有专有的业务名词，理解需求首先要搞清楚它涉及的专业术语。理解了相关术语，对这个需求相关的是一件什么样的事情，就有了一个初步的概念和认知。其中，了解的方法有两种：（1）向需求提出方询问：“XXX是什么意思？”一般情况，业务人员会从这项业务是干嘛的来展开介绍，在这个介绍里，你可以得到的信息包括但不限于：这个需求涉及的业务干系人（用户来源）；这个需求的关键操作（功能拆分来源）；这个需求的操作流程（流程来源）。（2）借助网络查询词语最通俗的释义业务方的介绍可能是从他们专业的业务操作上进行的，这对一个新手来说，有可能还是过于晦涩和专业，为此你需要自己通过网络理解名词背后最通俗的含义，有可能会有多重解释，但你能辨别出哪一种解释是跟你相关的。这一节点应该输出“名词解释”列表。有了上面的理解，就大致知道了需求是干嘛的，那实际的业务中，是如何操作的呢？经过了什么样的流程节点呢？二、整理流程图这个过程会经历两个阶段：（1）流程图草稿：把理解到的都用流程图的方式表达出来，不分泳道、不纠结流程节点命名、也不用在意这个节点该不该画出来，画出最粗又是最细的流程图。粗是因为不分泳道很多节点也不合理，细是因为把听到的理解的都作为节点画出来。这时候不要画泳道图，因为对业务还模糊不清，抽象不出合理的泳道，如果一开始就设计泳道图，反而会花费较多时间和精力，但效果并不理想。（2）细化流程图：经过对业务的不断调研，草稿图越来越完善越贴近真实业务，可以说对业务的整个流程有了宏观上全面的认识，那么就可以抽象泳道精细化节点来细化流程了。这时候输出的流程必须是泳道划分合理，流程节点粗细适宜，节点命名合乎业务的。但是这时候的流程有一点还是会有欠缺，异常流程和判断节点往往会缺失。但不要紧，后面的一步会帮助我们把这些细节都考虑清楚和全面。这一节点应该输出：一是流程图草稿（只给自己最初理解业务用）；二是业务流程图（用于向其他团队成员讲解和帮助他们理解业务）。三、整理状态迁移图业务型产品在研发实现上很重要的一点是状态，状态控制着整个业务的流转和什么时候什么人该干什么事，不合理的状态划分使得代码的难度和体量呈指数增长（因为每多一个状态，程序在做任何一个判断的时候，都要去判断一遍它），因此状态的划分要足够合理和精细。（1）抽象对象：顾名思义，状态用于标注一个东西在不同条件下的情况，那么整理状态迁移前提是先要有对象。在业务导向型的产品中，这个对象往往是业务操作过程中产生的各种单据。如：订单、退货单、收款单等。抽象对象的方法是：如果一件事情的完成需要不同的人在不同的节点做不同的操作才能完成，那么这个事情开始的时候就要生一条单据，后面的操作人都是对这条单据的操作。（2）抽象状态：处理对象的各个流程节点就是状态，但是在梳理流程图时，有些流程节点是辅助性的，它不影响整个业务的流转，这样的节点，不应该被抽象成状态。比如：在小明吃饭的业务中，评价是一个很重要的流程，顾客是否有做评价也是我们会统计和关注的点，但评价状态并不属于核心业务流，顾客有没有评价跟就餐是否完成一点都不影响，因此评价的状态并不适合抽象成主状态。是否有评价给单据打个标记，能够方便查询和统计就OK了。在梳理状态迁移的时候，会发现流程里面没有考虑到各种不同的情况，从而反过来指导完善了流程图的设计。这一节点应该输出：各个对象的状态迁移图。四、整理场景和规则有了流程图和状态图，就可以抽象出不同的业务场景。再根据场景逐个细化调研，从而获得业务规则，其中，业务规则细化到每个细节的长度、类型等等信息，是真正走到业务里面了。（1）抽象场景：对场景的抽象有两步，一是把流程图中的大节点抽象成一个场景，二是对大场景的不同情况进行细分，划分出小场景。这样做的好处是：总的场景不至于那么多，理解查看和维护都方便，但又不会落下细节和特殊情况，保证产品设计的完整性。（2）细化规则：有了场景，有了场景下的不同情境，就可以针对各个情境下的业务限制规则进行梳理和调研了。