核心部门

如果把我们前面讨论过的部门放在一起看，包括 SA、研发、QA、DBA、大数据、中间件、PE、NET、安全、风控、运维研发/工具平台、工程效能，那么一家技术公司的技术基础设施和工程交付体系已经比较完整，但距离一家完整的技术公司组织架构仍然有差距。

核心问题不是部门数量够不够，而是：谁负责创造业务价值，谁负责管理产品，谁负责公司的经营，谁负责控制风险，谁对最终结果负责？

如果这些职责没有明确归属，即使技术部门划分得非常细，也可能出现一种情况：平台建设得很好，流程也很完整，但业务增长、客户满意度和盈利能力却没有相应提升。

下面我从公司整体组织架构的角度进行梳理。

一、先看我们已经覆盖了什么

我建议把之前讨论的团队归入四个层次。

层次 团队 核心职责 完整性判断
架构与设计 SA、技术架构 系统设计、技术选型、架构治理 基本覆盖
应用研发 后端、前端、客户端等研发团队 业务系统开发与维护 基本覆盖
质量与交付 QA、PE、工程效能 测试、发布、工程流程、研发效率 基本覆盖
技术基础设施 DBA、中间件、NET、基础设施运维 数据库、公共组件、网络、运行环境 基本覆盖
数据与智能 大数据 数据采集、处理、分析、数据服务 部分覆盖，取决于实际业务
安全与风险 安全、风控 信息安全、业务风险控制 基本覆盖，但职责需进一步细分
资产与治理 CMDB、统一运维工具平台 资产管理、作业自动化、运维流程 基本覆盖，但需要明确数据责任人

这里有一个值得注意的问题：

有些是专业技术团队，有些是平台，有些是职能。它们不一定都应该成为独立部门。

例如：

  • DBA 是一种专业职能，规模较小时可以与基础设施团队合并。
  • CMDB 首先是一套资产数据体系，不一定需要单独成立部门。
  • 工程效能是跨研发、测试、交付的能力，可以由一个平台团队负责。
  • 安全与风控虽然都涉及风险，但两者的目标和决策机制不同，不能简单合并。
  • SA 既可能指解决方案架构师团队，也可能指系统分析师，需要根据公司的实际定义确定其职责。

所以，我们首先需要区分：哪些能力必须存在，哪些团队必须独立。

二、真正还需要补齐的六大领域

1. 产品管理与业务分析：决定做什么

这是我认为最值得优先检查的领域。

我们之前讨论了很多如何开发系统、如何部署系统、如何保障系统稳定运行，但还有一个更根本的问题：

为什么要开发这个系统？它解决了谁的问题？开发完成后，如何证明它创造了价值？

这些问题不能只交给研发团队回答。

应具备的核心能力

能力 主要职责 关键产出
产品战略 明确目标市场、产品定位和竞争策略 产品战略、目标用户
产品管理 规划产品功能与迭代优先级 产品路线图、产品需求
需求分析 理解业务流程、用户痛点和业务规则 业务需求、流程图、业务规则
用户研究 调研用户行为、使用场景和真实需求 用户画像、用户反馈
产品运营 推动产品使用、活跃和转化 运营方案、转化分析
产品数据分析 分析功能使用情况与业务效果 产品指标、实验结果

这里还需要区分产品经理与 SA。

  • 产品经理（PM）：主要决定产品解决什么问题、服务哪些用户，以及优先做什么。
  • 业务分析师（BA）：主要负责将业务目标转化为可分析、可验证的业务流程、规则和需求。
  • 解决方案架构师（SA）：主要负责将业务需求转化为可落地的解决方案，协调业务与技术设计。
  • 技术架构师：主要负责技术架构、系统边界、关键技术决策和非功能性要求。

实际公司可以合并角色，但不能让这些问题无人负责。

例如，业务部门提出一个需求：

我们希望增加一套智能审批系统。

产品经理需要回答：谁使用？解决什么问题？为什么现在做？如何衡量收益？

BA 需要梳理：现有审批流程是什么？有哪些角色、规则和例外情况？

SA 需要设计：与哪些业务系统集成？如何处理身份、权限、流程和数据？

研发团队负责实现，QA 验证，PE 负责上线交付。

上线之后，产品或业务负责人还要验证：审批时间是否缩短？人工成本是否下降？用户是否真正使用？

