第一部分 f-laws 定律
A1 最佳学习方法 A2 PPT 投影 A3 改进个别部分不能改进总体 A4 把成功经验归零 A5 知识分显性和隐性 A6 服从度与创新 A7 应对未来变化，假设比预测好 A8 引导学生自己找答案 A9 如不能容错，大家都尽力少做 A10 难教老人新把戏 A11 乐队指挥更懂管理 A12 行政 / 管理 / 领导 A13 问消费者想要什么没有意义 A14 扁平化管理 A15 智慧= 16x理解 A16 计算机不会比程序员聪明 A17 管理者只追求可衡量的东西 A18 要收集多少变量 A19 对被收购公司的增值比给收购公司的增值重要得多 A20 从外面评价公司比内部更容易 A21 幸福的大家族更需要的是忠诚，而伟大企业更需要的是能力 A22 无论企业多成功，如果不能适应变化，就会像恐龙一样灭绝 A23 下属与经理（上） A24 下属与经理 （下） A25 好奇心 A26 对下属期望越低，得到的就会越少 A27 高层认为他人是非理性的，但其实自己也一样 A28 官僚只有权利说“不可以” A29 是否听取建议取决于与提出者的关系 A30 职位越高越觉得不需要继续学习 A31 专注于组织的“核心竞争力” A32 能用现有的资源做些什么 A33 领袖的必要条件是才华 A34 要跳出盒子思考 A35 已经到了不可能变得更糟的情况 A36 电话会议 A37 电话第二部分 应用场景
B1 敏捷开发如何改善 B2 与高层交流 B3 现场培训 B4 从A3报告到量化持续改进难以依赖改进一个或多个部分来改进整个组织总体。
Ackoff教授（第3条）：You rarely improve an organization as a whole by improving the performance of one or more of its parts.
Ackoff教授： 组织是一个系统，其整体性能更多地取决于各部分之间的相互关联，而非单独看每个部分的表现。 就像我们可以识别每款汽车中最优的组件，比如甲车的发动机、乙车的轮胎等。但如果我们把这些“最佳组件”拆下来重新组装，并不能造出一辆性能最好的汽车，因为这些部件之间可能无法连接，更不用说性能表现了，所以连组装出一辆完整的汽车都很困难。 同理，仅仅改进公司的某一部分，并不等同于整个组织的改进。某些情况下，过度优化局部甚至可能导致企业的失败。因此，在评估某个部分的表现时，首先应考虑其对整体系统的影响，局部优化是次要的。 某些情况下，适度降低某个局部的性能，反而有助于公司整体表现的提升。 例如，提高库存可能会减少缺货现象，从而完成原本可能因断货而丢失的订单。这些新增订单所带来的利润，可能足以覆盖增加库存所带来的额外成本。 又如，将某些产品以低于成本的价格售出，可能会带动其他高利润产品的销售，从而提升整体盈利的能力。 |
系统思维 ● 系统由多个组件构成，每个组件都能影响整体 ● 因相互依赖，单一组件无法独立决定总体性能 ● 若将系统划分为多个子系统，则各子系统都会影响整体，但并非独立 总之，系统整体不可分割为相互独立的单元，因各部分相互依赖，分割后将丧失其在系统中的功能与特性。 以人体为例，各器官相互影响，优化某一器官的指标未必能改善整体健康，甚至可能因某一器官的异常而损害其他器官，导致整体健康状况恶化。 |
但有些管理者缺乏系统思维，误以为只要改善某些局部功能，就能带动公司整体的提升。
许多组织按照专业职能设置指标或KPI，甚至将其与奖金挂钩。例如：
● 需求的按时交付率
● 设计编码的效率或缺陷数量
结果导致各岗位只关注自身的指标，项目团队内部不同岗位之间缺乏沟通与协作：
● 开发常常抱怨需求编写太简单，未充分考虑各种场景，影响了后续的设计与编码
● 测试抱怨开发未对代码的质量把关，没有进行充分的内部评审、静态扫描和自测，进而导致提交给测试的版本漏洞百出。测试阶段发现大量缺陷，引发严重返工
虽然每个岗位看似都完成了自己的指标，但团队成员之间相互抱怨，最终交付给客户的产品质量依然不好。
然而，如果团队各岗位能够齐心协力，集中办公，不拘泥于各自的单项指标，每轮迭代回顾时：
● 所有成员一起分析本轮出现的缺陷和返工工作量，探讨背后的根本原因，共同制定改进措施，并在下一轮迭代中加以验证。
绝大多数团队都能在几轮持续改进后，显著减少系统测试与客户验收阶段的缺陷数量，降低返工工作量，进而提升整体生产率。
大家看到质量的明显改善，团队的士气也会随之提升。