新增一个功能不是说只是简单地加上去就可以，要考虑很多因素。比如作者分享的新增报表这个功能，要考虑的这几个问题点，你都有想过吗？

对于B端产品经理来说，当一个新功能平稳运行了足够长时间，数据也逐渐稳定，这时急需一个报表功能方便业务数据的统计，从而进一步指导业务的发展方向。

作为一个经验丰富的产品经理，做报表时具体又需要涵盖哪些重点呢？下面一起来看看吧。

1、报表的取数基础。

这是一个报表的底层逻辑，报表将如何取数，就首先要对取数功能的历史数据进行分析。比如仓库系统中的盘点功能，在设计盘点报表时，要考虑盘点单的类型，日常盘点是否需要计入报表中。这里就需要深入业务使用场景去分析了，还需要了解一些用户在管理上的一些预期和行为，针对这些问题，确定报表的呈现范围。这是报表是否可以直接指导业务的最重要基础。

2、报表都有哪些维度。

一个报表可能在时间上区分不同维度，比如去年和今年数据，就可以区分出今年业务量发展的趋势，甚至可以用于预测明年的业务量，提醒管理层提前做好准备。也有可能在一些关键字段上按一些报表汇总统计，比如各门店的销量报表，可以设立地区维度，这样很方便地可以看出销量与地域之间的差异。

3、报表是否涉及重算功能。

当报表取数的基础是动态数据时，在报表数据生成的时候数据还未定型，并不准确。为了能第一时间生成模糊数据进行参考，以及一定时间段后数据稳定下来保证数据真实可靠，我们需要给报表设置固定的或者手动重算功能来满足业务发展需求。

4、数据权限的处理。

报表涉及的数据是公司整体数据，一般用于管理层分析数据使用。有一些权限较低的一线业务员也需要查看报表的一部分内容，但是其他部门的业务数据应该是不可见的。这就需要在设计阶段就规定好该报表的功能权限如何设置，包括公司权限、客户权限、商品权限等多个维度。

5、使用报表的人群有哪些，是否涉及不同部门的使用，如果涉及需要考虑敏感数据针对部分人不可见。

比如erp系统中的销售数据报表，管理层、财务、业务都会频繁使用。但是涉及一些企业单品利润的列，比如毛利率、成本率等，只有部分管理层和部分财务才能掌握。就需要针对这些特殊列设置一定的数据权限。可以借助特殊权限组的形式来实现。这条与第四条是相似的，但又要注意区分，第四条指的是数据行的权限，第五条指的是特殊列数据权限。两种权限规则都非常重要。

6、写明报表的基础信息表是从系统哪个功能或者哪张表取值的。

这一条主要是为了便于开发人员直接取数据，减少沟通成本。基础数据有时可能来源不止一个功能，不同功能取数逻辑不同，这里也需要前期跟相关业务部门沟通清楚，如果是SaaS系统需要产品自己思考清楚用户场景。比如同样是取销量，财务口径的销量和业务口径的销量统计是不同的，需要确认是哪一个。由于报表的其他维度都是在这个基础表的基础上进行汇总计算的，一切的数据来源都是这个基础表，所以一定不要弄错了，避免上线后报表实用性不强的问题。

7、涉及本报表的计算相关列，需要写明计算公式，复杂时需要举例，并且必须重视维护准确的提示信息。

所有功能的复杂计算，都要写明提示信息，或者在醒目位置放上说明文档，才能保证我们的报表上线后，提供的数据是真实有效，并且可以直接指导业务生产的。

8、做好需求文档的版本迭代。

文件工作被很多产品诟病，觉得这部分工作枯燥无味，产品应该把时间花在需求调研和用户沟通上。我见过很多说起场景、需求时眉飞色舞，但是一看文档乱七八糟的产品，实在是美中不足。我们做产品要脚踏实地，这个岗位是一个重沟通的岗位，一个复杂功能要在寥寥千字的需求文档里交代清楚，文档表达能力是最基本的。要珍惜每一次与用户、开发的沟通，真正站在用户角度思考问题，并且使用对方的语言去描述。被误解是表达者的宿命，产品经理的宿命就是尽量缩小每一次的被误解空间。所以与用户、开发多次沟通需要保留每一次的原型与需求文档，最好记录每次调整的内容或者将调整内容标红显示，便于开发时遇到问题，追溯需求的来源。

9、写清报表数据生成的触发机制，是使用定时任务还是人为点击，按照什么逻辑生成一期报表。

报表的数据量是很大的，而业务数据又在不断地变动，报表的取值不可能实时更新，这样太过于浪费资源。所以需要设定一个合理的生成逻辑，再选用对应的技术手段，考虑报表的数据量，选取一个又快又好生成报表数据的策略。

这是【具体才是阶梯】系列文章的第二期，第一期文章是关于“新增字段时需要考虑哪些问题”，还原点击我的主页查看哦。期待与您的交流~