新开发团队能接手并完成现有的定制软件吗？

如果新团队能查清已经实现的功能、获得所需的授权访问，并说明如何完成一项关键任务，就有可能把软件做完。先安排一次小范围评估。看起来已经完成的页面，可能还不能保存结果；拿到了代码，也可能缺少运行所需的说明或服务。

如果员工已在使用现有版本，先明确评估期间由谁维持它运行。现在如何保障业务运转，与将来要不要换系统，可以分开决定。

有哪些东西能交给新团队？

找出上次实际使用或测试的源码版本，并收齐构建所需的说明和依赖。弄清谁管理发布软件和连接外部服务所用的账号、业务记录和备份存在哪里、现有协议允许共享或修改什么。能打开代码库，并不代表具备这些权限。

把这些问题分开核对。团队可能能运行副本，却无法更新线上版本；也可能有托管账号的访问权限，却无法用移交的材料重新构建软件。如果需要迁移记录，可以另做一次试导出，确认新系统能用这些数据。

应请接手的团队演示什么？

选一项对业务重要的任务。假设服务协调员用一个尚未完成的工具处理申请：员工已经能提交申请，但没人演示过主管能否审批并在之后查到决定。请新团队在独立且获授权的测试环境中构建一个已知版本，尝试走完这项任务。使用虚构记录，关闭真实通知、付款和其他线上操作，测试不要碰正在运行的系统。

看申请能走到哪一步，再记下它停在哪里。如果主管能审批，但重新打开申请后决定不见了，就有一个具体问题可查。如果缺少依赖导致软件根本无法启动，应记录该流程尚未得到验证，并写清缺的是什么。这与已经确认审批环节出错，意味着不同的下一步。

构建成功只能说明团队在当时的条件下构建了那个版本。它不能证明整个系统安全或便于维护，也不代表团队有发布权限或已能负责线上运行。谷歌对移交运营责任的说明说明了为何要把运营接手另作决定：评审会检查依赖和运行准备情况，并在必要时安排培训和改进。

是继续做、局部修复，还是替换？

用同一项业务任务比较不同方案，也比较以后维护各方案需要的工作。英国政府的采购指南提供了一个例子：结合需要、成本和运行能力，比较改造现有软件与重新开发。

如果决定替换，另行安排当前工作如何继续。让两套系统并行一段时间只是过渡方案之一，有自己的成本，也需要明确由谁负责记录。

评估报告应写清什么？

请团队整理一份简短记录，与你和实际使用软件的人一起核对。写明演示了什么、什么失败或尚未测试、缺少哪些访问权限或授权，以及什么可能打断当前工作。对每项可行方案，写清下一阶段、由谁推进以及追加投入前要检查什么。

以上述申请工具为例，下一阶段可以先查清已记录的审批结果为何消失，再在测试系统里演示主管能返回并查看原来的决定。如果正在比较接手团队，可参考选择定制软件开发团队前该问什么。

接手未完工软件的常见问题