小诀窍：不妨尝试从交付质量上打败对手

关于作者：小姬，某知名互联网公司产品专家，对数据采集、生产、加工有所了解，期望多和大家交流数据知识，以数据作为提出好问题的基础，发觉商业价值。

0x00 前言

我将整理文章分享数据工作中的经验，因为业务内容上的差异，可能导致大家的理解不一致，无法体会到场景中的诸多特殊性，不过相信不断的沟通和交流，可以解决很多问题。今天我们首先分析一下职场基本功，为什么要重视需求质量，常见的数据需求文档改怎么写。

以下，Enjoy：

0x01 为什么要重视需求质量

如果想快速的提高自己，但是不知道从哪里开始，不妨尝试从工作中将最为常见的需求文档质量提高，相信我，一份有优秀的需求文档，就可以让你打败了大多数的数据同行。

为什么要重视需求质量

• PRD是产品经理最直接，最重要的交付物；

• PRD的功底最容易体现专业能力，依靠逻辑和描述能力，直观反映产品思路；

• PRD曝光次数较高，是最佳的印象产品，产品的开发依赖技术人员，PRD的设计才是产品人员的核心；

• 最佳赢得口碑，给人以靠谱的感觉的交付物；

• 锻炼编导能力，梳理思维逻辑，提高业务水平的最好方式。

我的数据需求产品文档主要有：项目背景、项目范围、目标收益、需求详述、交互原型、功能说明、校验测试七大模块。在实际的工作场景中会根据情况做调整，基本情况下形成自身的特点（产品文档规范），并且自身的特点是高于团队质量的，长久坚持下去就会得到更多的认可，同时容易规范自身的思维，形成方法论。

0x02 怎么编写项目背景

• 任何需求不要忽略项目背景模块；

• 项目背景通常是最基本的项目需求，将所有的受众想象为职场小白，考虑怎么最简短的文字描述项目。

项目背景的书写方案其实很简单，抓住“问题+目标”两个关键字就可以。

• 什么场景下造成了什么问题；

• 什么样的诉求，实现什么目标。

整个项目背景以“问题+目标”描述一个场景下会发生什么问题，期望以后怎么解决类似问题作为目标达成，就是一段简洁明了的项目背景描述。

0x03 编写项目背景的过程分析

我做过关于数据标准化治理的项目，当时的目标诉求主要为：一致性，效率提升。为什么要设定这样的目标，因为我们经常受到“数据的问题困扰，数据生成过程中的内耗严重”。我们以“问题+目标”来总结分析一下项目背景的速写

问题

• 大家看到不一样的数值，对数据准确性的校验成本很大；

• 数据口径多样化，指标数量的膨胀导致数据问题严重，维护成本高；

目标

• 提高数据使用满意度，不要总是花费精力对数据进行校验；

• 效率提升，提高数据仓库的易用性和扩展性，降低开发难度；

鉴于以上的“问题+目标”，作为数据产品经理很快第一时间定位和反思了问题，决定以建立稳定的数据评估体系为基础，推动数据生成加工的标准化工作。

0x04 实战项目背景示例

项目背景

业务发展过程中未能建立有效的数据评估体系，数据维度/指标口径不一致，数据耦合严重，导致各业务数据的指标体系繁多，滋生了多种多样的数据问题。

数据问题的严重性，不仅增加了数据口径的理解消耗，还增加了数据生产和维度的难度，让参与数据建设的各方人员都为数据的准确性校验、数据问题排查耗费了巨大精力。因此建立稳定的数据观测体系，解决上述问题中的“效率提升，一致性”。

• 搭建稳定的数据观测体系（维度指标体系），让数据从生产到使用的整个流程更加标准、可靠；

• 稳定的数据观测体系，不仅能够让数据加工、使用的效率提升，还有利于统一认知，规范数据建设者的工作方法，解决数据维度/指标膨胀，数据不一致的问题，从而拉升内部的相关人员整体的数据专业水平。

本期将数据评估体系拆解为示例，以单页面数据评估为案例，优先对产品单页的价值进行评估，明确数据维度和指标体系，并以产品工具的形式向内部的目标用户提供数据可视化工具。

