能力证据链

这里不是项目列表,而是能力证据链。

五个重点项目展开完整战报,用来证明数据平台、指标治理、流程产品化、中台工具链和自动化运维能力;其余项目放入补充项目池,用来补齐职业宽度和阶段变化。

选择一个项目

横向切换项目,下面的战报内容会原地替换,不会把页面跳走。

Featured Case 01
数据采集平台

从 Excel 接力,到埋点治理闭环。

腾讯数据上报平台「大同」的核心,不是把线下表格搬到线上,而是把设计、开发、测试、质量诊断和运营度量串成一套可追踪、可治理、可持续运营的系统。

产品负责人 数据采集 流程产品化 质量治理 成本治理

项目战场图

这个项目不是“做一个工具”,而是把混乱的埋点协作现场,改造成一套可追踪、可治理、可运营的产品机制。

混乱现场 线下 Excel 流转,过程不可追踪

版本、状态、责任人和变更记录散在表格和聊天里,设计、开发、测试之间靠人工衔接,返工和误解容易发生。

产品化改造 三视图线上化,标准和模型沉淀

设计视图、开发视图、测试视图串起来,再通过上报标准、上报模型、质量诊断和运营看板把流程机制化。

治理闭环 从能上线,变成可治理、可运营

流程留痕、测试效率、质量诊断和成本控制形成闭环,平台从功能集合变成持续运营的数据采集系统。

效率多角色协同从线下传递变成线上流转
质量预警、诊断、复盘减少问题后置发现
治理标准、模型和成本管理让数据采集可管
运营培训、oncall、看板度量支撑持续推进

四个关卡

这个项目的难点不只在产品功能,而在于让组织、流程、系统和运营方式一起改变。

组织难点

埋点涉及产品、研发、测试、数仓和业务多角色,协作链条长。

流程难点

从线下 Excel 迁移到线上流程,会改变原有习惯和责任边界。

系统难点

平台需要联动上报上下游、数仓、欧拉、灯塔等链路生态。

运营难点

产品上线后还要通过培训、oncall、迭代传播和用户行为度量持续推进。

我的打法

把项目过程压缩成一条策略路径:先诊断,再机制化,再系统化,最后用运营和数据度量稳住。

1诊断流程分析埋点流程、组织形式和协作断点。
2设计三视图设计视图、开发视图、测试视图线上化。
3推动改造联动技术体系改造,合并产品能力。
4统一标准建立上报标准和上报模型。
5运营体系培训、oncall、迭代传播、看板度量。
6质量闭环前中后质量预警、诊断和复盘能力。

项目结果

结果区用图形化表达,让关键指标一眼能被记住。

100%埋点流程完成线上化改造
70%测试效率提升
45%上报成本减少
300+用户量提升
6业务数量提升
2.0完成 1.0 到 2.0 产品迭代
Before / After流程产品化
线下 Excel 依赖
线上流程留痕100%
质量诊断能力闭环
运营度量能力增强

项目价值

从“完成一个工具”上升到“建立一套机制”,这是项目真正能证明产品能力的地方。

流程价值

把原本分散在线下表格和人工沟通里的埋点流程,变成线上可追踪、可协同的产品流程。

治理价值

让数据采集不只停留在提需求和验收,而是具备标准、质量、成本和复盘能力。

产品价值

用产品化方式把复杂协作关系固化下来,让平台从功能集合变成可持续运营的系统。

指标平台

让指标有口径、有归属、有稳定去处。

腾讯视频指标平台解决的不是单个报表问题,而是历史指标、口径、生命周期、下游系统和业务使用方式长期割裂的问题。

产品负责人 指标平台 指标治理 生命周期管理 跨系统打通

项目战场图

核心不是新建一个指标查询入口,而是把指标从口径、流程、平台到下游使用方式重新组织起来。

口径割裂 同一数据,业务容易得到不同解释

历史指标沉淀多,口径解释分散,流程和下游系统各自为政,业务咨询和解释成本长期存在。

指标治理 规范、流程、平台和组织一起改

调整指标规范、组织和流程,联动中台建设指标平台,普及指标管理模型,治理存量指标。

指标生态 标准指标被下游系统稳定复用

指标管理和使用流程更规范,口径更统一,BI、实验和业务系统可以复用标准化指标。

