去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。
他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”
这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。
一、为什么组织需要 MVP？
产品经理都知道，不要花六个月做一个"完美产品"再推向市场。先做一个最小可用版本，验证核心假设，根据真实反馈迭代。
但到了组织设计这件事上，所有人都忘了这条铁律。
传统的组织变革路径是：顶层设计 → 全面规划 → 统一推行 → 复盘调整。周期通常是半年到一年。这在变化缓慢的时代行得通——因为组织面对的外部环境相对稳定，你有时间做"一步到位"的设计。
但 AI 时代不一样。钉钉自己就是亲历者：2024 年初还在做对话式 AI 助手，到年底 Agent 化已经铺开，2025 年 MCP 协议和多 Agent 编排又成了主线。工具以季度为单位迭代、工作方式以月为单位变化、价值创造方式以周为单位重塑。你用年为周期的方法做组织设计，设计出来的那天就已经过时了。
所以我的判断是：AI 时代的组织变革，必须用产品化的方式来做——先出 MVP，跑通闭环，快速迭代。
二、组织 MVP 设计模型（OPD 模型）
我把这套方法叫做 OPD 模型（Organization as Product Design），核心思路是：把组织当成一个产品，用产品设计的方法论来做组织设计。
产品设计有三个核心问题：用户是谁、核心场景是什么、最小闭环怎么跑通。 组织设计也一样。
2.1 用户是谁？——重新定义"组织的用户"
传统组织设计的"用户"是管理者——组织架构图是画给老板看的，它回答的问题是"谁管谁"。
但如果你把组织当成产品，它的用户是谁？是在这个组织里工作的每一个人（包括 AI Agent）。 组织的"产品体验"就是：一个任务从产生到完成，中间经历了多少摩擦、多少等待、多少信息丢失。
用钉钉自己的产品语言来类比：
- 你的组织有多少 “页面跳转” ？（一个需求从提出到交付，要经过多少个部门？钉钉那个案例里是 5 个。）
- 你的组织有多少 “加载时间” ？（一个决策从发起到执行，要等多少天审批？9 天的等待就是组织的"白屏时间"。）
- 你的组织有多少 “404 页面” ？（一个信息从产生到被需要的人看到，中间断了几次？销售口头转述客户需求，到产品经理手里已经变形了三次。）
好的组织和好的产品一样：低摩擦、快响应、信息透明。
2.2 核心场景是什么？——找到你的"Day 1 Use Case"
产品 MVP 不是缩小版的完整产品，而是只做一个场景，做到极致。组织 MVP 也一样：不要试图重新设计整个公司，而是找到一个场景，在这个场景里验证 AI 原生的工作方式能不能跑通。
什么样的场景适合做组织 MVP 的"Day 1 Use Case"？三个标准：
组织 MVP 场景选择标准
高频 + 跨部门 + 有明确产出
→ 最佳 MVP 场景（客户需求响应、内容生产、数据报告）
高频 + 单部门 + 有明确产出
→ 适合做 Agent 化试点，但验证不了组织协作问题
低频 + 跨部门 + 产出模糊
→ 战略规划类，不适合做 MVP
低频 + 单部门 + 产出模糊
→ 完全不适合
钉钉选的 Day 1 场景就是前面说的 “企业客户 AI 解决方案的端到端交付” 。这个场景完美命中三个标准：跨部门（销售 → 解决方案 → 产品 → 技术 → 交付，五个角色）、高频（每周都有新客户需求进来）、产出明确（交付周期和客户满意度都可以量化）。
2.3 最小闭环怎么跑通？——组织 MVP 的四个组件
一个产品的 MVP 需要前端、后端、数据库、部署。一个组织的 MVP 也需要四个组件：
角色（Role）： 不是"岗位"，是"能力包"。钉钉 MVP 小队的做法是把五个"岗位"（销售、解决方案、产品、技术、交付）压缩成三个"能力包"：客户理解（由一个既懂销售又懂产品的人承担）、方案生成（由一个技术 + Coding Agent 组合承担）、质量保障（由一个人 + 测试 Agent 组合承担）。不再按岗位分工，而是按能力组队。
协议（Protocol）： 不是"流程"，是"接口定义"。原来的流程是 SOP——第一步销售填需求单，第二步解决方案写方案，第三步产品评审……每一步都有审批节点。MVP 小队改成协议制：定义每个环节的输入格式（结构化的客户需求描述）、输出格式（可交付的方案文档）、质量标准（客户确认通过），中间怎么做由执行者自主决定。就像钉钉开放平台的 API 设计：定义 request 和 response，不管你用什么语言调用。
上下文（Context）： 不是"文档"，是"共享状态"。原来靠开会同步——每周一次项目会，每天一次站会。MVP 小队用钉钉文档搭了一个"项目状态看板"，每个客户需求的状态、历史决策、关键约束全部实时可见。任何人（包括 Agent）随时可以查询当前上下文，不用等开会才知道"那个客户的需求变了"。
反馈（Feedback）： 不是"绩效考核"，是"信号回路"。原来的反馈周期是季度——等到季度 review 才知道某个流程有问题。MVP 小队在每个任务完成后自动生成效率数据（从需求到交付的总时长、各环节等待时间、返工次数），用钉钉的数据看板实时展示。不是事后复盘，而是实时进化。
┌─────────────────────────────────────────────────────────┐
│ 组织 MVP 的四个组件（OPD 模型 × 钉钉实践） │
├──────────────┬──────────────────────────────────────────┤
│ 角色 Role │ 5 个岗位 → 3 个能力包 │
│ │ 人 + Agent 按能力动态组合 │
├──────────────┼──────────────────────────────────────────┤
│ 协议 Protocol │ SOP 审批链 → API 式接口定义 │
│ │ 定义输入/输出/标准，不定义路径 │
├──────────────┼──────────────────────────────────────────┤
│ 上下文 Context│ 周会同步 → 钉钉文档实时状态看板 │
│ │ 结构化、可查询、人和 Agent 共享 │
├──────────────┼──────────────────────────────────────────┤
│ 反馈 Feedback │ 季度 Review → 每任务自动效率报告 │
│ │ 实时数据、自动识别瓶颈、持续进化 │
└──────────────┴──────────────────────────────────────────┘
三、钉钉的 MVP 实施：六周跑通
说了模型，说路径。钉钉那个 MVP 小队实际怎么干的？
第一周：选场景、建小队。 从"企业客户 AI 解决方案交付"这个场景切入。从销售、解决方案、产品、技术四个部门各抽一个人，组成 4 人小队，配上三个 Agent 工具：一个 Coding Agent（负责方案原型搭建）、一个文档 Agent（负责方案文档生成）、一个数据 Agent（负责客户数据分析）。这个小队直接向产品线负责人汇报，绕开中间管理层。
第二周到第四周：跑通第一个完整闭环。 小队接了三个真实客户需求，用新方式跑：客户理解角色直接和客户对接，用结构化模板记录需求（不再经过销售转述）；方案生成角色和 Coding Agent 协作，48 小时内出方案原型（不再等排期）；质量保障角色做验收。全程在钉钉文档的共享看板上同步状态，零会议。
第一个客户需求，从接到到交付方案用了 4 天——比原来的 14 天缩短了 71%。但过程中暴露了两个问题：协议定义太粗，导致方案生成角色不确定"什么程度算完成"；上下文看板信息太多太杂，反而增加了认知负担。
第五周到第六周：迭代。 把协议细化——给每类需求定义了明确的"完成标准清单"（Definition of Done）。把上下文看板做了分层——顶层只展示状态和阻塞项，详情折叠。第二轮三个客户需求，平均交付时间压缩到 3 天，返工率从第一轮的 30% 降到 10%。
钉钉 MVP 小队的关键指标变化
旧方式 第一轮 MVP 第二轮 MVP
交付周期 14 天 4 天 3 天
等待时间占比 64% 25% 15%
返工率 35% 30% 10%
信息同步方式 周会+日会 共享看板 分层看板
参与人数 8-10人 4人+3 Agent 4人+3 Agent
四、三个常见的坑（以及钉钉踩过的）
在实际操作中，我见过最多的三个失败模式。我们踩了其中两个。
坑一：MVP 太大。 钉钉最初的计划是同时在三个场景（客户交付、内容运营、内部研发）推 MVP。第一周就发现人手不够、注意力分散，果断砍到只保留客户交付一个场景。一个场景、一个小队、一个完整闭环。什么都想验证 = 什么都没验证。
坑二：只换工具不换协作方式。 这是很多团队的通病——给每个人配了 AI 工具，但组织的协作方式一点没变。还是按岗位分工、按流程审批、按会议同步。这不是组织 MVP，这是工具采购。AI 工具在旧的组织方式下只能发挥 20% 的潜力，就像在马车上装了一个发动机但还是让马拉着走。钉钉 MVP 小队之所以有效，是因为他们同时改了四样东西：角色、协议、上下文、反馈——而不仅仅是加了几个 Agent。
坑三：用旧指标衡量新方式。 钉钉一开始差点掉进这个坑。有人提出用"人均产出"来评估 MVP 小队，但这个指标在人 + Agent 协作模式下完全失真——Agent 干的活算谁的？正确的做法是用新指标：端到端交付周期、任务闭环率、等待时间占比、人机协作比。用旧尺子量新东西，要么量不出来，要么量出来的数字误导决策。
五、从 MVP 到组织操作系统
钉钉的 MVP 跑通之后，下一步是什么？
是把 MVP 中沉淀下来的角色定义、协议规范、上下文系统、反馈机制，抽象成一套可复制的"组织操作系统"。在钉钉的语境里，这特别有意思——他们既是这套操作系统的设计者，也是使用者，还是提供者。自己先跑通，然后把经验产品化，赋能给客户。
这个"操作系统"不是一本管理手册，而是一套运行规则：
- 新场景接入时，怎么定义角色和能力包？（钉钉已经沉淀了一套"能力包模板"）
- 人和 Agent 之间的协议怎么写？（类似 API 文档的格式，定义 Input/Output/Quality Gate）
- 共享状态层怎么搭建和维护？（钉钉文档 + 数据看板 + Agent 自动更新）
- 反馈信号怎么采集和响应？（每个任务节点自动埋点，异常自动预警）
当这套规则能让任何一个新场景在两周内跑通闭环，你的组织就完成了从"MVP"到"操作系统"的升级。
组织不是管出来的，是设计出来的。而设计的第一步，不是画蓝图，是做 MVP。 钉钉用六周时间验证了这件事。
你的组织里，还有多少个 14 天，其实 4 天就能交付？