后端细节方案设计

流程和角色

我们要明确系统中涉及的角色，要和前期业务梳理中的利益相关方或岗位一一对应。无论是大型系统设计，还是某个具体需求的设计，都应该绘制流程图，帮助自己梳理业务、理清思路。通过跨职能分系统流程图，可以清晰地看出谁在哪做了什么。

角色在业务开展初期就已经存在，但在设计系统角色时，需要结合业务流程进一步梳理、修正和完善，以保证角色的工作内容明确并且固定。各个角色之间要避免职责交叉，这样才能保证团队成员分工明确、共同协作，达成业务目标。

有的时候可能会出现一个岗位对应多个业务系统角色的情况。在一些规模比较小的公司，或者业务开展初期的团队里，这种情况比较常见；在管理步入正轨的公司里，这种情况就比较少见。如果在系统管理中发现某些员工需要被赋予多个角色，最好和业务部门确认一下岗位的分工与定位是否合理。

除此之外，还需要绘制客户管理业务的页面流转图。页面流转图描述的是用户完成某项工作需要访问的页面，以及页面跳转顺序。一般来讲，产品经理绘制页面流转图时，都是针对某一个单一角色，绘制某个特定场景下的页面访问和跳转逻辑。从用户的视角梳理一遍所有相关页面，每到一个新页面时都要思考：需要新做一个页面，还是可以复用原有的页面。最终整理出系统设计的所有页面初稿。

页面流转图没有明确的形式要求，重点在于帮助产品经理在大脑中构思页面设计思路。通常来说，页面流转图比业务流程图更加细致。在页面流转图里，需要更加细致、准确地描述实现操作的具体步骤和对应的页面。

但不是所有页面都来自页面流转图，因为有些页面是独立于总体流程之外的，比如报表页、对账查询页等等。这些页面源自对功能模块设计的思考。

梳理场景并提炼汇总

一般情况下，业务型 B 端产品面临流程复杂、数据单据复杂的特点。对于产品经理，从已有流程入手分析业务是一个很好的选择。但有的时候，线下还没有业务流程在执行，产品经理就需要自己设计表单和流程。

在实践里，没有绝对的优先顺序，数据建模和流程建模需要互相依赖，持续迭代优化条件，不必拘泥于谁前谁后的问题，只需要根据实际情况按照最顺手的方式处理就可以。

独立一人负责的产品设计工作，梳理完不同业务场景之后，也应该有一个整体的汇总和进一步的总结提炼。

提炼汇总数据模型：这个工作也可能由技术人员完成，但是最好还是由产品经理也能够做出数据模型定义和设计，不用太精确，但是对于帮助理清系统背后的核心业务非常重要。
提炼汇总系统角色：在商业化软件产品里，很多时候由实施团队根据客户的运作模式和流程来设计并配置角色。但即便如此，系统也应该在标准流程预制一些默认角色，作为基准版本存在。
提炼汇总页面功能清单：不同的场景有可能会涉及相同的页面，因此非常有必要统一整理不同场景涉及的所有页面。很多时候在页面清单的梳理中，就可以将关键功能点也整出来。从本质上来讲，一套软件系统就是对不同数据对象的增删查改操作的集合。这个特点在业务型 B 端产品里会更加明显。

报表设计

报表可能是一张简单的明细表，也可能是一张复杂的汇总表。所以汇总表的设计具有比较高的难度，需要产品经理、业务人员和领导层等一起来讨论决定，形成一套科学的指标体系，以准确、有效地监控业务运转中的各种情况。

业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。只有从用户使用报表和分析问题的角度考虑，才能设计出优秀的报表产品。

观察、分析问题的视角和思路是报表设计的核心，交互和样式只是次要的外在。产品经理要尽量参与分析体系构建的过程，这是帮自己进一步理解业务运行和管理机制的非常好的机会，不要把太多精力投入在交互体验设计上。

同时，产品经理要尽量贴近业务。即便被动接受报表需求，也应该努力思考其背后的设计思路。等新的报表在线下实际使用过程中调查各种问题之后，再实现线上化，是一个比较好的选择。

报表上线之后，应该谨慎小心地进行一段时间的并行验证，也就是将线上系统计算的数据和线下手工计算的数据进行核对验证。确定线上系统的计算数据准确无误之后，再进行全面推广。

