日常项目技术方案脉络

开篇引砖

软件在其生命周期中，当其进入稳定期后，大部分时间都处于迭代更新维护阶段。在这漫长的三年甚至五年的存活期内，我们需要面对林林种种大大小小的需求。今天我们就聊聊在这段期间，如何快速产出一份合格的技术方案。

方案给谁看?

1、产品经理，从方案中确认系统功能是否可以覆盖产品需求，以及系统间交互是否符合前期讨论结果。

2、开发人员，通过方案，对系统改动有明确的全景影像，对具体的改动点能从中获取详细的实施方案以及明确的注意事项提醒，尽可能减少实施过程中出现方案较大的变动。

3、测试人员，通过方案了解本次系统改动点，明确测试所需覆盖面，从而产生相应的测试用例，后续再反向与开发人员确认测试用例的合理性、可行性以及全面性。

4、新进者或接盘侠，从文档中企图窥探系统演变过程。

技术方案脉络

日常项目周期基本为两周（开发->测试->发布上线），其中技术方案设计基本上必须在一到两天内完成，在这两天内需要完成的工作包括但不限于，产品方案疑难点二次沟通-->相关系统流程梳理确认-->技术方案输出落地-->技术方案评审等等。在这种技术时间极度压缩的情况下，我们常把软件工程学里面提及的概要设计和详细设计做有机结合，力求通过一份方案，既能让产品经理读懂，又能让测试产出测试用例，同时开发人员也可以根据方案快速开展系统改造工作。

为了满足以上诉求，我们必须让技术方案拥有清晰的脉络，一份合格的技术方案，我认为应包含以下几个不可或缺的内容，包括方案的背景及目标、系统数据流交互概述、系统功能改造点描述、数据库变更详细描述、前端接口交互文档、以及开发工作分工等等。下面我们逐一探讨下各个模块应该输出怎样的内容。

1、方案背景

技术方案的背景及目标应来自于产品需求，但有别于PRD的业务需求背景及目标，需要清晰的描述产品需求达成的技术路径及方法，另外，可以预估产出一些可量化的指标，类似运营操作效率可提升30%等等。

2、系统数据流交互概述

完成了方案背景的阐述，接着为读者奉上一张系统交互全景图会是是一个很好的选择，让读者能从上帝的视角对技术方案有个全面的认知。我们可以选择跨职能流程图为载体，通过图例清晰描述需求参与方（系统及组件）及其所涉及的功能点。另外通过流程交互图，也可以让业务数据的流转清晰可见。系统流程交互全景可参考下图表述：

3、系统功能改造点详述

完成了整体的概述，接下来我们就需要对各个开发功能点做详尽的描述。如何清晰的描述各个功能点，我个人觉得可以通过三个方面的内容表述，包括关于需求点的描述、涉及改动域、改动点详述（清晰描述涉及变更接口以及变动点）。如下图所示，图中所含内容应该已可以支持进入实际开发工作。

4、数据库变更详细描述

该部分应该详细记录数据库变更的内容，包括但不限于DML、DDL相关脚本。该部分内容在日常工作中，常常成为设计评审中重点评审的内容，各位评审官常纠结于库表及其字段的命名而欲罢不能。所以极尽可能的深入考虑以及详细描述，将极大可能的有助于技术方案评审工作的顺利进行。

5、前端接口交互文档

目前普遍采用前后端分离合作模式，详尽的前端接口文档，除了有助于前端提前介入开发外，更重要的是能让前后端双方开发人员更早的达成共识，更大的促进项目的推进。

交互文档可提供如下示例相关内容，包含了具体的接口入参及返回报文的详细描述，报文中所涉及字段必须清晰标注含义。

6、开发工作分工

该部分内容用于项目进度管理，需要详细列出各项分工、工作描述、相应负责人以及项目阶段标识。可参考如下示例：

总结

全文建议一份合格的技术方案，应该包含六个方面的内容：方案的背景及目标、系统数据流交互概述、系统功能改造点描述、数据库变更详细描述、前端接口交互文档、以及开发工作分。那这样子的方案是否能成为日常合格的技术方案呢？我们可以顺着方案的脉络纵向横向分别切割分析。整个技术方案所包含的内容，纵向采用总分的方式让参与者从面（整体的系统数据流交互）到点（各个功能点改动），逐步深入理解整个技术开发实施方案。同时，横向既按参与者维度清晰划分了各个参与方的工作点，不限于前后端开发人员，也从技术栈维度出发，列出各个技术点所需变更内容。个人觉得应值得各位参考尝试。

后记

在软件的完整生命周期内，每一次迭代都会产生相应的技术方案，这些方案很有可能是需求前后关联相互影响，如何让这些迭代能有序的完整记录下来，形成有序的历史脉络，目前仍未找到较好的办法。

by：江