帮你评估并降低「这个人走了项目就停」的组织风险。
文中核心拆解是：FDE 角色天然自带关键人风险——一个人同时握有客户上下文、系统知识与决策权，这在客户交付语境里后果比内部研发更直接，丢的是合同而不只是代码。最容易出现误用的地方是把缓解等同于「写文档」：没有随项目演进持续更新的活文档等于没写，甚至给人已交接的错觉。
相比把关键人风险归因于个人忠诚度的普遍思路，这篇主张结构性对策：关键客户双人在场、决策记录制度化、上下文文档化、定期轮岗，并用一个简单测试检验效果——这个人明天消失，项目能自己跑几天。它测的是组织冗余度，不是个人能力。
建议你为最重要的客户项目做一次「消失测试」，把薄弱环节列成清单，并每季度复测一次。
—— FDEChina编辑部 · 实战派
定义
Key-man risk（关键人风险）指项目或客户关系过度依赖某一位核心成员，其离职或不可用会直接威胁交付连续性与客户续约的组织风险。
展开
FDE 角色天然自带这一风险：一个人同时握有客户上下文、系统知识与大量隐含决策，客户信任也常绑定在具体的人身上。与内部研发不同，交付语境下的关键人风险后果更直接——丢的不只是代码与进度，而可能是整份合同与续约机会。关键人风险应当写进项目风险登记册。
常见误用是把缓解等同于「写文档」：没有随项目演进持续更新的活文档等于没写，甚至制造出已交接的错觉。有效的对策是结构性的：关键客户双人在场、决策记录制度化、定期轮岗，并用一个简单测试检验——这个人明天消失，项目能自己跑几天。天数越短，说明组织对个人的负债越高，越需要优先处理。轮岗不是惩罚，而是标准的风险管理动作。