如果缺少产品管理，技术团队很容易陷入持续交付需求，却无法判断交付是否产生价值的困境。

2. 业务部门与业务运营：决定如何赚钱

产品管理回答做什么，业务部门则要对业务结果负责。

不过，这一领域需要根据公司类型判断。

如果是面向外部客户的商业公司

至少需要考虑：

能力 主要职责
市场与行业研究 识别市场机会、客户需求与竞争格局
销售与商务 获客、销售、商务谈判、合同签订
客户成功 客户 onboarding、使用推广、续约与客户价值实现
客户服务 客户咨询、问题受理、投诉处理
业务运营 业务流程、运营指标、活动与日常运营
业务管理 负责业务目标、收入、成本和经营结果

不一定需要成立六个部门，但这些工作必须有人承担。

例如，一家提供企业软件的公司，即使研发能力很强，如果没人负责客户开发、合同签订、实施交付和续约，也可能无法形成可持续收入。

如果是内部技术平台部门

情况不同。

这类团队的直接客户可能是公司内部的业务部门，而不是外部付费用户。

此时更重要的是：

  • 内部客户需求管理。
  • 服务目录和服务等级协议（SLA）。
  • 服务成本与资源使用情况。
  • 内部客户满意度。
  • 平台使用率和重复建设治理。
  • 技术平台的投入产出评估。

不要为了组织架构看起来完整，就机械地建立销售、市场、客户成功等部门。应先明确公司的业务模式。

3. 项目管理与交付管理：决定如何协调复杂工作

这部分很容易被忽略。

有了产品经理、研发、QA、PE，并不意味着大型项目一定能够顺利推进。

因为大型项目通常涉及多个部门、多个系统、多个供应商，以及不同的交付时间。

例如，建设一个新的支付系统，可能同时需要：

  • 产品梳理业务流程。
  • SA 设计系统架构。
  • 研发实现业务逻辑。
  • DBA 设计数据库。
  • 中间件团队准备消息与服务治理能力。
  • NET 配置网络与访问策略。
  • 安全团队评估安全风险。
  • 风控团队设计风险策略。
  • QA 完成集成和业务场景测试。
  • PE 负责生产部署与变更。
  • 财务、法务、合规团队确认相关约束。

每个团队都完成了自己的工作，整个项目依然可能失败。

原因可能是依赖关系没有管理、交付顺序不合理、关键决策无人拍板，或者业务目标发生变化后没有及时调整。

建议补齐的能力

能力 核心职责
项目管理 计划、进度、资源、依赖、风险和问题管理
项目组合管理 对多个项目进行优先级排序和资源分配
交付管理 协调跨团队交付，推动端到端结果
变更管理 评估需求、范围、时间和成本的变化
供应商管理 协调外部技术服务、采购和交付

这里需要区分项目管理和工程效能。

  • 工程效能团队建设研发流程、工具平台和度量体系。
  • 项目经理或交付经理负责具体项目的计划、协调和结果。
  • 产品负责人决定业务优先级和产品范围。
  • 技术负责人对技术方案与技术质量负责。

小公司可以由技术负责人、产品经理兼任项目管理；规模较大、项目依赖复杂时，才更有必要建立独立的项目管理办公室（PMO）或交付管理职能。

4. IT 服务管理与可靠性工程：决定系统能否持续运行

之前我们已经讨论了 PE、NET、DBA、中间件、工程效能和运维工具平台。

但还需要进一步明确：谁对端到端服务的可用性和可靠性负责？

这里要避免把传统运维、SRE 和 IT 服务管理混为一谈。

能力 核心职责 与现有团队的关系
IT 服务管理（ITSM） 事件、问题、变更、服务请求、服务目录管理 PE、NET、DBA、中间件等共同参与
站点可靠性工程（SRE） SLI、SLO、错误预算、可靠性改进、容量规划 与研发、PE、基础设施团队协作
生产事件管理 故障分级、应急响应、跨团队协调、复盘 通常由值班体系与事件指挥机制承担
灾难恢复 备份恢复、异地容灾、恢复演练、业务连续性 DBA、PE、NET、研发等共同负责
服务连续性管理 识别关键业务依赖，制定恢复目标 业务负责人、架构、基础设施、安全等共同参与

一个关键区别

PE 负责部署和生产运维，并不意味着 PE 一定要对所有系统的可靠性独自负责。

