首席数据官Chief Data Officer简称 CDO这个头衔这两年在我们这行的饭桌上出现频率明显高了。但真要我给一个准确的说法——它不是数据部门的老大也不是高级版数据分析师而是一个要对数据变成商业价值这件事负总责的角色。数据谁都在用报表谁都在看可真正能把数据从每月导一次的 Excel变成能定价、能复用、能进决策会的资产的人少之又少。这篇东西我想聊的就是这件事首席数据官到底在干什么、需要哪几块能力、上任之后怎么落地、哪些坑是几乎每个人都会踩的。不管你是刚被任命、正在犹豫要不要接这个岗位还是想往这个方向走的数据条线从业者甚至只是老板让你研究一下要不要设个 CDO都能从里面找到能直接抄的东西。1. 先把角色说清楚首席数据官到底管什么1.1 从数据管理员到价值操盘手的定位差异CDO 这个岗位最早冒出来解决的其实是个很朴素的问题一个组织的数据越摊越散散在各个业务系统里谁都在改、谁都在用最后没人说得清哪个数字是真的。所以早期这批人的工作重心基本落在数据标准、数据质量、报送口径这些事情上本质上是个内务总管。但今天你要还是拿这套理解去当 CDO大概率活不过两年。原因很简单内务工作做得再好也只是不出错而不出错这东西在预算会上是讲不出故事的。我见过做得比较成功的一类 CDO他们的共同点是把工作重心从守住数据挪到了让数据产生可计量的经营结果——比如把客户流失预警做进续约流程续约率涨了几个点比如把库存周转指标打通到区域仓压掉了一部分呆滞库存。这些才是能写进汇报材料、能换来下一年预算的东西。这里有个很关键的心态转变数据治理本身不是目的是手段。你做元数据管理、做血缘追踪是为了让一个业务问题能被快速定位而不是为了做出一个漂亮的资产目录去汇报。很多新任 CDO 容易掉进的坑就是一上来先搞体系搞了半年做出一堆文档和标准业务侧毫无感知年底一算账发现没有任何一个指标因为你的工作而变好。这种局面一旦形成后续再想推任何事都要多花三倍力气。所以我会把 CDO 的定位归纳成一句话用数据资产的方式解决经营问题并且能算清这笔账。前半句决定你做什么后半句决定你能不能活下去。1.2 CDO 与 CIO、CTO、数据分析师的边界这块是访谈和面试里被问得最多的也是最容易互相打架的地方。我用一张表把边界摆清楚这张表我自己在内部对齐职责时用过效果比讲半小时 PPT 好。角色核心职责主要产出典型考核口径CDO数据资产价值化、数据治理体系、数据驱动决策机制数据资产目录、指标体系、数据产品、数据合规机制数据带来的收入/成本改善、决策效率、数据资产复用率CIO信息系统建设与运维、业务流程的 IT 承载系统上线、稳定性、信息安全系统可用率、项目交付进度、IT 成本CTO技术架构与技术路线、研发效能技术平台、架构演进、研发交付性能指标、研发效率、技术债务数据分析师具体分析任务、报表与洞察交付分析报告、看板、模型结果需求响应速度、分析结论采纳率数据工程师数据管道、存储与计算、数据质量执行数仓模型、ETL 任务、质量监控任务成功率、数据时效、故障恢复时间有几条边界要特别强调。第一CDO 不负责系统的稳定运行那是 CIO 的地盘你不能因为数据链路断了就去接管整个 IT 运维那会让职责无限膨胀。第二CDO 不直接做分析交付那是分析团队的活CDO 要做的是决定分析什么以及分析结果怎么进入决策流程。第三CDO 对数据合规负总责但具体的技术手段依赖 CTO 和安全团队。边界说不清的后果很实际你被拉去背系统故障的锅被拉去背报表出错的锅最后没时间做真正该做的事。我在一次内部沟通会上吃过这个亏当时为了体现配合顺手接了业务系统的数据接口改造结果后面所有的数据延迟问题都被归到我头上。后来我学乖了接口可以帮责任不能接一定要在会议纪要里把归属写清楚。1.3 什么阶段的企业真正需要一个 CDO不是所有组织都到设这个岗位的时候。我自己的判断标准有三条三条里满足两条才值得设专职 CDO否则让现有角色兼着更划算。第一条数据量级和复杂度到了一定的坎。具体说就是靠一个数据团队十几个人手工维护已经撑不住了指标口径开始在不同部门间分裂出现同一个客户数三个部门三个数的情况。到这个阶段靠个人英雄主义已经压不住了需要机制。第二条关键经营决策开始依赖数据。注意是依赖不是参考。如果预算分配、人员编制、渠道投放这些真正花钱的决策还是靠拍脑袋和经验那数据部门永远是成本中心CDO 也永远是配角。第三条跨部门的数据协同成为瓶颈。比如供应链、销售、财务三个条线的数据要对齐才能算清一个订单的真实毛利而这件事每次都要拉会、每次都要吵说明需要有人专职来建这套机制。反过来说如果一个组织还处在先把业务跑通的阶段数据的主要矛盾是能不能取到数那我建议不要急着设 CDO先设一个数据平台负责人把基础设施和基础口径稳住等业务侧的诉求密度上来了再谈。硬上一个 CDO最后的结果往往是这个人被迫去做数据工程师的活两年后带着一身疲惫离开组织还得出一条结论说这个岗位没用。2. 能力模型拆解一个能落地的 CDO 需要哪几块板2.1 业务翻译能力把报表语言翻译成经营语言这是我最看重的一块也是技术出身的人最容易缺的一块。什么叫翻译能力举一个具体场景业务方跑过来说我要看用户活跃度技术侧的第一反应是活跃的定义是什么DAU 还是 WAU登录算还是浏览算。这个反应没错但只做这一层你永远是个需求接收器。真正的翻译是往前推一步你为什么想看活跃度是想判断这次活动有没有效还是想预测下个月的续费如果是后者那活跃度只是中间变量你要的其实是一条从行为到续费的概率链路活跃度只是其中一个特征。这一推方案的层次完全不同。我自己练这块的办法是每次接需求先问三个问题这个数字变了你会做什么决定如果不给你这个数你现在怎么做决定你打算拿这个数去说服谁第三个问题尤其有用因为数据很多时候不是用来做决策的是用来做说服的。搞清楚说服对象你就知道这个指标需要多严谨、多及时、要不要写进口径文档。顺带说一句翻译能力不等于会讲业务黑话。有些人学会了用赋能抓手闭环这些词但一问具体到某个指标的计算逻辑就卡住那不叫翻译那叫包装。真正的翻译是双向的你能把业务问题拆成可计算的口径也能把计算结果还原成业务能听懂的动作。2.2 数据资产化的基本功资产这个词被用得很滥但它的内核其实很清楚能被反复使用、能产生收益、能被计量、能被处置。一条数据要成为资产至少得满足前三条。基本功具体包括几件事。数据盘点搞清楚手上到底有什么这件事听着土但极其重要我见过太多组织连自己有多少张核心表都说不清。主数据管理把客户、商品、组织这些核心实体的唯一标识定下来这是后面所有关联分析的地基。元数据与血缘回答这个数从哪来、经过哪些加工、如果上游变了会影响谁。数据质量度量把质量从形容词变成可监控的数字。这里面我最想强调的是主数据。因为这一块做不好后面所有的努力都是在流沙上盖楼。举个实际例子客户主数据里同一个客户有三个编码一个来自线上下单系统一个来自线下门店系统一个来自财务开票系统。这三个编码各自都对但一汇总就对不上。你花大力气做的客户分层模型跑出来的结果是同一个人被分成三档营销动作互相打架。这种问题不是靠分析能解决的是必须在主数据层面统一的。我一般会把主数据统一的优先级排在数据质量治理之前因为口径不统一带来的质量差是系统性的你逐个字段去修永远修不完。2.3 组织与机制的推动力技术能力再强推不动组织也白搭。CDO 这个岗位本质上是个横向岗位你要在没有直接汇报关系的情况下让财务、销售、供应链的人按你定的规矩来。这件事的难度不在方案设计而在利益协调。我的经验是推机制的时候要抓三样东西一把手的态度、业务侧的痛点、可量化的收益。一把手的态度决定你能不能进场业务侧的痛点决定别人愿不愿意配合你可量化的收益决定这件事能不能持续。有个很实用的技巧不要一上来就搞全公司统一标准先在一个业务痛感最强的场景里做深做透。比如先解决月度经营会的数据打架这一个具体问题让高管在会上第一次看到所有数字都能对上这个示范效应比开十次推进会都管用。等这件事有了成功案例你再推全域标准阻力会小一个量级。另外要习惯把功劳分出去。数据项目的特点是你做了基础设施功劳记在业务侧。这听起来吃亏但长期看是划算的业务侧尝到甜头会主动来找你要数据能力这时候你才有议价空间。反之如果每个项目你都抢着挂自己的名业务侧会觉得你在借他们的成绩下次就不带你玩了。2.4 技术判断力不必写代码但要能拍板CDO 不需要自己写 SQL但必须能在几个关键技术选型上拍板并且拍得对。哪些是需要拍板的存储与计算架构的形态湖、仓、湖仓一体、数据集成的方式批、流、CDC、数据服务的形态直连、中间层、API、以及工具采购与自建的取舍。拍板的关键不是懂技术细节而是懂成本结构与演进路径。比如湖仓一体好处是减少数据搬运、降低冗余但如果团队里没人维护过这类组件运维成本会吃掉大部分收益。这时候我的判断标准是团队现有的运维能力能不能覆盖如果不能宁可先用成熟稳定的方案等技术债和人力都到位了再迁。还有一个常被忽略的点要算总持有成本。很多选型在采购阶段看着便宜但三年后数据量涨十倍存储和计算账单会告诉你真相。我习惯让团队做一个三年的成本推演把存算增长曲线画出来再看不同方案的成本交叉点在哪。这一步经常能推翻掉最初的直觉判断。3. 数据从成本项变成资产项的关键动作3.1 数据盘点与资产目录的搭建盘点这件事我建议不要搞成填表运动。我见过一个组织搞了三个月的数据盘点让各业务部门填了上百张表格最后收上来一堆互相矛盾的答案谁也不敢用。这种做法的问题在于它把盘点的成本压给了最不了解全局的人。我自己的做法是自下而上先跑一遍自上而下再对一遍。技术上先从系统层拉元数据把表、字段、更新频率、数据量、上下游依赖自动抓出来形成一份技术侧清单。然后拿着这份清单去找业务侧的接口人问三个问题这张表你最常用的是哪几个字段如果这张表停更了你会受什么影响这张表里有没有你觉得不准的字段这三个问题能很快筛出核心表和边缘表。资产目录的字段设计上我建议至少包含这几项不多但要够用字段说明是否必填资产名称业务能听懂的名字不要用表名必填业务含义一句话说清这个数据描述什么必填责任人该资产的数据 owner不是系统 owner必填更新频率日更/周更/月更/实时必填覆盖范围时间跨度、主体范围必填质量水位关键字段的完整率、准确率抽样结果建议关联指标这张表支撑哪些对外指标建议使用热度近 30 天查询次数、引用者数量建议最后两列是我特意加的。很多资产目录做出来是给检查看的没人用。加上使用热度之后你每个月能一眼看出哪些资产是死资产占着存储和维护成本却没人碰该归档归档、该下线下线。这件事在预算会上很有说服力我砍掉了 X% 的冗余存储。3.2 指标体系建设从口径混乱到一本账指标口径打架是几乎所有组织都会遇到的问题也是 CDO 上任后最容易做出成绩的切入点。因为它的痛点极度显性——两个部门在会上报出两个数老板当场就问为什么这时候你站出来说我来统一没人会反对。具体怎么建我的经验是三步。第一步先收口一级指标也就是进经营会的那十几个数别贪多。收入的确认口径、活跃用户的定义、毛利的计算方式、订单的计入时点这几个定下来能解决 80% 的争论。第二步给每个指标写一份口径卡包含业务定义、计算公式、数据来源表、过滤条件、时间归属规则、责任人、变更记录。这份卡片的模板我一般用 YAML 或者一张固定的表格维护关键是变更记录一定要有因为指标口径是会长大的半年后有人问这个数为什么和去年不一样你得能追。指标编码: M-0007 指标名称: 有效订单数 业务定义: 完成支付且未在统计周期内全额退款的订单数量 计算公式: count(distinct order_id) 数据来源: dwd_order_detail 过滤条件: pay_status PAID and refund_amount order_amount 时间归属: 按支付完成时间归属不按下单时间 粒度: 日 / 区域 / 渠道 责任人: 某业务条线数据负责人 变更记录: - 2024-03-01 新增未全额退款过滤条件此前版本含退款订单第三步把口径卡挂到工具里做强制约束。这一条是分水岭。如果口径只写在文档里那它必然会被绕过如果指标只能从统一的指标层取绕过就会报错那才叫真的统一。技术上就是做一层指标服务所有前端看板、分析取数都走这一层不允许直接查明细表算指标。刚开始会有人抱怨不方便但坚持两个月大家就习惯了。3.3 数据质量治理的优先级排序数据质量这件事最怕的就是全面治理。字段成千上万全面治理等于不治理。我通常用两个维度做优先级排序影响面和修复成本。影响面看两点这个字段被多少个下游引用以及它出错会不会进经营报表。修复成本看三点是源头系统的问题还是加工逻辑的问题需不需要改上游业务系统改完之后历史数据要不要回刷。排完之后你会发现真正值得优先做的其实就那几件事。我一般归成三类高影响、低成本立即做比如某个核心指标的空值率从 8% 降到 1%只需要在加工层加一个兜底逻辑。高影响、高成本这类要做专项必须有业务方一起参与不能只有数据团队在推。典型的是上游业务系统的录入规范问题那得改流程、改系统校验。低影响、低成本攒着批量做或者干脆接受。低影响、高成本直接放弃不要碰。这里有个实操心得质量监控要设业务可感知的阈值不要设技术阈值。比如空值率小于 1%是技术阈值业务侧没感觉每日有效订单数与上游业务系统的差异不超过 0.5%是业务阈值一旦超了业务侧马上能感知到并来问。后一种报警才有人响应。另外报警一定要收敛。我见过一个团队配了三百多条质量规则每天几十条报警最后所有人都把报警群设成免打扰等于没有。我自己的原则是核心链路报警控制在 20 条以内每条报警都必须有明确的处置人和处置动作没有动作的报警一律删掉。3.4 数据产品的交付节奏数据团队的交付最忌讳接需求做需求的作坊模式。今天业务要个报表明天要个看板做完了没人用做不完还被投诉。我倾向于把交付分成三条线节奏完全不一样交付线交付内容节奏关键约束报表线固定看板、定期报表标准化、自助化尽量用工具自助减少人工排期分析线专题分析、归因、策略建议按项目制有明确结论交付每个项目必须有明确的决策场景产品线数据服务、模型、策略引擎按版本节奏小步迭代必须有业务侧的使用方和验收标准三条线里报表线要尽量去人化也就是把重复的取数需求转成自助看板让业务自己拖。这件事短期看是投入长期看是解放生产力。分析线要克制不是所有需求都值得做判断标准是这个分析结论会改变什么动作改变不了的就不做。产品线要选准一个数据产品如果上线三个月没有业务侧主动使用基本可以判定失败要及时止损。节奏上我建议数据团队内部有个需求池 排期会的机制每周过一遍按价值排序同时公开承诺交付时间。这个机制的好处是把谁催得凶谁先做变成谁价值高谁先做减少内耗。4. 实操路径一个虚构企业的 CDO 上任 90 天怎么走我用一个模拟场景把前面的东西串起来。假设某制造类企业设立了 CDO 岗位新任者接手一个二十来人的数据团队此前这个团队主要在做报表和取数业务侧口碑一般抱怨主要是慢和数不准。下面这个 90 天节奏是我在类似场景下验证过的。4.1 第 1-30 天摸底与建信任第一个月的核心任务只有一个搞清楚问题在哪并且让关键人相信你能解决问题。这个阶段千万不要急着出方案更不要急着改组。具体动作我一般做四件事。第一把最近半年的需求工单全部拉出来按类型、提出部门、交付时长、返工次数做个分类统计。这份统计能告诉你很多事哪类需求最密集、哪类返工最多、哪个环节最卡。第二和业务侧的关键接口人做一对一访谈不谈方案只问痛点和历史。第三把核心报表的实际使用情况拉出来看哪些看板每天有人看哪些三个月没人打开。第四找团队里最资深的两三个人单独聊问他们如果只能改一件事你改什么。这里有个很重要的判断不要相信数据不准这个笼统的说法。一定要让抱怨的人举出具体例子具体到哪张报表、哪个数、和哪个系统的数对不上、差多少。你会发现很多所谓的不准其实是口径不同真正的错误占比并不高。分辨清楚这两者你的工作方向就完全不一样了。这个阶段结束我一般会输出一份不超过十页的摸底报告内容就是三块现状、三个最痛的问题、接下来六十天打算做什么。这份报告要在一把手和业务负责人都在的场合讲一次目的不是汇报是拿到共识。有了这个共识后面推事情才有依据。4.2 第 31-60 天选题与速赢第二个月开始做第一件事选题原则我前面说过痛感强、范围可控、能在一个月内看到结果。在制造类企业里比较典型的选题是月度经营会的数据口径统一或者某个核心品类的库存周转看板。以库存周转为例这个题目的好处是涉及供应链、销售、财务三个条线天然是跨部门的业务侧痛感强因为库存压着钱结果可量化周转天数降了就是降了。落地路径大概是这样。先定口径周转天数到底是用平均库存除以日均出库还是用期末库存除以期间出库这两个算法结果差很多必须开会定死写进口径卡。然后拉数据把各仓、各品类的库存和出库打通这里大概率会遇到主数据不统一的问题——同一个 SKU 在不同系统编码不一样正好借这个机会把商品主数据的映射表建起来。最后做交付先出一个最小可用的看板只放最关键的几个维度让供应链的人用起来根据反馈再迭代。这个过程中一定会遇到数据质量问题我的处理原则是能被业务感知的优先修其余的先标注。比如某个仓的库存数据延迟两天这个必须修因为会影响周转计算某个非核心品类的分类字段缺失先在看板上标注数据待完善不影响主流程就往后放。速赢的意义不在于这个项目本身有多大价值而在于它证明了数据团队能把事做成。这个信任一旦建立后面推治理、推标准业务侧的配合度完全不一样。4.3 第 61-90 天机制与组织固化第三个月的重点从做事转向建机制。速赢项目做完如果不固化三个月后一切照旧。要固化的东西有三样。第一是例会机制比如每月一次的数据治理例会参会人必须是各业务条线的接口人会议议程固定上月数据质量问题闭环情况、本月新增口径变更、下月重点。会不用长半小时到一小时但必须定期开由 CDO 主持。第二是口径变更流程任何一级指标的口径调整必须走变更申请评估影响范围通知所有下游使用方更新口径卡。第三是需求受理机制把散落在各个群里的需求统一收口到一个入口统一排期。组织上我一般不建议大动但会做两个小调整。一是设数据 owner角色每个核心数据域指定一个业务侧 owner 和一个技术侧 owner双人负责。二是把团队按平台 分析 治理三条线做个内部分工避免所有人都既做取数又做建模。这里有个现实问题要提醒机制建立初期一定会被绕过。有人会直接找某个分析师私下要数有人会在口径变更上先斩后奏。我的做法是抓两次典型在会上公开讲清楚后果不是批评人是讲如果不走流程下游三个部门会跟着出错。讲清楚成本大多数人会配合。真不配合的就得靠一把手出面了。4.4 度量体系与汇报方式CDO 这个岗位如果不能用数字证明自己的价值很难长期立足。所以我强烈建议从第一天起就建一套自己的度量体系按季度看趋势。我常用的几个维度维度度量项说明效率需求平均交付时长、自助取数占比反映团队产能和自助化程度质量核心指标口径一致率、重大数据事故次数反映治理成效使用核心看板周活跃用户数、资产复用率反映数据是否真的被用起来价值数据驱动决策的案例数、可归因的业务收益反映对经营的实际贡献最后一行最难量化但必须做。我的做法是建一个案例库每做一个有价值的项目就记一条业务问题是什么、用了什么数据、做了什么动作、结果变化多少。一个季度攒三五条年终汇报的时候这就是最硬的材料。注意收益归因要保守不要把所有业务增长都算成数据的功劳那样反而没人信。宁可写预计贡献 X%主要归因于 A 和 B也不要写数据驱动增长 30%。5. 常见问题与排查技巧实录5.1 数据口径打架怎么处理这是最高频的问题。我的处理流程分四步。先分离事实与立场。两个部门报的数不一样先别急着判断谁对谁错先搞清楚各自的取数逻辑。大部分情况下双方的逻辑都是自洽的只是假设不同比如一个含税一个不含税一个按签收时点一个按下单时点。然后找差异点做归因。把两边的取数 SQL 拿出来逐层比对从最细粒度开始看是哪一步开始分叉的。这一步必须动手不能靠猜。我见过最典型的差异来源是一方过滤了测试订单一方没有一方用的是主表一方用的是包含历史归档的视图。接着定标准不定对错。很多时候不存在绝对正确的口径只有适合当前业务场景的口径。定完之后写进口径卡明确适用范围。最后建立变更联动。口径一旦确定所有下游报表、看板、模型都要同步这需要一份指标-下游的映射表改的时候照着表通知。这份表其实就是血缘关系的业务版本价值极高。5.2 业务部门不配合怎么办数据治理类的工作业务侧配合度低是常态因为对他们来说是纯成本。破局的关键是把配合你的工作变成解决他的问题。具体做法不要拿着标准文档去找业务而是先问他们最近最头疼的是什么。如果他们说每月初算提成要花三天那你就用这个切入帮他们把这个流程自动化顺带把里面的数据规范定下来。人不会为抽象的标准付出努力但会为具体的痛感付出。如果业务侧是表面配合、实际拖延我的做法是降级推进。不去追求全域覆盖先把配合度最高的那个条线做透做出成绩然后拿着结果去找一把手请他在会上做一次横向对比。对比的压力比自己催十次都管用。还有一种情况是业务侧确实没有能力配合比如接口人自己都不清楚业务流程。这时候要先帮他们梳理流程这件事听起来是分外之事但绕不过去数据是流程的影子流程不清数据必然乱。5.3 数据团队留不住人数据团队的人员流失通常不是钱的问题是成长感和价值感的问题。一个人如果每天在做取数、修数据、催上游看不到自己的产出被谁用了很快就会走。我自己会做几件事。一是让每个人至少参与一个端到端的项目从需求到落地全程跟让他看到自己的工作产生了什么变化。二是轮岗做平台的去跟两个月的业务分析做分析的去做一段时间的数据治理视野打开之后人的状态会不一样。三是把重复性工作尽量工具化我不希望团队里有人因为只有他会跑这个脚本而有安全感那种安全感是假的早晚会被替代而且会拖累整个团队。另外汇报的时候要点名。项目做成了在正式场合把具体做事的人点出来这件事成本极低效果极好。5.4 常见问题速查表现象大概率原因优先动作同一个指标多个部门口径不同缺少指标统一定义与强制取数入口先收口一级指标建口径卡做指标服务层报表没人看需求来源是觉得有用而非真实决策场景拉使用数据下线低使用率看板重新对齐需求数据延迟频繁上游系统或调度链路不稳定做链路监控区分源头延迟与加工延迟分别定 SLA治理推不动只有数据团队在推业务侧无感知选痛感最强的场景做速赢用结果换配合数据质量报警没人管报警过多、无处置人收敛到 20 条以内每条绑定处置人和动作数据团队忙但产出少需求无准入、无优先级建统一需求池按价值排序公开排期分析结论没人采纳结论与决策场景脱节分析前先确认结论会改变什么动作数据产品成本高收益低没有使用方验收标准上线即定验收指标三个月无使用则止损6. 几个容易被忽略的细节最后聊几个我觉得重要、但常规材料里很少提的点。第一CDO 这个岗位一定要有退出机制的意识。我说的不是给自己留后路是说数据治理的很多东西做到一定程度就该交给常设的组织机制去运转而不是靠你个人推动。如果你的组织离了你就转不动那说明你建的不是机制是个人权威。真正的成功标志是你休假两周口径变更流程照常走质量报警照常闭环。第二别把数据文化当成一个虚词。数据文化的实质是开会的时候大家习惯先看数再下结论争论的时候拿数说话而不是拿职级说话决策之后回头看数验证。这三件事能不能发生跟培训没关系跟你的机制设计有关系。比如经营会的材料模板里强制要求每个结论都附数据支撑这一条比讲十次课都有用。第三谨慎对待数据资产入表这类概念。方向是对的数据确实应该被当作资产来看待和计量但具体到怎么计量、怎么确认涉及大量专业判断和合规要求不是数据团队单方面能定的。我的建议是先把数据能被复用、能算清成本、能说清价值这三件事做好计量口径这种事等基础扎实了再和专业条线一起研究不要本末倒置。第四给自己留出思考时间。这个岗位很容易被会议填满一天开五个会一个月下来什么实质进展都没有。我自己的习惯是每周留半天不安排任何会议专门用来想一件事这个月我做的所有事情里哪一件是真的在创造价值哪一件只是在维持运转。这个习惯帮我砍掉过好几个看着重要、实际没产出的项目。踩过的坑里最大的一个大概就是早期太想把体系建全。我花了大半年做标准和文档做得很完整但业务侧几乎没感知。后来我调整策略把 70% 的精力放在具体的业务场景上20% 放在机制建设上10% 放在长期体系上节奏一下子就对了。体系是长出来的不是设计出来的这一点我用了很长时间才真正接受。
