开发者离开后，谁真正掌握您的业务应用？

设想，开发采购审批应用的员工提出离职。应用很好用，大家都依赖它。接替者能打开应用，交接看起来很简单。

接着有人问：供应商文件放在哪里？审批邮件由谁的账号发送？谁能修改采购金额门槛？答案都指向即将离开的那个人。

这是一个示例情境，但这种依赖确实存在，微软甚至为此编写了专门文档。应用可能被广泛使用，维护能力却仍集中在一个账号里。对于委托开发的企业主，最好趁原开发者还在时处理这个问题。

有用的应用，需要经得起人员变化的交接。示意照片：Alex Tyson / Unsplash。

开发越快，越容易忽略长期责任

微软 9 月 17 日的 Power Platform 更新增加了六个画布应用屏幕模板，以及 Power Automate 快速入门卡片。这些功能让有用的工作更容易起步。运营团队确实应该能为反复出现的问题开发合适工具，而不必把每个需求都变成大型软件项目。

采购决定仍需考虑上线之后。更快的开发不会自动说明谁接收失败告警、谁能更新连接，或谁有权发布修复。这些职责需要明确归属。

定制网站应用也一样。代码仓库在承包商的个人账号中，部署只能从他的笔记本完成，也会造成类似的交接问题。

所有者字段只说明了一部分

“我们拥有这个应用”里隐藏着几个不同问题：谁决定业务流程？谁能编辑和发布软件？哪些账号能访问数据？出故障时谁来处理？

微软的画布应用共享指南指出，应用还依赖数据源权限，以及可能涉及的流程、网关和连接。让某人能够打开界面，并不意味着他能访问背后的全部资源。

在假设的采购应用中，供应商列表、审批流程、发件邮箱和已发布应用可能各有不同权限。接替者或许能提交申请，却没有修复邮件步骤的权限。一次成功登录发现不了这个缺口。

先画一个简洁的流程图。从请求进入到结束，记录经过哪些系统。在每个系统旁写明负责人或团队、使用的账号，以及获授权的接替者如何取得访问权。文档只记录凭据在获批密码管理器中的位置，不要写入密码。

共同所有者有帮助，但还要检查连接

微软将孤立流程定义为没有有效所有者的流程，并提醒：如果连接依赖离职者的账号，流程可能失败。文档提供了管理员恢复路径。这说明需要规划移交，并不意味着每次离职都会立即导致每个应用停摆。

移交方式还取决于具体实现。微软的云流程所有权指南允许修改解决方案感知流程的所有者；非解决方案流程不能原地修改所有者。可用方案取决于环境是否有 Dataverse，可能需要将流程移入解决方案，或创建替代流程。

购买一个小型内部工具，不需要先成为 Power Platform 管理员，但供应商或内部团队必须识别正确的移交路径。要检查新所有者的许可证和连接权限，不能只改所有者姓名就算结束。

长期保留离职员工登录，不能替代受支持的所有权安排。在平台允许时，采用适当的组织身份，配置必要权限与许可证。不要把共享密码当作业务连续性计划。

把可用的交接写进范围

交接不一定要写成长篇手册。对于规模适中的应用，一份简短并持续维护的记录就可以回答关键问题：

• 用途与业务负责人：应用做什么，谁批准变更，哪些步骤仍靠人工。
• 位置与访问：公司控制的环境或代码仓库、部署目的地、数据源，以及各自的管理员。
• 账号与续费：所依赖的连接、订阅和凭据，谁维护，续费及失败通知发往哪里。
• 变更与恢复：如何把小修正发布到生产，如何恢复前一个正常版本，哪些数据需要单独保护。
• 支持责任：谁处理事故，维护协议覆盖什么，下一位维护者如何拿到最新文档。

开工前就约定这些内容。如果正在接手现有应用，也应在增加功能前收集同样的信息。原开发者还能解释选择时，缺失的责任信息更容易补齐。

让下一位维护者做一次普通工作

请接替者用自己的授权账号，在测试环境做一次无害修改。他应该能找到项目、解释相关连接、完成修改，并按照文档发布。原开发者可以旁观答疑；发现的每个缺失步骤都用来修正交接资料。

演练应与系统规模相称。简单审批应用不需要国家级支付平台的运营模式，但必须有现实可行的接手办法。账号变更应由管理员配合正常离职流程安排，不要通过关闭真实员工的生产权限来试验。

如果演练暴露几个权限或文档缺口，就修复这些缺口，并不自动意味着需要重建应用。Rosecraft 的技术评估可以帮助明确接手系统的需要，再决定是否投入进一步开发。

交接的终点，是下一位负责人能真正完成工作。请在项目中为此留出空间。