口径让历史指标解释从分散经验变成统一规范
流程建立指标增删改和生命周期管理机制
系统打通 BI、实验和业务系统的指标使用
运营通过 oncall、培训和咨询沉淀治理机制

四个关卡

指标治理的难点在于它不是一个人能改掉的表,而是跨业务、跨系统、跨生命周期的共同语言。

口径关

历史指标多,口径解释分散,业务理解不一致。

生命周期关

指标从创建、使用、变更到下线缺少统一流程。

系统打通关

BI、实验系统和业务系统之间需要统一指标出口。

组织推进关

需要让业务、中台、数据团队接受统一规范和流程。

我的打法

先把指标混乱拆清楚,再用标准、流程、平台和运营把治理动作长期固定下来。

1梳理链路梳理历史指标和现有使用链路。
2设计机制设计指标管理规范、流程和生命周期机制。
3联动建设联动中台建设指标平台能力。
4存量治理推动存量指标治理和标准化改造。
5系统打通打通 BI、实验和业务系统。
6运营沉淀通过 oncall、培训和咨询沉淀运营机制。

项目结果

用结果证明指标平台不是“多一个入口”,而是让业务数据从能查变成可信、可管、可复用。

3000+存量指标治理
800+标准化指标改造
-45%oncall 咨询量下降
40%业务满意度提升
2打通 BI 与实验系统
闭环跑通指标增删改线上流程
Before / After指标生态
口径分散程度下降
标准化指标覆盖增强
下游系统复用打通
业务解释成本-45%

项目价值

这个项目更能证明治理型产品能力:把长期存在的数据问题拆成可落地的产品机制。

治理价值

把指标混乱拆成标准、流程、平台、组织和运营,而不是只做一个展示型工具。

复用价值

让标准化指标能被 BI、实验和业务系统复用,减少重复解释和重复建设。

组织价值

通过流程和运营机制,让业务、中台和数据团队围绕同一套指标语言协作。

数据分析平台

给城市业务,建一个统一数据入口。

贝壳奥丁面向分析师、业务用户和管理层,承载一站式分析、指标体系、城市数据建设和业务管理场景。

产品负责人 数据分析平台 指标体系 城市数据建设

项目战场图

奥丁不是单纯的分析工具,而是把分散的数据入口、用户角色和城市推广机制统一起来。

入口分散 数据源、平台和城市标准各不统一

数据孤岛明显,老旧平台多,业务取数和分析入口分散,城市之间数据标准和使用方式不统一。

平台整合 把查询、建模、指标和可视化放到同一入口

整合数据源、可视化、建模、指标管理和数据查询能力,迭代 3 个大版本,并配套培训、认证和运营。

统一入口 支撑多城市、多角色的数据使用

形成统一分析入口,提升数据流通性和业务管理效率,支撑分析师、业务用户和管理层的数据使用。

入口将分散平台收束为统一分析入口
城市支撑 90 城数据建设与推广
运营建立培训、认证和场景化应用机制
迁移推动老旧平台下线和用户迁移

四个关卡

数据分析平台的难点不止是功能多,而是用户角色多、城市差异大,还要推动迁移和运营。

数据孤岛关

数据源、平台和分析工具分散,统一出口不足。

用户分层关

分析师、业务用户、管理层的数据使用方式不同。

城市推广关

城市数据建设需要标准、培训和认证机制支撑。

老平台迁移关

需要下线老旧平台,并让用户迁移到新入口。

我的打法

先按角色和场景梳理入口,再通过版本迭代、标准运营和迁移推动平台真正被使用。

1角色梳理梳理用户角色和数据分析场景。
2能力整合整合查询、建模、指标和可视化能力。
3版本迭代迭代平台主版本,逐步覆盖核心场景。
4建设标准制定数据使用标准和城市建设指引。
5运营推广建设培训、认证和运营体系。
6迁移收口推动老旧平台下线和统一入口迁移。

项目结果

奥丁的结果更像一个平台从工具建设走向组织级数据入口的过程。

90覆盖城市
85%城市覆盖度
4下线老旧平台
2人/天数据效率提升
3迭代 3 个大版本
统一形成分析和数据消费入口
Before / After统一数据入口
入口分散程度下降
城市覆盖能力85%
老平台治理4 个
用户运营能力增强

项目价值

这个项目能证明从平台建设到业务运营的完整能力。

平台价值

