简单介绍一下为什么要写这篇文章吧，入职接近一年了，越来越感觉技术文档是非常重要的，当然也和需求文档有关，需求文档清晰完整会大大降低后端RD整理技术文档的成本，但是一个合格的技术不仅仅应该能够应对这种简单的情况，即使是在相关资源缺失的情况下也应该能够cover好自己的工作并且拿到好的结果，当然了这些不是必选项，但是我个人理解是优势，想要走的更远，就必须具备在恶劣环境下拿结果的能力，在简单的情况下拿结果对能力的要求相对较低，在复杂的情况下拿结果才能在任何时候都能保质保量的交付产品。
这次的技术文档框架均建立在PM不合格的情况下的，技术Owner向前走一步，承担起PM的责任并且主导整个流程的假设下，并且由于我自己的工作年限也只有一年，经验不是很丰富，只能尽我所能的梳理一些我能想到的模块，如果有更好的建议欢迎在评论区提出
1.需求文档
一个良好的技术文档一定是建立在良好的需求文档上的，身为技术人员，在发现PM的需求文档有问题的时候应该第一时间发现，并且意识到存在哪些问题
个人认为一个好的文档应该包含包含背景，收益，用户交互图，技术指标，项目交付时间等模块，其中可以使用5W1H方法进行分析
当我们发现pm的交付的需求文档不达标时，可以记录下todo让其修改，同时如果信息缺失太多，应该将需求文档打回。
个人认为需求评审的过程中，研发最主要的事情有两个，梳理清楚pm要做什么，以及判断能不能做，其实我之前还喜欢评估这个需求有没有价值，但是后来逐渐分清了rd和pm的职责
因此，后来我会从研发的视角提出这个需求某个模块（我认为收益和投入不成正比的部分）的实现复杂度以及我所认为的收益，然后给pm提出合理的建议，如果pm执意坚持，我会同意他的观点并在会后和老板讨论这个问题，由老板来做最终的决策，我认为这是一个完整的流程。
上面梳理完了需求评审我应该做的事情，下面说一下技术评审我需要做的事情
2.技术评审
技术评审一般由后端RD发起，技术评审是为了保证需求的技术实现方案的合理性、可行性和高效性，从而确保产品的稳定性、安全性和可维护性，保障项目的进度和质量。技术评审也是一个团队合作的过程，需要各个团队成员共同协作，确保产品开发的成功实现。
一般来讲，就我个人而言，我认为一个好的技术方案应该是具备可行性、可扩展性、安全性、高效性和成本效益的，并且具有可读性、可维护性和可测试性等特点，能够全面满足需求和业务要求，并且能够提高团队的开发效率和协同能力。
另外最重要的一点，技术方案一定要让人看懂
从我自己来说，我自己整理了一套技术方案的框架
业务需求
首先是背景和收益，你要让参加你技术评审的人知道你要做什么（what），为什么要做这件事（why）
需求分析
然后是本次技术方案要实现的功能
概要设计
（如果涉及到一些特殊名词最好做一些详细解释）
需求的架构图
需求的时序图
详细设计
前后端的接口文档，
模块依赖关系以及开发量，
具体实现
相关同学的排期（前端，后端，qa，数仓同学的排期），
回滚预案
会议纪要（todo list）
最后要附上相关的参考文档，比如需求文档，前端同学的技术文档等等
除此之外，会议纪要也是非常重要的一部分，这个单纯看个人，因为我自己的记忆力比较差，除此之外由于团队的一些问题相对混乱，因此每次开会我都会把各个同学要做的事情记在最后（落实到人，具体时间，给到相应结果）并且会后在群内抛出，并约定相应时间定期review进度，如果有风险可以提前报漏