交付团队
没人能执行的建议只是一份文档。这里是 SofinWave 负责执行的部分：由工程师去构建我们所建议的系统，并且采用能把责任放在你希望位置上的那种形态。这里有两种形态——由我们对结果负责，或由你负责而我们配备人手——在两者之间做选择，看的不是资历或价格，而是当进度延误时，你希望由谁来回答。
托管交付——由我们对结果负责
我们接下一个明确的目标，配齐所需岗位，运行我们自己的流程，并对交付上线负责。你得到的是可以验证的进度，而不是被转述的进度。
- 一位技术负责人，对架构与代码质量负责。
- 按项目范围而非模板配备的后端、前端与移动端工程师。
- QA 从一开始就在团队内部，而不是上线前才挂上去。
- 一位交付负责人掌控节奏，并作为你唯一的对接人。
专属团队——由你对结果负责
长期指派给你的工程师，在你的流程里工作，而不是在我们的流程里。他们参加你的站会，从你的待办列表领任务，由你的技术负责人评审。你获得了内部员工般的连续性，却不必承担招聘周期。
- 岗位由你定义，候选人入职前由你面试。
- 工程师在你的仓库、你的任务系统、你的例会中工作。
- 由你的工程经理设定优先级并评审工作成果。
- 合同、薪酬、硬件，以及有人离职时的补位，都由我们处理。
如何在两种形态之间选择
真正重要的区别是：出问题时由谁担责。其余的一切——费率、资历、团队规模——都是从这个答案推导出来的，而不是反过来决定它。
| 托管交付 | 专属团队 | 人力扩充 | |
|---|---|---|---|
| 由谁管理工作 | 我们 | 你的管理者 | 你的管理者 |
| 由谁对结果负责 | 我们 | 你 | 你 |
| 典型周期 | 与项目等长 | 六个月以上 | 数周到数月 |
| 最适合的情况 | 你需要有人对交付担责 | 你需要长期稳定的额外产能 | 你眼下需要某项特定技能 |
| 启动成本 | 较高，包含需求梳理 | 中等，一次性投入 | 低 |
常见问题
- 我们怎么跟踪进度？
- 靠每个迭代结束时可运行的软件，加上对代码仓库与任务系统的直接访问权。如果进度报告是进度的唯一证据，那说明哪里出问题了。
- 我们可以面试这些工程师吗？
- 专属团队可以，而且应该面试——岗位由你定义，我们筛选名单，由你面试并决定。托管交付则由我们自己配置人员，因为对结果负责的是我们。
- 如果有工程师离职会怎样？
- 我们负责补位，并安排重叠期，让上下文得以转移而不是蒸发。留人的成本由我们承担，不由你承担。
- 中途可以更换形态吗？
- 可以，而且很常见。合作往往在方向尚不确定时以托管交付起步，等你自己的负责人能够掌舵之后再转为专属团队。更换形态属于合同变更，不需要推倒重来。
- 如果我们之后想把工作收回内部呢？
- 这是很正常的结果，合作本来就是照着这个前提设计的。文档与测试贯穿全过程，交接条款在一开始就谈妥，而不是等到有压力时再谈。