技术方案模板

转自：https://www.cnblogs.com/fn-f/p/13727241.html

做开发，写技术方案肯定不会少，但是通常一个公司一份模板，有点头疼，而且，部门模板对于一些必要点的梳理也并非十分清晰，因此写一份技术方案模板，用以方案前期评审时讨论及扩展，可以做参考哈，但是具体的还是以自身实际需求为准。

 

XXX技术方案

时间：xxxx-xx-xx       编写人：fn-f

- 需求背景

    PRD： 产品需求链接

    简述PRD产生的背景，1. 产品业务需求、2. 技术优化扩展、3. 痛点，缺陷，不足等问题点

- 需求目标

    分产品线、业务线、扩展性等方面，分析本次需求发布之后的涉及影响点

- 需求F&Q

    需求中疑问点记录及对原有逻辑的冲突问题、时间安排问题等等 

- 需求细分

    图示本需求涉及的功能点，将其拆解细化至团队或个人

- 技术方案

    1. 方案一(主)

       方案撰写：思路、流程图(时序图，标明涉及系统以及系统调用链、上下游依赖接口等梳理)、模型设计(表之间关联图)、架构设计(需求涉及的整个系统架构影响点)、涉及技术栈(技术关键点check)、接口幂等并发等处理、接口涉及大数据量预估处理、兼容处理(现有功能兼容及影响业务范围)、优缺点对比、接口文档(http、rpc) 等等... ... 

    2. 方案二(备) (小的改动点可省略备份方案)

        参考方案一，最后特别指出两者之间的优缺点、对比、扩展、兼容等方面

- 关键测试点

   针对需求，产品、测试、开发共同关注的测试点，包含以往逻辑交互的兼容、本期新增功能的测试关键点

- 人员估期

   需求的产品、PM、前端、客户端、服务端、测试等相关人员

   可以甘特图标识人员开发及介入时间安排，标明 deadLine

- 发布计划

   整理正式发布的checkList，多系统间发布顺序、配置变更、数据库变更、数据初始化、技术点增加、发布时间点等等... ...

 

注：能使用图示的尽量以图展现，能更加清楚明确，而且逻辑性对于涉及开发的人员更加清晰，改定点也可以cover住，可以实时针对其进行讨论

--------------------------------------------   迷人的分割线   ----------------------------------------

 

商品审核及交易账务对接技术方案

时间：xxxx-xx-xx       编写人：fn-f

- 需求背景

    PRD： 产品需求链接

    简述PRD产生的背景，1. 产品业务需求、2. 技术优化扩展、3. 痛点，缺陷，不足等问题点

- 需求目标

    分产品线、业务线、扩展性等方面，分析本次需求发布之后的涉及影响点

    商品：1. 完成商品审核对接流程【业务】

             2. 商品对外提供类抽离【技术】

    财务：1. XXXXXXXXXXXXXXX【业务】

- 需求F&Q

    需求中疑问点记录及对原有逻辑的冲突问题、时间安排问题等等 

    1. 本次涉及交易人员需求冲突，需产品与PM确认该功能点是否本期处理？

       -- 产品：与下期迭代一同上线

    2. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX？

- 需求细分

    图示本需求涉及的功能点，将其拆解细化至团队或个人【下图是xmind画的】

     

- 技术方案

    1. 方案一(主)

       方案撰写：思路、流程图(时序图，标明涉及系统以及系统调用链、上下游依赖接口等梳理)、模型设计(表之间关联图)、架构设计(需求涉及的整个系统架构影响点)、涉及技术栈(技术关键点check)、接口幂等并发等处理、接口涉及大数据量预估处理、兼容处理(现有功能兼容及影响业务范围)、优缺点对比、接口文档(http、rpc) 等等... ... 

    时序图：

      

     表结构设计： 

       

     架构设计： 

        

     涉及技术栈： 

           

     原有逻辑兼容： 

        暂无

     接口文档：

        1. api：/trade/third/xxx/xxx/xx【交易三方xxxx接口】
           param:  userId        number        用户ID
                       itemId       number        商品ID
           result： {"tag":"trade_success","msg":"成功","data":{"id":109723,"xx":"xxxxxxxxx","xxxxx":"xxxxxxxxxxxx"}}

        2. dubbo： com.xxxxx.xxxx.........XxxxClient # queryTradeXxxxxxInfo
            依赖包：<dependency>
                          <artifactId>hutool-all</artifactId>
                          <groupId>cn.hutool</groupId>
                          <version>5.3.2</version> 
                       </dependency>
            param:  userId        number        用户ID
                       itemId       number        商品ID
            result： {"tag":"trade_success","msg":"成功","data":{"id":109723,"xx":"xxxxxxxxx","xxxxx":"xxxxxxxxxxxx"}}

         3. .......other.........

 

    2. 方案二(备) (小的改动点可省略备份方案)

        参考方案一，最后特别指出两者之间的优缺点、对比、扩展、兼容等方面

- 关键测试点

   针对需求，产品、测试、开发共同关注的测试点，包含以往逻辑交互的兼容、本期新增功能的测试关键点

- 人员估期

   需求的产品、PM、前端、客户端、服务端、测试等相关人员

   可以甘特图标识人员开发及介入时间安排，标明 deadLine

   

- 发布计划

   整理正式发布的checkList，多系统间发布顺序、配置变更、数据库变更、数据初始化、技术点增加、发布时间点等等... ...

   配置项：

   表涉及：

   新增技术点：

   ------------------：