1.3 以业务为中心解决的问题

本书提出以业务为中心的框架，并给出实战方法，目的是要解决产品经理的问题。本书主要解决如下问题。

1.3.1 C端和B端产品经理的提升之路

C端产品经理也要做业务设计。此时，C端产品经理既要设计前台页面，也要考虑后台逻辑和异常流程，这样才能保证业务的完整性。但往往C端产品经理的业务设计能力并不强。所以对C端产品经理而言，如果说页面设计是其看家立命的根本，那么业务设计就是其提升能力的必由之路。

业务设计整体框架中的做细节和画界面层面，以及搭框架层面的功能框架部分，也适合C端产品经理来学习。适合的典型模块包括用户下单和退货、登录和注册、视频认证、优惠券领取和使用等。

业务设计显然是B端产品经理的核心工作。业务设计整体框架中的四层、九个要素都适合B端产品经理学，并可用于商品管理系统、库存管理系统、合同审核系统、排队系统、收银系统等的设计中。

1.3.2 编写内容全面的文档

要把业务考虑全面，不遗漏大的需求，这是毋庸置疑的。然而在过去，即使考虑不全面，也是可以容忍的。原因是过去企业的规模小、用户量小，即使没有考虑全面，以后也可弥补，不会造成大的损失。但现在企业规模大、用户量也大，如果需求考虑不全，就会产生大的影响。

比如，大型电商平台的分销系统就要考虑全面，如果上线后才发现有的功能没做，那么将导致业务无法运转，并产生严重损失。再如，给银行做CRM系统也要考虑全面，否则发现用户的需求没有满足，出现用户信息的重复，或者不符合国家的监管和安全要求，也将产生灾难性的后果。

本书将通过涉众分析、参与者分析、用例分析、梳理流程、梳理状态和梳理类等方法，来保证将业务考虑全面。

1.3.3 编写研发人员不返工的文档

产品的需求考虑全面了，也就是在广度上考虑周全了，但还要在深度上思考，即产品的细节也要考虑周到，否则将导致资金损失、研发人员返工等问题。因此，我们要通过学习流程图、状态图和类图等，来保证在细节上考虑周到，下面进行举例说明。

1.流程设计的问题

比如，用户要进行人脸识别认证，企业的人脸识别系统用的是第三方的，所以每次用户做认证，企业都要付出成本。如果用户反复进行人脸识别认证，企业就会产生不必要的费用，同时多次认证也不利于账户安全。所以，当出现用户反复识别认证也没通过的情况时，企业就要转为人工验证。如果产品经理没考虑到这一点，就会给企业造成损失。

2.审核信息的问题

在上面的人脸识别认证案例中，产品经理可通过迭代来弥补，只会产生资金损失，研发人员还不至于返工，但有的时候就需要研发人员返工了。

比如，一个商品的审核流程是在商家发布商品后平台就要审核。但有的产品经理会这样设计该流程，就是把要审核的商品分配给若干审核员，这样做似乎很合理。但是如果审核员因故未到岗或中途离开，要怎么办呢？再如，新员工做得比较慢，如何给新员工少分配一些任务？这些细节不考虑，将导致业务无法运转。

3.信息结构的问题

公司是做企业应用的，服务的企业可以登录后台。如果产品经理设计成只允许一家企业的账户登录，并且以手机号作为账户标记，这样就会产生问题。比如，以后多个账户同时登录怎么办？员工换手机号怎么办？有的读者说可以到时候再改，但对研发人员来说，如果设计不周，则意味着要大改。

在以上案例中，人脸识别认证案例对应业务流程设计，商品审核案例对应业务操作设计，企业登录案例对应信息架构设计，这些都属于做细节的要素。所以产品经理应仔细考虑以上问题，来避免研发人员返工。

1.3.4 实现高质量的调研和沟通

产品经理如果能设计好业务，则意味着做用户调研也会做得很好，日常沟通也更清晰。我们讲的用例、流程、状态和类的分析，就可以达到这些目的。比如，产品经理设计了排队系统，其用户调研和产品宣讲分别如下。

1.用户调研

产品经理通过用户访谈，就可以梳理出人工排队的流程。

在宾客到达餐厅后，服务员询问是否预订；如果宾客回答没有预订，则服务员询问几人就餐和手机号；如果宾客回答5人就餐并报手机号，则服务员会输入5人和手机号等信息；最后，服务员将纸质排队小票给宾客。

以上内容就是按照流程图念出来的，所以说流程图画好了，表达就清晰了。

2.产品宣讲

产品经理在理解了人工排队的流程后，就可以设计排队系统了。产品经理可向研发人员这样描述该排队系统：

在宾客到达餐厅后，服务员询问是否预订；如果宾客回答没有预订，则服务员询问几人就餐和手机号；如果宾客回答5人就餐并报手机号，则服务员会输入5人和手机号，并确定；最后系统打印排队小票，服务员再将此小票给宾客。

读者在学了流程图后，就知道用户调研和产品宣讲的内容，都是按照流程图的内容设计的，只是加入了少量转折词。所以只要流程图画好了，用户调研和产品宣讲就能做好。同样，用例图、状态图和类图画好了，用户调研和产品宣讲也能做好。