管理者对业务了解得越少，越需要更多的变量来解释

(狭义相对论）仅用一个独立变量m，就解释了科学家所能理解的最复杂现象之一。那么，为何需要三十五个变量来解释消费者选择零售店（或麦片）的行为呢?

答案是显而易见的：这些现象尚未被真正理解——对事物的理解越少，就需越多的变量“解释”。

理解能帮助管理者筛选信息，管理者会因为缺乏理解而试图收集所有信息，他们不知哪些信息是相关的，担心遗漏可能的重要信息，因此，相较于缺乏相关信息，他们更容易被大量无关信息干扰。

这篇文章观点传统意义上是对的，而且重点强调的是尽快量化，集中精力于要解决的概念问题，尽快落地，不断改进。但是大模型的观念，特别是无监督学习方法，强调的是数据量--量化，涵盖尽可能多的参数，基于统计概率解决问题。这个也值得对照考虑。

我：
在物理、化学、生物科学领域，大模型数据分析与预测有很多成功预测案例。但偏于管理的实例很少。为什么？软件开发顾问 Gerald M. Weinberg 说：“如果给管理层的方案需要使用高数，你应再考虑。”虽然有点夸张，但他是有道理的。如果用回归模型预测，管理层还是能理解，但他肯定难以理解神经网络或随机深林（虽然这些模型的预测更精准）。所以我更赞同Weinberg先生的建议，先简单入手，才有机会得到管理层的认可。

公司的度量分析师向我展示了一张包含五六十个项目变量的大表，涵盖缺陷、进度、工作量等。
我问：“为何要收集这么多变量？改进目标是什么？”
分析师答：“我们希望提高生产率，减少进度偏差，并降低最终的客户缺陷密度。”
我问: “大量缺陷到系统测试或验收时才被发现，导致大量返工。若能尽早发现缺陷，如加强前期评审效率，减少遗漏到后期的缺陷，就能降低返工，提升效率。若团队认可这点，就应该聚焦相关变量。如果对进度、工作量等偏差都要收集数据，则每轮都会涉及几十个变量，这样反而缺乏针对性。比如，你们有哪些不同评审方式？效果有何差异？”
分析师回应：“我们与开发团队讨论过，确实有区别。比如，前期做过正式评审的项目，质量通常更好一些；若无评审，后期发现的缺陷明显增多。明确按活动或实体编写需求的项目，比未明确需求的项目也有区别。一些项目规定需通过静态代码扫描，后期的缺陷数也会比较少。”

所以如果能估算出各种方式的缺陷引入率和排除率，就可用模型预测最终遗漏的缺陷数。还能利用蒙特卡洛预测工具，比较不同方法的组合效果，制定缺陷的目标范围。团队可以首先参考上一轮迭代数据，估算预测模型的参数，并集体头脑风暴，探讨改进的新方法。随后，利用蒙特卡洛预测模型比较不同组合，分析其对缺陷率、缺陷排除率和工作量的影响。团队可参考模型建议，最终选择下一迭代的最佳方案。
例如，某团队通过静态代码扫描预先发现代码的缺陷，就可实验比较代码扫描前后系统测试缺陷数变化及缺陷排除率等。
初期数据可能不足，但随着多轮迭代数据越来越多，可形成团队基线，所为团队标杆。因此，初期不必过分追求精确，而是应该尽快量化。

如果团队能尽早发现并修复缺陷，后期的返工量就可大幅减少，生产率自然提升，延误减少，进度偏差也会改善。