把原本分散的分析入口、指标体系和数据应用收束到统一平台中。

运营价值

通过培训、认证和场景化应用,让平台不只上线,还能被城市和业务持续使用。

管理价值

让数据平台从分析工具升级为业务管理入口,支撑多城市、多角色的数据决策。

数据中台工具链

搭起数据中台的工具链底座。

贝壳数据工厂 / 数据开发治理平台把开发、治理、权限、服务、质量和成本管理放进一套体系,体现团队和平台建设能力。

产品负责人 团队负责人 数据开发 数据治理

项目战场图

这个项目不是单个工具,而是一组数据中台能力的组合:开发、治理、权限、服务、质量和成本。

工具分散 开发、治理、质量和成本缺少统一支撑

数据开发和治理工具链不完整,质量、成本、权限、服务缺少统一平台,开发和管理效率受限。

中台建设 分模块建设数据中台工具链

建设数据地图、数据开发、数据交换、数据服务、指标管理、数据治理等能力,推进线上化迁移和精细化管理。

体系运转 平台能力支撑业务和城市数据建设

形成贝壳数据中台工具链,提升数据开发、质量治理、成本管理和团队协同能力。

工具链开发、交换、服务、地图、指标、治理成体系
质量质量分从 55 提升到 75
成本数据成本缩减 40%
团队组建 PM 与运营团队推动落地

四个关卡

它的难点是平台型产品组合:不只要做功能,还要让质量、成本和团队机制一起运转。

工具链关

数据开发、治理、地图、服务等能力分散,需要统一平台化。

质量关

数据质量缺少可持续监控和组织机制。

成本关

数据成本需要被看见、被管理、被优化。

团队关

需要带产品和运营团队一起推进平台落地。

我的打法

把工具链缺口拆成模块,再用线上化、质量分、成本管理和团队分工推动体系落地。

1梳理缺口梳理数据开发和治理工具链缺口。
2模块建设建设地图、开发、交换、服务、指标、治理能力。
3线上迁移推进线上化迁移和精细化管理。
4治理机制建立质量分和成本管理机制。
5组织优化推动质量组织优化。
6团队管理组建并管理 PM 与运营团队。

项目结果

数据工厂更适合展示平台组合能力:既有业务结果,也有团队和治理体系结果。

-40%数据成本缩减
55→75质量分提升
13PM 团队规模
3运营团队规模
6工具链能力模块
优化推进质量组织优化
Before / After中台工具链
工具链完整度提升
质量治理水平75 分
成本治理效果-40%
团队推进能力16 人

项目价值

它证明的不只是单个产品设计能力,而是平台组合、治理体系和团队管理能力。

平台价值

把多个分散能力组成数据中台工具链,支撑业务、城市和数据研发场景。

治理价值

把质量和成本从事后问题变成可度量、可管理、可优化的机制。

管理价值

通过 PM 和运营团队推进平台落地,体现从产品到组织协同的完整负责范围。

自动化运维

建设全局可观测底座,提升运维诊断效率。

字节数据加工自动化运维的核心,不是先做一个 Agent 入口,而是整合引擎和上下游系统能力,建设全局可观测与诊断底座,让用户在任务失败、任务变慢、大规模故障等场景下更快、更准地判断问题。

高级数据产品专家 自动化运维 全局可观测 诊断底座 MTTR / 自愈率

项目战场图

这个项目不是“给运维加一个聊天框”,而是先把信息、诊断和流程打通,让数据加工链路具备可观测、可判断、可处置的运维底座。

信息割裂 排障要跨多个系统来回找证据

任务失败或变慢后,用户需要在引擎、调度、日志、血缘、资源、权限、上下游系统之间排查,诊断慢,判断不稳定。

运维底座 整合引擎与上下游,建设全局可观测

打通采集、传输、开发、元数据、治理等链路信息,围绕任务失败、任务变慢、大规模故障建设诊断能力,并沉淀知识库和 SOP。

效率提升 从人工排查,走向诊断辅助与简单自愈

用户可以基于统一信息和诊断结论快速判断问题,高频 oncall 有标准处理流程,简单场景具备自愈能力,MTTR 下降。

观测引擎、采集、传输、开发、元数据、治理信息统一
诊断覆盖失败、变慢、大规模故障等核心场景
SOP沉淀队列资源、数据倾斜、权限丢失等处理流程
自愈基于底座推进低风险高频场景自动恢复