内容纯属虚构，不代表作者真实工作内容。数据治理属于长期且较大的项目，因此这个背景的描述内容多、话题偏大，实际工作可以根据项目大小有所增减或是量化具体。

0x05 为什么明确项目范围

任何项目一旦涉及到跨部门多人协作，或者是作为内部的横向打通产品工具，首先应该意识到项目推进过程中会出现各种阻力，同时又要考虑新的产品策划方案，对业务或是现有其他数据产品工具影响。

因此，明确项目的功能范围，解决业务环节上的什么问题（不承担解决什么问题），团队的成员各自负责哪块项目工作内容，是项目协作和保障项目顺利进行的必选项。常见的项目范围包括两点“事”和“人”，主要做以下考虑：

• 内容：

  项目管理的重心，解决什么业务问题（不解决为什么问题），项目能够达到什么期望值；

• 协作：

  实施明确到人的管理办法，明确项目的接口人。

5.实战项目范围示例

项目范围

产品资源

• 数据PM：

  李四

• 数据RD：

  王五

• 需求方：

  小明，小红，小白。

数据现状

• 全产品共计156个页面，其中活动营销性页面48个；

• 数据埋点比例85%，其中24个页面埋点存在缺陷，需要补充埋点；

• 数据转化模型目前公司存在3中，本次方案采用透传方案作为页面转化率的数据模型分析；

业务诉求

• 提供数据可视化工具，查询、下载所有页面数据明细报表；

• 解决因数据不一致导致的，数据校验成本，数据沟通成本的反复问题；

• 改善数据开发过程耗时久，各业务之间重复建设的现象。

0x07 为什么要设立目标及收益

聚焦收益，能够明确量化目标，很多工作场景下过分的苛责量化目标，但是学习从概念或是模糊思维中去抽象出量化目标，同大家达成认知的一致，具有共同的成就感和使命感，仍然是产品经理人员的必备技能。

0x08 编写目标及收益的过程分析

一句话，是否能找到数据来衡量目标中的收益。让结果以数字的增长来体现。目标收益在没有明确KPI的情况下，则需要自己创造出KPI，设定目标值。

0x09 实战目标及收益示例

项目目标收益

• 影响产品、运营、技术团队共计xxx人；

• 预估单项目节省人力xxx，节省时间xxxpd；

• 支持以多维形式聚类维度查询页面数据报表、下载分析，数据覆盖日常SQL取数的xx%；

• 支持日、周、月报形式对大盘数据进行汇报，减少工作数据报告制作时间xx%。

0x0A 编写需求概述的过程分析

为什么有需求概述，这不需要多说，编写需求概述是真正的考验业务理解和产品能力的重点，对于需求概述的编写可以参照两点中心思考：

• 如果作者不在场，读者是否能过通过阅读文档的方式理解项目自行TODO；

• 如果项目过程中出现盲点或是纠纷，需求概述部分是否可以保全基本的需求产出不受影响。

0x0B 实战需求概述示例

需求概述

为产品内页面搭建通用型的数据评估体系，明确页面效果评估中采纳的维度、指标。以统一的可视化数据分析工具落地项目，避免各自业务线重复的数据建设工作，同时优化数据仓库模型，提高数据的使用效率，解决因各自数据口径问题不一直产生的数据歧义。

数据定义

以下为本期页面数据评估体系内的维度、指标口径，其中包含维度9项，指标10项目。此为产品页面分析中使用的基础明细数据。支持以表格形式预览，下载分析。

数据体系（简单举例）

• 日期：

  格式：

  20190701

• 平台：

  枚举值：

  全部、iOS、android、其他，例如web、TV归为“其他”

• 版本：

  格式：

  8.1、8.2，仅支持x.x版本，8.2.2归为8.2版本

• 曝光UV：

  注释1

• 点击UV：

  点击用户数，全页面以日为单位去重。

  实际为用户设备id去重。

• 订单数：

  通过路径模型追踪得到的，访问过本页面路径产生的订单数量。

  用户提交订单日期在统计日期内，且截止当天23:59:59未取消的订单数量总和

