本文分析了做后台数据cheklist需要注意的十个方面：需要哪些数据（业务）、数据的来源（技术）、数据操作、数据批量上传、数据校验、数据展示方式和性能、数据实时性要求、数据计算规则（口径）、历史数据和版本处理记录、数据变更。

做后台，经常需要跟一些数据打交道，稍不注意，坑就在那里。

虚拟场景：当业务方跟小明说，我们要加一个很简单的数据。

小明分析了产品需求，觉得场景上来说是合理的真需求，业务确实需要，我们也有这个数据，见过别的地方用到了，那就这样提需求吧。

到了需求会上，小明说出了自己的来意。

研发说：数据从哪里来的？哪个数据表？需要校验码？

加上这个数据要计算，展示性能我没办法保证啊，大概需要3秒才能展示出来，你能接受吗？

实际上：我们可能不会像小明一样被问的这么惨，但是确实存在遗漏的情况。

那么我们究竟应该考虑哪些方面呢？我列举了十个方面：

1. 需要哪些数据（业务）
2. 数据的来源（技术）
3. 数据操作
4. 数据批量上传
5. 数据校验
6. 数据展示方式和性能
7. 数据实时性要求
8. 数据计算规则（口径）
9. 历史数据和版本处理
10. 记录数据变更

接下来详细介绍：

一、需要哪些数据（业务）

第一步这个算是产品的本命了，老生常谈系列。

当业务方给你提一个数据的需求，你需要了解需求的场景，他们处于什么样的目的想要这个数据。

我们要做的就是分清真伪需求，找到他们的根本目的是什么？比如业务方说，给我展示一下每个课程里面的视频学生学习了多少秒？

我看下学习情况。

你继续追问下去，才发现他们是因为需要计算运营的KPI，定了一个指标是学生的到课率，想看看每个班级到课率的情况。那最后的产品方案也是不一样的。

得到业务真正需要的数据，是产品应该做到的。

二、数据的来源（技术）

数据从哪里来，数据要到哪里去？

很多时候数据从哪里来（在哪个业务群的哪张数据表或者接口里可以用到）是研发需要考虑的问题或者是需要运营手动输入的。但是因为数据的来源会带来一些产品需求上的变动，甚至需要一些流程上的变更进而影响了需求的时间点，所以产品经理最好也能考虑到。

比如数据源是其他业务群的数据，那么这个数据我们是从接口里获取吗？现在有这个接口吗？现在的接口支持批量获取吗？

一旦没有或者不支持，我们就需要提前向别的业务群提需求，或者咨询开发还有没有其他的方式得到。

三、数据操作：增删改查和权限控制

1. 增删改查看：常规考虑项

• 增加数据（新增和编辑页面，必选还是选填，单选还是多选，下拉还是输入，具体交互是什么，能否通过现有的关键数据直接取到不需要手动输入）
• 删除数据（能不能删除，删除后的影响，删除的提示）
• 修改数据（能不能修改，修改后的影响）
• 查询数据（需不需要支持表头的筛选，需不需要放在筛选区域，单选和还是多选，高频查询还是低频查询）
• 查看数据（查看页面需要展示出来，列表页面需不需要展示出来）

2. 权限控制

数据谁能看到？能看到全部还是部分？

这个依赖于用户权限管理后台进行配置.但是提出需求时，需要明确这里的数据需不需要添加数据权限，来控制每个人看到的范围。

比如只能看到自己城市的数据，只能看到自己业务群的数据。

四、数据批量上传

1. 什么时候需要数据批量上传

考虑数据量：当新增数据有一定的量级的要求，人工新增耗时耗力的时候，应该考虑或者提前考虑到数据的上传；

实际上后台产品会经常用到批量上传功能，因为后台的主要目的就是提升效率，而批量数据录入是必要的手段之一。

2. 传什么

给出模板

3. 传上去之后的校验和错误提示

校验会在数据校验处说到，错误提示，最好给出上传数据条数、失败条数、成功条数。并选择恰当的方式给出错误的信息（Excel、直接罗列等）。

4. 数据处理

覆盖数据还是重复数据上传失败；部分失败是部分上传成功还是整体上传都失败；非必填数据的默认数据处理方式。

五、数据校验

• 常见数据校验：格式（中英文、数字、特殊字符）、长度（**字符以内）、必填还是选填、有效性（例如商品ID）、重复；
• 时效性：什么时间内可以支持增删改查；
• 其他：按照需求要求做校验；
• 数据上传时的校验。

上传的时候同样需要考虑以上所有的普通校验；

表头的校验和提示（解析为对应字段）：表头名称不符、表头未填无法识别。

六、数据展示方式和性能

1. 数据展示方式

列表页面需不需要展示出来，查看页面需要展示出来，数据展示的交互形式；

2. 性能

一些交互的渲染或者口径的实时计算，会使得页面的加载速度变慢，这时候需要考虑展示性能的优化。

比如将一些数据由进入页面时拉取和计算全部相关数据改为手动点击触发单个数据的计算；比如将列表页数据由100条降为50条，也可以缓解加载速度变慢的问题。

七、数据实时性要求

一般根据数据的应用场景考虑T+1数据还是实时数据，对实时性要求比较高的数据会选择实时数据，要求不高的直接选择T+1数据即可。如果数据依赖于其他的业务群，一定要确认好该数据接口的实时性问题。

额外的，会因为展示性能的问题，选择*分钟或者*小时缓存，来解决实时计算带来的服务器压力；同时避免T+1的数据延迟时间过长。

八、数据计算规则（口径）

明确数据计算的规则，

举例：转化人数是满足什么条件的属于转化，支付状态，购买顺序，多人转化归属。

最好是给出多个案例，辅助大家理解口径的计算。

九、历史数据和版本处理

对于已有的数据表，增加一个数据字段，一定要考虑历史数据的处理，一般采用历史数据默认选择为**。

十、记录数据变更

后台的数据口径是复杂而变动的，经常出现的现象是很快忘记了之前指定的数据口径，或者面对新的公司发现没有任何数据口径的记录。

这需要产品经理做好数据口径变动记录，利人又利己！

至于数据相关的一些功能：数据列表、筛选区域等需求的注意事项，会在接下来的checklist中讲到。

本文由 @后台阿喂 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于CC0协议