作为从小团队出来的人，我之前并不能理解技术方案和相关的评审存在的价值。在我经历了几次技术方案评审和较大的协作项目时，有了一些自己的心得体会。

1 管理预期

凡事预则立，不预则废。在工程中，最怕的就是不确定性，高度的不确定性意味着高度的风险。
梳理技术方案就是在开发期前，通过理清技术方案，减少不确定性。
评审通过的技术方案会指导整个开发工作。
而同步给相关方后，通过描述路线，明确难点，又可以管理相关方的预期，使其对项目的预期和开发接近。

2 寻找优化

完(糊)成(弄)一个需求是非常简单的。
一方面，需求稿和视觉稿不能把所有场景都列举出来，在未列举出来的地方自由发挥还是深入思考并合理处理都考验着开发的责任心。
第二，页面卡顿/热区过小/手势冲突这些技术的细枝末节会对用户的体验产生很大的影响，用户会感知到这些问题但很难描述或者不会去描述，他们会选择用脚投票。
当我们拿出一份细致的技术方案时，就会把这些细节中的魔鬼暴露出来，在自己和小伙伴的审视优化掉暴露出的问题。

3 自我提升

编写和讲述技术方案，也是向别人传授对项目的理解和思考。这个过程会逼自己快速了解需求，也会增加对业务现状的理解，技术方案本身也沉淀出业务文档。
同时，对这种编写和简述本身就是对自身软技能的提高。
一个人的大脑思考过程是非常快的，一秒钟的灵感，可能要花一分钟去记录，而简述给别人理解可能需要一个小时的PPT。经过反复的总结和沟通的锻炼，才能领悟出适合自己的高效沟通方法。