例如，某个服务发生故障：

  • 研发团队负责修复应用缺陷。
  • DBA 负责处理数据库性能或故障。
  • NET 负责排查网络链路。
  • 中间件团队负责处理消息队列或服务治理问题。
  • PE 负责生产操作、发布回滚和运行协调。
  • SRE 或事件负责人协调整体故障处理，推动事后改进。

在实际组织中，SRE 可以是独立团队，也可以是分布式职能。但无论采用哪种形式，都必须明确服务级目标、值班责任、事件指挥机制和故障复盘责任。

对于关键系统，还应该建立明确的恢复目标：

  • RTO：业务中断后，要求多长时间内恢复。
  • RPO：发生故障时，最多能够接受多长时间的数据损失所对应的数据恢复点差距。

否则，备份做了、监控也做了，却可能从未验证过系统是否真的能够恢复。

5. 财务、法务、合规与采购：决定公司能否持续经营

如果我们讨论的是一家完整的技术公司，而不只是技术部门，那么这些职能不可缺少。

它们不一定全部属于技术组织，但必须进入公司的整体管理体系。

职能 核心职责 对技术公司的特殊意义
财务 会计核算、预算、成本、现金流、税务、经营分析 控制研发成本，评估项目收益与现金流
人力资源 招聘、薪酬、绩效、组织发展、员工关系 建立可持续的人才供给和组织能力
法务 合同、知识产权、诉讼与法律风险 处理软件授权、客户合同、数据和知识产权问题
合规 识别适用法规与监管义务，推动合规管理 根据行业要求处理数据、隐私、金融等合规事项
采购与供应商管理 采购流程、供应商准入、合同履约、成本管理 管理云资源、软件许可、外包和硬件采购
内部审计 独立评价内控、流程和风险管理的有效性 检查权限、财务、变更和关键业务控制是否有效

需要特别注意三点。

第一，安全、风控、合规不是同一个部门的三种叫法。

  • 信息安全关注系统、数据、身份、网络和技术安全。
  • 业务风控关注欺诈、交易风险、信用风险等具体业务风险。
  • 合规关注法律法规、监管要求、合同义务和内部制度的遵循情况。

三者需要协作，但各自的职责、专业判断和升级路径应当明确。

第二，审计需要适当的独立性。

如果一个团队既负责执行控制，又负责独立评价这些控制是否有效，就会存在自我检查的问题。小公司可以借助外部审计或其他独立机制，但不宜完全忽略这一点。

第三，职能存在不等于必须设立部门。

初创公司可能只需要外部会计、法律顾问和兼职合规支持；业务规模、监管要求或复杂程度上升后，再逐步建立专职团队。

6. 数据治理与 AI 治理：决定数据和智能能力能否可信地使用

我们之前讨论过大数据，但大数据工程不等于完整的数据管理体系。

大数据团队可能擅长数据采集、存储、计算和数据服务，却不一定负责定义业务指标、管理数据权属或审批数据使用。

数据领域还应考虑的能力

能力 核心职责
数据治理 数据标准、责任归属、质量规则、数据问题处理
元数据与血缘 管理数据含义、来源、转换过程和依赖关系
主数据管理 统一客户、产品、组织等核心业务实体
数据安全与隐私 数据分级分类、访问控制、脱敏、保留和删除
业务指标管理 统一收入、活跃、转化率等指标定义
数据分析与决策支持 业务分析、经营分析、实验评估

这些能力可以由大数据团队、数据平台团队、业务部门和安全团队共同承担，但不能全部默认归给大数据工程师。

AI 时代还需要补充什么？

如果公司计划将 AI 深度用于产品、研发或内部运营，还需要关注：

  • 模型与供应商管理。
  • 模型评测与版本管理。
  • Prompt、知识库和检索质量评估。
  • Agent 工具调用权限和操作审计。
  • AI 应用的成本、延迟、可用性监控。
  • 敏感数据保护、提示注入和越权风险。
  • 人工复核、异常处理和业务回滚机制。

这些能力不一定要成立独立的 AI 治理部门。

更合理的方式是：由 AI 平台或应用团队承担技术实现，由安全、法务、合规和业务负责人共同确定使用边界，由产品负责人对实际业务效果负责。

AI 治理的重点不是给模型增加多少限制，而是确保 AI 在可授权、可评估、可追溯、可控制的范围内创造价值。

