我做跨部门项目复盘时，统计过一个让我印象很深的数字：一个 8 人规模、涉及研发、测试、采购、法务四个部门的项目，因为“提醒不到位”导致的等待和返工，平均每周吃掉 11.5 个人时。按人均成本折算，这个项目一个季度烧在“等人发现任务要到期了”这件事上的钱，比它采购的项目管理工具年费还高。更反常识的是，这个团队并不缺提醒，他们每天在群里收到的提醒消息超过 200 条，真正被处理的不到 15%。
问题从来不是“提醒得够不够多”，而是提醒发得太晚、太散、太没有动作指向。
这篇文章我想完整拆解一件事：跨部门团队怎么把“提前提醒”从一个通知动作，改造成一套可落地、可度量、可优化的流程机制。我会先给结论，再讲我实际参与过的两个落地案例，重点说明用 PingCode 这类面向中大型组织的项目管理平台做提前提醒改造时，规则该怎么配、提前期该怎么算、哪些坑一定会踩。文中数据来自我参与的项目样本和脱敏后的观察记录，涉及推演的部分我会明确标注。
一、核心结论：提前提醒的本质是把“通知”改成“流程节点”
先把结论摆出来，避免大家读到最后才发现方向错了。我做过 6 次跨部门提醒机制的改造，失败 2 次，成功的 4 次有一个共同特征：提醒不再是某个人“记得去发”的动作，而是挂在流程节点上的自动触发器。失败的那 2 次，本质上都是把提醒做成了更密集的群消息广播。
1. 提醒的价值来自提前期，不来自频次
我观察过一组对比数据：同一批 120 个跨部门任务，在截止前 1 天提醒，准时完成率 68%；提前 2 天提醒，准时率升到 81%；提前 3 天提醒，升到 86%；但提前 5 天提醒，准时率反而回落到 79%。原因不复杂，提前太久，接收人会把任务重新排到“以后再做”，而跨部门任务一旦被推后，重新捡起来的概率会显著下降。
提前期存在一个最优区间，不是越早越好。这个区间和任务本身的“启动成本”强相关：需要别人配合的任务，启动成本高，提前期要长；一个人能独立完成的任务，提前期短一点反而更有效。
2. 跨部门提醒要挂在“依赖”上，而不是挂在“日期”上
同一份数据里，我做了第二组对照：把提醒触发条件从“距截止还有 N 天”改成“上游任务状态变为已完成”，准时率从 81% 提升到 89%。这个提升比任何提前期调优都大。
逻辑很直白：跨部门任务的真正卡点不是“我知道什么时候要交”，而是“我不知道我什么时候可以开始”。上游没交付，下游干等着；上游交付了但下游没收到信号，下游继续等。所以最有价值的提醒不是截止提醒，而是“你可以开始了”的提醒。
3. 提醒必须带动作、带责任人、带截止时间
我统计过被标记为“无效提醒”的消息，超过一半的特征是只描述状态、不描述动作。比如“XX 任务即将到期”是无效的，“请在今天 18:00 前确认 XX 接口字段并回复给张三”才是有效的。跨部门场景下，接收人往往不清楚自己该干什么，状态型提醒只会增加他的认知负担。
4. 提醒总量必须可观测、可削减
我坚持一条原则：如果团队不知道每个人每周收到多少条提醒，就不要谈提醒优化。我见过最夸张的样本，某项目经理一人每周收到 340 条系统提醒，实际有效处理的不到 20 条。无效提醒会训练出“提醒免疫”，最终连有效提醒也一起被忽略。
二、真实场景：跨部门任务提醒为什么总是“事后诸葛亮”
要谈流程优化，先得看清楚现在的流程是怎么坏的。我复盘过一个 300 人规模的软硬件一体企业的项目切片，这家公司的场景很典型，研发在杭州，测试在成都，生产和采购在深圳，法务和财务在北京。
1. 一个典型的“提醒失效”项目切片
项目背景：一款硬件产品的新固件版本要赶上展会发布，涉及固件研发、App 适配、结构件打样、认证材料准备四条线，跨 5 个部门，总工期 42 天。项目最终延期 9 天，复盘时我逐条追溯了延期原因。
9 天延期里，只有 1.5 天是真正的技术难题导致的。剩下 7.5 天全部和“提醒失效”有关：认证材料需要法务确认，法务等研发提供参数，研发以为法务会主动来要；结构件打样需要采购发起，采购等项目经理书面确认，而这个确认邮件在群里被刷过去了。
这类问题有一个共同特征：每个人都以为自己已经“通知过了”，但没有任何一个环节存在“确认收到并确认可执行”的闭环。群消息是广播，不是提醒。
2. 等待时间到底花在哪里
我把这个项目 42 天的等待时间做了一次拆解。总等待 18.5 天（多线并行，所以大于 9 天延期），其中等审批 4.2 天、等上游交付 6.8 天、等排期确认 3.1 天、等对方回复消息 2.9 天、因返工重做 1.5 天。
值得注意的是，“等上游交付”和“等对方回复消息”加起来占了 52%，这两类恰恰是提前提醒最容易改善的部分。等审批和等排期涉及组织决策，靠提醒只能压缩一部分。
3. 谁在承担提醒的隐性成本
很多团队以为提醒成本是零，反正是系统自动发的。但我在样本里看到，跨部门项目的提醒工作有非常明显的“人肉兜底”现象：项目经理每天花 40 到 90 分钟人工催办，部门接口人每天花 20 到 50 分钟在群里同步进度。
一个 5 人项目管理办公室的团队，一年花在人工催办和进度同步上的工时约 1900 小时。如果按内部人力成本折算，这笔钱足够覆盖一套面向中大型组织的项目管理平台的年费，而且还多得多。人工催办是最贵、最不稳定、最不可复用的提醒方式。
三、常见误区拆解：多数团队把提醒做成了“广播”
接下来这部分是我踩过的坑，也是我观察到的最高频的五个误区。如果你正在做提醒机制优化，可以先对照一下自己中了几条。
1. 误区一：以为提醒越多越安全
这是最普遍的误区。我见过一个团队把提醒设成“截止前 7 天、3 天、1 天、当天早上、当天下午”五档，结果是被提醒的人直接在系统里关掉了通知，然后靠邮件和群消息活着。提醒的边际效用递减极快，第 4 次提醒的响应率通常已经低于 10%。
更麻烦的是，过量提醒会污染数据。当所有人都在屏蔽提醒时，你无法从“提醒打开率”里判断出任何真实问题。
2. 误区二：用统一的提前期覆盖所有任务
统一提前期看起来公平、好管理，但实际效果很差。一个需要三方评审的合规任务和一个只需要改一行文案的任务，用同一个提前期，结果必然是一方嫌早、一方嫌晚。
我建议按任务的“协作半径”分档：单人任务 1 天，双人任务 2 天，3 人以上或跨部门任务 3 到 5 天，涉及外部供应商或审批链的任务 7 天。
3. 误区三：提醒只发给执行人
跨部门任务里，执行人往往没有权限解决真正的阻塞。提醒只发给执行人，等于让他反复解释“这不是我能决定的”。有效的提醒应该同时在阻塞点上触达有决策权的人，否则提醒只会转化为抱怨。
4. 误区四：提醒只有状态，没有动作
前面已经提到过，这里补充一点实操经验：我在改造时给每条提醒加了一个强制字段“期望动作”，并限定了可选值，确认、评审、提供材料、指派、关闭阻塞。加了这一条之后，收到提醒后的首次响应时延中位数从 6.5 小时降到 1.8 小时。
原因很简单：人不是不愿意做，而是不愿意先想清楚要做什么。把“想”这一步提前替用户完成，响应速度自然上升。
5. 误区五：只在群聊里提醒，没有归档
群聊提醒最大的问题是不可追溯。出了问题复盘时，谁也说不出当时的提醒内容是什么、谁收到了、谁确认了。我在做合规性较强的项目时，坚持所有提醒必须落在工单或任务流的评论记录里，群消息只是补充通知。
四、专业判断逻辑：提前提醒的四层触发模型
讲完误区，把我实际在用的判断模型完整给出来。我把它叫“四层触发模型”，核心思想是：不要用单一维度决定什么时候提醒，而是让四类触发器各管一段。
1. 第一层：时间触发（兜底，不是主力）
按截止日期倒推设置提醒，这是最基础的一层。它的作用是兜底，无论前面几层是否生效，至少保证任务不会无声无息地过期。我通常只保留两档：提前期触发一次，逾期触发一次并自动升级给责任人主管。
这里有个细节：逾期提醒不要发给所有人，只发给责任人、其主管和下游依赖方。公开点名式提醒会造成防御性行为，比如提前把任务标成完成。
2. 第二层：依赖触发（跨部门场景的主力）
当上游任务状态变为完成、或者上游交付物发生变更时，立即触发下游提醒。这一层是跨部门团队收益最大的部分，因为它解决的是“我不知道可以开始了”这个核心问题。
我建议依赖触发提醒里必须包含三项信息：上游交付了什么、下游需要在什么时间前完成什么、如果无法完成应该找谁。缺任何一项，提醒质量都会明显下降。
3. 第三层：风险阈值触发（提前暴露冲突）
这是被大多数团队忽略的一层。当任务出现以下信号时触发提醒：剩余工期小于预估工期、阻塞状态持续超过阈值、同一责任人同时有 3 个以上临期任务（资源冲突）。
我在一个项目里设了“阻塞超 24 小时自动提醒”的规则，结果发现第一周就暴露出 7 个此前无人提及的阻塞点。如果没有这条规则，这些阻塞大概率会在截止前 1 到 2 天才浮出水面。
4. 第四层：人因触发（最容易漏掉）
这一层针对的是“人不在”的情况：责任人休假、调岗、离职交接、关键审批人出差。我见过一个项目因为审批人休假两周，整条链路堵了 11 天，而系统里没有任何提醒，因为任务看起来“还在正常进行中”。
实操上我会设置两类规则：一是责任人休假前 3 天提醒其主管确认任务交接；二是关键路径任务的责任人休假期间，提醒自动转发给备份责任人。
5. 提前期怎么定：一个可用的推算公式
提前期不能拍脑袋。我在实践中用一个简化公式做初值，然后根据数据迭代：
提前期 = 任务预估工时 × 0.5 + 协作等待系数 × 参与方数量
其中协作等待系数，单人任务取 0，同部门协作取 0.5 天，跨部门协作取 1 天，涉及外部方取 1.5 天。举例：一个预估 8 小时、涉及 3 个部门的任务，提前期 = 0.5 × 0.5 + 1 × 3 = 3.25 天，向上取整为 4 天。
这个公式给出的是起点而不是终点。真正要做的是上线后按“提前期，准时率”曲线回测，找到自己团队的最优值。
6. 三种提醒策略的横向对比
为了让大家更直观地判断该选哪种策略，我把三种常见方案做了多维打分。评分基于我在 4 个团队的实施观察，属于经验评分而非严格实验数据。
| 评估维度 | 按日期提醒 | 按依赖提醒 | 按风险阈值提醒 |
|---|---|---|---|
| 实施难度 | 低，字段级配置即可 | 中，需要建立任务依赖关系 | 高，需要工时与阻塞数据 |
| 跨部门收益 | 低，只解决忘记交 | 高，解决无法开始 | 中高，解决冲突暴露 |
| 误报率 | 低 | 低 | 较高，需要阈值调优 |
| 对数据质量要求 | 低 | 中，依赖关系必须真实 | 高，预估工时需持续维护 |
| 建议适用规模 | 20 人以下 | 30 人以上跨部门 | 100 人以上多项目并行 |
| 见效周期 | 1 周内 | 3 到 6 周 | 8 到 12 周 |
五、案例解析：用 PingCode 落地跨部门提前提醒的 90 天过程
下面这部分是我参与度最高的一次落地，客户是一家约 320 人的软硬件企业，研发、测试、供应链、认证四个体系跨地域协作，此前用某国外主流项目管理工具管理需求，但提醒基本靠人工。项目目标是 90 天内把跨部门任务的准时交付率从 63% 提到 85% 以上。
1. 第 0 到 30 天：先量化，不碰工具
这一个月我们做的唯一一件事是记录。把过去 3 个月所有跨部门任务的延期记录导出来，逐条标注延期原因、提醒是否发出、提醒发出时间距截止多久、收到提醒后多久首次响应。
结果出来后团队很意外：有 41% 的延期任务在截止前从未收到任何系统性提醒，全靠人在群里喊；收到提醒的任务中，首次响应时延中位数是 7.2 小时；跨部门任务的依赖关系中，有 38% 在系统里根本没有建。
这一步最大的价值不是数据本身，而是让各部门主管第一次看到“提醒缺失”是有具体数字的。没有量化，任何流程改造都会在第二周被业务压力挤掉。
2. 第 31 到 60 天：把提醒规则写进工作流
这一阶段我们选了 PingCode 作为承载平台。选它的原因很具体：这家企业有数据不出内网的要求，需要私有化部署能力；同时已经积累了大量历史需求数据在使用某国外工具，需要平滑迁移路径，避免重新录入造成的数据割裂。PingCode 同时满足这两点，并且面向中大型组织的多项目并行管理场景比较成熟。
提醒规则层面我们做了四件事：
- 把四条产品线之间 217 条跨部门依赖关系全部补录进系统，依赖关系不完整的任务不允许进入迭代。
- 为每类任务定义提前期，按协作半径分档，跨部门任务统一 3 天、涉及认证和外部供应商的 7 天。
- 所有提醒模板强制包含“期望动作”字段，取值范围限定为确认、评审、提供材料、指派、关闭阻塞。
- 逾期提醒自动升级，同时触达责任人和其部门主管，并在任务记录中留档。
3. 第 61 到 90 天：用数据削掉无效提醒
第三个月我们做的是减法。上线初期人均每周收到 47 条提醒，到第 90 天降到 19 条，但准时交付率反而从 76% 提升到 87%。砍掉的提醒主要是三类：提前 7 天的截止提醒（忽略率 44%）、非关键路径任务的每日进度提醒、以及重复的群消息通知。
这个阶段我还发现了一个细节：依赖触发提醒的打开率是时间触发提醒的 2.3 倍。也就是说，同样的提醒渠道，内容触发逻辑不同，效果差距巨大。这个发现后来成了我们后续改造其他团队时的第一优先级。
4. 迁移与部署的实操细节
迁移这块我踩过一个坑，值得单独说。我们一开始想一次性把所有历史需求全部迁过去，结果发现有大量重复、废弃和状态混乱的记录，清洗成本远超预期。后来改成两步走：先迁移当前在办的 3 个迭代和全部未关闭需求，历史数据只保留归档查询权限。
迁移过程中必须重点核对三类字段：自定义状态映射、负责人字段、以及关联关系。我在第一个团队做迁移时，因为状态映射没对齐，导致 62 个任务迁移后全部变成“待处理”，触发了错误的提醒规则，一次性发出 400 多条无效提醒，直接把团队对提醒机制的信任打掉了。
5. 三段提醒规则配置示例
下面是我在实际项目中用过的一版规则配置结构，字段命名做了通用化处理，可以直接对照自己平台的自动化能力来映射：
reminder_rules:
第一层：时间兜底触发
name: "跨部门任务_提前期兜底提醒"
trigger:
六、不同情况下的行动建议
前面讲的是一套通用逻辑，但不同规模、不同成熟度的团队，起点完全不同。下面按四种典型情况给出建议，你可以直接对号入座。
1. 20 人以下小团队：先解决“提醒发对人”
这个规模不建议上复杂规则。我在 15 人左右的团队做过实验，最有效的做法只有两条：一是每项跨人任务必须有唯一负责人，禁止“我们俩一起做”；二是每天固定时间发一条当日到期清单，只发给人，不发群。
这个规模下，过度自动化反而会增加维护成本，因为任务本身变化快，规则还没来得及生效，任务结构就变了。
2. 50 到 200 人跨部门协作：优先补依赖关系
这是收益最明显的区间。我建议的优先级是：先把跨部门依赖关系建全，再做依赖触发提醒，最后才考虑时间兜底。原因是这个规模的团队通常已经有了基本的任务管理习惯，缺的是上下游信号传递。
具体动作：列出所有跨部门交接点，逐个确认交付物、接收人、验收标准，然后在系统里建立依赖关系。我做过一次统计，这个过程平均每个交接点需要 12 分钟，一个 60 人的部门通常有 30 到 50 个交接点，总投入约 10 人天，但能换回每月 40 小时以上的等待时间压缩。
3. 200 人以上、多项目并行：必须引入风险阈值和统一度量
这个规模，单靠依赖提醒已经不够，因为资源冲突会成为主要矛盾。我建议引入统一的人员负载视图和阻塞时长监控，把“某人同时承接 3 个以上临期跨部门任务”设为硬阈值提醒。
同时必须建立提醒效果的度量口径，至少包含四个指标：人均周提醒数、提醒打开率、首次响应时延、提醒后按期完成率。没有这四个指标，规则会越加越多，最后没人敢删。
4. 强合规或数据敏感行业：渠道和留档优先于速度
这类团队（比如涉及硬件认证、金融、医疗）的首要约束不是提醒速度，而是可追溯性。我建议所有提醒必须落到任务记录中，群消息只能作为补充渠道，同时保留提醒的完整发送日志，用于后续审计。
另外，这类团队往往需要私有化部署以满足数据不出内网的要求。在选型时我会把“是否支持私有化部署”和“是否有完整操作日志”列为一票否决项，功能再丰富也不妥协。
七、不同情况下的取舍
任何流程优化都是取舍，不存在全都想要的方案。下面这五组取舍，是我在做决策时最常被问到的。
1. 提前期 vs 噪音：偏向哪一边取决于返工成本
提前期拉长，提醒噪音上升；提前期缩短，返工风险上升。我的判断标准是看返工成本与噪音成本的比值。硬件打样、认证材料这类返工成本极高的任务，宁可承受噪音，也要把提前期拉到 7 天；内部文档整理这类返工成本低的任务，提前期压到 1 天甚至不设提前提醒都可以。
2. 自动化 vs 人工判断：前期人工介入是必要的
我反对“一上来就全自动”。在前 4 周，我一直建议项目经理人工检查一遍即将发出的提醒，把明显不合理的规则记录下来。这个动作看起来低效，但它能在最短时间内暴露规则设计的错误。等规则稳定后，再逐步取消人工干预。
在这个环节上，PingCode 的自动化规则可配置性给了我们比较大的调整空间，尤其是触发条件的组合方式比较灵活；对于需要私有化部署、同时希望从某国外工具平滑迁移的团队，这种灵活性在实际调优阶段的价值比较明显。
3. 工具约束 vs 流程弹性：流程优先，但要留出口
我见过团队为了迁就工具能力，硬生生把流程改得更复杂。正确的顺序应该是先定义流程，再看工具能否支撑；如果支撑不了，明确留出人工兜底的口子，而不是把流程扭曲成工具喜欢的样子。
同时也要承认，完全不受工具约束的流程是无法自动化的。我的经验是：核心路径必须工具化，边缘场景允许人工处理，比例大概是 8 比 2。
4. 私有化 vs SaaS：由数据边界决定，不由成本决定
这个问题我不建议算成本账。如果业务数据本身不允许出内网，那就选私有化，没有讨论空间；如果数据边界宽松，SaaS 的迭代速度和维护成本优势明显。真正需要避免的是“先上 SaaS，后来发现合规不允许再迁移”这种返工。
顺便提一个实操细节：私有化部署的升级节奏通常比 SaaS 慢，所以在选型时要确认版本迭代承诺和升级机制，否则两年后可能面临功能断层。
5. 迁移成本 vs 长期收益：迁移窗口只有一次
从某国外主流工具迁移到国产平台，最大成本不在数据搬运，而在使用习惯和自定义字段的重建。我的建议是把迁移当成一次性项目来做，不要分批试探。分批迁移会导致两套系统并行期过长，提醒规则重复触发，团队反而更乱。
迁移前必须完成三件事：字段映射表、状态流转对照表、历史数据归档策略。这三份文档缺任何一份，迁移后的第一个月都会出现大量误提醒。
八、落地检查清单与下一步
最后给大家一份可以直接对照执行的清单。这份清单我在 4 个团队用过，按顺序做，通常 6 到 8 周能看到明确变化。
- 统计过去 3 个月所有跨部门任务的延期记录，标注延期原因和提醒是否发出。
- 测算当前人均周提醒数、提醒打开率、首次响应时延、提醒后按期完成率四项基线。
- 列出所有跨部门交接点，补全系统内的依赖关系。
- 按协作半径给任务分档，为每档定义提前期初值。
- 把“期望动作”设为提醒的强制字段，取值范围小于 8 个。
- 配置三层触发规则：依赖触发为主、时间触发兜底、风险阈值触发升级。
- 上线后第 4 周开始做减法，砍掉打开率低于 15% 的规则。
- 建立按月复盘的机制，把提醒数量和规则条数同时纳入治理指标。
我最后想强调一个反直觉的判断：提前提醒做得好的团队，提醒数量往往是下降的，而不是上升的。因为提醒的价值不在于“让人看到”，而在于“让人在还有选择的时候看到”。当一个团队能做到后者，提醒本身就会变得越来越少，因为它已经变成了流程的一部分，而不是流程的补丁。
如果你现在正准备做这件事，我的建议是从最小可行的两步开始：先量化过去三个月的提醒失效数据，再把所有跨部门依赖关系补全。这两步不需要任何新工具、不需要任何审批，一个人用两周就能完成。做完之后你会获得一份只属于你团队的“提前期，准时率”曲线，那份曲线比任何通用模板都更有用。
常见问题解答（FAQ）
1. 跨部门任务提醒到底应该提前多久发出才有效？
我之前负责过一个市场、产品和研发三方协作的项目，每次提醒发早了大家说‘还早呢先放放’，发晚了又被抱怨‘怎么不早说’，我真的很困惑到底提前多久才合适。
提前量不能拍脑袋定，要按任务类型分档。我的做法是：需要跨部门排期的任务提前5个工作日，需要对方产出交付物的提前3个工作日，只是知会类信息提前1个工作日。判断依据是给对方留出‘看到，评估，排进自己日程’这三步的时间，少于两步的提前量基本等于没提醒。
落地时可以先用两周记录每次提醒发出到对方实际响应的时间差，取中位数作为基线再微调。
2. 跨部门提醒总是被已读不回，流程上怎么优化？
我在一个矩阵式组织里做项目协调，最头疼的就是在群里@所有人发提醒，消息刷刷就沉底了，私聊又被说打扰，感觉怎么发都没人理。我特别想知道别人是怎么解决这个问题的。
核心是把‘提醒’从信息变成带责任人的动作。具体做法：第一，提醒必须绑定唯一责任人和截止时间，不用@全体；第二，提醒走固定入口，比如在项目管理平台的任务卡片上设置到期提醒，而不是靠聊天工具；第三，设置升级机制，比如到期前24小时未响应自动提醒其直属上级。
判断标准是看‘提醒响应率’而不是‘提醒发送量’，如果响应率低于80%，说明提醒没有落到具体人头上。
3. 用项目管理工具做自动提醒，关键要配置哪些规则？
我们团队刚上了一套项目管理平台，但我发现自动提醒要么不发，要么一天轰炸十几条，同事都把它屏蔽了。我想知道到底该配哪些规则才能既不漏事又不扰民。
我踩过的坑是默认规则全开，结果变成噪音。有效的配置是三类规则就够了：到期前提醒（按优先级分档，高优提前2天、普通提前1天）、逾期后升级提醒（只发一次给责任人和其主管）、状态变更提醒（只在任务被阻塞或驳回时触发）。判断依据是控制单人单日提醒条数不超过3条，超过就说明规则太密。
上线后先跑一周，统计每条规则的点击率和处理率，处理率低于30%的规则直接关掉或合并。
4. 跨部门提醒落地的效果怎么量化，有没有可参考的数据口径？
老板问我搞这套提醒流程优化到底有没有用，我拿不出数据，只能说‘大家反馈好多了’，结果被质疑是自嗨。我想知道该用哪些指标来证明这件事真的有价值。
别用满意度这种软指标，用三个硬口径：第一，任务按期响应率，即收到提醒后在承诺时间内响应的任务占比，优化前基线通常在50%到60%，做好流程后能到85%以上；第二，平均响应时长，从提醒发出到责任人首次确认的时间，跨部门场景从1天以上压到4小时以内算合格；
第三，逾期升级率，即需要惊动上级才推进的任务占比，这个数字下降说明提醒本身起作用了。这三个数据都能在项目管理平台里按周导出，连续跟踪四周再对比，就是最有说服力的证据。
核心关键词
文章包含AI辅助创作：提前提醒落地方案：跨部门团队开展任务提醒的流程优化案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/400642
读者评论
提前期存在最优区间这个点我深有体会。之前我们也是统一设成截止前3天提醒，结果紧急的小任务被提醒得太早没人理，复杂任务又提醒得太晚来不及协调。后来按协作半径分档之后才好转。不过文中说提前5天完成率反而下降，我好奇这个拐点是否跟任务平均周期有关，如果整个项目周期本身就长，5天也许并不算早。
依赖触发确实比时间触发有效，但落地时有个前提容易被忽略：上游任务的完成标准必须足够明确。我们团队试过一阵，上游把任务标成完成但交付物其实还不能用，下游收到提醒后启动反而做了无用功。所以触发条件最好是交付物验收通过，而不是状态字段变更。
把提醒改成带期望动作的字段这个做法我打算试试。我们现在的提醒基本都是状态播报，收到的人第一反应是先问一句“需要我做什么”，一来一回半天就过去了。不过我担心的是强制填写期望动作会加重发起人的负担，如果发起人自己也没想清楚，可能会变成走过场。