同时，B 端产品经理要了解数据仓库的基本概念，包括掌握数据体系的逻辑架构，构建逻辑集市、数据集市、星型模型、数据立方体等技术概念，这对于报表设计会非常有帮助。

采用报表引擎也可以大幅提高企业对报表类产品形态的开发速度，非常经济有效。除非有特殊的呈现需求，不然其他情况都推荐采用成熟的报表引擎。

总体而言，报表设计与应用的流程是：

构建分析体系：在构建分析体系之前，首先需要明确分析目的，也就是需要通过分析发现哪些方面的问题，然后思考该采用什么方法来识别和诊断这些问题，其中可能的困难是什么。构建分析体系必须建立在对业务深刻、准确的理解之上，并且要和一线管理团队多沟通。可能很多问题的分析框架和思路已经被一线工作者发现并有效实践了，一定要善于发掘并参考借鉴。
定义观察指标：一般会先从大的方面拆出几方面的观察指标，然后考虑是否将指标进一步拆解为二级指标，甚至三级指标，从而在更精细的维度观察、分析业务，更准确地反映业务特征。
设计呈现形式：在这个环节，产品经理要和实际用户多讨论，寻找最佳的呈现方式。
跟踪指标的变化。
分析变动原因。
跟进处理问题。

数据埋点

在网站里注入分析工具提供的代码片段，以便网站工具能够准确捕捉用户行为，这项工作就叫数据埋点。一般要先申请分析网站账号，然后获取埋点代码片段，将代码片段放入网站或 APP 的代码里，最后就可以观察分析数据了。

B 端产品和 C 端产品数据埋点主要有两个不同：

首先是诉求不同。B 端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率，为持续优化提供依据。

C 端产品通过数据埋点来持续优化设计。因为 C 端产品和经理、运营人员要想尽办法持续优化功能，而优化功能的前提是细致全面的数据埋点和分析，这样优化分析方向才是明确的。

其次是方案不同。B 端产品多为 PC 端 Web 站点。在 Web 埋点工作中，很多时候只需要分析页面级别的流量和行为就足够了，所以只需要部署一次公共 JavaScript 代码片段，就完成埋点工作了，然后就可以做基本的代码监控。

通常而言，默认的埋点只能记录 URL 的访问跳转等数据；如果想记录视频播放、按钮点击、文本框录入等行为，就需要针对事件做更细致的埋点监控。

C 端产品多为移动端 APP 版本，用户的操作都在屏幕很小的区域内完成，保证良好的用户体验非常重要，所以 C 端产品会对各种点击交互行为的监控非常严格，会对所有交互行为做细致的埋点，以便全面掌握用户的动作，并进行准确优化，工作量会大很多。

但无论是 B 端产品埋点还是 C 端产品埋点，无论是 Web 端埋点还是移动端埋点，都要遵循公司统一的埋点格式要求。埋点格式就是指在埋点过程中需要记录的拓展字段。

权限设计

权限设计是业务系统设计中一个非常重要的环节，因为这个环节可以反映产品经理对整个业务体系中岗位和流程的理解。权限设计合理的前提是角色设计合理。在此基础上，只要明确不同角色能访问哪些页面、能看到哪些数据，以及能做什么操作即可。

设计页面功能时，要考虑页面中的各个功能点是否需要做权限控制。相应地，在每个页面的设计文档里，除了描述页面功能本身，还需要描述系统中不同角色对页面中各个功能点的访问权限。

通常用权限表来描述权限角色的配置关系，这张表在产品设计阶段就要准备好。

RBAC 模型可以简单抽象为 ER 图：每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操作权限。

RBAC 模型中还引入了用户组的概念。如果用户较多，可以对用户进行分组，再将角色和用户组进行关联。有新用户时，只需要设置其所在的用户组，就会将用户组关联的权限赋予新用户。如果用户角色需要批量调整，只需要调整用户组和角色的关联关系，而不用重新变更每一个用户和角色的对应关系。

完整的 RBAC 模型理论称为 RBAC96 模型组。该模型对角色的继承关系、权限的约束关系等更复杂的话题进行了深入分析和指导。RBAC96 是对计算机系统权限管理的高度抽象模型，适用于任何业务系统。

