指南

基于 Lean Software Development（Poppendieck 7 原则，en.wikipedia.org/wiki/Lean_software_development）与 OKR 定义（whatmatters.com）编写

速查

• 消除浪费：用价值流映射识别不增客户价值的环节，迭代移除
• 放大学习：短迭代 + 反馈环替代详尽前期计划，用代码与原型学习
• 尽晚决定：set-based 开发保留多方案，用可逆决策延迟承诺
• 尽快交付：JIT 拉动 + 小批量，反馈越快纠偏成本越低
• 团队授权：决策下放给离信息最近的人，去掉微观管理
• 内建完整性：感知完整性（用户体验连贯）+ 概念完整性（组件协作）
• 全局优化：看整体价值流，警惕局部最优拖累全局
• OKR 结构：3-5 个 O，每 O 配 3-5 个可量化 KR
• KR 必须是 outcome：衡量结果而非任务，可量化可验证有时限
• OKR 对齐：自上而下（公司→团队→个人）+ 自下而上（个人提案）结合
• OKR 评分 0.7 即成功：鼓励拉伸目标，挂钩绩效会摧毁机制
• 核心共识：Lean 给工程哲学，OKR 给目标机制，二者都强调全局价值导向

Lean 7 原则深度

原则一：消除浪费（Eliminate Waste）

一切不增客户价值的活动都是浪费。识别方法：价值流映射（Value Stream Mapping）——画出从需求到交付的每一步，标注每步的时间与等待，找出不增价值的环节。软件中的典型浪费：

浪费	表现	对策
部分完成的工作	未合并的分支、未测试的功能	小批量、限制 WIP
额外功能	用户不用的功能	YAGNI、按价值排序
任务切换	多项目并行	单线程、WIP 限制
等待	等审批、等依赖	自动化、消除瓶颈
交接	hand-off 丢知识	跨职能团队、结对
缺陷	bug 返工	质量内建、自动化测试
额外流程	冗余审批文档	精简流程

原则二：放大学习（Amplify Learning）

软件开发本质是不确定的持续学习。与其用详尽的前期计划（注定失准），不如用短反馈环学习：写代码、做原型、给用户看、迭代。技术如：迭代开发、原型、A/B 测试、可执行的 spike。学习是减少不确定性的手段，不是「浪费时间」。

原则三：尽晚决定（Decide as Late as Possible）

关键决策应延迟到基于事实而非假设时做出。手段：

Set-based 开发：同时保留多种可选方案，随信息明朗逐步淘汰，
              而非前期锁定单一方案。
可逆决策 vs 不可逆决策：可逆的早做无妨，不可逆的尽量晚做。

注意：「尽晚」不是「拖延」——它要求保留可选性的工程能力（可扩展架构、模块化），否则晚决定会变成无法决定。

原则四：尽快交付（Deliver as Fast as Possible）

尽快交付让反馈环最短、纠偏成本最低。手段：JIT 拉动（Kanban）、小批量、短迭代、自动化部署（DevOps）。关键洞察：快与质量不矛盾——慢往往源于大批量、长等待、返工，消除这些反而更快。

原则五：团队授权（Empower the Team）

把决策权下放给离信息最近的人，而非上层远离一线的管理者。管理者应：倾听开发者、提供支持、清除障碍、给自主权，而非微观管理。这与敏捷的「自组织」、Scrum 的「self-managing」一脉相承。

原则六：内建完整性（Build Integrity In）

完整的产品有两种完整性：

完整性	含义
感知完整性 Perceived	用户感受到的整体连贯体验
概念完整性 Conceptual	组件协作良好、内部一致

完整性要内建（持续重构、自动化测试、面对面沟通），而非靠末期测试修补。「自动化测试不是目的，而是减少缺陷的手段」。

原则七：全局优化（See the Whole / Optimize the Whole）

软件系统是交互的产物，非部分的简单加总。局部优化某环节（如开发提效）却忽视整体（集成、发布瓶颈）会拖累全局。要找根因而非症状，维护跨环节的共赢关系。只有 7 原则一起实施，才有成功基础。

OKR 写作规范

Objective 写作

好的 O：
  - 定性、鼓舞人心、行动导向
  - 简短易记，传达方向
  - 有挑战性（拉伸）

差的 O：
  - 「提升产品」（模糊）
  - 「完成 10 个功能」（任务清单）
  - 「维持现状」（无改变）

Key Results 写作

好的 KR：
  - 可量化（有数字）
  - 可验证（有明确达成标准）
  - 有时限（季度内）
  - 衡量 outcome（结果）而非 output（产出）

差的 KR：
  - 「优化登录页」（任务，非结果）
  - 「提升用户满意度」（不可量化）
  - 「开发新模块」（产出，非业务结果）

OKR 数量

• 组织/团队：每季度 3-5 个 O，每 O 配 3-5 个 KR
• 超出此数会稀释聚焦——OKR 的力量来自「少即是多」

OKR 对齐机制

公司 OKR（年度/季度）
   │ 自上而下传递方向
   ▼
团队 OKR（季度，承接公司 + 团队自身）
   │ 自下而上提案 + 协商
   ▼
个人 OKR（季度，承接团队 + 个人成长）

好的对齐是双向的：上级给方向，下级提案具体目标，协商确定。不是单纯的「上级下达」。

OKR 评分与复盘

评分

• 用 0.0-1.0 评分每个 KR
• 0.7 视为成功——鼓励拉伸目标
• 若总是 1.0，说明目标不够有挑战

周期

季度初：设定 OKR（自下而上提案 + 对齐）
季度中：周/双周 Check-in（跟踪进展、移除障碍）
季度末：评分 + 复盘（学到了什么、下季调整）

OKR 不挂钩绩效的深层原因

whatmatters.com 明确 OKR「divorced from compensation」。挂钩奖金会导致：

后果	表现
保守设定	怕完不成影响收入，目标定得低
隐藏困难	不愿暴露风险，透明度丧失
博弈指标	为达成数字做短视行为
雄心丧失	OKR 鼓励拉伸的目标机制被摧毁

OKR 的目的是对齐与聚焦，绩效评估应基于更综合的判断（贡献、协作、成长），而非 OKR 完成度。

Lean 与 OKR 的关系

维度	Lean	OKR
关注	工作如何流动与交付	组织往哪里走
提供	工程哲学（消除浪费、尽快交付）	目标机制（聚焦、对齐）
共通	都强调全局优化、以价值为导向	同左

二者互补：Lean 让团队的「怎么干」高效，OKR 让组织「干什么」聚焦。成熟组织常并用。

反模式清单

Lean 反模式	OKR 反模式
把原则当口号不落地	KR 写成任务清单（output 非 outcome）
局部优化忽视全局	季度末赶分、平时不跟踪
尽晚决定变拖延	与绩效/奖金挂钩
无工程支撑的快交付	目标过多稀释聚焦