先给结论:只有当“等待”已经占用了可交付的排期资源、并且你能把等待时长与具体交付物对应起来时,记录等待成本才有意义。否则,记录只会变成一份情绪台账,既不能用于协商,也不能用于调整排期。判断标准很简单:这段等待是否让某个已排定的动作无法开始。如果答案是肯定的,就按“被阻塞的交付物”记账;如果答案是否定的,说明它只是进度偏慢,不该计入等待成本。
阻塞型等待指的是,某项工作因为缺少客户提供的材料而完全无法启动。例如首页文案未确认,导致设计无法进入定稿;产品图未提供,导致详情页无法排版。这类等待有明确的起点和终点,可以直接对应到具体交付物。
背景型等待则是客户在并行处理自己的事情,而你的团队仍有其他可推进的工作。比如客户还没给域名解析权限,但内页模板仍可继续开发。这种情况下,等待确实存在,但没有造成实际阻塞,把它计入成本会夸大影响。
区分两者的实际动作是:在项目排期表上,为每个交付物标注“前置依赖”。当依赖项来自客户时,记录其应到日期和实际到齐日期。只有那些实际到齐日期晚于应到日期、且期间没有替代工作可做的条目,才进入等待成本记录。这个动作的结果会直接影响下一步:你会发现真正需要催的往往只有少数几项,而不是所有未回复的消息。
有效的记录至少包含三列:被阻塞的交付物、等待起止日期、等待期间团队是否仍有可推进的工作。第三列决定了这条记录是“成本”还是“背景信息”。
一个假设的例子:某项目原定周一进入首页设计,但客户品牌色直到周四才确认。等待期间,设计无法开始,但内页结构梳理可以继续。那么等待成本应记为“首页设计被阻塞3天”,而不是“整个项目停了3天”。这个区分会影响下一步:如果被阻塞的是关键路径,就需要调整整体排期;如果只是并行分支,只需记录,不必触发重新协商。
在单个项目里,按上述方法记录通常能帮助你和客户对齐节奏。但当你同时推进多个项目时,同样的记录方式可能得出误导性结论。
原因是:个别项目中的“等待”往往被归因于客户一方,但规模化之后,等待可能来自你自己的排期冲突、内部评审延迟或需求变更。如果仍然沿用“谁晚到谁负责”的简单归因,记录就会变成对客户的单方面施压,反而掩盖了内部瓶颈。
一个反例:假设你同时有五个项目,其中三个都在等待客户资料。表面上看,客户拖延是主要问题。但如果检查排期就会发现,这三个项目的交付物原本就排在同一个设计人员身上,即使客户按时提供资料,设计资源仍然不够。此时等待成本的真实来源是资源排期,而不是客户资料。继续按“客户等待”记录,会导致错误的下一步动作,比如向客户催得更紧,却没有解决自己的排期问题。
因此,规模化之后需要增加一个校验步骤:在把等待归因于客户之前,先确认该交付物在等待期间是否有可用的内部资源。如果没有,等待成本应部分或全部归因于内部排期,而不是客户。
你可以用一张简单的表来记录,字段包括:项目、被阻塞交付物、依赖项来源、应到日期、实际到齐日期、等待天数、等待期间可推进工作、归因判断。其中“归因判断”只在规模化时填写,用于区分客户原因和内部原因。
记录之后,下一步动作取决于等待是否落在关键路径上:
这些动作的结果会反过来验证记录是否有效:如果调整排期后等待天数明显下降,说明记录抓住了真实瓶颈;如果等待天数没有变化,说明被阻塞的交付物可能并不是真正的关键路径,需要重新检查依赖关系。
当客户资料延迟已经成为常态,且每次延迟都对应不同的交付物、没有稳定的关键路径时,继续逐条记录等待成本会消耗大量管理精力,却难以形成可行动的结论。此时更合适的做法是暂停逐条记录,改为与客户重新约定资料提交的整体节奏,例如按周批量确认,而不是按交付物逐个催办。
另外,如果合同中没有约定资料提交的时间节点,等待成本记录只能作为内部参考,不能直接用于要求客户承担额外费用或压缩后续工期。记录的价值在于帮助你判断排期风险,而不是替代合同约定。
最后,等待成本记录的目的是让下一步动作更清楚,而不是让责任更清楚。当你发现记录无法指向一个具体动作时,就应该停止记录,转而去解决那个让记录失去意义的结构问题。