决定产品的成败：数据产品建设中的组织分析

| 决定产品的成败：数据产品建设中的组织分析 张勍腾讯数据产品专家 目录CONTENT 01为什么聊组织 02理想的组织模型 03讲几个例子 04实践 05总结 | 01为什么聊组织 ffi"#$%&'()* 产品调研 产品设计 产品研发 产品运营 产品需求 绝大多数产品从接到需求开始，会快速陷入功能设计、迭代、研发的产品循环中组织对产品的影响往往在产品上线遇到阻力后 &'+,-. 技术硬件数据 组织个人 相对固定、个体变化较小的 时常变化、个体变化较频繁的 相对确定 不确定性 假设：我用世界上最好的技术、领先业内10年的产品，是否能把公司的埋点做到最棒？ 财务 市场 行政 一个人的公司 财务 市场 行政 销售 售后 售后 销售 做好时间管理，安排妥当 单人变多人时，单块效率增加，但加入了协作的必要性，同时不确定性增加了 了解组织协作的全貌 了解不确定性（变量） 减少不确定性带来的风险 &'() 提前做好规避 调整各方预期 | 02理想的组织模型 与数据流向息息相关的组织结构 绝大部分公司以数据流来做组织划分 数据采集 数据仓库 数据应用/分析 数据供给 数据消费 user 拿来就用 如何做好数据供给侧的高效协同 如何做好衔接 最佳组织形态的设计目标 1 •需求、问题有清晰的流程 •业务部门用数沟通成本低 数据部门（供给）与业务部门（消费）衔接是畅通的 2 数据部门的子部门定义明确，边界清晰•Case:OLAP引擎只存在一个部门 •业务部门用数沟通成本低 3 避免重复造轮子 4 避免因组织边界不清晰、职责不合理导致后续的治理行为 •例如让研发设计埋点 理想组织模型 业务一 不设数据岗 业务二 少量数据岗 业务三业务四 设数据岗、部门，数据应用、分析闭环 服务 业务N.. 他们在哪儿？ 报表挖掘实验AI.. 运 消费DS/DPM/BI营 / 供给 数仓 平台/应用/工具(saas) 集群/底层技术/引擎/存储（IaaS) !"#$用 户 DE/RD/PM成功 主数据 组织变化时，什么会受到影响 权限 技术性 留下历史债 &'-/ 项目延续性 非技术性 方向调整 技术性：抗击业务变化带来的组织调整，需要考虑主数据和权限带来的变化 非技术性：优秀的标准、流程、和角色的设计，在组织变化过程中会很好的保证延续性 | 03讲几个例子 它们都不是方案的问题 分裂的数仓 APPDWSDWD ODS 团队A APPDWS DWDODS 团队B 团队A 下游优势 团队A 上游劣势 •DWD的表不能用，太慢，加工SQL复杂 •DWD的表满足不了业务需求，自己建模 •ODS接入时间太长 •接触不到业务，主动接触会违背组织设定 •错误回收站，所有问题都可归咎于接入和模型 •精力转移，治理为主要工作内容，偏离了本质 •数仓的割裂是不利于数据内容的建设的 •得数仓者得天下 •团队的分裂最终会是个吞并的过程 •数据模型迭代缓慢，甚至有可能倒退 随着时间的推移，演变成 APPDWSDWD 团队A | ODS 团队B 内容集中化管理与组织的冲突 数据部门 •报表统一出 •表权限收拢 •主推纯供给方式 业务部门 •消费原始数据 •自己制作报表、应用 •主推内容自闭环 天然的地理、组织属性导致集中管理不能实现 解决数据一致性问题团队规模扩大 集中化管理效率高 北京上海杭州深圳… 均设有独立的数据岗位和部门提 索•报表的迭代跟不上业务的变化供要•一致性问题并未真正解决大 原•需求时长按周起量 始•需求非常多，承载能力有限的数•越来越多的负面声音报 据表 数据部门 要时效性要灵活性要自主性 组织的建设要全盘来看，不能为重点解决单项问题而设计 找到最佳效率模式，做高效且讨好的事情 中台/平台的组织演变过程 平台/应用/工具(saas) 业务一业务二业务三业务四业务N.. 集群/底层技术/引擎/存储（IaaS) 商业化产品矩阵 与内容相结合 加入了运营和用户成功团队 血统非常纯正的工具团队 理想：业务用的越多越好，WAU\高频用户为主要核心目标，考虑商业化的可能性实际的组织的演进过程（从0-1的建设）： %&%'()* 业务是否接受平台平台覆盖度、渗透 9&9:;<+=>* '+,&,-./*%01234567,+!8* 数据的使用者的使用深度、对业务的服务深度使用率、优质内容的丰富程度 ?@ABCDEFGHIJKL MNOPQRSTU 希望有点收入 组织如果不随着平台产品成长而随时调优，都会增大失败的可能性 | 04实践 0123456 1 业务/业务体量 直播业务是公司的一个主要业务线，业务体量很大，DAU3000万以上，收入不错，但公司有成本管理意识，业务部门有产研闭环，有自己的数据部门，负责数仓和数据分析，集群、底层技术、平台由集团统一管理。 2 现状 •业务部门的数据问题总是出自上报错误 •业务提出需求由数据部门分析师负责分析+上报 •上报工具在数据平台部门 •业务产品研发、数据仓库归属业务自己 •数据上报量越来越大，成本逐步增高 期望 3 •业务部门要出HC成立常态化的上报小组 •减少数据上报的问题 •让数据成本可量化、可控 •发现问题能够快速处理、有SLA保证 你在业务数据部门，给我们5个人负责埋点，1年的时间，达到期望目标，该怎么做？ 分析过程 组织脉络图 关系分析 变量/动作 产品、运营、业务部门 原有模式 •需求提出方 •每周的需求量是多少？5人的承载上限？ •是否有标准的流程？ •业务方对上报工作的理解程度和工作边界是否清晰？ 业务研发数据 部 业务测试门 数仓团队 我们的5人在这 •接手原来分析师的上报工作 分析师团队 •研发、测试是紧密合作伙伴 •数仓团队是下游 •埋点工具需用集团统一的 •以往的工作模式是什么？问题点在哪儿 •上报流程是否规范标准，问题纠纷怎么解决 •研发、测试对上报工作的要求是什么？ •数仓、研发、在上报方案上是否有统一的原则 •成本管理与数仓、研发的协作关系？ •工具是否满足需要？ •工具能否给我们的工作带来便捷 集群、平台（提供工具） •和工具有无合作的可能性？ •不合作、不好用，怎么办？ •【工作过程】：5人的协作、备份、考核、工作方法、效能、人员变动、内容沉淀的方法？ •【团队稳定】：成员成长空间 •【团队保护】：流程、标准、兜底原则、工作边界 如何去做/风险预期 期望 •减少数据上报的问题 •让数据成本可量化、可控 •发现问题能够快速处理、有SLA保证 1 2 【没有流程】【上报标准规范不全】【工具不好用】【没有问题发现预警机制】【工作边界不清晰】 分析问题多的原因 阻力点：规范研发、测试平台方的配合度 阻力点：规范业务行为 会有沟通与组织风险，流程达不到一致，或者没有落地，不执行（包括提需求、协作） 【业务】制定需求流程 现在1年后 3 【研发、测试】制定上报规范、标准 【时间长】，有一定的概率达不成一致，需要联动的角色多，需要落地到工具中 5 【数仓、平台、研发】成本量化可控 【量化算法】不统一，【量化与可控】的方案在平台的落地情况 4 6 •6件事，5件在供给侧、1件在需求侧重点关注共计侧的合作机制： 找到共同的利益点、或者协同制定OKR 【预警、质量】需要产品化，与平台工具的合作很重要，可以事先跑通 【数仓、平台、研发】问 题预警、SLA 阻力点：平台方配合度 【不是唯一的使用方】需求可能不会被重视，或者排期时间长，需要寻求利益共同点 【平台】工具不好用 •规范、标准、流程为主旋律，但想真正落地需要平台侧支持，如何让平台能够及时满足自己的需求规划需要重点考虑 •顺序上可以先尽可能的人工下线跑 通，拿出有利的证明，进行合作 | | 05总结 78%"#897%8:#%* 组织脉络图 先有一个组织脉络 寻找不确定性 寻找组织中的不确定 摸清边界 什么能做什么不能做 明确定位 在整个组织中的定位 •【事前分析】养成做事前对组织以及整体脉络进行分析的习惯，明确风险和不确定性，在着手做方案 •【利益共同体】找到共同的利益点是最佳的合作策略，如果找不到，可以通过行政手段来绑定 •【OKR捆绑】OKR链接不同组织非常有用，找到和你合作密切的部门/角色，想法设法在他的OKR中体现你的需求 •【兜底原则/程序正义】摸清事情的运转流程后，优先去制定规则，占据流程的主导权，保护团队和自己的产品 •【饭桌】多和合作的部门一起吃饭，聊聊人生 | | 拥抱变化THANKU