去年我接手过一个已经延期四周的交付项目，复盘时发现一个很讽刺的事实：项目群里累计发出过 200 多条任务提醒，但真正推动任务状态发生变化的不到 30 条。剩下的 170 多条，要么被已读忽略，要么根本没人点开。更麻烦的是，当我试图追究"为什么没人执行"时，团队成员的回答高度一致，"提醒太多了，我根本分不清哪条是真正急的"。
这个场景几乎每个项目经理都经历过。我们习惯性地把"提醒"等同于"推动"，把"发得多"等同于"盯得紧"，但现实往往相反：提醒发得越多，单条提醒的可信度越低，最终整个通知体系会彻底失效。这篇文章不谈"为什么要重视提醒"，而是直接回答一个更实际的问题，当你发现团队已经对提醒麻木时，制度应该怎么重新设计。
一、核心结论：任务提醒制度要解决的是"可信度"，不是"覆盖率"
在展开完整方案之前，我先给出几条经过多个项目验证的核心判断。这几点也是后文所有模块设计的基础逻辑。
结论一：提醒制度的失效，几乎都不是因为发得太少，而是因为发得太随意。当提醒的触发条件、内容格式、时间窗口都没有统一标准时，接收方会本能地把所有提醒降级为"背景信息"，直到它们被彻底屏蔽。
结论二：有效的提醒制度必须同时覆盖"提醒前，提醒中，提醒后"三段。绝大多数团队只设计了"提醒中"（即发什么内容），却忽略了"提醒前"的触发规则和"提醒后"的升级与闭环，导致提醒发出后没有下文。
结论三：制度比工具重要，但工具决定了制度能不能落地。再好的提醒规则，如果依赖人工记忆去执行，两三周后必然走形。工具的价值在于把规则固化下来，让人不需要"记得提醒"，而是系统自动按规则提醒。
结论四：提醒的核心目标不是"催办"，而是"对齐预期"。一条好的提醒，让接收方清楚知道：这件事什么时候要、要成什么样、现在卡在哪里、需要他做什么。做到这四点，提醒才真正产生执行力。
二、背景与真实场景：多项目并行下，提醒为什么会集体失灵
1. 一个项目经理的典型早晨
我每天的开工流程通常是这样的：9 点打开工具，看到昨晚到今早累计的 23 条待处理提醒。其中 8 条是某项目管理平台自动推送的"任务即将到期"，5 条来自另一个项目群的手动催办，4 条是职能经理转发的协作请求，还有 6 条是各种审批、评论和状态变更通知。
我扫一眼，快速判断，2 条必须马上处理，3 条需要今天内回应，剩下的先放着。等到下午再打开时，那 18 条"先放着"的提醒，已经有 4 条超过了截止时间。
这不是个例。在同时跟进 3 个以上项目的场景里，项目经理每天接收的消息通知数量普遍在 40-80 条之间，其中真正需要即时响应的不足 20%。
2. 通知疲劳是怎么一步步形成的
通知疲劳的形成有清晰的阶段性。理解这个过程，有助于判断你的团队目前处于哪个阶段，以及应该采取什么干预手段。
第一阶段（蜜月期）：团队刚上线工具，提醒被认真对待，响应率高。这个阶段通常持续 2-4 周。
第二阶段（泛化期）：各项目开始自定义提醒规则，频率和格式不统一，接收方需要花额外精力判断优先级。此时响应率开始下滑。
第三阶段（麻木期）：提醒数量超过人的处理能力，接收方开始批量忽略，只处理最显眼的。此时重要提醒和一般提醒一起被忽略。
第四阶段（失效期）：团队默认"提醒不可信"，重要事情必须靠人肉当面确认或电话追。工具里的提醒沦为形式。到这个阶段，再重新设计提醒制度，难度会显著高于前三个阶段。
3. 工具默认配置为什么不够用
很多团队一开始会依赖工具的默认通知设置，比如"任务到期前一天自动提醒""任务被指派时通知负责人"。这些默认配置本身没问题，但它们的假设是：所有任务同等重要、所有接收方处理能力相同、所有提醒通道都有效。
现实显然不是这样。一个 3 人天以内的配置工作，和一个需要 5 个部门协作的关键里程碑，显然不应该用同一套提醒策略。而工具的默认配置不会替你做这个区分，它只会平等地给每条任务发提醒，最终把接收方淹没。
三、常见误区：为什么多数提醒制度落地后就走形
1. 误区一：把"提醒"当作"通知"
通知是单向的信息传递，提醒是带有明确行动要求的信息传递。二者最大的区别在于，提醒必须包含"需要对方做什么"。
我见过很多提醒模板只写"任务 A 将于明日到期，请关注"，这类提醒等于没有提醒。合格的任务提醒必须包含明确的行动指令，例如"任务 A 的接口文档需在明日 18 点前完成初稿并上传至指定目录，当前进度为 40%，请确认能否按期交付"。
2. 误区二：所有任务用同一套提醒规则
最常见的错误是把所有任务按相同频率、相同通道、相同格式推送。结果是紧急任务被淹没在常规任务的通知里。
合理的做法是按"紧急度×重要度"划分 4 类任务，分别配置不同的提醒策略。紧急重要任务用多通道 + 短周期，常规任务用单通道 + 长周期，参考型任务甚至可以只更新状态不主动提醒。
3. 误区三：只设计"提醒中"，不管"提醒后"
提醒发出后没有确认机制、没有升级路径、没有闭环验证，是制度走形最快的原因。如果一条提醒在设定时间内没有收到任何反馈，制度必须定义"接下来发生什么"，是自动升级给上级，是标记为风险，还是重新指派。没有这一步，接收方很快会发现"不回应也没有后果"，提醒自然失效。
4. 误区四：把提醒频率当作"管理强度"
有些项目经理把"我每天提醒三次"当作"我很负责"的证据。但在团队视角里，高频提醒往往意味着"发提醒的人不信任接收方"或"这个人做事没有重点"。过度提醒不仅无效，还会损害协作关系。
四、专业判断逻辑：任务提醒制度的五个核心模块
1. 触发规则：什么任务、什么时间、提醒谁
触发规则是整个制度的起点。设计时建议用一张二维矩阵明确"任务类型 × 接收角色"的对应关系，避免"提醒了大家等于没提醒任何人"。
| 任务类型 | 首要接收人 | 次要接收人 | 提醒时机 | 通道建议 |
|---|---|---|---|---|
| 紧急重要（阻塞型） | 责任人 | 项目经理、职能经理 | 即时 + 每 4 小时复核 | IM + 电话 |
| 重要非紧急（里程碑） | 责任人 | 项目经理 | 提前 3 天、1 天各一次 | IM + 邮件 |
| 常规任务 | 责任人 | ， | 提前 1 天一次 | IM |
| 参考型任务 | 协作人 | ， | 仅状态变更时 | 工具内通知 |
这张表不是模板，而是逻辑示范。真正落地时，你需要结合自己项目的任务分类标准，把每一行的"时机"和"通道"换成团队能执行的具体参数。
2. 提醒内容：一条合格提醒的五个要素
我总结过一个"任务提醒五要素"公式，团队里用了两年多，响应率明显提升。这五个要素是：任务名、截止时间、交付标准、当前状态、所需动作。
下面是一条可以直接复用的提醒话术模板：
【任务提醒｜任务名：订单模块接口联调】
截止时间：本周五 18:00
交付标准：接口文档完成 + 联调通过截图上传至项目共享目录
当前状态：接口文档完成 60%，联调尚未开始
所需动作：请于今日 17:00 前更新联调排期；若存在阻塞，请直接在评论中@我并说明依赖项
对比常见的"任务即将到期请及时处理"，这条提醒把"什么时候要、要成什么样、现在在哪、要你做什么"四件事一次说清，接收方不需要再翻上下文就能判断该不该马上处理。
3. 通道选择：什么时候用哪个通道
不同通道适合不同场景。我的经验是：IM 负责"提醒注意"，邮件负责"留存记录"，电话或当面负责"确认决心"。
- IM（钉钉/飞书/企业微信）：适用于日常任务提醒、状态更新确认。优点是触达快，缺点是容易被消息流淹没。
- 邮件：适用于正式里程碑、跨部门协作、需要留痕的节点。优点是信息完整、可追溯，缺点是响应慢。
- 电话或当面：适用于紧急阻塞、跨部门推不动、责任人不响应的情况。使用时要克制，过度使用会损害关系。
- 工具内通知：适用于状态变更、评论回复、审批流转。适合作为基础层，不适合作为关键任务的唯一提醒。
4. 升级机制：提醒无效时如何逐级升级
升级机制是很多人忽略但极其关键的一环。合理的升级路径一般是：责任人 → 项目经理 → 职能经理 → 项目发起人。
每一级升级都应有明确的触发条件和时间窗口。例如：责任人在提醒发出后 24 小时未回应，自动升级至项目经理；项目经理 48 小时未解决，升级至职能经理；涉及跨部门阻塞超过 3 天，升级至项目发起人。
升级不是"告状"，而是让问题在正确的层级被解决。如果制度里没有升级路径，所有问题都会堆在项目经理这里，最终变成人肉兜底。
5. 反馈闭环：确认提醒被接收和执行
建议使用"确认，更新，闭环"三步法。确认：接收方需要在提醒发出后第一时间回应"收到"或给出异议；更新：执行过程中，任务状态或排期变化时主动更新；闭环：任务完成后在提醒上下文里明确记录交付结果。
这三步不需要复杂工具支持，但需要在制度中明确写入，并在团队会议上反复对齐。缺少闭环，制度就是一个漏水的桶。
五、具体观察：来自三个项目的数据与案例
1. 数据观察：提醒响应率的现实水平
过去三年我在三个不同规模的项目中统计过提醒响应情况，以下是具有代表性的观察（数据取自各项目工具后台的提醒记录，时间跨度均为连续 8 周）：
项目 A（12 人，2 个项目并行）：提醒总量 480 条/月，48 小时内被明确回应的约 132 条，回应率 27.5%。
项目 B（28 人，4 个项目并行）：提醒总量 1200 条/月，48 小时内被明确回应的约 216 条，回应率 18%。
项目 C（上线提醒制度后，21 人，3 个项目并行）：提醒总量降至 620 条/月，48 小时内回应率提升至 51%。
项目 C 的关键变化不是"发得更少"，而是每条提醒都带明确的所需动作，并且规定了 24 小时未回应的自动升级规则。提醒数量减少了近一半，但有效响应翻了一倍以上。
2. 案例：一个中大型团队如何用 PingCode 重建提醒制度
我参与过一家约 200 人规模企业的提醒制度重构。这家公司同时运行 6 个研发项目，团队分布在北京、深圳和成都三地，之前所有提醒依赖人工在 IM 里发，项目经理每天要花 1.5 小时手动催办，跨部门任务经常卡壳。
改造过程中，他们将提醒规则统一收拢到 PingCode 中，主要做了三件事：
- 任务分类落地：按"紧急重要/重要非紧急/常规/参考"四类重新打标签，每类任务对应不同的提醒时机和通道。
- 话术模板化：在任务模板中固化"五要素"字段，项目经理创建任务时自动生成提醒文本，减少手工编辑。
- 升级自动化:设置"任务到期前 24 小时未更新则通知项目经理，48 小时未响应则通知职能经理"的自动规则，减少人工盯守。
PingCode 本身主要服务中大型企业和 100 人以上的组织，支持私有化部署，也支持从 Jira 平滑迁移，适合有国产替代需求的团队。对于这类多项目、多地点、多部门的场景，工具的规则引擎和权限体系是制度能否落地的关键。改造 3 个月后的复盘数据显示：
- 项目经理手动催办时间从每天 1.5 小时下降到每天 25 分钟
- 跨部门任务平均处理周期从 6.8 天缩短到 4.1 天
- 任务逾期率从 23% 降到 11%
- "因提醒未响应导致的问题"从每月 14 起降到 3 起
六、7 个常见问题与对策
1. 提醒太频繁，团队已经麻木了怎么办？
先做减法再做加法。第一步是砍掉所有"没有明确所需动作"的提醒，只保留需要接收方回应或执行的通知。通常这一步能减少 30%-40% 的提醒量。第二步是把保留下来的提醒按重要性重新分类，给最重要的一类加上差异化通道（比如 IM + 邮件）。
2. 责任人已读不回怎么办？
已读不回往往不是态度问题，而是提醒里没有明确的回应要求。改进方向有两个：一是在话术里明确写出"请于 X 时间前回复是否可以按期完成"，把回应变成任务的必要动作；二是设置 24 小时未回应自动升级到项目经理，让"不回应"有明确后果。
3. 跨部门任务提醒推不动怎么办？
跨部门问题的本质不是"提醒不到"，而是"提醒不到对的人"。解决办法是：提醒必须直接送到执行人的直属上级可见范围内，并在制度中明确跨部门任务的响应时限。如果仍然推不动，必须升级至共同上级或项目发起人，不能靠项目经理反复催。
4. 非工作时间要不要发提醒？
建议默认在工作时间发送，紧急阻塞类任务除外。同时，制度中应明确"非工作时间收到提醒不要求立即响应"，避免给团队造成隐性加班压力。具体合规边界因地区和企业规定而异，建议由 HR 或法务参与确认。
5. 工具默认提醒不好用，怎么调？
不建议在默认设置上反复尝试，而是直接按任务类型创建自定义规则。主流工具（如 PingCode、Jira、飞书项目等）都支持按任务字段、优先级、截止时间配置差异化提醒，关键是先明确"规则要对应哪类任务"，再去工具里配置对应参数。
6. 多个项目同时提醒，怎么排优先级？
优先级的判断标准不是"哪个项目更急"，而是"哪条提醒的延迟成本最高"。建议用一句话自检：如果这条提醒延迟 24 小时处理，会造成什么后果？后果越大，优先级越高。对于后果难以直接评估的提醒，一律按常规处理。
7. 制度推了一段时间就形同虚设，怎么持续？
制度走形的根因通常是缺乏复盘机制。建议每月做一次"提醒有效性统计"，看哪些类型提醒响应率高、哪些长期无人回应，然后把无效提醒规则删除或重构。制度不需要完美，但需要每月迭代一次。
七、可直接套用的提醒制度模板
下面这张表是可以直接改参数使用的制度框架，覆盖六类典型任务场景。使用时只需把"时机"和"话术模板"替换成自己团队的表述即可。
| 任务类型 | 提醒时机 | 通道 | 话术要素 | 升级条件 | 闭环要求 |
|---|---|---|---|---|---|
| 阻塞型紧急任务 | 即时 + 每 4 小时复核 | IM + 电话 | 五要素全含 | 4 小时未响应升级至项目经理 | 任务完成需在提醒上下文回执 |
| 里程碑任务 | 提前 3 天、1 天 | IM + 邮件 | 五要素全含 | 1 天未确认升级至项目经理 | 交付物需上传并评论确认 |
| 常规任务 | 提前 1 天 | IM | 四要素（可省当前状态） | 24 小时未回应再提醒一次 | 任务状态更新为完成即可 |
| 跨部门协作任务 | 提前 3 天、1 天、当天 | IM + 邮件，抄送双方上级 | 五要素 + 依赖说明 | 48 小时未实质推进升级至职能经理 | 必须有书面回应记录 |
| 参考型任务 | 仅状态变更时 | 工具内通知 | 简版（任务名 + 状态） | 不升级 | 无需回执 |
| 审批/评审任务 | 发起时 + 24 小时未处理再提醒 | IM + 工具内通知 | 任务名 + 审批要点 + 期望结论 | 48 小时未审批升级至发起人 | 审批意见必须填写 |
表格本身只是骨架，真正起作用的是团队是否愿意每周用 15 分钟复盘"哪些提醒有效、哪些无效"。如果只落地模板而不复盘，三周后它仍然会变回一堆被忽略的通知。
八、工具配置建议：不同工具中的提醒规则落地逻辑
1. 自研或国产项目管理平台
以 PingCode 为例，它的提醒配置主要集中在任务级和项目级两个层面。任务级配置适合处理责任人提醒和截止时间提醒，项目级配置适合处理里程碑和跨模块协作。对于 100 人以上、涉及多项目并行的组织，建议先把任务分类字段落到工具里，再基于该字段配置差异化提醒规则，否则会在默认通知里越陷越深。
2. Jira 类国际工具
Jira 的优势在自动化规则灵活性高，可以用 JQL 结合自动化触发提醒。缺点是对中文团队的默认体验一般，规则维护成本偏高。适用于已经深度使用 Atlassian 生态、具备配置管理员资源的团队。
3. 飞书/钉钉/企业微信
这类工具的优势是消息触达快、与日常办公融合度高，适合作为任务提醒的"触达层"。但它们缺少任务结构化管理能力，因此更适合承担提醒送达和升级通知，任务定义和状态跟踪仍应放在专业项目管理平台里。
4. 工具与制度的分工
工具负责"按时按规则送达"，制度负责"定义规则是什么、响应不了怎么办"。先有制度，再配工具，顺序颠倒会导致工具配置越复杂、团队越抗拒。
九、不同场景下的行动建议与取舍
1. 团队规模 10 人以内的小项目
建议优先做话术模板化和任务分类，不需要上复杂工具。每周花 10 分钟对齐一下"哪些提醒被忽略了"，效果已经明显。这个阶段的核心是习惯养成，不是流程建设。
2. 团队规模 10-50 人的中型项目
建议引入专业项目管理工具，把任务分类、提醒触发、升级路径都配置到工具里。这个阶段最容易出现的错误是"工具上线了但制度没有对齐"，结果是工具里的提醒和 IM 里的提醒各说各话，反而增加混乱。
3. 团队规模 50 人以上、多项目并行
建议按"中心制度 + 项目微调"的方式设计。中心制度规定提醒的基本规则和升级路径，各项目在框架内微调参数。这个规模下，没有统一制度几乎必然导致通知泛滥，也最容易触发前述的"失效期"。若有国产替代需求或私有化部署场景，像 PingCode 这类服务中大型组织的平台通常更合适。
4. 什么时候可以简化甚至跳过提醒制度
如果团队规模很小、任务高度连续、成员长期固定协作，那么制度化的必要性的确不高，靠口头同步反而更快。但一旦出现多项目并行、跨部门协作或远程协作，制度就是必要的。
十、总结与下一步行动
任务提醒制度的核心不是"多发几条"，而是让每一条提醒都重新变得可信。可信来自四个方面：触发规则清晰、内容要素完整、升级路径明确、闭环反馈到位。这四件事缺一个，整套制度都会走形。
关于常见问题，最值得记住一条判断：当团队开始抱怨"提醒太多了"时，问题通常不在数量，而在提醒内容里没有明确"需要我做什么"。先把这一点改对，能解决一半以上的失效问题。
如果你想从今天开始动手，建议按下面四步走：
- 今天：翻出最近一周发过的所有提醒，统计一下其中有多少条明确写了"需要接收方做什么"。这个比例通常低于 40%。
- 本周：把本文的任务分类矩阵改成自己项目的版本，先覆盖 3-4 类高频任务。
- 本月：选一个专业项目管理工具（如 PingCode）把规则配置进去，并规定"24 小时未响应自动升级"这条硬规则。
- 每月：做一次提醒有效性复盘，删除无效规则，迭代话术模板。
提醒制度不是一次性工作，而是需要持续维护的"沟通基础设施"。把它当成产品来做，团队就会慢慢重新相信每一条提醒；把它当成一次性的任务清单来做，三周后它一定会变回一堆没人理的通知。
常见问题解答（FAQ）
1. 项目经理任务提醒制度到底该包含哪些模块，才算完整而不是拍脑袋？
我自己带三个项目，团队八个人，之前提醒全靠我记着发，结果漏掉两次关键节点被老板约谈。后来想整理一套制度，但网上搜到的都是“要及时提醒”“要闭环”这种空话，不知道一个完整的制度到底该由哪几个零件拼起来。
一个能跑起来的提醒制度至少要覆盖五个模块，缺一个就会在某类场景下掉链子。第一是触发规则，明确什么类型的任务、在什么时间点、提醒哪些角色，建议用“任务紧急度×责任人角色”做个二维分类，而不是一刀切。
第二是内容模板，一条合格的提醒必须包含任务名、截止时间、交付标准、当前状态、需要对方做什么这五项，少一项就会产生来回追问。第三是通道选择，重要节点和跨部门协作不要只发即时消息，要配合邮件或项目管理工具里的任务指派，IM适合催办、不适合留痕。
第四是升级机制，明确提醒几次无响应后升级给谁，比如责任人一次未回升级到职能经理、两次未回升级到项目发起人。第五是反馈闭环，设计“确认收到，更新状态，关闭任务”三步，没有确认环节的提醒等于没发。你可以先按这五个模块列一张表，把每个模块填上你团队的实际规则，制度雏形就出来了。
2. 任务提醒发得太频繁团队已经麻木了，怎么把提醒的可信度重新拉回来？
我们团队之前是每天早晚各一次站会提醒，加上任务到期自动推送，结果现在大家看到提醒基本不点开，真正紧急的事情反而被淹没。我自己也知道发太多了，但一减少又怕有人真的忘记，这个度到底怎么把握。
核心思路不是减少提醒总量，而是让提醒重新变得“稀有且可预测”。具体做法有三条。第一，做提醒分级，只保留三类会主动推送：24小时内到期且未启动的任务、已逾期任务、依赖关系上别人在等你的任务，其他一律收进每日汇总或看板，不单独打扰。
第二，固定推送时间窗，比如只在上午十点和下午四点两个时段集中发提醒，其他时间不推送，让团队形成预期，知道什么时候该看消息。第三，建立“提醒即承诺”的约定，凡是推送出去的提醒，责任人必须在两小时内给出状态回复，哪怕只是“收到，今晚处理”，这样提醒就带上了责任属性，而不是背景噪音。
判断标准可以看一个指标：如果某个提醒类型连续两周的响应率低于百分之六十，说明它要么频率过高、要么内容不清晰，应该先停掉再重新设计，而不是继续加量。
3. 责任人已读不回，除了反复催还有没有更有效的处理办法？
我在项目群里发任务提醒，消息显示已读但对方就是不回复，私聊也装没看见，催多了显得我像在求他办事，不催又怕耽误节点。我特别想知道这种情况下有什么制度层面的解法，而不是靠我一个个去追。
已读不回的本质不是态度问题，而是“不回复的代价太低”。解法是把提醒从“请求确认”变成“默认确认加异议机制”。具体操作是：在提醒里写明“如无异议，默认你已确认此任务和截止时间，我将按此推进”，并给出一个明确的异议截止时间，比如当天下午五点前。这样对方不回复就视为默认接受，后续追责时有据可依。
同时配合升级机制，同一任务提醒两次无回应后，自动把状态同步给职能经理和项目发起人，不是告状，而是让信息透明。另外要把提醒留痕在项目管理工具或邮件里，而不是只在即时消息里发，IM消息会被淹没，工具里的任务指派和邮件记录才是升级时的证据。
最后一点，项目经理要敢于在周会上公开未响应任务清单，公开本身就是一种低成本高效果的约束。
4. 跨部门协作的任务提醒总是推不动，制度上应该怎么设计才不靠人情？
我是项目经理，但对接的研发、测试、运营都不归我管，发提醒过去经常被当成“帮个忙”，催急了对方直接说这不是他的KPI。我想知道在制度层面怎么设计，才能让跨部门提醒有约束力，而不是每次都靠刷脸。
跨部门提醒推不动的根因是“权责不对等”，项目经理有协调责任但没有考核权。制度设计上要做三件事。第一，把跨部门任务写进项目章程或立项文件，明确交付物、责任部门、对接人和时间节点，并且让双方部门负责人在上面签字，这一步是把口头协作变成书面承诺。
第二，提醒抄送机制要固定化，跨部门任务提醒默认抄送对方职能经理和项目发起人，不是每次临时决定抄给谁，而是制度规定必须抄送，这样对方知道不处理会被上级看到。第三，设计升级路径，跨部门任务逾期超过约定天数后，由项目经理提交风险清单给项目发起人，由发起人在跨部门例会上推动，而不是项目经理自己去硬扛。
判断制度是否有效的标准很简单：如果一件事只有你亲自去催才动，说明制度没建立起来；如果按流程走对方就会响应，才说明制度真正生效了。
核心关键词
文章包含AI辅助创作：消息通知最佳实践：项目经理任务提醒制度设计，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/440872
读者评论
提醒发得多确实容易变成背景音，我们团队也经历过类似阶段，后来改成只有阻塞任务才发即时提醒，响应率明显回升。
漏斗图里真正推动状态变更只有15%这个数据太扎心了，说明大部分提醒其实是在制造噪音，不是推动执行。
五要素模板很实用，尤其是‘当前状态’和‘所需动作’两点，以前我们提醒只写截止时间，接收方还得自己翻记录确认。
升级机制那段最有共鸣，没有升级路径的项目经理就是人肉兜底，最后所有事都压在自己身上，累死也推不动。
通道选择总结得挺准，IM催日常、邮件留里程碑、电话处理阻塞，混着用反而让人分不清轻重，最后全部忽略。