开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 1 天，点击查看活动详情
1、背景
去年年末到年初，在项目组内参与了一系列技术项目，有纯前端项目，也有同时包含前后端的。 在这个过程中自己在功能层面实现问题不大，但是在输出技术方案方面存在一些软硬实力的缺陷。
输出技术方案，在汇报和阶段总结的时候，能让别人清晰的理解你的逻辑和整体规划；在协同执行的时候每一步清晰有目标，最终拿到符合预期的结果
很多人都不重视写技术文档，一切以功能实现为重点，在应用层反复折腾
很多成长类书籍中都有介绍，在具体领域成为高手需要 事前有规划，事中有调整，事后有复盘，然后刻意训练
平常的开发工作中，想想有多少时间是在低水平重复，把自己纯当工具人
这篇文章结合自己实际，聊聊如何输出技术文档
2、心态建设
在正式介绍之前，先梳理几个常见心态
1、 折腾文档就是务虚，面向ppt编程
很多人谈项目汇报，绩效总结就反感，认为这是务虚，是为了晋升，讨好上级的表现。这种心态不对，表达与总结是对自己所思所想系统的展示，很多时候我们得站在听众和使用者的角度表达观点，实现功能大家的差距不会很大，而展示思维和系统表达才是拉开差距的地方
2、先实现功能，技术设计后面再补
思路优于行动，想清楚综合多方建议再动手，技术文档是结构化的，不只有功能实现相关，是一套完整的，系统的工程实践
3、前端就是实现产品功能，逻辑，数据都在后端，因此不关心业务
完全不关注业务肯定不行，产品说什么就是什么，到了裁员你才知道业务黄了。
了解阶段性业务规划，行业竞对实现，从前端视角给出建议和方案
4、平时的业务需求不习惯写技术文档
这个我觉得因人而异，一般是相对复杂，模块较多，多人协作的项目需要输出技术文档，也没有必要业务需求都先从文档做起，最后流于形式自己记todo list
但是刚参加工作的同学建议即便业务需求也坚持写技术文档，然后让团队有经验的同学帮忙发现问题，有如下好处
- 快速规范化完整开发流程，降低熟悉成本
- 职业早期养成文档记录习惯，有思考有总结
- 沉淀可复用开发物料，能力进阶
- 积累汇报资料，年底总结有理有据
3、关键能力
3.1 结构化表达
描述一个综合性的工程方案需要借助结构化表达，具体可以参考麦肯锡《金字塔原理》
在谈技术方案设计的时候一般需要遵循以下结构，当然具体情况略有调整
从体来说就是讲清楚为什么要做，具体做了什么，如何做的，要收获什么结果
1、背景与问题
出于什么现状，遇到哪些问题所以要立项，具体是为了解决什么问题。对问题的描述需要基于业务，同时达成共识
2、想达到什么目标
从定性和定量的角度描述预期获得的目标，尽量输出定量指标，目标制定符合SMART原则
3、输出技术方案
- 行业类似方案调研，关键点优劣对比
- 整体设计思路，全局视角介绍
- 分模块具体细节介绍
- 架构思路，流程思路等
- 衡量指标
4、进度与时间安排
结合实际按时间点总结阶段目标和成果，同时上下游信息同步，切忌光立项期间无反馈
5、未来规划
当前方案客观存在的问题，结合实际情况预计未来如何规划，需要什么资源
3.2 图形化表达
根据前面介绍，技术人员最关心的方案是第三部分，这一块需要一定的图形表达能力（这里的图形只是举例，具体实践可以借鉴专业的工具书）
1、整体架构图
从整体视角介绍系统，介绍一个完整的工程方案需要学会画架构图，从上到下，从左到右以全局视角介绍
2、逻辑流程图
按先后顺序，逻辑分支介绍具体功能点
3、方案对比表，时间规划表等
4、实体关系图，数据库设计等（后端方向）
4、其它
以上便是个人一点点工作的经验，还有很多不足，在工程建设领域希望抛砖引玉看到更多大佬的观点，评论区谈谈你们对技术文档的看法吧！
输出技术方案只是开始，做事闭环还需要事中跟踪，事后复盘，这样才能刻意向高手迈进
