项目延期后，先修正任务系统

案例声明：这是为展示方法而编写的合成案例，不是真实用户评价，也不代表使用 Todos 后的效果。目标人群为同时交付客户项目和自有产品的自由职业者。内容负责人 Adrian Stark；依据为 Todos 当前任务、截止日期、优先级和完成状态的人工演练；审核日期 2026-08-28。

演示场景：上线任务连续延期两周

一位自由职业者计划周五上线作品集改版。清单有 17 条任务，其中 9 条写成“完善首页”“优化案例”这类无法判断结束的标题，6 条已经逾期；他同时承诺了两个客户交付，却仍按一整周空闲时间排期。

第一步：只看事实，不写性格评价

• 原计划容量：5 个工作日；实际可用容量：约 2 个工作日。
• 9 条任务没有单一交付物，开始前仍需继续决策。
• “等客户确认文案”没有独立标记，隐藏依赖阻塞了 3 条后续任务。

这些事实可以被任务数据或日历验证；“我执行力差”不能直接告诉你下一步该改什么。

第二步：给每个根因一个修正动作

1. 容量失真：下一周只按可用时间的 70% 排任务，保留突发客户需求空间。
2. 任务过大：把“完善首页”改为“确定首屏一句定位”和“发布 3 个项目截图”。
3. 依赖隐藏：把“催客户确认文案”设为高优先级，并将被阻塞的制作任务移出本周。
4. 验收不清：把上线结束条件写为“手机与桌面均可打开 3 个案例页面”。

第三步：删除，而不是把所有逾期任务顺延

逐条问：“它是否仍然服务于本周唯一结果？”答案为否就删除或移到“以后”。案例中保留首屏定位、3 个案例截图、移动端检查和部署四项；动画、博客迁移与多语言不进入本轮。

第四步：一周后只复核两个数字

复核“本周承诺任务数”和“按时完成数”，再记录一个最主要阻塞原因。样本还很少时，不需要复杂仪表盘；连续四周记录后，才有足够依据调整容量。