B类产品的科学化设计与分析流程
2018/12/2 20:14:38流年 人人都是产品经理
作者：流年，微信公众号：流年产品录
全文共 10772 字 7 图，阅读超过 22 分钟
———— / BEGIN / ————
众所周知，企业级的2B项目涉及到的业务复杂，模块繁多，那么此类项目要如何去系统地做产品设计与分析呢？
本文会把我在学习和工作中习得的2B类项目的产品分析流程分享给大家，希望能给大家带来一些启发。
序：由业务驱动的需求思想
在面对2B类型的项目中，核心是要具备业务驱动需求的思想，能准确识别出客户/用户的问题级需求。
有时，企业级的利益相关者提出的一些所谓“需求”都是一些方案级别的，比如：“帮我们做一个平面图的展示功能”、“协助制作一个详细数据的报表”、“这个界面增加一个查询工具”等等，这些都是客户/用户提出的方案，有时照客户/用户的意思做出来也未必能够解决他们的实际问题。
而问题级需求则是站在客户/用户的角度展开的。要通过客户/用户访谈，澄清方案级需求背后的问题本质，深入了解此问题是在什么使用背景下发生的，并在这些的基础上，提出准确的解决方案。
另外，涉及到项目风险的角色，也会是项目的相关干系人，比如：项目对一类客户/用户产生负面的影响，此类客户/用户也是干系人。
2.2 各干系人的分析
识别出了项目设计的各干系人，接下来就要分析出他们对于项目的需求点和关注点。
我们首先要选择出各干系人，如果一类干系人有很多位，就要选择出一个干系人代表，我们要确切的了解他的职业角色和工作联系信息，做到对每一类干系人都了若指掌。
在这里，分析干系人最常用的方式还是访谈。根据干系人的具体工作主题分解、工作阶段分解去了解其在项目中的需求点与关注点，明确他们在项目中的位置。
我们可以从两个角度出发：
一是他们希望项目解决什么问题、提供什么业务支持；
二是他们希望避免出现什么样的负面影响。这样就能完成比较立体的干系人分析。
现在，我们也明确了各干系人通过项目可以完成哪些工作了，接下来我们就要去拆分一下这个大项目了——业务模块分解。
三、业务模块的分解
2B类的项目有时很复杂，会涉及到不同的业务，为了控制其分析的复杂度，我们通常会先将其分解成更小的部分，在这里推荐根据业务来进行划分。
通常采用的策略如下：
3.1 按业务职能分解
对于管理业务的项目，最典型的业务子模块划分就是按照业务职能进行的。
在划分之前，可以先绘制出与其相关的组织架构图，然后根据组织/部门之间的关系，划分出各个业务子模块即可，部门职能最典型的是产(生产/产出)、销(销售)、供(供给/供应)、管(管理)四部分。
如下图体检中心的项目系统划分：
3.2 按项目、服务分解
此时可以梳理出业务结构树，然后以不同的项目/服务作为划分的线索。比如，项目中涉及到不同的审批类型，而此时不同的干系人需要在不同的类型中扮演不同的角色，此时就应按照项目/服务进行划分“资金审批”“物资审批”“行政类审批”等。
3.3 双维度分解
对于一些更加复杂的系统，有可能需要采用上述双维度进行划分，先用其中一个维度做一级划分，再用另一个维度做二级划分。
本子模块需要其他模块提供什么服务？
本子模块能够为其他模块提供什么服务？
这些服务由谁负责提供？
这些接口哪些是现有的？哪些需要开发/修改？
好了，已经得到了不同的业务子模块，接下来就要对各个模块进行业务流程的分析了——业务流程的分析。
四、业务流程的分析
4.1 识别出相关的业务流程
2B项目的核心价值之一就是支持业务，而业务支持的核心是对业务流程的设计、固化、优化和重构。
所以，识别出项目的相关业务流程是很关键的。
4.1.1 什么是业务流程
业务流程是项目的核心，任何一款项目都有自己的业务流程(不管2B还是2C)。
在2B类的项目中，业务流程尤为重要。
业务流程通常是一个多人协作的过程，而且需要一定的有效规则进行控制，才能达到预期的效果。
如何才能有效识别出项目中的业务流程呢？企业或组织的核心价值在于响应外部客户/用户的服务请求，通过一系列的协作满足其服务请求，为客户/用户带来价值，同时为企业/项目带来价值。
也就是说：业务流程的起点就是这些外部服务的请求。企业中每个成员的工作都是属于某个流程的，而且会是多个流程。我们应该寻找其源头，即服务请求，这样也就识别出了业务流程。
寻找到源头只是起步，因为业务流程是要有一个合适的结束点的。这个结束点体现在服务请求从提出到满足的全过程，也就是要判断这个服务请求是否被满足或被拒绝。同时，也要考虑业务流程的边界，不要跨越到未涉及的业务域或者是系统未关注的部分。
4.1.2 如何识别出业务流程
在实践中，我们需要对各个业务子模块逐一进行业务流程的识别。我们可以按照一定的顺序去操作，一般会通过先外部(外部客户/用户请求)后内部(内部员工请求)的顺序进行，具体步骤如下：
(1)识别出外部引发的主、变、支流程
先识别出由外部客户/用户的服务请求，大部分业务流程会来自外部。
在此阶段，要明确子模块有哪些外部的客户/用户以及其他部门的员工会发起服务请求。
在此基础上，识别出主业务流程：主服务请求；主服务请求的变体流程：变体业务流程；支撑业务流程：更好服务客户/用户的辅助支持业务。
比如一个酒店住宿系统，主业务流程就是“办理住宿流程”，变体业务流程是“换房流程、续费流程”，支撑业务流程是“投诉流程、房内消费流程、行李寄存流程等”。
(2)识别出内部引发的主、变、支流程
有些服务请求是由内部员工发起的，如审批流程，还有的会在特定时间、特定状态下发起的，因此内部请求要作为补充。
在此阶段，要明确有哪些内部员工会发起流程，以及有哪些特定时间或状态下会引发的流程。将员工最核心的业务请求识别为主业务流程，将业务诉求的变体识别为变体业务流程，将辅助支持业务识别为支撑业务流程。
(3)识别管理流程
有一些业务流程是为了实现控制、监督和管理，要单独识别。
管理流程的识别通常会是一个难点，比较好的方式就是通过与客户/用户沟通交流获得。在此阶段，要注意几个维度的思考：是否需要业务的审批控制流程；是否需要人、财、资源的管控流程；进度及异常的控制。
(4)判断业务流程优先级
对业务流程做优先级判断，有利于做出合适的迭代计划。
业务流程是系统项目交付的最小单元，只有实现了完整的业务流程支持，对客户/用户来说才是有增量价值的。在识别完所有的业务流程之后，应对其进行优先级判断以支持项目迭代。
这里推荐从是否为主营业务与发生频率高度两个维度进行分析：
4.2 业务流程的分析
在识别出业务流程之后，就要对每一个业务流程进行分析，绘制业务流程图。
在分析之前，需要掌握两个关于业务流程的关键点:
4.2.1 业务流程是分级的
组织级流程：展现各部门间的协作，以部门为泳道/职能带区，读者对象一般是管理视野。
部门级流程：展现岗位间的协作，以具体岗位为泳道/职能带区，与部门协作无关。
个人级流程：定义岗位的操作规程，通常没有泳道，尽量细化具体流程。
子流程：个人级流程如果过于复杂，可继续拆分子流程。
层级关系：组织级流程>部门级流程>个人级流程>子流程。
4.2.2 业务流程的八要素
五个基本要素(分工，活动，协作，产物关系，分支)
分工(各部门、岗位间的分工)是流程中极其重要的要素，当一个流程中有了分工，就必然会将前一个人负责的事拆成一系列更小的、相对独立的工作任务，这就是“活动”。
当我们分析分析一个业务流程时，首先要明确出整个流程中涉及哪些分工、每个角色负责执行什么活动，然后选择合适的流程图将其表示出来。当然，这些活动之间不是相互独立的，它们之间存在顺序执行、并行执行以及异常执行多种可能，这就是“协作关系”，在流程图中就是各个活动之间的连线。
而且协作过程不是一成不变的，还需要根据实际情况进行处理，这就是流程中的“分支”。这也是流程图中的一个重要因素。
最后，在协作过程中，各分工之间需要传递工作产物(数据)，管理者可能会制定一些表单、数据表，这就是“产物关系”。在流程图中通常是数据流或文档等形式。
三个管理要素(审核、规则、异常)
审核通常对应着审批流程，在分析流程时，应识别出审批内容和审批意图，这样才能分析到位，并且在命名时不要采用“岗位名称+审批”的格式。
如果涉及到的是系统之间的业务流程，如“银行转账”等，这时通常需要强调的是系统之间的交互过程，此时最好采用UML时序图：
(2)勾勒流程主体。厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。
在这一步要注意：分工应平级。要么全是岗位名称，要么就全是部门名称，不要混着使用。
并且，应该绘制出业务全过程，不要考虑系统的边界，以免在后续的分析中遗漏。
最后，业务流程要从服务请求者开始画，谁发起的服务请求就从这里开始画起，保证流程的完整性。
(3)补充管控点。厘清业务流程中的异常、审批、规则。
首先，要和干系人代表就“异常”进行交流。重点的思考方向是“是否存在完全不能够按这个业务流程执行的情况？如果存在，应该如何处理？”可以用文字或异常流程图进行说明。
其次，要把重点放到“审批”上，可以询问相关干系人“现在有哪些审批点？还有哪些环节存在执行风险？需要增加怎样的审批流程？由谁进行审批？”等问题。
最后，再沿着流程，思考一下是否需要设置规则。
可以从下面几个角度着手思考：
协作间规则：用于控制流程协作的规则，比如“仓库管理员应该在每月5号前向采购部门上报采购申请订单”；
业务活动执行规则：在执行各个业务步骤时需要遵循的规则，比如“只对有审批盖章的文件进行处理”；
数据规则：针对表单、文档等生成产物的格式、内容进行限制的规则，比如“金额取小数后两位”。
(4)分析流程执行过程中的监控需求。从高层管理者的角度，对流程进度、异常等方面的管控、识别，补充一些辅助的相关需求。
在这一步骤中，我们要通过管理者获得相应的管理需求，可以在进度与效率、执行异常和其他管控三个维度进行收集。
(5)检查、优化流程。
在完成了业务流程的分析、绘制后，我们要回过头来，重新跑一遍各个业务流程，看一下是否有可以进行优化的地方。优化的策略如下：
清除无效(删除)。找到流程中浪费的、低效的环节，想办法清除。
简化高频(简化)。对于使用频率最高的流程进行优化，提升流程效率。
整合依赖(组织)。将相互依赖度高的环节整合到一起，提高效率。
自动化(转移)。将人做起来麻烦的事让机器去做，提示使用效率。
现在，各业务流程已经分析出来了，接下来就要识别出这些流程中存在哪些和项目/产品相关的业务场景了——业务场景分析。
五、业务场景的分析
用例、用户故事是我们耳熟能详的需求分析技术。它们的精髓在于“用户视角、业务场景/使用场景”。要求我们不再关注系统提供什么功能，而是用户在什么场景下需要项目/产品提供支持。
5.1 业务场景的识别
有了对业务流程的分析，识别项目/产品所支持的业务场景将变得很简单，只要基于流程图来识别出角色、场景，然后补充一些时间、状态触发的场景，最后将其呈现出来即可。
1. 基于流程图识别角色
明确以下维度：
要对这个流程提供支撑，至少要涉及到哪些用户？
对于项目/产品而言，这些用户扮演的是什么角色？
从权限角度如何抽象出这些角色？
2. 基于流程图识别业务场景
沿着流程过程，对每个活动、分支、判断点进行分析和思考：哪些业务活动要系统支持、哪些是不分支持，审批点是否属于系统内，判断点是否为独立环节。
3. 补充业务场景
除了由人触发的业务场景之外，还存在特定时间、特定状态触发的业务场景，它们有可能没有在流程图中体现出来。因此在完成前两步之后，还需要花费时间补充出这类易于遗漏的业务场景。
4. 绘制用例图并概述业务场景
当所有业务场景都识别出来后，我们可以使用用户图来呈现结果，并对涉及的业务场景做一些说明。用例图中最为核心的就是actor(参与者)与用例。
我想强调一下用例的概念：用例即业务场景(用户的使用场景)，一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。
用例图的表示方式如下：
5.2 业务场景的分析
5.2.1 概述业务场景
(1)该业务场景中，用户要实现什么样的业务目的？
用一句话概述用户执行该业务场景所要完成的业务目的是什么。要使用用户语言，重在传达用户的意图。
(2)执行该场景有什么前提条件？结束前需要保证何种状态？
对于一个业务场景而言，有时是需要执行条件的，有时则是在业务场景执行完成之前必须确保满足某个状态。分别称之为前置条件和后置条件。
前置条件是用户在执行该业务场景之前，系统/产品需要检查什么状态。例如用户在操作查阅合同报表之前，必须已经上传该合同信息。
后置条件是用户在结束该业务场景之前，系统/产品需要检查以确保什么状态。例如，在电商网站下单的业务场景，其后置条件是要检查下单数量要小于库存数量。
(3)除了场景的执行者之外，还有谁关心它？关心什么内容？
在一个业务场景中，除了执行它的用户之外，还可能涉及上游、下游、管理者、协作者等其他关心该场景的其他角色。对于一些关键的业务场景，还有必要思考他们有什么关注点，是否需要提供一些功能来满足这些需求等。
5.2.2 细化业务场景的业务步骤
细化业务场景的业务步骤时，可以通过访谈干系人代表、观察他们的工作、或者直接收集他们的操作规程作为输入。
在执行该过程中，可以思考三个维度：最典型的、用户预期内的业务步骤时怎样的；针对各个步骤，有哪些潜在的变化情况；针对各个步骤，有误异常的情况，异常如何处理。
5.2.3 重复步骤分析困难，导出功能
我们要针对每一步骤与客户/用户了解存在的困难、挑战，然后构思系统的解决方案。在这个步骤中，一般从两个角度来思考：
首先是执行这些步骤时会遇到什么困难，也就是思考“在这个业务步骤、变化及异常情况下会遇到何困难？针对这些困难，系统/产品需要提供什么样的功能支持”两个问题。
其次，分析是否存在一些关键的例外，会带来执行的麻烦，也就是思考“是否存在不能按以上步骤处理的情况？这种情况需要系统/产品提供什么样的功能支持？”
5.2.4 识别环境与规则
在分析一个业务场景时，还应该考虑环境、业务特点给系统/产品实现带来的要求和影响。
通常可以通过以下几个维度进行：
性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度。
易用性相关：主要是用户相关系统的使用经验，这对于系统易用性设计有着指向性的作用。
部署环境相关：说明用户所在的网络、软硬件等相关环境。
5.2.5 分析实现方式，完成初步的交互设计
此时的交互设计不是详细的交互设计，是初步的交互设计，通常包括以下几方面的内容：
交互过程：界面的跳转图，用来表达我们希望系统/产品如何实现该场景的所有业务步骤。
静态快照：即每个页面上的具体内容，通常可以使用纸面原型表达。
设计说明：针对于每个页面内容、界面跳转做一些描述，核心在于说明为什么这样考虑，以及这是一种建议还是必须如此。
截至当前，我们已经完成了业务流程与业务场景的分析，接下来，我们要为以后考虑，通过数据分析可以优化我们的系统/项目，这就要引出接下来的要点——数据指标的识别预分析。
六、数据指标的识别与分析
2B类项目重要的价值之一就是要支持管理，而支持管理的核心就是通过数据指标分析管理系统/产品，和通过数据分析完成后续的项目迭代。
准确的识别与分析出数据指标，能帮助我们很好的实现支持管理。
识别与分析出数据指标的核心在于：把握用户想要得到什么信息，明确他的管理意图是什么。
6.1 标识管理者
在这一步骤中，应该首先在子系统模块寻找到相关的决策层(高管)、管理层用户，然后在流程层级寻找相关的管理层用户，最后应该在整个系统层级寻找相关的决策层用户。
找到了整个系统所涉及的管理者之后，还应该继续判断他是属于哪种类型，比如管理型还是经营型，不同类型的管理者所关注的重点也是不一样的。企业级2B项目中涉及到的管理者通常有六级：
管理自我型：这一级别准确地说应该是员工，作为一个员工，也应该做好个人的一些管理，比如时间管理、计划管理等。
管理团队型：通常负责带领一支小团队完成上级交给的任务，比如组长、队长等都是此类管理者。他们关注团队管理、人员管理。
管理事务型：项目经理就是典型的这一类管理层。他们将对一件事负责，人、进度、资源都会涉及到。
管理职能型：此类管理层关注于多事务，也会关注人、进度和资源。
管理业务型：他们将涉及经营性指标，更加关注客户、产品、供应商等经营性主题，对具体的执行性事务关注较少。
管理事业群型：他们将管理多业务，一般对于资本、均衡等方面更加重视，想法会更宏观，通常他们关注的都是决策相关的内容。
6.2 识别管理意图
标识出所有的相关管理者之后，接下来可以通过访谈，侧面了解其职位职责及考核指标，标识出其希望通过项目/产品来实现的管理意图。
如果是管理型的管理者，建议从管理问题着手，比如事务管理、人员管理、财务管理等方面；如果是经营型管理者，则可以从经营性问题着手，比如客户、产品、供应商等方面。
6.3 分析所需指标
分析数据指标时，可以从正反两面进行。正面就是要思考分析业务设置合理性需要哪些数据信息，反面就是思考如果业务设置不合理会出现哪些情况，这些情况又可以通过哪些数据反映出来。
生成数据所需的输入条件：可以是界面呈现，也可以是基于查询条件。
数据来源：明确该数据是由哪些数据表中获得的基础数据，说明要对哪些数据进行统计。
数据报表中数据的格式与计算方法：逐一列举出每个数据项的格式及计算方法。
至此，一个企业级2B项目的分析与设计的流程就差不多了，但是还没有完，接下来要明确在项目投入使用之后，涉及到的维护性需求——维护性需求分析。
七、维护性需求分析
在维护性需求阶段，要抛开功能性思考，识别出有哪些维护性场景，以及维护场景需要提供什么支持。
7.1 标识配置性维护场景
对于企业级2B项目，第一种典型的维护场景就是各种配置，用来应对变化带来的影响。
那么，标识配置性维护场景应该从变化入手。
系统通常会遇到以下几方面的变化：
用户群变化：使用项目/产品的用户发生改变，比如他们的职位发生改变，他们的权限发生改变等。因此，要想维护用户、维护角色、维护权限，就需要一些相应的配置功能。比如，功能权限、数据范围权限、分配权限的权限。
流程变化：企业流程会根据自身发展过程中关注点的改变而不断进行调整，以满足阶段性的管理目标。因此，如何应对流程的变化带来的影响，是需要提前考虑的。
数据变化：随着企业业务的壮大，会需要在项目/产品中引入更多的数据项或更多的数据细节。因此，应该提前考虑如何应对未来增加的数据或数据构成的调整与变化。
法规变化：企业在经营过程中，有时会涉及法律法规的要求，而法律法规会在一定的时间周期内变更或出台新的条例。因此也需要考虑当法规变化时，如何有效应对。
因此，在该阶段，应该列举出项目/产品生命周期中可预见的变化，通过配置功能提前应对。
7.2 标识项目运行阶段的维护场景
项目在运行过程中，要确保其安全、可靠、稳定的运行。此方面，可以从正常和故障两方面进行分析。
正常时：系统正常运行时，要对运行状态进行监控，通过服务、网络通信、数据库等方面进行运维。
故障时：在系统出现故障时，需要及时有故障排查、故障修复等措施的支持。
7.3 其他维护场景
除了上述的维护之外，还包括以下其他维护场景：
系统初始化：在项目第一次运行时，需要提供什么样的初始化配置，安装什么工具等。
系统升级：在系统升级时需要提供什么样的支持，比如自动化升级、版本检查升级等。
系统迁移：每次系统升级时，是否需要进行数据迁移等。
维护性需求可以帮助项目/产品有效的应对待维护性场景，接下来，还需要明确一些项目的非功能性需求——非功能性需求分析。
八、非功能性需求分析
非功能性需求可以为业务提供稳定、可靠、易用的支持，因此非功能需求也是不可小觑的。
8.1 标识非功能需求
非功能性需求包括但不限于：安全性、可靠性、易用性、高并发、可维护性、可移植性等。
8.2 重要性排序
对于非功能去求重要性的排序，可以通过“威胁影响度”和“出现频率”进行判断。
威胁影响度：生命攸关>造成经济损失的>造成小损失的>操作不便的。
出现频率：出现频率可分为三级，经常出现、偶尔出现、低频率出现，可分别赋予不同权重。
不同的维度可以交给不同的人/团队，然后将结果相乘，根据最后的结果排序，找到最重要的非功能需求。
8.3 制定对策
对于以上找出的非功能性需求，我们要找到相应的对策去避免其发生，是采用技术手段还是通过优化业务去完善等。
8.4 验证矛盾并解决
在实际给出的对策中，有时会产生一些矛盾。比如，验证码与用户体验之间的矛盾，这时我们就要去衡量，是否可以有更高效的方式？比如，拖拽图形验证。再或者，为了系统的性能，不得不牺牲一些用户体验。
至此，整个项目/产品的设计分析流程就结束了。在整个过程中，业务规则会一直贯穿其中，深入理解业务才是最重要的核心。
九、总结
我们来总结一下，涉及到的整个流程如下：
项目目标分析
▼
各类干系人角色的分析
▼
业务模块的分解
▼
业务流程的分析
▼
业务场景的分析
▼
数据指标的识别与分析
▼
维护性需求分析
▼
非功能习惯需求分析
这个流程不一定适用于所有项目，活学活用，希望能给你带来一些启发~
———— / END / ————
———— / 推荐阅读 / ————
>> 后来，我就再也没乱提过需求
>> 一文读懂需求的科学化挖掘流程
>> 只是痒点需求的产品，怎么做起来？!
>> AI时代，从需求思维方式到专家系统实例解析
>> 你和别人沟通产品需求时，都有哪些要点和技巧？
实战派产品大咖手把手带你
搭建PM必备知识体系!
告别野路子做靠谱PM!
点击“阅读原文”，了解更多!
http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药