作者介紹：曾永洪(sea)， 研發資訊中心支付金融測試團隊TL，  從業十多年，經歷過創業公司，上市企業，從工程師到高階測試工程師到資深測試工程師，到測試專家，中途做過人力資源經理，負責HR運營管理與企業戰略運營，人力成本與編制管理，參與招聘、績效、流程優化等體系建設，2018年底回到長沙擔任興盛優選測試專家崗位至今。  作為移動網際網路領域的老鳥，Testner測試社群創始人，工信部 ITSS工作組DevOps專家組成員，OWASP國際安全組織中國區高階會員，BAT等大企業測試行業公益服務組織金陽光測試深圳區負責人，熱愛軟體測試，熱衷公益事業，踐行 “窮則獨善其身，達則兼濟天下”，一直在軟體測試的領域默默耕耘。 

        在我看來我們研發中心今年提出降本增效是個很好很務實的目標，提高交付效率開源節流也是一個企業要生存與提升市場競爭力必須常抓不懈的。之所以說降本增效是個目標，而非運動，我是這麼認為的： 運動是某些人策劃組織，然後其他人按照規則參與即可，參與完了也就結束了。但是目標不一樣，可能是長期的過程，要不斷去挑戰與突破，更重要的它不是某幾個提出人的事情，而是整個團隊的事情，必須全員都行動起來，堅持不懈，從每個人日常工作做起，才能量變引起質量。一定要走出這個誤區，光靠幾個管理者提出口號，遠遠不夠，目前降本增效已經真正應用到OKR目標中。目標確定了，那麼我們如何去落地？ 我認為這個問題必須我們每個人從自身工作去思考，我相信管理層無法給出標準答案。作為技術leader的視角，我最近思考了一些降本增效最佳實踐途徑，希望能拋磚引玉與大家一起共同完善！

          

        第一部分： 降本增效之技術在行動

　　　　

        作為研發中心，技術是我們強項，如何用好我們手中技術武器去降本增效，提升我們公司利潤與市場競爭力，這理應是我們技術人擅長之事。 當然，並不是越多越好，而是應該充分的根據日常工作情況，找出可以降本增效的痛點，機會點，進行優先順序與ROI評估後，擇優而動！ 

         

             作為自動化而言，提升效率是最容易考慮的，但是以我的經驗來看，不是所有自動化都能增效，任何自動化實踐一定要提前進行ROI科學評估，比如UI測試自動化，變更頻繁且不是核心功能邏輯，指令碼維護工作量巨大，但是價值與產出非常非常低，一般不應該輕易去考慮。

           

          而介面（API）自動化測試應該是很高的，介面自動化測試目前大中企業都做得比較成熟，我不多說，只是提醒一句，我們不要為了自動化而自動化，我們要不忘初心做自動化的目標是降本增效，因為自動化的實踐方案一定是夠用即可、經濟實惠，高性價比。做平臺級的產品同時，多做些小而美的自動化創新實踐快速增效。

         單元測試理論上來說ROI應該是最高的，但是它的成功條件人的因素很大，這個人是否真正理解單元測試的目的與技巧，能否用最少的程式碼做到最佳的分支覆蓋等，都會直接影響到單元測試的有效性。我經過一些團隊，單元測試的程式碼行很多，每次花和編寫業務程式碼差不多的時間去做單元測試編碼，但是還是帶著實現業務時的開發思維，單元測試case的覆蓋與質量很不理想，這樣的單元測試實踐不但起不到降本增效，反而增加專案成本和延長開發交付週期。

         

         指令碼化的話，我個人和團隊會形成不斷沉澱和整理的習慣，將日常要用的輸入經常沉澱，比如驗證測試某某金額的準確性、去配置一些東西，整理成SQL指令碼、BAT指令碼\SHELL指令碼等等，這樣用的時候可以大大提高效率，也可以提高測試質量，規避因為個人測試輸入不正確引起的測試結果錯誤。其實說到底，也屬於複用的一種，複用是我想重點推薦的，複用本身很好理解，大家也都知道，但是真正形成最佳實踐，從各個層次各個角落去最大程度複用和減少重複發明輪子，這個既要有研發中心自上而下 的組織布局、又要有每個人日常工作中自下而上的輪子貢獻。這句話也許很繞，但是我相信開發同事都能理解，關鍵是能否有意願去做，並且願意和敢於多跨一步去貢獻。

       複用率的高低一定程度決定了組織能力成熟度的高低，一些新的功能與技術不斷沉澱，伴隨著不斷的迭代驗證與PDCA，這些沉澱的輪子質量越來越穩定，後續開發者可以高效的基於API引用，真正的做到高質量高效率，降本增效是非常顯著的。我這裡想補充的是，複用一定不能停留在程式碼複用一個層面，業務解決方案的複用、技術方案的複用、開發思維與測試思維的複用，這些都可以形成最佳實踐。比如連線池的使用，有些同學可能會基於自己習慣去引入一些新的連線池，有些同學可能會基於個人經驗或者網上文章初始化最小與最大連線數，這些都是未經過我們研發中心專案匹配和長期驗證，質量風險是很高的，這樣的拿來主意不丟人，我們業務研發與測試不同於搞科研，一定是如何快速高效如何最低成本實現為前提！當然，這個與業餘時間去探索新的思想與方案不衝突，一個是工作需要，一個是專業興趣。

      對於測試而言，之前我的做法是基於面向測試物件的思維模型，首先梳理出我們研發中心的測試物件，然後基於各個測試物件進行測試思維的沉澱與PDCA，可以把一些優秀的個人思維形成組織思維，這對於提升測試組織能力成熟度是非常有效的，當然，複用到日常測試中測試用例設計與測試執行中，在降本增效方面的複用收益也是顯而易見的，在測試質量穩定性方面也是我比較推薦最佳實踐。有點劫富濟貧的感覺，這樣可以規避因人而異的測試輸出，同時真正做到位，可以一定程度上降低用人要求與成本。

  

        coc（convention over configuration）實踐 ，比如參考springboot的零配置思想，用約定代替繁瑣的配置，可以一定程度上減少配置檔案和配置工作量，同時減少大量配置開發與維護帶來的質量問題。類似改善應用未嘗不是一種降本增效的實踐。 比如研發中心內部系統見的介面資料傳輸，如果有固定的字首和引數，比如http://produce.xsyx.com/xxx/xxxx/xxxxxxx?param1=value1&param2=value1, 我們能否直接傳遞元組(value1,value2)，這樣對於減少網路頻寬資料傳輸，降低頻寬成本，當然，這個與自動化實踐一樣，一定要具體情況具體分析，評估可行性！

                     

        第二部分： 降本增效之管理在行動

         管理行動之一就是所有人足夠聚焦專案業務，只有專案才是直接輸出和可以衡量業務價值的，我們每個人每一分鐘都是成本投入，一定要聚焦在業務專案目標本身，或者是為專案服務，減少一些純管理事務，尤其讓專案成員去花時間做些管理事項，也要儘可能減少。
 