• 每1万展示UV带来多少交易额：

  (支付金额/曝光UV)*10000

注释1：曝光UV可以通过多种方式获得，常见的方法为依靠模块埋点作为基础数据计算，在模块颗粒度级别的埋点中要多加注意埋点的上报时机。

模块数据上报时机如下

• 露出上报采用实际展示曝光上报策略，只有当事件本身实际曝光显示在屏幕当中才需要触发上报策略进行数据上报（露出像素>0px）；

• 滑动：

  在页面内上下滑动时，不重复记录；

• 刷新：

  刷新当前页面时，重复记录曝光；

• 翻页：

  下拉到新一页后再返回到前一页，上下滑动不重复记录

• 返回：

  事件点击到落地页后，从落地页返回（包括返回按钮返回、滑动返回、支付等行为后自动跳转返回），不重复记录曝光；

• 唤醒：

  • a) 手机锁屏被打开，直接展示事件所在的页面，不重复记录曝光；

  • b) 应用或者浏览器在后台被唤醒，展示广告所在的页面，不重复记录曝光；

注释2：数据评估体系的搭建需要结合多部门业务诉求后，综合统一规范之后给出；注释3：数据评估体系为基础的数据维度和指标，产品可视化展示根据实际的报表需求，进行多维汇总、聚合。

数据矩阵

以下为指标所需要监控分析的数据维度，✔️表示需要， ❌表示不需要。

数据矩阵（略）

注：数据矩阵，即cube矩阵，通过数据矩阵形式,需求方需对自己的数据进行更深的思考，它帮助RD和需求方在每一个维度和指标的筛选上进行思考，通过长时间的交互，可以让双方更专业的理解数据业务和数据加工的逻辑，让业务可以深入的理解数据，进而尽量让所有能预处理的数据预处理，减少推送明细数据，动态计算的需求方案。

注: 【查询】是指显示的结果是否包含该维度；【筛选】指是否用该维度过滤数据；【分组】是指是否用该维度汇总数据。

0x0C 编写交互原型的过程分析

产品经理的工作不只是画图，但是画图不擅长的人一定不是产品经理。交互原型的设计讲究实用，让人读懂。初级的追求美感本身也没有错，但是重点是美感之前的逻辑清晰。作者本人在原型交互设计中比较喜欢OmniGraffle这款工具，主要是考虑一点几点：

• 选择OmniGraffle的的原因是它能导出优秀的PDF格式，整体的方案单个PDF文件搞定；

• 在方案设计上的使用感发挥想象力的空间更大，对交付物有要求的同学可以多尝试一下；

• 如果是项目性强的产品工具策划方案，我通常会将整个方案全部以OmniGraffle完成。

0x0D 实战交互原型示例

暂略，后续会专门输出一个PRD交互方案。

0x0E 为什么要有功能描述

多数的功能描述体现在交互原型中，如果方案本身不涉及原型交互，对于功能的描述信息单独呈现。比如本次单独的项目中，如果涉及到数据仓库底层的内容，可以一并写在下面，供给研发使用，关于一个方案需要涉及多深的层次，因不同的公司，部门，人员能力不同多有差异，个人比较倾向的原则是，作为产品类岗位，永远要有主动承担灰色地带的觉悟，多向前迈进一步，多渗透交叉。

0x0F 实战功能描述示例

以下为本项目已知的数据底层内容

• ta.table1：

  基础流量表（需要单独将页面数据抽新表）

• ha.table2：

  订单数据表

• aa.table3：

  城市维度表

数据验证方式

• 数据仓库内应用层数据表SQL校验。

• 分析师或PM手工验证。

• 历史数据需要回溯（2019.01.01起）

数据调度周期：日（期望每日8：00前产出数据）

0xFF 总结和思考

今天整理的文章分析是数据工作中的开端和基础，希望让伙伴们意识到需求文档交付质量的重要性并尝试有所提高自己的工作方式，接下来的文章我会根据这份需求文档来聊一下如何实现这个需求，为了实现这个需求都哪些数据产品和工具，数据仓库中的数据是怎么加工生产的，以及我们的数据都是怎么来的，希望能够对你有所帮助。