三、把所有团队放在一起：完整的技术公司组织能力地图

下面这张表可以作为我们后续设计组织架构的基础。

一级领域 二级团队或职能 是否必须具备 是否必须独立成部门
业务与产品 产品管理、业务分析、产品运营 是，面向业务产品时尤为重要 否
市场与商业化 市场、销售、商务、客户成功 取决于商业模式 否
项目与交付 项目管理、项目组合管理、交付管理 中大型复杂项目需要 否
架构与研发 SA、技术架构、前后端研发、客户端研发 是 视规模而定
质量与工程 QA、工程效能、CI/CD 是，具体实现可以分层 否
基础设施 PE、NET、DBA、中间件、基础设施平台 是，具体技术栈决定边界 否
可靠性 SRE、ITSM、故障管理、灾备 关键生产系统应具备相应能力 否
数据 大数据、数据治理、数据分析、主数据 视业务数据复杂度而定 否
安全与风险 信息安全、业务风控、隐私、合规 视行业、业务与监管要求而定 部分能力可能需要独立
企业治理 财务、人力、法务、采购、审计 完整公司必须具备相应职能 否
AI 与智能化 AI 平台、模型评测、AI 治理 使用 AI 的公司应逐步建设 通常不必一开始独立
资产与知识 CMDB、技术服务目录、知识管理、架构资产 随系统规模和复杂度逐步建设 通常不必独立

这里的“必须具备”，指必须有人承担相应责任，而不是必须建立同名部门。

四、真正容易遗漏的，是横跨所有部门的管理机制

我认为，组织架构图只能解决一部分问题。很多技术公司不是缺少部门，而是缺少跨部门的责任机制。

至少还应该明确以下六项。

1. 技术决策机制

谁有权决定：

  • 技术栈和核心架构？
  • 重大技术债是否偿还？
  • 哪些系统应该合并、拆分或下线？
  • 何时允许上线高风险变更？
  • 研发效率与稳定性发生冲突时如何取舍？

建议建立轻量级架构评审机制。重要决策记录原因、备选方案、影响范围和后续验证结果，而不是让所有技术问题都依靠会议拍板。

2. 预算与投资机制

谁决定研发资源投向哪里？

技术平台可能需要投入大量资源，但收益未必直接体现为收入。公司需要同时评估：

  • 业务增长。
  • 运营成本下降。
  • 故障与风险降低。
  • 研发效率提升。
  • 长期战略价值。

不能只用代码量、系统数量或平台功能数量来判断技术投资是否值得。

3. 服务责任机制

每一个重要系统都应该明确：

  • 业务负责人。
  • 技术负责人。
  • 日常运维责任人。
  • 服务等级目标。
  • 上下游依赖。
  • 故障升级联系人。
  • 下线和数据处置责任。

建议以服务而不是部门为单位建立责任清单。一个服务可能涉及多个团队，但必须有明确的最终责任人。

4. 风险与变更机制

重大变更需要明确：

  • 谁提出？
  • 谁评估？
  • 谁批准？
  • 谁执行？
  • 谁验证？
  • 谁负责回滚？
  • 谁更新资产和审计记录？

并不是每次变更都需要复杂审批。低风险、标准化的变更可以自动执行；高风险变更才需要更严格的审核和授权。

5. 指标与经营复盘机制

技术团队不能只看自身产出，也需要知道产出是否对业务有帮助。

例如：

维度 代表性指标
产品价值 用户采用率、功能使用率、客户留存
交付效率 需求交付周期、部署频率、等待时间
质量 缺陷逃逸率、变更失败率
可靠性 可用性、恢复时间、SLO 达成情况
成本 云资源成本、单位业务处理成本、平台维护成本
安全与风险 高危问题修复时效、风险损失、控制有效性
客户价值 满意度、续约率、问题解决时长

指标必须结合业务背景解释。比如，部署频率越高并不必然越好，云成本越低也不意味着服务质量更好。

6. 人才与知识机制

还需要有人负责：

  • 技术人才招聘与培养。
  • 技术梯队和关键岗位备份。
  • 技术文档与知识沉淀。
  • 关键系统的知识交接。
  • 跨团队协作和职责冲突处理。

这些工作可以由各技术团队负责人、人力资源部门和技术管理层共同承担。

五、我建议采用的组织结构

