从七十四天到物理极限：Jensen Huang的“光速”思维如何改变工程
引言：为什么在理解时间表之前，就要改善它？
一个团队说，一道流程需要七十四天，并提出将其缩短到七十二天。这个建议听起来像是进步。但如果换一种安排，实际工作六天就能完成呢？
这些数字是对方法的说明，而不是对某个具体项目的承诺。Jensen Huang用“光速”思维来描述一种做法：在把现有流程接受为起点之前，先寻找根本极限。
重要的问题不是如何让同一批人更加努力，而是如何区分必要工作与沿袭下来的延误。
1. 现有流程是证据，而不是自然法则
既定时间表里可能包含许多不同内容：实际工作、等待、审批、交接、批量处理，以及因如今已不适用的原因而作出的妥协。
渐进改进 [Continuous Improvement] 从既有安排出发，询问怎样让流程好一点。
第一性原理推理 [First-principles Reasoning] 则提出更早的问题：究竟必须发生什么？什么阻碍了它以不同方式发生？
这并不使经验失去价值。有经验的人往往清楚知道，某个困难步骤为什么存在。重点是找回那些理由，而不是把时间表本身当作解释。
2. 为每个重要维度寻找极限
“光速”是对相关约束下可能性极限的简称，并不意味着每项商业活动都在字面上受到光传播速度的限制。
在计算中，维度可以包括内存数据移动、能耗、响应时间 [Latency]、处理速率 [Throughput]、成本和制造时间。设计可能在一个维度接近极限，在另一个维度却仍有很大空间。
把这些维度分开很有用。快速给出一个答案的系统，与为高效处理大量请求而设计的系统，可能不同。优化一个，并不会自动优化另一个。
在把一切合成最终设计之前，团队应该理解每个目标提出什么要求。
3. 建立理想基线，再解释差距
六天的例子，只有在审视剩下六十八天时才有价值。
其中一些差距可能合理。较慢的流程可能成本更低、更公平地使用稀缺设备，或提供必要检查。其他延误则可能源自重复决策，或近期无人质疑过的顺序。
这种练习让选择变得可见。团队不必只争论能否省下两天，而可以讨论为什么接受与根本基线之间大得多的差距。
因此，物理最小值是判断的参照点，并不会自动成为正确的商业截止日期。
4. 简单意味着去除不必要的复杂性
复杂精密的计算系统可以有很多相互作用的部分，同时仍有简单的目的。复杂性存在却不服务于目的时，才成为问题。
Huang的方法是询问一个部件、步骤或依赖关系是否必要。必要，就理解它；不必要，就问它为什么仍然存在。
这与把系统削减到无法完成任务不同。供电、冷却、测试和可靠性，不会因为使图变复杂就成为可选项。
有用的目标是：设计包含满足要求所需的复杂性，但不包含仅为保留习惯而增加的复杂性。
5. 领导者需要理解行动发生的现场
项目报告可能描述延误，却隐藏原因。在工作发生的地方，解释可能清楚得多。
一根电缆怎样安装？一个部件为什么等待？哪项决定阻碍下一项任务？这些问题把宏观系统与产生它的细小行动连接起来。
紧迫感在移除真实障碍时才有用。不理解工作，只反复提出更激进的期限，不会产生工程进步。
领导者应该帮助揭示约束、集合合适的专业知识，并决定哪些取舍 [Trade-offs] 可以接受。
结语：庆祝改进之前，先质疑基线
“光速”思维的力量，是持续追问为什么的纪律。为什么是这个顺序？为什么要等待这么久？为什么采用这个设计？哪些极限来自物理规律，哪些来自选择？
这些答案明确后，渐进改进就有了更好的基础。团队可以改进自己理解的流程，而不是只打磨继承下来的流程。
这种方法不承诺每个七十四天的项目都会变成六天。它要求团队知道为什么不能。这样的知识会改变其后每个决策的质量。
Powered By K7