2.5 我怎样给断点取一个能行动的名字

“销售和交付协作不好”听起来像结论，却不知道该改变什么。我把十笔订单摊开后，开始给每个具体断点取名字。

我常见到五种现象

等待是事情停在那里没人继续；返工是前面没说清，后面重新做；丢失是重要事实在交接时消失；越权是没有相应责任的人作了决定；无人负责是异常出现后大家都能看见，却没人必须处理。

同一个订单可能同时出现几种现象。我会找到第一次出现的位置，不把最后暴露问题的人当作根因。

项目负责人原先说销售交接质量差，销售则认为项目团队要求太多。我选了五笔顺利订单和五笔延期订单，按签约前后排在一起。

结果不是所有交接都差，而是非标准订单在方案阶段没有明确谁确认工作量。销售以为售前已经确认，售前认为项目经理会在签约后评估，项目经理最后发现人力不足，只能退回。

这件事同时包含丢失和无人负责，但第一次断开的位置是方案进入合同之前。给它取名“非标准工作量在承诺前无人确认”，比“加强销售与交付协作”更能指导行动。

我通常写清发生在哪个事件、什么事实或动作没有成立、由谁受到影响、造成什么经营后果。例如：“折扣申请提交后两天没有处理人，导致三笔报价错过客户采购窗口。”

名称中不急着写原因，因为“负责人不重视”“系统不好用”仍需验证。先把可观察现象说完整，再去查规则、资料、权限和工作量。

如果一句话只能用岗位评价来表达，说明样本还不够具体。

我不写“销售不专业”，而写“十笔非标准订单中有七笔在签约后才由项目经理确认工作量”。不写“审批太官僚”，而写“折扣审批平均等待四天，其中两天没有明确处理人”。

这样的描述能被验证，也能让负责人讨论规则和责任，而不是为岗位声誉辩护。

一次复盘中，我曾写“销售经常遗漏客户条件”。销售团队立刻进入防御。改成“十笔非标准订单中，六笔客户条件只存在于会议记录，未进入合同交接”后，大家开始讨论条件应该在哪一步被确认，而不是争论谁更专业。

我也会记录反例。四笔没有遗漏的订单都由同一位售前在发方案前开过确认会，这为后续设计提供了可以复制的做法。

AI 能从大量记录中找出反复出现的等待、缺失字段和版本冲突。我要求它同时展示反例和样本来源。相关性不等于原因，最终判断仍要回到现场和负责人。

业务岗位确认事件与影响，数据负责人说明记录是否完整，我负责比较样本和追查第一次断点。AI 全栈工程师可以帮助建立事件视图，但此时不要急着修系统；如果断点源于没有负责人，增加提醒只会提醒更多人继续等待。

我会请上下游负责人共同回答：下一笔相似订单到这个位置时，应该由谁基于什么事实采取什么动作；如果条件不成立，工作停在哪里；结果怎样被下游看见。

云枢科技最终规定，非标准方案必须在对客户发出前由售前和交付共同确认工作量与客户准备条件。连续四周观察该类订单的退回、毛利偏差和等待时间，才能判断修复是否有效。

如果断点清单只有几十个问题却没有优先级，我会按客户、收入、现金、成本和风险影响重新排序。诊断不是问题收集比赛。

断点名称	类型	样本与反例	经营影响	下一步验证
非标准工作量在承诺前无人确认	无人负责	5笔未确认订单均签后改范围；2笔提前确认没有无偿变更	毛利、验收与回款	扩大到20笔同类订单
客户准备条件只在会议记录	丢失	10笔中6笔未进入合同交接；4笔有确认会的没有遗漏	项目重新访谈与等待	检查合同附件和启动退回
特殊折扣两天无人处理	等待	7笔报价平均等待4天	错过采购窗口	区分标准与例外折扣
方案更新后项目仍使用旧范围	返工	3笔下游取得旧版本	额外工作与争议	建立版本和确认人映射

这些名称说明发生位置、缺失事实和后果，没有写“销售不专业”或“项目不配合”。完整清单保存在诊断证据包。

断点还不能直接变成功能。下一节我要查看正式系统、群聊和员工私人表格，判断这些断点为什么在现有工具中反复出现：我为什么还要查看员工的私人表格。