为什么要写技术方案？

有同学留言问我：在中小型公司做测试工作，领导提出要做自动化测试，是找个框架直接落地开干呢，还是先做做调研写个技术方案？担心做调研写方案没人看，领导只关注效率和结果。

又是一个难得一见的好问题，这个问题的终极拷问是效率高低和结果优劣的对比，这种现象在很多中小型公司甚至大型公司都屡见不鲜。一方面要效率要快速产出结果，另一方面又要求结果不能太差甚至要符合领导预期，作为技术同学，该如何平衡这个效率和质量的难题？

以自动化测试为例，简单来说就是将人工执行的测试用例转变为机器执行，更快的产出测试结果，其背后潜在的价值是缩短信息反馈链条，达到更快验证更快修复的目的。

想法挺好，好的技术实践案例也不少，但为什么在很多公司自动化测试最后都不了了之呢？原因无外乎这几点：

1、对自动化测试的实现细节和落地难度不太了解，认为自动化测试就是找个工具把用例转化一下，然后跑起来出结果就行了，简单快速，还容易出结果，随之定了比较理想的目标，大干快上。

2、项目迭代速度快，人力和时间资源紧张，寄期望能快速通过自动化提高测试回归效率，分出了一部分资源来自研/二次开发自动化测试框架或者平台。结果两三个月过去了，效率没提升反而下降，交付压力更大，质量也没有明显提升。

3、前期没调研，落地没规划，推广难度大，来回折腾不断修改，最后 KPI 不好看。

上述三点之外，还有其他影响因素，但无论是自动化测试还是其他的技术项目落地，失败的原因主要可以概括为目标、成本、时间和人的因素。

首先是目标，无论要实践哪种技术工程，都需要制定一个合理的可实现的目标。其次需要投入的一定的资源支撑目标的达成，再次需要有相对足够的时间来落地实践，最后还要有合格的工程师参与，并且和相关协作方保持良好的沟通协调。

这几点概括一下，其实就可以回答本文开头的问题：要不要前期调研写个技术方案？答案是，一定要！

其实，有过自动化测试落地实践经验的同学都明白，只是单纯的技术实现并没有什么难度，难的是是否有资源支撑，给的时间够不够，定的目标合不合理，以及参与这件事情的人是否配合。

有些同学高估了自己的技术能力，低估项目落地和目标达成的难度，领导发话了，直接开干。这样做确实短期内能拿出一些所谓的产出，但稍微扩大覆盖范围就捉襟见肘，出现各种问题。

原因在于对目标没有足够的理解，没有管理好自己和领导的预期目标，落地过程不够具体，任务拆分比较粗糙，甚至没有考虑到时间、资源等各种因素是否满足落地条件。

本文开头的同学存在的疑惑是要不要写技术方案，我的建议是一定要写。无论项目大小难易程度，都建议写一个技术方案或者落地规划，写技术方案的好处在于：

1、梳理思路：做事情要靠系统而不是靠直觉，写技术方案的过程，是不断搜集信息并重新加工的过程。比如选择自研框架还是开源工具，比如当前团队现状是否有足够的时间和资源支撑，比如目标是否合理，比如落地要面临哪些挑战。将这些可能遇到的问题和落地实现步骤都写出来，不断梳理，最终成为一份可行的技术方案。无论有没有人看或者是否有评审环节，技术方案更多的写给自己看的，是用来梳理思路管理自己的。

2、管理预期：有了可行的技术方案，就可以判断预期的目标是否合理。如果不合理，可以拉上领导一起评审，找到双方对目标理解的 gap，然后针对性调整，毕竟领导也不希望项目失败或者拿不到好结果。

3、争取资源：合理可行的目标+可落地的技术方案之外，还需要通过技术方案说明落地的难度和需要的资源。很多同学在职场容易犯错的一点就是不懂得向上管理争取资源，这样很容易导致做什么事情都束手束脚，最终拿不到好结果。

4、便于调整：技术方案还有一点好处就是可以根据具体情况实时调整。比如落地过程中资源不足或者时间紧张，可以按照方案中所述的落地步骤和里程碑，适当调整交付时间，或者申请更多的资源支撑，这也是保护自己的一种手段。

以自动化测试来说，落地实践拿到结果是一个复杂的工程，其中涉及到的人(直接参与 &配合的人)、事(要做的事情)、物(资源)都会影响最终的结果。而合理可行的技术方案(或者说落地规划)则是串联其中并指导最终达成目标的关键因素。