在产品流程里，画完原型不代表设计阶段就结束了，还有好几件事需要做：数据埋点、权限设计和文档管理。这篇文章，我们看看作者的分享。

产品的详细设计在原型图设计完成后，是不是就大功告成了？

诶，好像还没有，剩下的几个部分是我初入职场时，经常会忘记的环节，但又非常重要。

主要有什么呢？

• 数据埋点：对系统埋点，可了解用户的真实操作路径，使用习惯等，是考核产品使用程度的重要依据之一，也是业务用户行为分析、产品分析、产品改善的重要参考数据来源；
• 权限设计：用户在访问我们的系统时，只能浏览/管理其有权限的页面，保障了数据隐私与管理制度方面的诉求；
• 文档管理：本文主要介绍产品需求文档（PRD）的编写、主要包含的 内容等（这个倒是不会忘，只是里面有些细节容易遗漏）。

让我们开始正文部分吧。

一、数据埋点

工作中常遇到的埋点之痛：

• 业务需做数据分析发现，统计的埋点数据不对或该埋的点没埋，不该埋的埋了一大堆
• 业务一句话的需求，也不说明白想要看什么指标，需要做什么分析
• 产品这边埋点需求文档每个业务线都不一样，我到底按哪个标准来？
• 埋点事件的存在性好测，埋点数据的准确性测得我心累

……

基于上述经常发生的事情，我复盘了一下以前几家公司的埋点工作流程，重新制定了一套方案供大家参考：

1）首先确定埋点的目的与必要性

我会让自己多思考一下为什么要给这个事件加埋点，不加的话有没有别的地方可以统计相关数据？确定要加，那最终是为了统计什么？都用于哪些方面的分析？

2）产品内部制定好埋点文档规范

包括埋点名称规则、没点类型、版本规则等，便于下游同学实现与查阅；

3）埋点的格式说明

在埋点过程中需要记录的扩展字段，例如，业务系统在埋点时，除了获取按键点击行为，还要记录事件发生时该业务用户的所在团队，后期分析时，就可以观察不同业务团队的操作习惯，及对不同功能的使用程度；

4）定期复盘埋点准确性

收集历史已使用埋点数据业务方的反馈，及已有埋点对业务支撑的效果等，定期检查埋点数据的准确性与赋能情况。

埋点文档举例如下：

大家可根据自己公司业务情况，增删埋点文档所需内容、制定相关规范，只要符合业务需要即可。

二、权限设计

等于功能权限+数据权限。

主要涉及不同用户/角色能访问哪些页面、能看到哪些数据以及能做什么操作等 。

1. 功能权限

我一般常用表格进行梳理，包括页面的权限、页面中元素（如按键）的权限等，一般根据业务管理情况看权限需要细到哪种程度，权限数据举例如下：

其中“√”表示可以访问或操作，“×”表示不可以访问或操作。

其中第5行一级导航列空白，因为“计划详情”页在导航菜单中不可见，但可以通过计划列表页的计划名称超链接进入。

需注意：在设置按键的权限控制外，点击按键进入后的页面也需做页面权限控制，若用户知道该页面的URL，即使看不到按键入口，也可以访问页面，容易出现数据越权等问题，所以页面级别的控制也是有必要的。

除了表格梳理外，还有一些针对权限管理的模型：如 RBAC模型

模型描述了一套用户、角色、权限组的设计理念。每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操作权限。

简单抽象一下RBAC模型，用ER图来表示如下：

RBAC模型还细分了几种不同模型，若大家感兴趣可进行该模型的详细查阅学习。

2. 数据权限

我较常用的方案是：组织树+数据权限配置

两个维度叠加管理，满足组织多层级权限管理诉求的同时，还可灵活配置每个角色在对应层级的数据范围，数据权限配置可划分成仅本人、本人所在组织及下属组织、仅本人当前组织、全部。

举例某一集团组织架构如下：

若通过以上方案实现后，工程部-管理员，可以访问全部客户所有数据，生产部-负责人可以管理客户1公司及其子节点上的所有数据，除了能与前面角色一样的数据范围，还可以修改成仅当前层级的数据范围，下级子节点的数据不可见，灵活度较高。

大家可以根据业务实际情况，设计权限配置所需要支持的程度。

三、需求文档

这里主要介绍产品的需求文档（PRD），文档内容尽可能完善、易于理解、非必须在文档中体现的内容，尽量不要加进来，不然会影响下游同学的阅读成本。

我常用的需求文档结构如下：

1.文档标题：注明系统、版本号、时间

2.需求来源：业务方、优先级、时间等

3.项目背景：包括业务现状、面临的问题、解决思路等，必要的数据分析结果

4.项目预期目标：可以是考量功能的使用情况、满意度等，也可以是直接收益或业务价值

5.修订记录：在系统正式上线前，记录每次针对需求的修改、变更时间、变更原因、变更人等，便于后续出现问题好追溯

6.项目方案概述：简述项目方案即可

7.项目范围：项目涉及的系统、产品，以及项目的影响范围，提前确认好项目关联方、影响方，避免需要其他方支持时，但对方确表示之前没接到过这个需求的情况

8.项目风险：项目中可能存在的产品风险、运营风险、技术风险等，以及这些风险的应对方案

9.需求清单：列出本次版本需要做的所有功能点/需求点，简要说明相关页面和大概内容即可，让团队成员对整个迭代有个大致预期

10.功能需求：

1）产品框架：系统框架图、业务流程图等，根据实际情况添加相应内容

2）产品详细需求：原型图及各页面详细说明

11.埋点需求：本次版本需要做统计/分析的埋点清单

12.角色和权限：本次版本涉及到的角色，及其权限说明

13.初始化配置：为了便于用户使用或历史业务支撑等，可能需要提供初始化方案，如原来代码写死的审核流程，迭代成系统页面后，支持用户自行配置，那迭代后，就需要将原来写死/线下业务在用的审核流程通过代码自动同步到新增的配置页面中，否则上线后，会影响客户实际使用。

需求文档看起来涉及的条条框框很多，不过实际工作中，很多要素基本一两句话可以概括，主要能让大家快速清晰的理解我们要表达的事情就可以了。

好了，以上就是我这次的分享了，希望可以帮到你，欢迎一起交流学习~