MADE · 第 1 步 · MAP
绘制您的
组织地图。
一套简单的语言和一张地图,看清组织真正如何运作,无需“敏捷”或框架的行话。不知道自己在哪里,就无法弄清下一步去哪里。
地图
两项授权,一张地图
每个单元,无论是一个人、一个团队还是一个 AI agent(AI 智能体),都按它被赋予的两项授权来定位,而不是按头衔。始终围绕一个业务成果来绘制:授权只有相对于某人必须交付的成果,才谈得上宽或窄、完整或不完整。
工作由智能主体完成,即组织单元:个人、群体和 AI。同一张Mandate(授权)地图适用于所有这些主体,无论是人、智能体还是机器人。按它被允许学习和从事的内容来定位,而不是按头衔。
从一个成果出发
先说出业务成果,可以是一个产品、一个客户问题或一条价值流,以及谁要为它工作。然后对照它来判断每个单元的授权:一个团队对某个成果可以是完整的,对另一个成果则可能不完整。
技能授权范围
单元被赋予并被允许运用的技能。越靠右,越能在没有依赖的情况下快速交付。分界线左侧的单元是不完整的,需要他人配合才能交付客户价值;右侧则是完整的。
工作授权范围
单元拥有多少工作:从任务和能力(outputs)到部分解决方案和整体解决方案(outcomes)。更多的 output 并不意味着更多的 outcome。
四个象限
两条分界线把地图切成四个象限:Directing、Driving、Doing 和 Delivering,即四种智能。
四种智能,由授权塑造
一个组织能感知、决定和做到什么,并不存在于它的人员或工具中,而是源自赋予每个单元的授权。狭窄的授权限制智能;宽广而连贯的授权拓展智能。地图上的位置描述的是组织的能力,而不是人的价值。
DIRECTING
协调智能
以集中控制俯瞰整个解决方案空间。缺乏直接创造价值的技能,而是通过计划和控制来协调他人的工作,从中增值。
示例 · 撰写需求的业务分析师。
借助 AI · 有造成控制幻觉的风险,除非它能让领导者更贴近真实的工作。
DRIVING
适应智能
专注于对成果负责,并决定接下来构建什么。把探索与交付结合起来,用真实的客户信号同时完善问题和方案。
示例 · 一家三人创业公司,或一个团队的团队。
借助 AI · 一个倍增器,能减轻在新领域中的认知负荷。
DOING
专业化智能
在狭窄领域中技能精湛。在明确界定的边界内追求精确、质量和效率。作为深度专家,专注于既定任务而非成果。
示例 · 一丝不苟照着菜谱出菜的厨师。
借助 AI · 能自动化任务,但更快的任务只会加快局部产出。
DELIVERING
流动智能
在界定的工作领域内独立创造价值。掌握完整的 Definition of Done,在既定边界内快速交付成果。
示例 · 电商搜索团队。
借助 AI · 作为老师,降低了学习更大系统的成本。
摘自本书 · 10X ORG,原则 3:用授权塑造智能
正如人可以“语言聪明”“逻辑聪明”“音乐聪明”等等,组织也通过赋予组织单元的结构化授权,表现出不同的聪明之处,即智能。
Organizational intelligence(组织智能)不是固定不变的特质,也不存在于个人身上。这些品质来自系统本身,具体来说,来自界定谁被允许决策、行动、学习和塑造成果的授权。授权狭窄时,智能受到限制。授权宽广而连贯时,智能得以扩展。
问题不再是哪种智能“更好”,而是哪种组合最能支持当前的战略挑战,以及这种组合如何随战略变化而演进。……组织不会被锁定在单一智能上;它们可以有意识地发展被忽视的智能,并将它们组合起来支持绩效。
详细地图 · 4×4
十六个原型,一种语言
2×2 展示四种智能。要对组织单元做详细的地图绘制,有 4x4 map(4×4 地图)版本:每条轴四个层级,共 16 个原型,即单元如何构成和运作的常见模式,每个都有一个简短的名称。
名称如何构成
前缀表示工作授权所在的行(TASKS、CAPS、PART、WHOLE);数字表示技能授权所在的列,从左数起。因此 CAPS-3 读作“端到端 @ 能力”:一个完整单元,面向产出,属于 Delivering 一组。
技能授权范围 →
- 职能型:某一职能领域的专家,例如电影的服装部门。
- 多技能:跨职能但仍不完整,例如依赖术后护理的外科团队。
- 端到端:具备交付完整价值所需的一切,例如软件特性团队。
- 拓展型:端到端,并有权在需要时获取新技能,例如特种部队小队。
工作授权范围 ↑
- 任务:与某一项专长匹配的细粒度任务,例如备料的副厨师长。
- 能力:一整项能力(特性、职能、服务环节),例如理赔处理小组。
- 部分解决方案:一个业务垂直领域,例如 Uber Ride 与 Uber Eats。
- 整体解决方案:整体性的问题和客户价值,单元内部没有永久的分隔,例如类似 Instagram 的两人创业公司。
生态系统地图
地图的好处
一套简单的记法和几句话,就能描述整个生态系统,让人从整体上把握它、认清它的挑战,并展开如何改进的对话。不是逐个团队地做:团队层面的改进很少能持久。生态系统中的各个单元相互依赖,所以必须作为一个系统一起改进。
地图语言
生态系统 1 · 现状
大多数团队是 CAPS-2:多技能,但不完整,缺少某些能力。职能型的 TASKS-1 专家为它们提供支持。这就产生了依赖,由 CAPS-1 和 PART-1 小组来管理。
生态系统 2 · 改进后
专家加入团队,于是大多数团队成为 CAPS-3:端到端,具备交付一整项能力所需的全部技能。有一个团队成长为 CAPS-4,在工作需要时学习新技能。依赖大幅减少,不再需要 CAPS-1 协调小组;仍由一个 PART-1 小组设定方向。合在一起,就是 Delivery Topology。
2×2 还是 4×4?
先从 2×2 讲起。只有当特定的Archetype(原型)名称确实能让观点更清晰,或有人问起时,再使用它。
如何绘制 · GO SEE
带着地图 Go See
拓扑从来不是坐在办公桌前评估出来的。绘制地图与 Gemba,也就是工作真正发生的地方,会彼此促进。不评判、带着好奇心、一起绘制。
STEP GOAL · FROM 10X ORG
我们组织的哪些部分在为创造价值作贡献,它们如何互动来产生价值,从想法到现金?
CORE VALUE · 好奇心
成果
我们在绘制哪个业务成果,谁要为它工作?
工作的类型
为了这个成果,这个单元承担什么?
它的输入
它依赖什么,来自哪里?
它的输出
它产出什么,为谁而做?
流动
工作如何流动,从想法到现金?
Go See 为地图提供素材
您无法凭组织架构图来定位一个单元。观察工作:什么进来、什么出去、谁在等谁,然后画下来,而不是画头衔和层级。
地图指引行走
地图画好后,它会显示接下来该看哪里:密集的依赖线、不完整单元之间的交接、与所需拓扑之间的差距。
共享的工件
地图可以一起评审、质疑和改进,让领导者和一线工作者共同拥有最重要的发现。
摘自本书 · 10X ORG,“带着地图 GO SEE”
这样的地图并不取代走访 Gemba:绘制地图与 Go See 相辅相成。……一旦绘制完成,价值创造的地形就呈现为一个活的结构,而不是定格在某一时刻的静态组织架构图,并准确地标出最需要改进的地方。
绘制示例
2021 年,Alexey Krivitsky 帮助总部在乌克兰的 SaaS 公司 Poster 重新思考其组织设计。公司把研发部门从 12 个狭窄的、面向组件的专家团队,重塑为 6 个多面手的整体产品团队。
之前:Doing
组件团队配有团队级管理者,各有各的工作清单,靠依赖关系串联在一起。
之后:Driving
一个Team-of-teams(团队的团队)共用一个产品 Backlog,周围是产品负责人、产品经理和工程经理。
完成意味着被采用
团队对功能的采用负责:只有当选定的客户积极使用,功能才算完成。
设计上的韧性
当 COVID-19 以及后来的全面入侵来袭时,Poster 无需在压力下重新设计。
来自社区
真实的组织,由与之合作的人绘制。每张地图都附有读懂它所需的背景,以及完整案例的链接。
DIM.RIA:在战时适应
Resource topology: Head of Product, PMs and team leads in Directing; analytics, design and eight web, Android, iOS and QA teams in Doing; work flows down from the PMs. DIM.RIA 是乌克兰领先的房地产平台之一。2022 年全面入侵冲击市场时,它完全远程地围绕 LeSS 原则重新设计了结构。地图显示了它的起点:一个 Resource Topology(Directing + Doing),产品经理把工作下发给许多小团队。案例讲述了它如何朝适应型组织迈进。
Flo Health:从领域孤岛到战略性负责制
A General manager joins the product manager, analyst, designer and UX researcher in Whole-1 (dotted ring); the same value creation, value capture, platform and support teams sit in Part-3, Caps-3 and Tasks-3. Flo Health 是欧洲第一家女性健康科技独角兽,拥有 20 多个覆盖移动端、AI、内容、医疗和商业的Cross-functional(跨职能)产品团队。Flo 没有解散领域团队,而是叠加了一层 General Manager,使每项举措都有一位负责人,同时领域团队保留自己的专长。
Eurecat FPED:研究单位中的敏捷
4x4 map with both states (AK 2026-10-05): initial state in black (four people in PART-1, four pools of people in CAPS-2); current state in blue (one person in WHOLE-1, four teams in PART-3, one pool of people in TASKS-1). FPED 是加泰罗尼亚技术中心 Eurecat 的一个研究单位,开发塑料和复合材料的新制造工艺。研发线负责人从管理每个细节,转向类似 Product Owner 的角色,并向团队授权更多。地图显示了两种状态:初始状态为黑色,当前状态为蓝色。
Paradigm:让业务与 IT 走到一起
Business owner hands to the central solution team in Part-2, which feeds a circled partial-solution team around the Part-3 / Caps-3 boundary; PO? and Ops? sticky notes mark open questions. 欧洲最大的技术公司之一,其规划领域的一列 Agile Release Train,各列火车围绕业务能力组织。新一代规划解决方案 Paradigm 成为重新设计的契机。地图显示了最优设计:处于 PART-3 的Team-of-teams(团队的团队)。
一切始于一顿晚餐
Future state: Stacy in Part-1 hands work to a single team of teams in Part-3, which feeds the implementation unit in Tasks-2. 一家政府机构的产品经理领导三位产品负责人和四个团队。纸面上他们是敏捷的;实际上每个人都在做自己的 Backlog,一个团队受阻时,其他团队只能旁观。地图显示了未来的设计:团队对齐整个产品领域,端到端地构建、验证和运行产品。
de Volksbank:开发团队与运营并肩
4×4 map of de Volksbank in 2023: four dev teams at CAPS-2 (customer onboarding, new business lending ×2, maintenance) still paired with operations at TASKS-1, the bloxx team at CAPS-3, the vendor team at CAPS-1 and ten IT dev teams at TASKS-1. de Volksbank 的企业银行业务,从开发人员做任务,转向与所服务的运营团队结对的特性团队。到 2023 年,四个开发团队大多处于 CAPS-2,即围绕客户旅程工作的不完整团队,其中一个达到 CAPS-3,端到端工作。地图显示了这一现实,供应商和 IT 仍然围绕在团队周围。
框架地图
绘制您的框架?
ACADEMY
学习 Org Topologies 方法
所有即将举行的活动





