有同學留言問我：在中小型公司做測試工作，領導提出要做自動化測試，是找個框架直接落地開幹呢，還是先做做調研寫個技術方案？擔心做調研寫方案沒人看，領導只關注效率和結果。
又是一個難得一見的好問題，這個問題的終極拷問是效率高低和結果優劣的對比，這種現象在很多中小型公司甚至大型公司都屢見不鮮。
一方面要效率要快速產出結果，另一方面又要求結果不能太差甚至要符合領導預期，作爲技術同學，該如何平衡這個效率和質量的難題？
以自動化測試爲例，簡單來說就是將人工執行的測試用例轉變爲機器執行，更快的產出測試結果，其背後潛在的價值是縮短信息反饋鏈條，達到更快驗證更快修復的目的。
想法挺好，好的技術實踐案例也不少，但爲什麼在很多公司自動化測試最後都不了了之呢？原因無外乎這幾點：
1、對自動化測試的實現細節和落地難度不太瞭解，認爲自動化測試就是找個工具把用例轉化一下，然後跑起來出結果就行了，簡單快速，還容易出結果，隨之定了比較理想的目標，大幹快上。
2、項目迭代速度快，人力和時間資源緊張，寄期望能快速通過自動化提高測試迴歸效率，分出了一部分資源來自研/二次開發自動化測試框架或者平臺。結果兩三個月過去了，效率沒提升反而下降，交付壓力更大，質量也沒有明顯提升。
3、前期沒調研，落地沒規劃，推廣難度大，來回折騰不斷修改，最後KPI不好看。
上述三點之外，還有其他影響因素，但無論是自動化測試還是其他的技術項目落地，失敗的原因主要可以概括爲目標、成本、時間和人的因素。
首先是目標，無論要實踐哪種技術工程，都需要制定一個合理的可實現的目標。其次需要投入的一定的資源支撐目標的達成，再次需要有相對足夠的時間來落地實踐，最後還要有合格的工程師參與，並且和相關協作方保持良好的溝通協調。
這幾點概括一下，其實就可以回答本文開頭的問題：要不要前期調研寫個技術方案？答案是，一定要！
其實，有過自動化測試落地實踐經驗的同學都明白，只是單純的技術實現並沒有什麼難度，難的是是否有資源支撐，給的時間夠不夠，定的目標合不合理，以及參與這件事情的人是否配合。
有些同學高估了自己的技術能力，低估項目落地和目標達成的難度，領導發話了，直接開幹。這樣做確實短期內能拿出一些所謂的產出，但稍微擴大覆蓋範圍就捉襟見肘，出現各種問題。
原因在於對目標沒有足夠的理解，沒有管理好自己和領導的預期目標，落地過程不夠具體，任務拆分比較粗糙，甚至沒有考慮到時間、資源等各種因素是否滿足落地條件。
本文開頭的同學存在的疑惑是要不要寫技術方案，我的建議是一定要寫。無論項目大小難易程度，都建議寫一個技術方案或者落地規劃，寫技術方案的好處在於：
1、梳理思路：做事情要靠系統而不是靠直覺，寫技術方案的過程，是不斷蒐集信息並重新加工的過程。
比如選擇自研框架還是開源工具，比如當前團隊現狀是否有足夠的時間和資源支撐，比如目標是否合理，比如落地要面臨哪些挑戰。將這些可能遇到的問題和落地實現步驟都寫出來，不斷梳理，最終成爲一份可行的技術方案。
無論有沒有人看或者是否有評審環節，技術方案更多的寫給自己看的，是用來梳理思路管理自己的。
2、管理預期：有了可行的技術方案，就可以判斷預期的目標是否合理。如果不合理，可以拉上領導一起評審，找到雙方對目標理解的gap，然後針對性調整，畢竟領導也不希望項目失敗或者拿不到好結果。
3、爭取資源：合理可行的目標+可落地的技術方案之外，還需要通過技術方案說明落地的難度和需要的資源。很多同學在職場容易犯錯的一點就是不懂得向上管理爭取資源，這樣很容易導致做什麼事情都束手束腳，最終拿不到好結果。
4、便於調整：技術方案還有一點好處就是可以根據具體情況實時調整。比如落地過程中資源不足或者時間緊張，可以按照方案中所述的落地步驟和里程碑，適當調整交付時間，或者申請更多的資源支撐，這也是保護自己的一種手段。
以自動化測試來說，落地實踐拿到結果是一個複雜的工程，其中涉及到的人(直接參與&配合的人)、事(要做的事情)、物(資源)都會影響最終的結果。
而合理可行的技術方案(或者說落地規劃)則是串聯其中並指導最終達成目標的關鍵因素。