匈牙利医生汉斯·赛尔有个实验给小白鼠注射一种无毒药剂结果小白鼠大量死亡。后来查清楚了杀死它们的不是药剂而是注射过程带来的极度紧张。免疫力崩了病就来了。做过芯片项目的人都知道流片窗口一旦定下来整个团队的状态会变得很奇怪。功能还是那些功能时序还是那些路径。但出错的概率会莫名其妙地上升。一个真实场景流片前两周工程师在做最后的sign-off检查。时序报告里有一条路径Path 1: MET Startpoint: u_mac/data_reg[7] (rising edge-triggered flip-flop) Endpoint: u_acc/sum_reg[7] (rising edge-triggered flip-flop) slack (MET) : 0.03nsslack是正的技术上没问题。但0.03ns这个数字正常情况下会被标记出来复查。结果那次没人提。因为大家都在赶觉得MET就是MET过了就行。后来那颗芯片回来在某个corner下时序违例功能异常。这件事的根源不是技术判断错了是压力改变了人的决策阈值。平时0.05ns以下的slack都会重新评估那两周直接跳过了。芯片项目的压力来源通常有两类一类是客观的工期紧、需求改了、工具跑出问题另一类是人为制造的比如不断拉会同步进度、每天要汇报百分比、管理层在群里频繁人。后者才是真正危险的。前者会增加工作量但人在清醒状态下还是能处理的。后者会持续消耗注意力让工程师的认知资源被占满然后在最关键的检查节点上出现判断失误。真正稳的团队会把关键的技术检查节点单独保护起来不允许被进度压力打断。sign-off review就是sign-off review不在那个会上讨论排期不在那个会上问别的事。保护技术判断的环境和保证技术判断的质量是同一件事。汉斯·赛尔后来把这个现象叫做”应激反应”。他发现让生物体垮掉的往往不是外部的威胁本身而是对威胁持续反应所消耗的资源。下次项目出了问题不妨先问一句最后那段时间团队的状态是什么样的。技术问题往往只是结果不是原因。