如何对软件系统做技术规划

1. 前言

本文整理了我对软件系统技术规划的一些理解。

本文写于 2024 年，记录的是当时的一些思考；迁移到本站时仅对部分表述作了轻微调整。

2. 我对软件系统技术规划的理解

软件系统技术规划，顾名思义，就是从技术视角对软件系统的未来演进作出规划。可以从三个部分理解：

1. 软件系统
2. 技术视角
3. 规划

2.1. 软件系统

从桌面软件、Web 应用和移动应用，到单个服务、模块、组件或工具，都可以视为不同规模的软件系统。

软件系统通常都存在继续规划的空间。一方面，现实中的系统很难始终保持理想状态，总会积累功能、架构、性能、稳定性或成本方面的问题；另一方面，即使系统当前运行良好，也需要结合业务变化和技术发展，判断未来是否需要演进。

2.2. 技术视角

技术视角是相对于业务视角而言的，但两者并不能割裂。业务发展决定技术能力需要解决什么问题，技术能力也会影响业务能够以怎样的效率和成本发展。因此，技术规划虽然以技术问题为主要对象，但不能脱离业务目标和实际约束。

2.3. 规划

根据百度百科对“规划”的解释，规划关注未来一段时间内整体性、长期性和基本性问题，并据此设计行动方案。

按我的理解，技术规划主要包含两个方面：

1. 规划是一套方案
2. 规划也是一项计划

2.3.1. 规划是一套方案

方案用于解决问题，因此首先需要明确问题是什么，然后给出具体的解决思路、实施步骤和取舍依据。

技术规划所关注的通常不是一两个孤立的缺陷，而是对系统未来影响较大的基础性问题。好的规划需要从局部问题上升到整体视角，分析问题之间的关系，避免各自为战的局部优化。

2.3.2. 规划也是一项计划

2.3.2.1. 规划面向未来

规划主要面向未来，但对未来的判断必须建立在对现状和历史演进的理解之上。只有充分了解系统当前的能力、问题和约束，才有可能提出合理的演进方向。

2.3.2.2. 规划具有一定的时间跨度

技术规划需要覆盖多长时间并没有统一答案。实践中可以将未来 3 至 12 个月作为一个参考范围，但具体周期仍取决于业务变化速度、系统复杂度、团队资源和不确定性。周期太短容易退化为需求排期，周期太长则可能因为前提变化而失去可执行性。

2.3.2.3. 规划需要落地

规划不能停留在方向描述上，还需要形成优先级、阶段目标和执行计划，并在实施过程中根据实际反馈持续调整。

2.4. 小结

1. 不同规模的软件系统都可以进行技术规划
2. 技术规划不能脱离业务目标和现实约束
3. 规划既是解决问题的方案，也是面向未来的执行计划
4. 一个基本过程可以概括为：
   1. 梳理历史和现状
   2. 结合目标提出未来的理想状态
   3. 识别现状与理想状态之间的关键差距
   4. 针对关键问题设计并选择解决方案
   5. 制定计划并推动落地

3. 为什么要做技术规划

规划的主要价值是建立目标和方向，使有限的资源能够投入到更重要的问题上。

对软件系统而言，技术规划可以帮助团队从持续出现的局部需求和故障中抽离出来，识别影响长期发展的关键问题，并提前安排必要的治理和建设工作。对工程师而言，参与技术规划也有助于形成系统性思考能力：不仅解决眼前的问题，还需要理解问题产生的背景、相互关系和长期影响。

4. 如何对软件系统做技术规划

4.1. 收集资料

资料收集贯穿技术规划的全过程。常见资料包括代码、历史规划、技术方案、接入文档、故障记录、监控数据、用户反馈和业务计划等。输入是否充分，会直接影响后续判断的质量。

4.2. 梳理现状

可以从两个方面梳理系统现状：

1. 业务功能
2. 技术架构

4.2.1. 业务功能

可以从用户和接入方视角实际体验系统，了解系统服务哪些角色、解决哪些问题、包含哪些主要流程，并形成必要的功能或接入说明。

4.2.2. 技术架构

在体验系统的同时，可以通过抓包、日志、监控和代码分析等方式梳理系统架构与核心链路。根据系统复杂度，可以整理分层架构图、核心链路图或其他能够准确表达现状的材料。

4.3. 提出未来的理想状态

判断系统未来形态时，可以结合归纳和演绎两种方式。

4.3.1. 归纳

通过调研内部或外部的同类系统，总结其中已经得到验证的实践，再结合自身系统的目标和约束，判断哪些能力值得借鉴。

4.3.2. 演绎

当同类系统缺少可直接参考的做法时，可以回到系统的服务对象、核心价值和业务目标，从这些前提出发推导未来需要具备的能力。

无论采用哪种方式，理想状态都不应只是架构形式上的追求，还需要说明它要解决的问题，以及可以观察或衡量的结果。

4.4. 识别问题

问题可以理解为现状与目标之间的差距。在现状和理想状态相对清楚之后，可以从以下方面进行分析：

1. 技术架构
2. 接入与研发效率
3. 性能
4. 稳定性
5. 成本
6. 安全与合规
7. 其他影响目标实现的约束

问题不宜只按数量罗列，还需要结合影响范围、紧迫程度、解决成本和依赖关系确定优先级。

4.5. 设计解决方案

针对关键问题，应尽可能比较多个可行方案，说明各自的收益、成本、风险和适用条件，再基于目标与约束作出选择。方案数量不必机械地追求某个数字，重点是避免在缺少比较的情况下过早确定结论。

方案的表达形式也应服务于沟通和决策。对于复杂系统，可以使用分层架构图和核心链路图；对于较简单的问题，清晰的文字、接口说明或数据对比可能已经足够。

4.6. 排期落地

方案确定后，需要拆分任务并明确优先级、负责人、阶段目标和验收标准。对于风险较高的改造，还应考虑灰度、监控和回滚方式。

技术规划不是一次性文档。执行过程中需要持续检查关键前提是否发生变化，并根据实施结果调整后续计划。