如果我们讨论的是一家具有一定规模、拥有多套业务系统和复杂技术基础设施的公司，我建议先按照以下结构设计。

CEO / 总经理
│
├── 一、业务与产品
│   ├── 产品管理
│   ├── 业务分析
│   ├── 产品运营
│   ├── 市场 / 销售 / 客户成功（视商业模式而定）
│   └── 项目与交付管理
│
├── 二、技术研发
│   ├── 解决方案架构 SA
│   ├── 技术架构
│   ├── 业务研发
│   ├── QA / 测试
│   ├── 工程效能 / CI/CD
│   └── AI 应用研发（视业务需要）
│
├── 三、技术平台与基础设施
│   ├── PE / 基础设施运维
│   ├── SRE / 可靠性工程
│   ├── NET / 网络
│   ├── DBA / 数据库
│   ├── 中间件
│   ├── 统一运维工具平台
│   └── CMDB / 资产与服务目录
│
├── 四、数据与智能平台
│   ├── 数据工程 / 大数据
│   ├── 数据平台
│   ├── 数据治理
│   ├── 数据分析
│   └── AI 平台 / 模型治理（视业务需要）
│
├── 五、安全、风险与合规
│   ├── 信息安全
│   ├── 业务风控
│   ├── 隐私与数据保护
│   └── 合规管理
│
└── 六、公司职能
    ├── 财务
    ├── 人力资源
    ├── 法务
    ├── 采购与供应商管理
    └── 内部审计（按规模及独立性要求设置）

这只是一个职责归属示意图，不是要求所有公司照搬的部门树。

例如，SRE 可以归属技术平台，也可以采用平台团队与业务研发共同负责可靠性的模式；数据治理可以由数据平台牵头、业务部门承担数据责任；安全与合规也可以采用独立团队加各部门安全负责人的协作机制。

最重要的是明确责任，而不是追求组织结构上的整齐。

六、不同规模的公司，应该怎样取舍？

同一套组织架构不适用于所有规模的公司。

公司阶段 组织重点 不建议过早建设的组织
初创期 产品、研发、交付、客户反馈、现金流 过细的中间件、DBA、NET、独立 PMO 等部门
成长期 专业分工、工程效能、可靠性、数据治理、安全治理 职责重叠的多个平台团队
规模化阶段 服务所有权、平台化、跨团队治理、成本优化 只增加审批层级而不改善交付的管理机构
强监管或关键业务阶段 独立控制、审计、灾备、合规、权限隔离 缺乏独立性的关键风险控制安排

需要补充一点：组织规模不是唯一决定因素。

一家只有几十人的金融科技公司，可能需要比几百人的普通软件公司更早建设独立的风险、合规和审计能力；一个客户很少但系统极其复杂的基础设施公司，也可能需要提前建立 SRE 和专门的基础设施团队。

七、最终判断：还缺什么，应该按什么顺序补齐？

结合我们之前的讨论，我会把需要进一步确认的领域分为三个优先级。

优先级 需要确认的领域 为什么重要
P0：首先明确 产品管理、业务负责人、项目交付责任、系统服务负责人 避免只管技术建设、不管业务结果
P1：建立机制 SRE/ITSM、财务成本管理、数据治理、安全与合规边界 保证系统可持续运行，资源投入可衡量，风险可控
P2：逐步建设 AI 治理、独立 PMO、成熟的数据分析体系、专门的客户成功团队 随业务规模、产品形态和组织复杂度逐步演进

我的核心建议是：不要继续单纯增加技术部门，而应该从“技术团队清单”升级为“公司运营与技术治理体系”。

我们之前讨论的各个部门，已经覆盖了技术系统从开发、测试、发布到运行的大部分环节。接下来最值得做的，不是再补一个技术团队，而是把业务、产品、技术、财务、风险和交付串成一个闭环：

业务目标 → 产品规划 → 需求与架构 → 研发交付 → 生产运营 → 数据反馈 → 经营复盘 → 下一轮投入决策。

如果这个闭环真正成立，一家公司才不仅仅是拥有很多技术能力，而是能够持续地把技术能力转化为业务价值。

如果要继续深入，我建议下一步把这些团队整理成一份企业组织与职责总表（部门、核心职责、输入、输出、上下游、决策权、考核指标、平台系统），再基于同一套体系设计端到端流程。这样更容易发现职责重叠、责任空白和平台重复建设的问题。

参考资料