第一部分 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教授（第21条）：The less managers understand their business, the more variables they require to explain it.
Ackoff教授： E=mc2（狭义相对论）仅用一个独立变量m，就解释了科学家所能理解的最复杂现象之一。那么，为何需要35个变量来解释消费者选择零售店（或麦片）的行为呢? 答案是显而易见的：这些现象尚未被真正理解——对事物的理解越少，就需要越多的变量“解释”。 理解能帮助管理者筛选信息，管理者会因为缺乏理解而试图收集所有信息，他们不知哪些信息是相关的，担心遗漏可能的重要信息，因此，相较于缺乏相关信息，他们更容易被大量无关信息干扰。 |
王工（大数据分析资深顾问）：这篇文章的观点从传统意义上来说是对的，而且重点强调的是尽快量化，集中精力于要解决的概念问题，尽快落地，不断改进。但是大模型的观念，特别是无监督学习方法，强调的是数据量——量化，涵盖尽可能多的参数，基于统计概率解决问题。这个也值得对照考虑。 我：在物理、化学、生物等科学领域，大模型数据分析与预测有很多成功案例。但偏管理的案例很少。为什么？ 软件开发顾问Gerald M. Weinberg说：如果给管理层的方案需要使用高数，那么你应再考虑一下。 虽然有点夸张，但他是有道理的。如果用回归模型预测，管理层还是能理解的，但他肯定难以理解神经网络或随机森林（虽然这些模型的预测更精准）。所以我更赞同Weinberg先生的建议，先从简单入手，才有机会得到管理层的认可。 |
某软件开发公司计划推行量化管理，欲以数据驱动提升生产率。 公司的度量分析师向我展示了一张包含五六十个项目变量的表格，涵盖缺陷、进度、工作量等。 我：为何要收集这么多变量？改进目标是什么？ 分析师：我们希望提高生产率，减少进度偏差，并降低最终的客户缺陷密度。 我：大量缺陷到系统测试或验收时才被发现，从而导致大量返工。若能尽早发现缺陷，如加强前期评审效率，减少遗漏到后期的缺陷，就能降低返工，提升效率。若团队认可这一点，就应该聚焦相关变量。如果对进度、工作量等偏差都要收集数据，那么每轮都会涉及几十个变量，这样反而缺乏针对性。比如，你们有哪些不同的评审方式？效果有何差异？ 分析师：我们与开发团队讨论过，确实有区别。比如，前期做过正式评审的项目，质量通常会更好一些；若无评审，则后期发现的缺陷明显增多。明确按活动或实体编写需求的项目，与未明确需求的项目也有区别。一些项目规定需通过静态代码扫描，这样后期的缺陷数也会少一些。 所以，如果能估算出各种方式的缺陷引入率和排除率，就可以用模型预测最终遗漏的缺陷数，还能利用蒙特卡罗预测工具比较不同方法的组合效果，制定缺陷的目标范围。团队可以首先参考上一轮迭代数据，估算预测模型的参数，并集体头脑风暴，探讨改进的新方法。随后，利用蒙特卡罗预测模型比较不同组合，分析其对缺陷率、缺陷排除率和工作量的影响。团队可参考模型建议，选择下一迭代的最佳方案。 例如，某团队通过静态代码扫描预先发现代码的缺陷，就可以实验比较代码扫描前后系统测试缺陷数变化及缺陷排除率等。 初期数据可能不足，但随着多轮迭代数据越来越多，可形成团队基线，以此作为团队标杆。因此，初期不必过分追求精确，而是应该尽快量化。 如果团队能尽早发现并修复缺陷，后期的返工量就可以大幅减少，生产率自然提升，延误减少，进度偏差也会改善。 |
许多人误以为度量分析必须像大数据分析那样，依赖海量数据，用很多因子得出预测模型方程式。事实恰恰相反，变量越多，量化改进越难成功，开发人员也就越抵触。我们应针对需要改进的指标重点收集对应的数据。所以我建议迭代团队先聚焦缺陷与返工工作量，以降低返工的工作量为目标，每轮迭代回顾时分析数据，逐步推进量化管理。