合作与交付

已有软件要改造，先准备什么？

从当前问题、可用源码与接口、数据和回退条件开始，先判断怎样改，再安排功能扩展。

描述具体变化，而不是只说不好用

改造软件时，先说明现在怎样操作、哪里不方便，以及希望操作后得到什么结果。例如找一笔订单要来回打开多个页面，或同样的信息需要重复填写。提供一个可脱敏的例子，比只说“优化系统”更容易确定工作范围。

把新增功能、界面调整、数据连接和故障排查分开列出。它们可能同时出现，但检查方法不同。故障还应说明出现条件、预期行为与实际表现，避免在没有证据时直接把问题归因于某个组件。

评估改造需要了解系统版本、部署方式、可用源码、接口文档和维护限制。能登录业务后台，并不代表有修改程序或访问接口的权限。缺少源码时，也应先判断有没有官方接口或可用扩展方式，不能默认所有软件都能直接修改。

初次沟通可以提供页面说明、脱敏截图和问题描述。账户、代码和数据访问在明确范围后按需授权。涉及第三方服务时，确认权限、测试环境和调用规则，再决定采用直接修改、接口连接或另建辅助模块。

旧系统通常承载正在进行的业务，改造前要列出不能中断的流程、需要保留的数据，以及可安排的变更时间。数据字段调整和迁移需要样本核对；备份也应验证能否恢复，不仅仅确认文件已经生成。

将修改先放到约定的测试环境，用典型记录走一遍新增功能和受影响的原有功能。若业务权限、状态或接口发生变化，相关流程都需要复测，同时准备出现问题时怎样回到原版本和数据状态。

可以先验证一个关键接口或小功能，再确认完整改造范围。每阶段记录修改内容、依赖和检查结果，客户能看到改善是否达到目标。发现新的历史问题时单独评估，不把整个旧系统的所有问题混入同一次修改。

交付时说明版本、配置、部署或安装步骤，以及需要继续观察的事项。改造后的维护方式也提前约定，让后续负责人员知道什么发生了变化、数据如何处理、遇到异常该从哪里检查。

从你的目标开始

说明谁会使用、想完成什么，以及已有的资料或系统。范围、时间和费用在后续沟通中确认。