理由
为什么需要编写技术方案和进行技术评审
- 加强对需求理解，减少错误几率。通过编写文档，可以再自己复盘一下需求流程，并且对开发过程有个大概的模拟，可以初步判断任务的难点和可能出错点。
- 变更详细。通过文档记录，可以对需要变更那些文件，有个具体的记录，方便后期维护。
- 可以将需求资料集中。因为有文档记录，开发期间可以方便查阅相关内容，如果以后其他人有基于这个需求的迭代也可以先查看这个文档。
那些需求可以不用
- 逻辑跨度不超过两个页面的非主流程任务
- 纯UI更新，没有需要新增/更改组件或没有新增逻辑。
- 开发时间小于1天的非主流程任务
方式
按照项目、迭代版本进行路径存放，用主任务的名称进行文件命名
内容
- 背景（为什么要做这个需求）
- 目标（对这个需求的目标是什么，主要是技术类的需求，业务的可以不写）
- 资料（开发流程需要的各种资料）
- 方案
- 流程简述
例如
- 可以是流程图，类图，时序图各种
- 也可以是单纯的文本描述
- 还可以是伪码
- 形式不重要关键是要能把流程理顺，自己能说清楚，别人能理解就行
- 变更内容
例如
- 需要新增那些类
- 那些已有类需要新增那些逻辑/UI
- 旧逻辑/UI的更改
- 那些类需要新增入口或参数
- 尽量还是能写的详细一点，方便后续自己查看
- 需要后台提供的接口
- 风险（根据方案可能会存在的难点）
- 技术类风险
例如
- 某些UI需要自定义功能
- 某个功能业务逻辑较重
- 协同类风险
例如
- 需求变更了
- 设计图完了
- 接口没那么快开发
- 其他人阻塞了你
- 需要协调的地方
例如
- 后台接口文档时间
- 依赖其他人的服务
- 备注（可能有需要更改的地方和你觉得的一些问题）
模板
参考
流程
- 需求评审结束后编写技术文档（见技术文档格式）
- 组内相关开发人员参加
- 开发者根据文档，进行技术方案讲解
- 参与人员对存在的疑问提问，开发者解答
- 将遇到的问题或更改，同步到文档
时间
评审开始节点
原则上是在需求评审结束后，估时开始前；如果手里任务紧，则在开发前必须完成评审
评审时长
建议不超过30分钟
存在问题
如果一个需求很大，该如何编写技术文档？
注意
- 如果文档有变更需要周知
-------------------------------
技术文档模板
背景
目标
资料
方案
流程简述
内容变更
后台提供的接口
备注
风险
技术类
协同类
需要协调的地方
-------------------------------