2、团队角色与职责:数据产品经理、数据工程师、数据分析师、算法工程师、业务方
数据产品化这件事,说白了就是一场接力赛。每个人跑好自己的那一段,交接棒的时候别掉地上,成绩自然就出来了。
我带过好几个数据产品团队,踩过最大的坑就是——角色边界不清。数据分析师跑去写ETL,数据工程师抢着做可视化,业务方觉得数据产品经理就是个传话筒。嗯,这种混乱我经历过太多次了。
所以这一章,咱们把五个核心角色的职责和协作边界彻底理清楚。你想想看,一个数据产品从需求到上线,到底谁该干什么?
核心原则:每个角色都有自己的「责任田」和「协作区」。责任田内说了算,协作区内必须对齐。
2.1 数据产品经理:团队的「方向盘」
数据产品经理不是「写文档的」,也不是「传话的」。我见过太多团队把PM当成需求,结果产品做出来没人用。
数据产品经理的核心职责就三件事:定方向、排优先级、保落地。
- 需求管理:从业务方收集需求,判断真伪。我曾经遇到业务方说「我要一个实时大屏」,聊了半小时才发现他真正要的是「每天早上一封邮件告诉我昨天销售额」。需求澄清是PM的第一道关。
- 产品规划:制定产品路线图,明确每个版本做什么、不做什么。这里最难的是拒绝——「这个需求很好,但我们下个版本再做」。
- 跨角色协调:数据工程师说「数据源还没接」,算法说「模型还在调」,分析师说「指标定义不统一」——PM得把这些拧成一股绳。
我的习惯:每周一上午固定开15分钟「对齐会」,每个角色只说三件事——上周完成、本周计划、需要谁配合。雷打不动。
2.2 数据工程师:数据的「管道工」
数据工程师负责把原始数据变成可用的数据资产。说白了,就是修管道、铺路、保证水能流到用户手里。
我团队里有个数据工程师,他常说一句话:「数据没到,一切都是空谈。」这话糙理不糙。
| 职责领域 | 具体工作 | 常见产出 |
|---|---|---|
| 数据采集 | 对接业务系统、埋点、日志采集 | 数据接入文档、采集脚本 |
| ETL开发 | 清洗、转换、加载数据 | 调度任务、数据管道 |
| 数仓建设 | 分层设计、模型设计、元数据管理 | 数仓模型文档、DDL脚本 |
| 数据质量 | 监控、告警、异常修复 | 质量看板、巡检报告 |
这里有个容易踩的坑——数据工程师不要替分析师做报表。我见过工程师花三天写了个炫酷的可视化,结果分析师说「我要的不是这个维度」。嗯,边界不清,白费功夫。
2.3 数据分析师:业务的「翻译官」
数据分析师是离业务最近的技术角色。他们要把业务问题翻译成数据问题,再把数据结果翻译回业务语言。
我曾经带过一个分析师,他做的最漂亮的一件事是——业务方说「最近用户流失严重」,他没有直接拉数据,而是先问:「你说的流失是指30天未登录,还是60天未下单?」这一问,把模糊的需求变成了可执行的指标。
- 指标定义:和业务方一起明确「什么是活跃用户」「什么是流失用户」。定义不一致,后面所有分析都是鸡同鸭讲。
- 探索性分析:发现数据中的规律和异常。比如「为什么上周三的转化率突然跌了20%」——可能是代码上线,也可能是数据延迟。
- 可视化与报告:把分析结果做成业务方能看懂的形式。记住,图表是手段,决策才是目的。
避坑指南:我曾经见过分析师花两周做了一个完美的回归模型,结果业务方说「我只看同比环比」。分析之前,先问清楚业务方到底要什么。
2.4 算法工程师:模型的「建筑师」
算法工程师负责把数据变成预测能力。推荐系统、风控模型、智能定价——这些都是算法工程师的活。
算法工程师和数据工程师的协作边界,经常是团队里最模糊的。我建议这样划分:
- 特征工程归算法:哪些字段做特征、怎么处理缺失值、要不要做归一化——算法说了算。
- 数据管道归工程师:特征数据怎么存储、怎么调度、怎么保证时效——工程师说了算。
- 模型评估归算法:准确率、召回率、AUC——算法自己把关。
- 线上部署共同负责:算法提供模型文件,工程师提供部署环境,一起做压测和监控。
你想想看,如果算法工程师自己写特征工程代码,自己搭数据管道,那还要数据工程师干嘛?专业的事交给专业的人。
2.5 业务方:需求的「源头」
业务方不是「甲方」,而是「队友」。他们最懂业务痛点,但往往不懂数据能做什么、不能做什么。
业务方的核心职责:
- 提出真实需求:不是「我要一个报表」,而是「我想知道为什么这个月的复购率下降了」。
- 提供业务解释:数据异常时,业务方要能解释「是不是有促销活动」「是不是竞品上线了新功能」。
- 验收与反馈:产品做出来,业务方要用起来,并且告诉团队「这个指标不对」「那个维度少了」。
我的经验:业务方最怕的是「需求提了,然后就没有然后了」。所以我会要求PM在每个需求完成后,给业务方做一个简短的「交付说明」——做了什么、为什么这么做、下一步可以怎么用。
2.6 协作边界:谁该听谁的?
角色清楚了,但协作的时候还是会有摩擦。我总结了几条「边界铁律」:
| 协作场景 | 主导角色 | 配合角色 | 常见冲突 |
|---|---|---|---|
| 需求评审 | 数据产品经理 | 所有角色 | 业务方说「很简单」,工程师说「做不了」 |
| 指标定义 | 数据分析师 | 业务方、PM | 业务方要「活跃用户」,分析师要「7日活跃」 |
| 数据管道建设 | 数据工程师 | 算法、分析师 | 分析师要「实时数据」,工程师只能做「T+1」 |
| 模型上线 | 算法工程师 | 数据工程师、PM | 算法说「模型效果很好」,线上跑起来就崩 |
| 结果验收 | 业务方 | PM、分析师 | 业务方说「不对」,分析师说「数据没错」 |
为什么会冲突?因为每个人看问题的角度不一样。PM看价值,工程师看实现,分析师看逻辑,算法看效果,业务方看结果。没有谁对谁错,只有目标没对齐。
我的建议:每个迭代开始前,五个人坐在一起,花30分钟过一遍「这个迭代我们要解决什么问题」。不是过需求列表,而是过问题本身。目标对齐了,后面的事就好办了。