题目重点：按交付依赖和个人能力分配 owner，用可验收里程碑与风险缓冲管理时间，发现延迟时及时调整。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 回答基于真实项目的实际授权：不论是否是正式经理，都需说明自己能决定什么、哪些由经理/团队协商。
- 期限不是单个日期，而与依赖、风险和验收标准相连；外部承诺/法规截止需与内部目标区分。
- 任务分工不能只按‘谁快给谁’，应考虑能力、负载、成长和关键路径风险。
解题路线
- 先明确交付物、用户验收与约束，把工作拆成可独立交付的垂直切片，画出依赖与关键路径。
- 和成员核对意愿、技能、现有负载，为每块指定一个 DRI/owner 和备援；高风险边界可以安排 pair/review。把自己也纳入负载，不把协调工作视为零成本。
- 期限用估算范围、集成/测试缓冲和外部依赖确定阶段性里程碑。若信息不全，标出假设和可重新估算日期，而不制造虚假的精确承诺。
- 每周/关键节点用可见工件检查进度：接口、测试、示例、风险清单。落后时先查阻塞与范围，调整顺序、增援或提前通知相关方；不能只加班逼团队‘赶上’。
- 复盘交付质量、团队体验与后续维护，承认一项自己分工或期限判断的偏差。
手动走一遍
虚构训练例三人项目中，API contract 是前置依赖，A 负责 contract 和后端，B 负责客户端适配，C 负责回归/发布；你负责跨组决策和风险。第 1 周验收 mock API，第 2 周端到端，第 3 周灰度并留两天缓冲。若 contract 延迟，不等到发布前才告知客户，而先缩范围并给替代里程碑。
规模与取舍
非算法题。主答需明确目标、分工理由、依赖、里程碑、一次变更和结果；单说‘我把任务分给适合的人’缺少判断过程。
易错点与追问
容易失分的边界
- 只按每个人速度分配，忽略关键人员瓶颈和成长。
- deadline 没有估算/风险依据。
- 延期时最后一天才升级，给上下游零缓冲。
- 把所有团队成果据为己有。
继续深挖
- 两个人都想做关键任务，如何决定 owner？
- 进度已落后但你没有改 deadline 权限，怎么办？
- 技术债/测试与新功能争资源时怎样分配？