四个关卡

自动化运维真正难的不是单点能力,而是先把复杂链路里的信息、诊断、知识和自动化边界逐层打通。

信息整合关

引擎、采集、传输、开发、元数据、治理等系统信息分散,需要先形成全局可观测底座。

诊断准确关

任务失败、任务变慢、大规模故障背后的原因复杂,需要提高诊断效率和准确性。

知识沉淀关

队列资源不足、数据倾斜、权限丢失等高频 oncall 问题,需要沉淀为知识库和 SOP。

自动化边界关

简单场景可以自愈,但生产链路中的自动处置必须区分风险、确认和回滚边界。

我的打法

先把全链路信息收进来,再做诊断能力和 SOP,最后用自愈与 Agent 化能力承接更高阶的自动化运维。

1整合信息打通引擎、采集、传输、开发、元数据、治理等上下游信息。
2梳理场景围绕任务失败、任务变慢、大规模故障拆解真实排障路径。
3建设诊断组织日志、调度、血缘、资源、权限和依赖信息,提高定位准确性。
4沉淀 SOP把队列资源不足、数据倾斜、权限丢失等问题沉淀为流程。
5支撑自愈选择低风险、高频场景建设简单任务自愈能力。
6打底 Agent用可观测、诊断和 SOP 为后续运维 Agent 独立端打基础。

项目结果

结果重点不只是“智能化”,而是用户在运维场景下的诊断能力、判断能力和处置效率被系统性提升。

MTTR平均故障恢复时间下降,真实口径待补充
自愈率简单场景任务自愈能力提升,真实口径待补充
诊断任务失败、变慢、大规模故障定位效率提升
准确性用户基于统一信息和诊断结论的判断能力提升
SOP沉淀高频 oncall 问题知识和标准流程
底座形成全局可观测 + 诊断 + SOP 运维底座
Before / After自动化运维底座
信息分散程度下降
诊断依据完整度提升
高频问题 SOP沉淀
简单场景自愈推进

项目价值

这个项目证明的是:我能先打穿复杂数据加工链路里的信息、诊断和流程,再把自动化和 Agent 能力长在可靠底座上。

底座价值

整合引擎和采集、传输、开发、元数据、治理等上下游信息,形成数据加工运维的全局可观测基础。

效率价值

提升任务失败、任务变慢、大规模故障等场景的诊断效率与准确性,减少用户排障和判断成本。

演进价值

通过知识库、SOP 和简单自愈能力,为后续运维 Agent 独立端和更复杂的智能处置打基础。

补充项目

把职业宽度,收进补充项目池。

这里收纳不需要展开成长战报、但能补充职业跨度的项目:早期数据门户、0 到 1 平台产品、管理驾驶舱、开发工具和个人品牌产品化。

滴滴数据开发平台 京东金融数据门户 Boss 数据驾驶舱 DataLeap 个人品牌静态站

补充项目池

这些项目用来补充职业宽度:数据开发、数据门户、管理驾驶舱、开发工具和个人品牌产品化。

P1 / 平台产品 滴滴数据开发平台

从 0 到 1 建设面向数据研发的开发平台,设计权限、交互和用户开发模式,支撑 500+ 用户,提升安全、成本、效率、质量和管理能力。

2017.04 - 2018.070 到 1技术用户
P1 / 数据门户 京东金融数据平台 / 数据门户

参与京东金融早期数据服务平台建设,覆盖 adhoc、报表、监控、指标体系等场景,完成从数据分析师到数据产品经理的关键转身。

2013.01 - 2017.04数据服务角色转型
P1 / 驾驶舱 京东金融 Boss 数据驾驶舱

面向 CEO 和管理层的数据消费场景,设计移动端数据查看、经营指标模型和权限体系,开启独立设计管理层数据产品的阶段。

2014 起移动端管理层场景
P1 / 开发工具 DataLeap 开发工具

回到数据开发平台和开发工具方向,负责 DataLeap 相关产品建设,重新下场理解复杂平台工具的一线执行和技术细节。

2024.01 - 至今复杂系统一线执行
P1 / 个人品牌 个人品牌静态站

将复杂职业经历拆成个人简介、工作经历、项目介绍三页,先做轻量静态上线,再把项目经验拆成可切换的项目战报。

2026内容产品化快速上线