关于作者:小姬,某知名互联网公司产品专家,对数据采集、生产、加工有所了解,期望多和大家交流数据知识,以数据作为提出好问题的基础,发觉商业价值。
我将整理文章分享数据工作中的经验,因为业务内容上的差异,可能导致大家的理解不一致,无法体会到场景中的诸多特殊性,不过相信不断的沟通和交流,可以解决很多问题。今天我们首先分析一下职场基本功,为什么要重视需求质量,常见的数据需求文档改怎么写。
以下,Enjoy:
如果想快速的提高自己,但是不知道从哪里开始,不妨尝试从工作中将最为常见的需求文档质量提高,相信我,一份有优秀的需求文档,就可以让你打败了大多数的数据同行。
为什么要重视需求质量
我的数据需求产品文档主要有:项目背景、项目范围、目标收益、需求详述、交互原型、功能说明、校验测试七大模块。在实际的工作场景中会根据情况做调整,基本情况下形成自身的特点(产品文档规范),并且自身的特点是高于团队质量的,长久坚持下去就会得到更多的认可,同时容易规范自身的思维,形成方法论。
项目背景的书写方案其实很简单,抓住“问题+目标”两个关键字就可以。
整个项目背景以“问题+目标”描述一个场景下会发生什么问题,期望以后怎么解决类似问题作为目标达成,就是一段简洁明了的项目背景描述。
我做过关于数据标准化治理的项目,当时的目标诉求主要为:一致性,效率提升。为什么要设定这样的目标,因为我们经常受到“数据的问题困扰,数据生成过程中的内耗严重”。我们以“问题+目标”来总结分析一下项目背景的速写
鉴于以上的“问题+目标”,作为数据产品经理很快第一时间定位和反思了问题,决定以建立稳定的数据评估体系为基础,推动数据生成加工的标准化工作。
业务发展过程中未能建立有效的数据评估体系,数据维度/指标口径不一致,数据耦合严重,导致各业务数据的指标体系繁多,滋生了多种多样的数据问题。
数据问题的严重性,不仅增加了数据口径的理解消耗,还增加了数据生产和维度的难度,让参与数据建设的各方人员都为数据的准确性校验、数据问题排查耗费了巨大精力。因此建立稳定的数据观测体系,解决上述问题中的“效率提升,一致性”。
本期将数据评估体系拆解为示例,以单页面数据评估为案例,优先对产品单页的价值进行评估,明确数据维度和指标体系,并以产品工具的形式向内部的目标用户提供数据可视化工具。
内容纯属虚构,不代表作者真实工作内容。数据治理属于长期且较大的项目,因此这个背景的描述内容多、话题偏大,实际工作可以根据项目大小有所增减或是量化具体。
任何项目一旦涉及到跨部门多人协作,或者是作为内部的横向打通产品工具,首先应该意识到项目推进过程中会出现各种阻力,同时又要考虑新的产品策划方案,对业务或是现有其他数据产品工具影响。
因此,明确项目的功能范围,解决业务环节上的什么问题(不承担解决什么问题),团队的成员各自负责哪块项目工作内容,是项目协作和保障项目顺利进行的必选项。常见的项目范围包括两点“事”和“人”,主要做以下考虑:
产品资源
数据现状
业务诉求
聚焦收益,能够明确量化目标,很多工作场景下过分的苛责量化目标,但是学习从概念或是模糊思维中去抽象出量化目标,同大家达成认知的一致,具有共同的成就感和使命感,仍然是产品经理人员的必备技能。
一句话,是否能找到数据来衡量目标中的收益。让结果以数字的增长来体现。目标收益在没有明确KPI的情况下,则需要自己创造出KPI,设定目标值。
为什么有需求概述,这不需要多说,编写需求概述是真正的考验业务理解和产品能力的重点,对于需求概述的编写可以参照两点中心思考:
为产品内页面搭建通用型的数据评估体系,明确页面效果评估中采纳的维度、指标。以统一的可视化数据分析工具落地项目,避免各自业务线重复的数据建设工作,同时优化数据仓库模型,提高数据的使用效率,解决因各自数据口径问题不一直产生的数据歧义。
以下为本期页面数据评估体系内的维度、指标口径,其中包含维度9项,指标10项目。此为产品页面分析中使用的基础明细数据。支持以表格形式预览,下载分析。
数据体系(简单举例)
注释1:曝光UV可以通过多种方式获得,常见的方法为依靠模块埋点作为基础数据计算,在模块颗粒度级别的埋点中要多加注意埋点的上报时机。
模块数据上报时机如下
注释2:数据评估体系的搭建需要结合多部门业务诉求后,综合统一规范之后给出; 注释3:数据评估体系为基础的数据维度和指标,产品可视化展示根据实际的报表需求,进行多维汇总、聚合。
数据矩阵
以下为指标所需要监控分析的数据维度,✔️表示需要, ❌表示不需要。
数据矩阵(略)
注:数据矩阵,即cube矩阵,通过数据矩阵形式,需求方需对自己的数据进行更深的思考,它帮助RD和需求方在每一个维度和指标的筛选上进行思考,通过长时间的交互,可以让双方更专业的理解数据业务和数据加工的逻辑,让业务可以深入的理解数据,进而尽量让所有能预处理的数据预处理,减少推送明细数据,动态计算的需求方案。
注: 【查询】是指显示的结果是否包含该维度;【筛选】指是否用该维度过滤数据;【分组】是指是否用该维度汇总数据。
产品经理的工作不只是画图,但是画图不擅长的人一定不是产品经理。交互原型的设计讲究实用,让人读懂。初级的追求美感本身也没有错,但是重点是美感之前的逻辑清晰。作者本人在原型交互设计中比较喜欢OmniGraffle这款工具,主要是考虑一点几点:
暂略,后续会专门输出一个PRD交互方案。
多数的功能描述体现在交互原型中,如果方案本身不涉及原型交互,对于功能的描述信息单独呈现。比如本次单独的项目中,如果涉及到数据仓库底层的内容,可以一并写在下面,供给研发使用,关于一个方案需要涉及多深的层次,因不同的公司,部门,人员能力不同多有差异,个人比较倾向的原则是,作为产品类岗位,永远要有主动承担灰色地带的觉悟,多向前迈进一步,多渗透交叉。
以下为本项目已知的数据底层内容
数据验证方式
数据调度周期:日(期望每日8:00前产出数据)
今天整理的文章分析是数据工作中的开端和基础,希望让伙伴们意识到需求文档交付质量的重要性并尝试有所提高自己的工作方式,接下来的文章我会根据这份需求文档来聊一下如何实现这个需求,为了实现这个需求都哪些数据产品和工具,数据仓库中的数据是怎么加工生产的,以及我们的数据都是怎么来的,希望能够对你有所帮助。