角色在页面里能查到的数据范围，就叫该角色的数据权限。所谓能查到的数据范围，不是指能看到的数据字段，而是指能查出来的数据集合。

针对数据权限的控制，常见的实践方式通常有两种：

通过组织机构树控制：这个方案根据账号所在机构树中的节点位置，判断能够查询的数据范围。这也是最复杂的一种方案，但同时也最灵活，能够支持各种复杂的业务数据权限诉求。
通过客户地区控制：这个方案根据账号所在区域，判断允许查看的数据范围。实现起来比较简单，但灵活性比较差，只能满足非常初级的数据权限管理诉求。

当然，对于成熟的商业软件产品，还可以做更精细的设置。

文档编写与管理

在 B 端产品领域，必须有详细的文档留底。一方面，逻辑清晰的文字可以帮助设计人员进一步梳理复杂业务，以此完成设计；另一方面，这也是帮助研发人员理解设计、保证沟通理解一致性的重要保证。

随着公司规模扩大，规范的产品需求文档非常有必要。它可以让项目开展更有序，大大方便产品经理和研发人员的沟通，让知识传播与传承更加准确、有效。

写文档时，可以分成两种视角：

以业务场景和流程的视角来阐述设计思路。
以功能与模块的视角来阐述设计思路。

场景视角聚焦业务的实际应用场景和面临的问题，技术属性比较弱，业务属性比较强，更强调功能对业务的实际应用价值。从流程的角度出发，尤其是从单一用户视角出发来研究场景，天然更关心用户体验。但场景视角本身也有非常明显的局限性。如果是复杂系统和复杂生态，流程和场景无法体现业务和软件背后共性的抽象及本质。这也是为什么类似用户故事地图、用户旅程这类工具，在单一用户视角和简单场景下的 C 端产品设计中比较常见，但却不太适合用于 B 端产品设计。

功能视角聚焦业务背后的本质提炼和系统完备性的方案设计，技术属性强，业务属性弱一些。对软件功能进行高度提炼、抽象化、模块化的表述，天然会丧失业务场景的代入感，并忽略背后的业务问题，更聚焦于软件功能点。总体而言，功能视角是一种更偏向于软件工程和计算机视角的思路模式，对研发更友好。

工具型产品，场景属性本身就很强，并且软件复杂度相对而言不是特别高，因此完全可以从场景视角来描述软件功能、撰写文档。

业务型产品的业务流程错综复杂，很多时候通过场景来描述软件功能，可能会感到力不从心、无从下手。

从 0 到 1 的第一版软件设计工作，又像盖大楼一样，画图纸、定框架，这正是功能视角的工作方式。而从 1 到 N 的工作中，更多的是围绕某些具体的场景和功能点做设计，面临的系统性挑战要简单很多，通过场景视角来拆解功能，反而会更轻松。

产品形态如果是产品化的，那就要求软件产品能够支撑不同客户的诉求，对软件的抽象性和拓展性要求比较高。这就更需要将不同场景进行提炼抽象，从功能的角度来完成设计。

定制化项目很多时候也会采用功能视角做设计，但因为定制化项目更加聚焦单一客户的个性化业务，所以有些时候从场景视角来拆解、描述功能，也比较顺手。

如果产品需求文档编写者是甲方的设计人员，那么设计的软件产品大概率是内部使用的自研系统。内部系统更像是定制化设计，设计人员更关心解决实际业务场景和业务问题，相对而言不太在意软件的抽象设计。而且撰写产品需求文档很重要的目的是和业务方确认，所以选择场景视角会更容易些。

如果产品需求文档的编写者是乙方设计人员，那么由于在曾经的 IT 项目之中，本身就没有 PRD 的概念，所以编写的都是需求规格说明书。需求规格说明书本身就是功能视角的风格。

总而言之，如果乙方做的是从 1 到 N 的定制项目，则可能采用场景视角；如果乙方做的是从 0 到 1 的产品设计，则更可能采用功能视角。

很多时候，某些功能模块本来就代表了某个作业场景，场景和功能模块并不是一种非此即彼的关系。所以，在编写产品需求文档的时候，采用的视角也不是非黑即白。

在实践里，两种视角是可以融合在一起使用的，而且非常建议不要采用单一的功能视角，必须重视对场景和问题的还原。现代软件设计的目的是帮用户解决问题，而不是给用户上线功能。