一些公司要求全員寫日報，週報，月報，大家都認為正常，其實不是，這些都是為了滿足管理者需要，並沒有直接的業務價值；相反，如果這個管理者過程中能及時根據，這些彙報必要性不大，即使要有彙報，應該也只是聚焦業務風險、問題、困難求助，但是即便這些也最好實時同步溝通，不應該等到固定的期限來以報告反饋。要強調的是我說的都是專案組內成員，純管理人員除外，專案組成員應該讓他們為研發中心更加高效高質創造更多輸出。

        容易忽視的就是日常最多的溝通成本了，比如會議溝通、非正式溝通等。一般而言，網際網路文化追求的是扁平化，小步快跑，資訊快速同步，所以專案事情應該郵件與IM群儘可能同步所有干係人，
但是會議上，應該儘量縮小範圍與時間，每多一個人多一分鐘都是成本，試想一下， 10個人或者20個人，裡面有工程師、高階工程師、專家，一開會就是兩個小時四個小時，按人均直接成本與機會成本去估算，成本還是很驚人的，我們的效率就在會議中溜走了。我個人一般不喜歡參加1H以上的會議，在團隊也極力提倡半小時會議文化。 比如原來我們的測試用例評審經常要2H，現在同樣的效果，30分鐘以內大多數可以結束，辦法總比困難多，事在人為，降本增效的機會就在我們的身邊。 

        此外，應該減少職能型會議，減少彙報性會議，這些會議不僅直接產出低，而且時長往往比較長，涉及人員也多。 而決策會是我最鼓勵的，帶著方案來決策，效率是很高的，而且產出很直接； 此外，評審會也是我們可以重點優化的點，現在各種評審會佔據的時間非常多，在此我也建議後續研發內部的評審，儘量安排到下午，上午大家精神最好的時候應該聚焦業務輸出，這個時候不僅效率高質量也高。

        頭腦風暴會，在我們支付金融測試團隊也是比較多的，有些時候我會當做是決策會之前民主補充，這樣往往大家都能提前參與，決策後能心甘情願的快速去執行落地，不至於一邊被動執行一邊還不理解或者不太認可，過程再反覆溝通與變更，這樣的效率與質量可想而知。

        第三部分： 降本增效之質量在行動 

        最後推薦大家看一本書： 《質量免費》，《質量免費》是管理學的經典名著，也是哈佛、沃頓、耶魯等商學院MBA的必讀物。克勞士比在書中闡釋了質量管理的錯誤觀念，以及ITT公司如何在全球實施質量過程改進的成功故事。對於降本增效最佳實踐也是有很大參考意義，之所以說是參考，是為了防止一般公司習慣性的全盤照搬，任何對標的理論一定要結合本企業實際情況進行微創新和改進，否則很容易水土不服（別人的問題未必是你的問題，別人的鑰匙未必能完全開啟你的鎖，別人的起點和你不在一個水平線，別人的產品和你不一樣）。我提倡對標的是思想，而非行為。

         HPA的傳奇故事更是詳細而完整地解剖了管理層如何運用14個步驟推動組織改進的全過程，而質量管理成熟度方格又提供了一種讓管理者決定其組織的質量過程何去何從的方法。由此你將理解質量不僅是免費的，它還是一棵貨真價實的搖錢樹。由於工作一開始就做對了，沒有返工而省下的每一分錢，都會寫入會計報表上 “利潤”這一欄。試想，如果我們的開發交付沒有低階問題，確保可用性，那麼SLA就已經能確保，後續引起的QA測試、BUG修復、迴歸驗證、以及因此引起的溝通成本，延誤的時間與市場機會成本，那麼是很客觀的。 我要強調的是質量免費不是質量無成本，而是一次把事情做對和做好，減少額外的成本浪費。質量的成本更多用於質量內建（質量預防為主）、測試更深更廣進一步提升使用者體驗（而非大部分的時間耗在原本開發本身就可以自測做好的低階問題），需求基線的質量、開發編碼的提測質量、測試質量都非常關鍵，所以做好這些關鍵點的評審是必要的質量成本（評審的目的正是如此，不是為了走個流程，更重要的是對工件質量的把關與準出）。每個環節嚴格做到三不原則： 不接收不良品、不生產不良品、不流出不良品，那麼我們的降本增效才是由內而外的質變！                不要為了交付而交付，而應該是在確保質量的前提下，熟能生巧，提升個人與團隊能力成熟度，逐步提升交付效率,否則快速交付犧牲質量，帶來的返工成本與時間往往是更多的， 一次做對才是真正的捷徑與低成本！           最後，我想說的是，成事在人，降本增效關鍵在於人，團隊成員發自內心的默契是非常重要的，大家覺得我們的支付金融測試團隊如何？