跳到主要内容

需求技术方案模版

1. 项目概要​

1.1 背景​

1.2 项目目标​

1.3 相关调研资料​

1.4 项目资料​

1.4.1 项目相关​

包括人员，prd，设计稿，自测用例链接，排期

1.4.2 工程相关​

涉及到的页面和对应 PR

2. 详细设计​

2.1 核心业务流程​

按模块/产品图/功能描述/实现方案列举

2.2 业务埋点​

3. 工时评估​

4. 影响范围评估​

5. 技术方案目录​

更新版本更新日期更新说明更新人版本颜色确认周知
1.02024.4.5初稿@xxx

补充​

技术方案要简短&多细节 功能点描述里考虑到哪些边界情况，也要列举一下，不然无论有没有考虑过都很难看出来

多个维度的相似功能视具体情况可以做成多页面，而不是单页面 关于技术方案，继续补充 原则是开发者拿着技术方案，无需 prd 就可以实现需要的功能

•重点一是注意结构化，功能点/描述 e.g. 页面背景-可关闭 前者说明功能在哪，让人能找到；后者是尽量简短但是有细节的描述（很可能有包含业务特别的要求）

•重点二是表述实现方案 e.g. 页面背景-样式动态修改，然后.. 前者说明功能在哪，让人能找到；后者是描述实现思路，必要时须给出代码/流程图帮助理解

技术方案的意义​

需求经历复杂迭代后，后续同学不可能翻代码了解实现思路，在将来同学拿到 prd 的前提下，去找功能对应的技术方案表述，接着能快速理解实现思路； 那我们写技术方案时，就是要以能帮助将来同学理解为目标，一定能理解的地方不要冗余表达，不一定能理解的地方要提示/解释，难以理解的地方要重点解释

关于技术方案的意义，再补充： 以上是方案对他人或后续自己的价值， 对于当前也有好处： •不会想到哪写到哪 •和其他同学技术沟通时能快速 match

技术方案要加深考虑的地方​

业务概念和映射变量是否一对一？ 例如：业务概念 A 类型，代码中定义了 a 和 b 两种常量，开发时只能确定 a 一定属于 A 类型，无法反推 A 类型只会包括 a 常量，必须和定义变量的 RD 确认 文案精准到每个按钮

流程图规范 https://www.woshipm.com/zhichang/2329530.html 子流程图游道图介绍 https://blog.csdn.net/vbirdbest/article/details/114186455