决定产品的成败：数据产品建设中的组织分析
导读： 本文将分享决定产品成败的关键，即数据产品建设中的组织分析。
一直以来，很多人都在聚焦如何做好产品，绝大部分的分享与交流都聚焦在需求、场景、用户、价值、运营以及增长和对业务的理解上，谈论组织相关的内容却鲜为少见。
老产品经理都明白一句话，技术问题都不是问题，人的问题才难解决。作为产品，我们的核心工作就是解决问题。解决问题离不开人，往大了说，离不开组织。
公司中的人都会按照功能和实际业务进行组织的划分，组织形态和每个公司的人数、业务规模、人才发展息息相关，组织的变化对业务和产品的影响非常重要，例如组织调整导致的产品夭折；组织内耗导致的产品跳票，口碑不好，运营成本高；良好的组织设定对一个产品进行良性发育起着非常重要的作用，可以说，没有一个良好的、稳定的组织，就不会有一款好的产品。
分析组织、解决组织带来的问题，也是我们作为产品需要必备的一项能力，本文就组织决定产品成败进行了分析，也希望能够在组织影响产品发展这一块能够给到一些启发。
全文目录：
-
组织分析
-
理想的组织模型
-
讲几个例子
-
实践
-
总结
分享嘉宾｜张勍 腾讯 基础产品组组长
编辑整理｜依依 哔哩哔哩
出品社区｜DataFun
01/组织分析
1. 为什么要做组织分析
我们要做一个产品并解决某些场景下某些用户问题的时候，大致的思路是接到产品需求，产品调研需要什么，如何解决问题。然后开始进行产品设计，包括流程设计、功能设计，中间会参考行业内优秀的产品，经过迭代把产品研发出来，最后进行产品运营。
绝大多数产品从需求开始，很快陷入功能设计、迭代、研发的产品循环中，其实很多产品上线之后会发现存在组织的阻力。这些阻力会导致产品后续发力不足，或者中途夭折的情况发生。
在设计产品的过程中，有两类因素需要考虑，一个是相对确定的，一个是不确定的。
比如数据类产品会涉及技术、交互、硬件等等。这些本身相对固定，技术就是技术，数据就在那里摆着，在一定时间周期内不会发生太大的变化，个体变化较小，比较容易确定。
组织和个人会是变量。随着外部环境和业务而变化，组织是不断变化的，变化会带来不确定性，例如人员的变动、思想的变动、组织的变动。因此一定要将确定和不确定的内容组合起来统一思考。
我们可以换个角度来思考，如果你有了很好的技术、硬件、资源投入，是否能做出一款好用的产品？
举个例子，如果你要开一家公司，公司只有你一个人，可能你需要负责售后、售前、行政、市场和财务，整个公司的所有业务过程不存在和任何人交流，都是自己来决策和执行。所以公司不存在组织，你个人只需要做好时间管理，事情安排妥当，公司就能够运转，公司效率=你个人的效率。
结合不同的业务和职位，分配了更多的部门和人，人一多，变量就会增加。因为人多了，会有沟通。沟通方式以及信息传递会有损耗，互相之间的意识和想法也会有不同，进行摩擦。协作的加入，增加了不确定性。
2. 组织分析
组织既然是变量，并能带来不确定性，对组织进行有效的分析、进行合理的判断和调整就非常有必要。
在做组织分析的时候，需要了解以下几点：
① 了解组织协作的全貌：需要知道现在所做的事情在整个公司组织内所处的位置；
② 观察、发现、探索组织带来的不确定性（变量）：通过与不同组织的沟通了解获得；
③ 减少不确定性带来的风险；
④ 提前做好风险规避。例如知道和某个组织之间存在协作，目标不太一致情况下如何解决，能够提前预判而不是事后解决；
⑤ 调整各方预期，拉齐目标。
综上，进行组织分析主要是由于组织会带来更多的风险和不确定性，我们要提前做出预判。
下面重点分享数据产品在整个组织中的理想模型。
--
02/理想的组织模型
1. 与数据流向息息相关的组织结构
目前很多公司的数据部门内的组织都是基于数据流向来设定的。数据流向从数据采集到数据仓库再到数据应用，最后数据被用户使用。
我们一般把数据组织按照两类划分，一类是数据供给侧，一类是数据消费侧。供给侧是通常所说的数据部门，解决数据供给的数据采集、生产、加工和分析，最后把可靠准备的数据给到业务。该组织更关心组织内部如何做到高效协同，能够把数据建设本身做到最高效。另一部分就是和消费侧如何做好衔接。
消费侧包括业务、产品、运营、老板，甚至外部用户，这类人群的组织想要通过数据帮助提升业务的能力。
供给侧的组织，一般在公司内是数据部门，主要负责平台的建设和数据内容的加工处理。消费侧则是业务部门下有数据专业能力的人，对数据本身进行消费（分析）进而帮助业务进行业务决策和业务辅助。
2. 最佳组织形态的设计目标
供给组织与消费组织如何做到协同最佳？最佳组织形态的设计应遵循以下原则：
① 数据部门和业务部门衔接是畅通的，至少业务部门要某些数据的时候能知道找到谁，流程是什么，有很低的沟通成本，减少或者避免组织墙的存在；
② 数据部门的子部门定义明确，内部运转协作过程中边界是清晰的，部门运转起来高效；
③ 避免重复造轮子，业务由于数据部门的服务周期长、灵活度不足等问题，导致部门自己去建设数据平台；
④ 避免组织边界不清晰、职责不合理引发后续的治理行为，治理的问题不是技术和方案的问题，一定是人的问题。
3. 理想组织模型
理想的组织模型：
底层 IaaS 和 SaaS 层包括平台工具和引擎、技术、数仓，这类的职能和角色在任何公司内部都相对明确，都是工程师、大数据的研发以及做集群的角色。这部分以技术人员研究技术为主，组织稳定，是成本中心，长期主义。
数据分析、数据产品、内容型或平台型产品，以及挖掘、实验、人工智能、搜索推荐等在什么位置，会根据公司的不同发展阶段，以及不同的需要，有不同的设定方法。
如上图所示。
第一种业务，不设数据岗，所有数据需求和能力都会往下；
第二种设少量数据岗，自己有主观能动性，能够设置一些角色结合下面的数据部门和纯数据岗位进行交流满足业务；
第三种是设置较全的数据岗位，分析师来自己做分析的闭环，只是往下要数据能力，不是要数据，甚至有的业务的需求直接打到 IaaS 层，所以根据不同的业务面对的情况都不一样。
中间层消费在哪是根据实际情况而定的，但一定是从上往下走的，运营和用户成功更多偏向于数据和平台，在业务需要能力的时候如何能够将能力用的更好，所以中台侧和平台侧更需要这类角色，比如做工具型产品希望用户把工具用的更好，运营在其中起到非常大的作用。以上就是我们通过数据流看到的较为理想的组织模型。
4. 组织变化时，什么会受到影响
公司经历较长的生命周期时，组织变化会给数据平台带来什么样的实际影响呢？
一影响到主数据，组织变了，A 业务和 B 业务发生融合，主数据一定会发生很大的变化和冲突。
二是权限，从 A 组织变到了 B 组织，权限会大面积丢失或者会存在交接期，这是技术性方面我们需要考虑到的。
三是项目的延续性，原来做某些技术性研究或者对某一个业务上较有帮助的项目做到了 50%，因为组织、人员的变化有可能会被中断。
四是目标方向调整，融合的业务在数据方向上可能会有调整，比如组织调整前数据部门关注业务在数据上的使用效率，调整后更关注数据质量和成本，这时候方向就需要掉头。原先组织的项目计划就会中断，组织协同也会因为目标的变化而变化。
所以总结来说，抗击业务变化带来的组织调整，主要是在主数据和权限上，在技术上做出考虑；
非技术性方面，应该尽一切可能在组织调整时，影响决策者，让有价值的项目延续下来。并且很多项目在立项之初，就要确保做好沉淀。沉淀流程，角，标准，技术底蕴。组织再变化，沉淀的流程和技术，也不会推翻了重做，确保这些内容不会因为人的变化而变化，甚至是要让变化的成本很高。
--
03/讲几个例子
1. 分裂的数仓
一般来说，业务数据流，最终都会融合到数仓里，然后基于数仓做后面的应用。
分裂的数仓指数仓团队由两个不同的领导负责，团队 A 负责上层的应用，分析师和业务经常用到的数据，例如 APP 和 DWS 层；团队 B 负责数据接入和数据模型的建设。
从实际的经验来看，两个团队一定是不能够长期并行合作下去的，最终一定会融合成一个。例如团队 A 在上层做有业务主动优势，是能够接触到业务，可以对接到对应的数据产品，出于私心，就可以说底层团队的 DWD 表不能用，无法解决业务需求，甚至是时效性和准确性都无法保障，后续就会逐步会自己做 DWD。
团队 B 会存在较大的劣势，因为接触不到业务，团队 A 会对业务灌输 B 存在不合理的导向，以便逐步摆脱对 B 的依赖。例如会说团队 B 数据产出不准确，实效性差等。长期的错误宣导会让 B 处于及其不利的境地，组织会从新思考 B 团队存在的必要性。
其实本质上是数据内部的问题，即数仓本身的设定问题，对于业务和数据本身来说是一个不利的现象，业务拿不到好的数据使用，好的情况会持续一段时间，但一旦人员发生变动最终会是一个融合和吞并的过程。
那么 A 的动机是什么呢？一山不容二虎，组织竞争过程中，人的私心所致。所以职能团队相似的情况下，融合的优势大于分裂。
得数仓者得天下，拿着内容和数据一定是占据优势。数据建设不会在分裂的过程中有较好的进步，对业务和数据来说都不是一件好的事情。
2. 内容集中化管理与组织的冲突
公司业务部门使用数据时一定会遇到数据不一致的问题，业务反馈数据存在问题，希望数据报表和指标都由数据部门提供。数据部门也希望解决数据一致性的问题，想通过集中化的方式来解决问题，白话说就是所有的报表数据都统一由数据部门来做。
对于数据部门的领导者来说，是有好处的，因为要解决业务的需求，团队规模能够扩大，且集中化管理效率高。但在执行这种组织模式前，需要考虑公司现有的组织形态。
有些公司有很多的分公司，都有自己独立的数据部门，对他们来说服务当地的业务很难把所有的数据需求都提到总部来，数据部门有三个"要"，要时效性，要灵活性，要自主性，本质上来说和前面的思维是冲突的。不可能把所有分公司的数据全部接过来，也不可能承包所有需求，ROI 会随着人数的增多更直线降低。设想，在深圳的业务老总，要一个数据，还需要等北京的总部数据部门的分析师来跑数吗？
所以天然的地理位置和组织属性导致集中管理难以实现。即便是部分实现也比较困难，因为不同的业务在不同的地方会有不同的业务侧重倾向，比如北京更关注市场，深圳更关注政策，上海更关注外资，无法实现数据对齐。所以在决策时要考虑到组织，不能为重点解决某一个问题来做对应的设计，应该全盘考虑，找到最佳效率模式。
3. 中台/平台的组织演变过程
最后说一说平台，平台的组织在不同阶段也会需要一些变化。初期，我们是一个非常纯正的工具团队，就是为了做某一个工具，例如开发/测试/可视化工具，过程中想的是 0-1 的建设能否让工具被使用，最关注的是 WAU 和用户的使用情况，以及是否有团队和我一起在做这个事情，避免重复造轮子的问题。
立住之后需要思考如何让它用的更好更深，与内容相结合，如何能基于平台创造出好的内容，比如原来是看报表的，现在能否基于平台做深度的分析，例如实验、人工智能等，服务能否统一，将其他同质类的产品基于我们的服务产出，这是中台的能力演变过程，在演变过程中也需要做对应团队的调整。
到第二阶段需要加入运营和用户成功团队，到第三阶段一定要和不同业务的分析师，数据科学家以及数据挖掘工程师深度结合，"内容在哪，用户就在哪"，能否通过能力创造出更好的内容来。再往后是商业化产品矩阵，希望把自身的能力，思考和产品方案能够商业化。所以组织在平台的建设过程中一定要根据自身不同情况进行调优，而不是一直在做工具。
--
04/实践
1. 数据上报/埋点
在数据产品领域，一个埋点，一个指标，对于新人来说是看似简单实则非常不友好的工作。
我们做一个假设：有一个业务体量还不错，直播业务，收入不错，公司有比较好的成本管理意识，在过程中业务产研闭环，有自己的数据部门，负责数仓和数据分析，集群、底层技术、平台由集团统一管理。现状是业务觉得数据上报总是出现问题，现在数据埋点上报由数据部门分析师负责，工具在平台侧，业务产品研发、数据仓库归属业务自己，数据上报量越来越大，成本逐步增高。业务和公司期望需要给一些人解决问题，出 hc 成立常态化的上报小组，减少数据上报的问题，并且能让数据成本可量化、可控，在当前经济下行的环境中减少不必要的上报，发现问题能够快速处理，有 SLA 保障。假设你在业务的数据部门，给我们 5 个人负责埋点，1 年的时间，达到上述期望目标，该如何做？
这里的解法是：首先需要解决技术问题，其次需要解决方案问题，同时一定要考虑组织协同性的问题。
2. 分析过程
首先分析组织的脉络，平台和工具在最底层，往上是业务部门，包括自己的数据部门，业务研发和测试，原有的模式是分析师和数仓团队对接业务解决他们的数据埋点。
流程是业务提出需求，接手原来分析师的上报工作，研发、测试是紧密的合作伙伴，每次埋点和他们都有关系，数仓团队是下游，上报完成之后数仓负责接手，埋点工具由集团统一控制。
变量和工作是什么？对于业务来说，我们不知道他们每周的需求量是多少，当然可以根据原来的情况进行分析，是否有标准的流程，以及业务方对上报方的工作是否有比较清晰的理解，能否比较好的进行配合工作，这是关于业务的。对于研发来讲，工作模式是什么，如何进行协作，有无对应的规范，过程中规范是否合理，研发、测试对上报工作的要求是什么，数仓和研发在成本方面管控是否有对应的方案，到底如何协作，这是和研发、数仓紧密协作的过程。集群和平台对于他们也是存在需求的，工具是否满足我们的需要，如果在合作过程中不合作或者是不好用怎么办，可能会有一些预判。对于自身团队来说，5 个人如何协作，团队稳定性方面是否有成长空间，最后一个非常重要的是团队保护，我们在做这件事情过程中，流程、标准、兜底原则、工作边界是什么，在其中有清晰明确的规定保护自己的团队。
3. 如何去做/风险预期
首先需要分析原因，为什么会存在之前的问题，例如没有流程，上报标准规范不全，工具不好用，没有问题发现的预警机制，以及工作边界不清晰，当然还存在方案或者技术性的问题。
第二步对于业务来说，要做沟通与组织风险，和业务明确要做什么，以及是否能对现在要做的事情有了解，其中阻力点在于要规范业务的行为，有需求要正常走流程，他们可能会不配合，如何解决这些问题。
**第三，**研发、平台工具和数仓，不是唯一的使用方，需求可能不会被重视，或者排期时间长，如何解决。研发和测试联动的过程是否有对应的标准，出现纠纷如何解决，其中对应的阻力点是需要规范研发和测试，以及平台方的配合程度。对于控制成本以及发现问题能够快速处理，需要制定规则，规则是否能基于平台能力做，所以阻力点仍在于平台的配合度。
综上，6 件事，5 件在数据供给侧，1 件在需求侧，重点需要关注供给侧的协作问题，比较好的方式是需要找到共同的利益点，或者是协同制定 OKR。此外，规范、标准、流程是整个埋点过程中的主旋律，像生产线一样，给定工具和技术，是否能将流程和标准按照方式严格执行，怎么样落地，这是非常难的，制定了标准并且跑通了，能否落地下来是从第一步迈进有了流程，到最后一步有了一个真正大的跃进其实是落地，需要平台侧的支持，如何让平台能够及时满足自己的需求，以及有对应的规划，能够一起合作共建是很重要的一点。顺序上，很多规则和流程需要尽可能地人工线下跑通，再拿出有利的证明，进行合作。
在这 1 年的过程中，先分析再找到在不同的组织中阻力点和问题，再把他们列出来，集中攻克，我们需要通过组织分析帮助解决对应的不确定性。
--
05/总结
1. 谁，做什么，和谁做，怎么做
对于数据产品和组织来讲，最重要的一点，首先要从产品设计中跳出来，思考需要和谁合作，做什么，以及怎么做，这是非常关键的，需要认清周围的人，了解他们，不管是控制整个全局还是局部。首先要有一个组织脉络图；在做事的过程中寻找组织中的不确定性，人、事的不确定性以及未来预期可能会发生的不确定性；第三块摸清边界，没有流程和标准就没有办法走上程序正义；最后就是明确自己的定位，同时需要老板、周围的用户以及服务的对象能够明确你的定位是什么。
2. 最后总结
**① 事前分析：**首先需要有一个事前分析，养成做事前对组织以及整体脉络等进行分析的习惯。
**② 利益共同体：**发现了问题，怎么去做，实现合作共赢，长久之计是合作能够达到一定的目标，解决自身的问题，合作一定比互相拆台更有效果，这里关键在于如何做。
**③ OKR 捆绑：**在利益共同体不明确的情况下可以做一些 OKR 的捆绑，有时候写 OKR 大家都在讲 OKR 对齐，可以将 OKR 工具利用起来，尤其是在汇报的层面上，能否基于某些关键场合和关键重点基于自己的方向建立起 OKR。
**④ 兜底原则/程序正义：**能进能退，在守的过程中找到一个点，遇到问题，如果大家合作出现问题的时候如何解，发现问题谁来兜底，谁来做最终的决策者，这是必须要有的。
**⑤ 饭桌：**多和合作的部门线下沟通，一起吃饭，聊聊人生，互相之间在生活上有更好的了解。
最后用拥抱变化一词反映现状。原来非常反感变化，尤其是做数据，但还是要慢慢适应环境、组织、人的变化给我们带来的影响。
--
06/问答环节
Q1：工具产品在业务推广过程中用不起来，使用率不高
A1：首先需要了解用户量，例如有 1000 人，现在只有 100 人，还有 90% 的上升空间，提升它首先需要做一下调研，可以做全量的 NPS 或者是满意度的调研，了解为什么，其次需要做好客服 oncall，大家用的时候会有问题反馈，结合 oncall 和调研长时间的反馈观察大家的聚焦点在哪里，用不好或者是使用率不高主要存在两种情况，第一种是不好用，本身产品确实难用，费了半天效率变低，质量变差；另一种是人家已经有了，得去了解对方是否用已有的，比如我们的工具是做分析和可视化的，对方使用 Excel 就能完成，而且特别方便，每天花半个小时就能实现，不用学习工具，但是我们现在的工具还得让对方重新学习一遍，所以我们需要将自己的优势和对方现在的现状做一个对比，将自己的好处和优势让对方能够清楚的了解。
所以让工具使用率高不是一个一蹴而就的过程，一定是相对缓慢的，得制定一定的目标，比如到年底或者明年能够从 100 人到 300、500，在 300 的增量过程中找到目标用户以及合作方，最好是找一个大的合作用户，比如某一个业务的老板，达成线下协议，这种方式会比较快，过程中需要做好保障，产品一定要好用，能够让老板知道用这个工具之后他能够有什么样的好处，比如提效，质量提高等等，并且同时需要把用户看板做起来，了解用户的行为，哪里用了哪里没用，为什么不好，能够每天进行观测。
Q2：业务对每次的工具迭代都有抵触，应该如何高效推进？
A2：需要找到抵触的是什么，主要是两个点，一方面本身自己有或者是有私心不想用想自己去做，另一方面是产品自身的问题，先抛开自身的问题，先和对方沟通抵触的是什么，有些时候获取不到对方真实的想法，可以通过外部的信息，业务的口吻或者是协作部门，比如 A 部门非常抵触你，可以通过和 A 部门关系密切的 B 部门了解，但是 B 部门可能不是目标用户，了解为什么不使用或者是怎么看的，从侧面了解也是一个关键的方式。
Q3：怎么和团队沟通确定兜底原则？
A3：兜底原则相当于是定一个框架，确定自己和谁之间一定会有问题和矛盾，比如和数仓团队、研发团队和业务团队都有矛盾，在确定之前先确定他们之间以及和我之间四方一定会有交集，如果没有交集我们先看我们和哪一方会存在交集，是一对一还是多对多的交集，将脉络图确定好之后一定要找到交集的问题点在哪，一定会发生各种各样的问题，比如问题 A 出现可能是数仓和研发之间的问题，你在过程中可能是第三方，但是你也需要去解决，因为和你脱不开关系，所以需要去看你们三方遇到问题应该如何处理，埋点这个事研发说不能做，数仓说不能做，最后怎么办，问题如何解做一个复盘，最终落下沉淀一个问题，以后再遇到类似问题的时候拿原则来说话，这是一个不断沉淀的事情。
Q4：资源有限的情况下怎么用业务价值和战略目标反推核心和一般的问题进而锁定范围？
A4：做数据需要去看最核心需要解决的业务是什么，比如是做搜索还是推荐还是成本管控，因为有些时候做比较上游的功能不太能够直接感受到业务价值，包括数据本身例如做埋点是不太可能知道后面数据怎么用，上游的事只能把准确性和效率提升这是你自身的价值，业务价值结合战略去看通过数据帮助业务有什么样的提升一定是可量化的，比如搜索率、转化率提升了，以及直接带来的业务收入，这是能够通过上层确定的点，然后将有限的资源投入这一个点即可，不要松散的去做，当然不是全部的人都投入这一个事情，别的不管也是不现实的，集中主力做这个事，其他的关于基础的建设以及需要并行去建设的也要列出来。
今天的分享就到这里，谢谢大家。
▌2023数据智能创新与实践大会
- 4大体系，专业解构数据智能
- 16个主题论坛，覆盖当下热点与趋势
- 70+演讲，兼具创新与最佳实践
- 1000+专业观众，内行人的技术盛会
第四届DataFunCon数据智能创新与实践大会将于⏰ 7月21-22日在北京召开，会议主题为新基建·新征程，聚焦数据智能四大体系：数据架构 、数据效能 、算法创新 、智能应用 。在这里，你将领略到数据智能技术实践最前沿的景观。
欢迎大家点击下方链接获取大会门票～
DataFunCon2023（北京站）：数据智能创新与实践大会
