误报复盘：“下周要三名开发”为什么还不是技术外包项目 Brief

重点监测信号

• 业务结果和技术范围可以描述
• 内部负责人、现有团队和依赖明确
• 交付物、验收和时间可以拆分
• 权限、安全、合同和关系需要确认

直接结论

“下周需要三名开发”只描述人数和时间，不是项目 Brief。可执行外包需要业务目标、技术范围、现有系统、团队关系、交付和验收、权限与数据、安全、预算负责人以及合适的合同和用工边界。

原判断

原判断是：对方急需三名开发并给出开始日期，因此属于高意向外包项目，应立即提交人员简历。

实际问题

对方没有明确项目和交付物，只希望人员长期按内部经理安排工作。技术栈、权限、验收、预算和当地关系认定都未知，更接近未完成的人员需求。

误判原因

1. 把人数和紧急程度当成项目范围
2. 没有确认业务目标和交付物
3. 忽略人员由谁管理和如何评价
4. 没有盘点代码、数据和系统权限
5. 没有区分项目承包、派遣和实际雇佣关系

缺少的证据

• 业务目标与产品负责人
• 代码库、架构和技术债
• 任务、里程碑与验收标准
• 工作地点、管理和合同关系
• 预算、付款、安全和知识产权

修正后的规则

只有当需求能以业务结果、范围、负责人、交付物、验收、权限和时间表达，并且合同与工作关系得到适当确认时，才升级为技术外包项目 Brief。

修改后的处理流程

1. 先问业务目标与不可移动日期
2. 盘点现有系统、代码和依赖
3. 把人员请求改写成工作包与交付物
4. 明确内部负责人、沟通和验收
5. 确认权限、安全、知识产权与合同关系

复盘问题

1. 项目要解决什么业务问题？
2. 三名开发分别负责什么工作包？
3. 现有系统和依赖是什么？
4. 谁管理日常工作并批准交付？
5. 需要访问哪些代码和数据？
6. 合同、付款和关系由谁确认？

可复用结论

• 人数与紧急程度不是项目范围。
• 工作包比简历列表更重要。
• 验收责任必须在开始前确定。
• 最小权限适用于外包团队。
• 项目合同不能掩盖实际工作关系。

相关内容：远程承包商入职清单、AI招聘微案例。本文复盘用于改进判断规则，不声称真实客户结果。

常见问题

原判断为什么会误报？

对方没有明确项目和交付物，只希望人员长期按内部经理安排工作。技术栈、权限、验收、预算和当地关系认定都未知，更接近未完成的人员需求。

修正后的规则是什么？

只有当需求能以业务结果、范围、负责人、交付物、验收、权限和时间表达，并且合同与工作关系得到适当确认时，才升级为技术外包项目 Brief。

第一次复盘应该问什么？

项目要解决什么业务问题？；三名开发分别负责什么工作包？；现有系统和依赖是什么？

资料来源与延伸阅读

1. AWS：详细应用评估
2. 国际劳工组织：雇佣关系建议书（第198号）