如何用研發(fā)效能搞垮一個(gè)團(tuán)隊(duì)

本文作者：茹炳晟 ，校對(duì)：張樂

談到研發(fā)效能，我們有著自己的獨(dú)到見解。我們看到的現(xiàn)象是：只要努力搞，沒有折騰不垮的團(tuán)隊(duì)。雖然有很多大廠研發(fā)效能做的還不錯(cuò)，成為了大家膜拜的對(duì)象，但是我們也看到很多“內(nèi)卷”現(xiàn)象的發(fā)生。經(jīng)歷了很多故事，我們更能談?wù)勛约旱睦斫夂透形颉?/span>

研發(fā)效能是目前互聯(lián)網(wǎng)企業(yè)和傳統(tǒng)軟件企業(yè)都高度關(guān)注的領(lǐng)域，互聯(lián)網(wǎng)大廠希望通過“研發(fā)效能”實(shí)現(xiàn)持續(xù)的研發(fā)能力提升以應(yīng)對(duì)日趨復(fù)雜的產(chǎn)品開發(fā)；腰部廠商則希望通過“研發(fā)效能”實(shí)現(xiàn)彎道超車，充分發(fā)揮后來者居上的優(yōu)勢；更多中小企業(yè)看到國內(nèi)互聯(lián)網(wǎng)大廠不約而同地在這個(gè)領(lǐng)域重點(diǎn)投入，紛紛也是摩拳擦掌準(zhǔn)備在效能領(lǐng)域發(fā)力。

一夜之間，似乎只有推進(jìn)了研發(fā)效能，才能提升研發(fā)團(tuán)隊(duì)的效率，才能讓自己在和友商的比拼中不至于輸在起跑線上。

那么現(xiàn)在企業(yè)的研發(fā)效能實(shí)踐到底為企業(yè)帶來了多大的優(yōu)勢，又幫企業(yè)解決了哪些問題呢？那些推行研發(fā)效能的企業(yè)現(xiàn)在的狀態(tài)怎么樣？研效問題到底解決了嗎？

別急，這些問題其實(shí)大多都還沒有解決，而且有些問題可能還變得更糟糕了。畢竟研發(fā)效能的實(shí)施沒有捷徑，需要摸著石頭過河，肯定不會(huì)能像電影里面演得那樣注定會(huì)有皆大歡喜的結(jié)局。經(jīng)歷了風(fēng)雨，不一定能看見彩虹，更有可能會(huì)得重感冒。研發(fā)效能問題今天解決不了，不要著急，因?yàn)槊魈焱瑯右步鉀Q不了。所以就讓我們“放心大膽“地看看研發(fā)效能到底是如何搞垮一個(gè)團(tuán)隊(duì)的。

要看懂研發(fā)效能如何搞垮一個(gè)團(tuán)隊(duì)，我們首先需要對(duì)研發(fā)效能有一個(gè)全局的認(rèn)識(shí)，需要先從正向的角度來理解研發(fā)效能。

到底什么是研發(fā)效能

和敏捷的概念類似，到底什么是研發(fā)效能很難精確定義。其實(shí)很多復(fù)雜概念也不是定義出來的，而是逐步演化出來的，是先有現(xiàn)象再找到合適的表述。其實(shí)，效率和效能也從來都不是軟件工程的專有名詞，縱觀人類發(fā)展史，就是生產(chǎn)力和生產(chǎn)效率不斷提升的發(fā)展篇章，到了數(shù)字化時(shí)代，軟件研發(fā)效能的重要性被凸顯了出來。如果要用一句話來總結(jié)研發(fā)效能的話，我們會(huì)用“更高效、更高質(zhì)量、更可靠、可持續(xù)地交付更優(yōu)的業(yè)務(wù)價(jià)值”來總結(jié)。

圖1：研發(fā)效能的“第一性原理”

解釋一下其中幾個(gè)關(guān)鍵概念：

• 更高效：價(jià)值的流動(dòng)過程必須高效順暢，阻力越小越好。
• 更高質(zhì)量：如果質(zhì)量不行，流動(dòng)越快，死的也會(huì)越快。
• 更可靠：安全性和合規(guī)性要保障好。
• 可持續(xù)：輸出不能時(shí)斷時(shí)續(xù)，小步快跑才是正道，不要憋大招。
• 更優(yōu)的業(yè)務(wù)價(jià)值：這是從需求層面來說的，你的交付物是不是真正解決了用戶的本質(zhì)問題。比如：“女生減肥不是本質(zhì)問題，女生愛美才是”?？梢泽w會(huì)一下。

在這個(gè)概念的引導(dǎo)下，我們引出持續(xù)開發(fā)，持續(xù)集成，持續(xù)測試，持續(xù)交付和持續(xù)運(yùn)維的理念，它們是研發(fā)效能落地的必要實(shí)踐。與此同時(shí)，我們還需要從流動(dòng)速度，長期質(zhì)量，客戶價(jià)值以及數(shù)據(jù)驅(qū)動(dòng)四個(gè)維度來對(duì)研發(fā)效能進(jìn)行有效的度量。

為什么大廠都開始搞研發(fā)效能

阿里的云效、騰訊云的CODING、百度的工程效能白皮書都是國內(nèi)研發(fā)效能領(lǐng)域的標(biāo)桿，可是你有沒有想過，為什么最近幾年各大行業(yè)龍頭企業(yè)都紛紛開始在研發(fā)效能領(lǐng)域發(fā)力，而且步調(diào)如此一致，我們認(rèn)為背后的原因有以下這么三點(diǎn)：

圖2：組織層面的“谷倉困局”

01

很多企業(yè)存在大量重復(fù)造輪子

就像“中臺(tái)“概念一樣，現(xiàn)在很多大企業(yè)的產(chǎn)品線非常廣，其中存在大量重復(fù)的輪子，如果我們關(guān)注業(yè)務(wù)上的重復(fù)輪子，那么就是業(yè)務(wù)中臺(tái)；如果我們關(guān)注數(shù)據(jù)建設(shè)上的重復(fù)輪子，那么就是數(shù)據(jù)中臺(tái)；如果我們關(guān)注研發(fā)效能建設(shè)上的重復(fù)輪子，那就是研效平臺(tái)，其實(shí)研效平臺(tái)在某種程度上也可以稱之為”研發(fā)效能中臺(tái)“，其目標(biāo)是實(shí)現(xiàn)企業(yè)級(jí)跨產(chǎn)品跨項(xiàng)目的研發(fā)能力復(fù)用，避免原來每條產(chǎn)品線都在做研發(fā)效能所必須的”0到1“，沒人有精力去關(guān)注更有價(jià)值的”1到n“?，F(xiàn)代化的研效平臺(tái)會(huì)統(tǒng)一來打造組織級(jí)別通用研發(fā)能力的最佳實(shí)踐平臺(tái)。

02

toC產(chǎn)品已經(jīng)趨向飽和

從商業(yè)視角來看，現(xiàn)在toC產(chǎn)品已經(jīng)趨向飽和，過去大量閑置時(shí)間等待被APP填滿的紅利時(shí)代已經(jīng)一去不復(fù)返了，以前業(yè)務(wù)發(fā)展極快，那么用燒錢的方式（粗放式研發(fā)，人海戰(zhàn)術(shù)）換取更快的市場占有率達(dá)到贏家通吃是最佳選擇，那個(gè)時(shí)代關(guān)心的是軟件產(chǎn)品輸出，研發(fā)的效率都可以用錢填上。而現(xiàn)在toC已經(jīng)逐漸走向紅海，同時(shí)研發(fā)的規(guī)模也比以往任何時(shí)候都要大，是時(shí)候要勒緊褲腰帶過日子了，當(dāng)開源（開源節(jié)流中的開源）遇到瓶頸了，節(jié)流就應(yīng)該發(fā)揮作用。這個(gè)節(jié)流就是研發(fā)效能的提升，同樣的資源，同樣的時(shí)間來獲得更多的產(chǎn)出。

03

部分企業(yè)存在“谷倉困局”

從組織架構(gòu)層面看，很多企業(yè)都存在“谷倉困局”（圖2），研發(fā)各個(gè)環(huán)節(jié)內(nèi)部可能已經(jīng)做了優(yōu)化，但是跨環(huán)節(jié)的協(xié)作可能就會(huì)有大量的流轉(zhuǎn)與溝通成本，從而影響全局效率?；诹鞒虄?yōu)化，打破各個(gè)環(huán)節(jié)看不見的墻，去除不必要的等待，提升價(jià)值流動(dòng)速度正是研發(fā)效能在流程優(yōu)化層面試圖解決的一大類問題。

研發(fā)效能真的能夠提高嗎

既然如此重要，那接下來的問題是研發(fā)效能是否真的能提高？

很不幸，我們的觀點(diǎn)比較悲觀。我們認(rèn)為研發(fā)效能的絕對(duì)值隨著以下因素的增長必然會(huì)變得越來越差，就像我（聲明一下，這里沒有張樂老師）的頭發(fā)一樣，隨著時(shí)間的推移必然會(huì)越來越少一樣。

• 軟件架構(gòu)本身的復(fù)雜度提升（微服務(wù)，服務(wù)網(wǎng)格等）
• 軟件規(guī)模的不斷增長（集群規(guī)模，數(shù)據(jù)規(guī)模等）
• 研發(fā)團(tuán)隊(duì)人員規(guī)模不斷擴(kuò)大引發(fā)溝通協(xié)作難度增長

所以，我們能做的不是提升研發(fā)效能的絕對(duì)值，而是盡可能減緩研發(fā)效能惡化的程度，使其下降的不至于太快，努力保持現(xiàn)狀就是成功。

圖3：研發(fā)效能的鴻溝

減緩研發(fā)效能惡化我們能干啥

看清了本質(zhì)后，關(guān)于如何減緩研發(fā)效能的惡化，我們能做點(diǎn)什么呢？

可以說研發(fā)效能的涉獵面是很廣的，軟件研發(fā)的每個(gè)階段都有研發(fā)效能需要關(guān)注的問題，騰訊提出的“研發(fā)效能雙流模型”可以說很好的詮釋了這一概念。雙流模型從軟件研發(fā)的各個(gè)階段提出了研發(fā)效能提升的各種工程實(shí)踐，并且倡導(dǎo)需求價(jià)值流和研發(fā)工程流的自動(dòng)聯(lián)動(dòng)。

圖4 研發(fā)效能的雙流模型

這里我們列舉一些實(shí)踐給大家拋磚引玉一下，下期的文章我會(huì)更系統(tǒng)地來說明其中的最佳實(shí)踐。

• 可以通過All-in-one的開發(fā)環(huán)境降低每位開發(fā)人員開發(fā)環(huán)境準(zhǔn)備的時(shí)間成本，同時(shí)又能保證開發(fā)環(huán)境的一致性。更高級(jí)的玩法是使用云端集成開發(fā)環(huán)境IDE，實(shí)現(xiàn)只要有瀏覽器就能改代碼，這一領(lǐng)域國內(nèi)典型的代表就是騰訊云CODING旗下的Cloud Studio以及Github目前處于beta測試階段的CodeSpaces。

• 可以借助基于AI的代碼提示插件，大幅度提升IDE中代碼的開發(fā)效率。輸入一段相同的代碼，不借助AI代碼提示插件，需要敲擊鍵盤200次，啟用插件可能只需要50次鍵盤敲擊，這樣可以更容易讓開發(fā)工程師進(jìn)入“心流“狀態(tài)，實(shí)現(xiàn)”人碼合一“。

• 代碼的靜態(tài)檢查沒有必要等到代碼遞交后由CI中的Sonar流程來發(fā)起，那個(gè)時(shí)候發(fā)現(xiàn)問題再修復(fù)為時(shí)已晚，完全可以通過Sonar Lint插件結(jié)合IDE實(shí)時(shí)發(fā)起本地的代碼檢查，有問題直接在IDE中提示，直接修復(fù)，這樣開發(fā)工程師會(huì)更愿意修復(fù)問題，因?yàn)槌杀靖?，也不?huì)引起修復(fù)后的再次發(fā)版。

• 單元測試比較耗費(fèi)時(shí)間，可以借助EvoSuite之類的工具降低單元測試的開發(fā)工作量。

• 對(duì)于規(guī)模較大的項(xiàng)目，每次修改后編譯時(shí)間比較長?？梢圆捎迷隽烤幾g，甚至是分布式編譯（Distcc和CCache）提升效率，對(duì)于Maven項(xiàng)目還可以通過緩存pom依賴樹進(jìn)一步降低編譯時(shí)間。

• 前端開發(fā)可以借助JRebel和Nodemon之類的工具使前端開發(fā)預(yù)覽的體驗(yàn)更流暢，實(shí)現(xiàn)前端代碼的“所見即所得”，避免重復(fù)的編譯、打包、部署和重啟步驟，以此提高開發(fā)過程的流暢度。

• 選擇適合項(xiàng)目的代碼分支策略對(duì)提升效率也大有幫助。

• 構(gòu)建高度自動(dòng)化的CI和CD流水線將大幅提升價(jià)值的流轉(zhuǎn)速率。

• 選擇合適的發(fā)布策略也會(huì)對(duì)效能和風(fēng)險(xiǎn)之間的平衡起到積極的作用。比如架構(gòu)相對(duì)簡單，但是集群規(guī)模龐大，優(yōu)選金絲雀，如果架構(gòu)比較復(fù)雜，但是集群規(guī)模不是太大，可能藍(lán)綠發(fā)布更占優(yōu)勢。

• 引入DevSecOps與DevPerfOps實(shí)踐，使安全和性能不再局限在測試領(lǐng)域，而是形成體系化的全局工程能力，讓安全測試成為安全工程，性能測試成為性能工程。

• ...

研發(fā)效能的“羅生門”

好了，理解了研發(fā)效能的正面觀點(diǎn)后，我們再回來看看研發(fā)效能在實(shí)際落地過程中又是一番什么樣的景象。

可以說理想很豐滿，但是現(xiàn)實(shí)很骨感，下面就我一起看看國內(nèi)研發(fā)效能的各種亂象。

01

迷信單點(diǎn)局部能力，忽略全局優(yōu)化和拉通的重要性

研發(fā)效能的單點(diǎn)能力其實(shí)都不缺，各個(gè)領(lǐng)域都有很多不錯(cuò)的垂直能力工具，但是把各個(gè)單點(diǎn)能力橫向集成與拉通，能夠從一站式全流程的維度設(shè)計(jì)和規(guī)劃的研發(fā)效能成熟平臺(tái)還是鳳毛麟角。現(xiàn)在國內(nèi)很多在研效領(lǐng)域有投入的公司很多其實(shí)還在建設(shè)，甚至是重復(fù)建設(shè)單點(diǎn)能力的研效工具，這個(gè)思路在初期可行，但是單點(diǎn)改進(jìn)的效果會(huì)隨著時(shí)間收益遞減，企業(yè)往往缺少從更高視角對(duì)研發(fā)效能進(jìn)行整體規(guī)劃的能力。很多時(shí)候局部優(yōu)化并不能帶來全局優(yōu)化，有時(shí)候還會(huì)是全局惡化。

02

具有普適性的通用研發(fā)效能工具其實(shí)沒有專屬工具來的好用

既然打造了研發(fā)工具，那就需要到業(yè)務(wù)部門進(jìn)行推廣，讓這些研效工具能夠被業(yè)務(wù)部門使用起來。其實(shí)，很多比較大的業(yè)務(wù)團(tuán)隊(duì)在CI/CD、測試與運(yùn)維領(lǐng)域都有自己的人力投入，也開發(fā)和維護(hù)了不少能夠切實(shí)滿足當(dāng)下業(yè)務(wù)的研發(fā)工具體系。此時(shí)要把新打造的研效工具來替換業(yè)務(wù)部門原來的工具，肯定會(huì)遇到很強(qiáng)的阻力。除非新的工具能夠比老工具好10倍，用戶才可能有意愿替換，但實(shí)際情況是新打造的工具為了考慮普適性很有可能還沒有原來的工具好，再加上工具替換的學(xué)習(xí)成本，所以除非是管理層強(qiáng)壓，否則推廣成功的概率微乎其微。即使是管理層強(qiáng)壓，實(shí)際的執(zhí)行也會(huì)大打折扣，接入但不實(shí)際使用的情況不在少數(shù)。

03

用“偽”工程實(shí)踐和“面子工程”來濫竽充數(shù)

如果你去比較國內(nèi)外研發(fā)效能工程實(shí)踐的差距，你會(huì)發(fā)現(xiàn)國內(nèi)公司和硅谷公司的差距還是相當(dāng)明顯的。但是當(dāng)你逐項(xiàng)（比如單元測試，靜態(tài)代碼掃描，編譯加速等）比較雙方開展的具體工程實(shí)踐時(shí)，你會(huì)驚訝地發(fā)現(xiàn)從實(shí)踐條目的數(shù)量來說，國內(nèi)公司的一點(diǎn)都不亞于硅谷公司，在某些領(lǐng)域甚至有過之而不及。那為什么這個(gè)差距還會(huì)如此明顯呢？我們認(rèn)為這其中最關(guān)鍵的點(diǎn)在于，國內(nèi)的很多工程實(shí)踐是為了做而做，為的是“政治上的正確”，而不是從本質(zhì)上認(rèn)可這一工程實(shí)踐的實(shí)際價(jià)值。這里比較典型的例子就是代碼評(píng)審和單元測試。雖然很多國內(nèi)互聯(lián)網(wǎng)大廠都在推進(jìn)代碼評(píng)審和單元測試的落地，但是在實(shí)際過程中往往都走偏了。代碼評(píng)審變成了一個(gè)流程，而實(shí)際的評(píng)審質(zhì)量和效果無人問津，評(píng)審人的評(píng)審也不算工作量，也不擔(dān)任何責(zé)任，這樣的代碼評(píng)審能有什么效果，結(jié)果可想而知。單元測試也淪為一種口號(hào)，都說要貫徹單測，但是在計(jì)劃排期的時(shí)候壓根沒有給單測留任何的時(shí)間和人力資源，可想而知這樣的單測是否能成功開展。所以，國內(nèi)公司缺的不是工程實(shí)踐的多少，而是工程實(shí)踐執(zhí)行的深度。不要用“偽”工程實(shí)踐和“面子工程”來濫竽充數(shù)。

04

忽略研發(fā)效能工具體系的長尾效應(yīng)

再回到研效工具建設(shè)的話題上，很多時(shí)候管理團(tuán)隊(duì)希望能夠打造一套一站式普遍適用的研發(fā)效能平臺(tái)，希望公司內(nèi)大部分業(yè)務(wù)都能順利接入，這和想法的確非常好，但是不可否認(rèn)的，研效平臺(tái)和工具往往具有非標(biāo)準(zhǔn)的長尾效應(yīng)，我們很難打造一套統(tǒng)一的研效解決方案來應(yīng)對(duì)所有的業(yè)務(wù)研發(fā)需求，各種業(yè)務(wù)研發(fā)流程的特殊性是不容忽視的。退一萬步說，即使我們通過高度可配置化的流程引擎實(shí)現(xiàn)了統(tǒng)一研效解決方案，那么這樣的系統(tǒng)會(huì)因?yàn)檫^于靈活，使用路徑過多而易用性變得很差。這兩者的矛盾是很難調(diào)和的。

05

盲目跟風(fēng)

再來看看一些中小型研發(fā)團(tuán)隊(duì)，他們看到國內(nèi)大廠在研效領(lǐng)域不約而同的重兵投入，所以也會(huì)跟風(fēng)。他們往往試圖通過引進(jìn)大廠工具和大廠人才來作為研效的突破口，但實(shí)際的效果可能差強(qiáng)人意。大廠的研效工具體系固然有其先進(jìn)性，但是是否能夠適配你的研發(fā)規(guī)模和流程是有待商榷的，同樣的藥給大象吃可以治病，而給你吃可能直接喪命。很多時(shí)候研效工具應(yīng)該被視為起點(diǎn)，而不是終點(diǎn)，就像你買了一輛跑車，你依舊不能成為賽車手。

06

迷信外部專家

引入大廠專家其實(shí)也是類似的邏輯，我常常會(huì)被問及這樣的問題：“你之前主導(dǎo)的研效提升項(xiàng)目都獲得了成功，如果請你過來，多久能搞定”？這其實(shí)是一個(gè)無解的問題。一定程度上，投入大，周期就會(huì)短，但是，實(shí)施周期不會(huì)因?yàn)橥度霟o限大而無限變短。我可以幫你避開很多曾經(jīng)踩過的坑，盡量少走彎路，犯過的錯(cuò)誤不再次犯，但是，適合自己的路子還是要靠自己走出來，拔苗助長只會(huì)損害長期利益。

07

研效度量的罪與罰

最后再來看看度量。研發(fā)效能的度量一直以來都是很敏感的話題?？茖W(xué)管理時(shí)代我們奉行“沒有度量就沒有改進(jìn)”，但是數(shù)字時(shí)代這一命題是否依然成立需要我們的反思?，F(xiàn)實(shí)事物復(fù)雜而多面，度量正是為描述和對(duì)比這些具象事實(shí)而采取的抽象和量化措施，從某種意義上來說，度量的結(jié)果一定是片面的，反映部分事實(shí)。但沒有銀彈，也沒有完美的效能度量。數(shù)據(jù)本身不會(huì)騙人，但數(shù)據(jù)的呈現(xiàn)和解讀卻有很大的空間值得探索。那些不懂?dāng)?shù)據(jù)的人是糟糕的，而最最糟糕的人是那些只看數(shù)字的人。當(dāng)把度量變成一個(gè)指標(biāo)游戲的時(shí)候，永遠(yuǎn)不要低估人們在追求指標(biāo)方面“創(chuàng)造性”，總之我們不應(yīng)該純粹面向指標(biāo)去開展工作，而應(yīng)該看到指標(biāo)背后更大的目標(biāo)，或者是制定這些指標(biāo)背后的真正動(dòng)機(jī)。

總體來看，對(duì)于研發(fā)效能，我認(rèn)為最重要的不是技術(shù)升級(jí)，而應(yīng)該是思維升級(jí)，我們身處數(shù)字化的變革之中，需要轉(zhuǎn)換的是自己的思維方式，我們需要將科學(xué)管理時(shí)代的思維徹底轉(zhuǎn)為字節(jié)經(jīng)濟(jì)時(shí)代的思維。

研發(fā)效能的“冷思考”

最后，回到工程師層面，研發(fā)效能的提升對(duì)我們而言又意味著什么？

01

工具效率的提升并沒有減少我們的工作時(shí)長

新工具新平臺(tái)在幫助我們提升效率的同時(shí)，也不斷增加著我們學(xué)習(xí)的成本。用前端開發(fā)來舉例子，以全家桶為基礎(chǔ)的前端工程化大幅度提高了前端開發(fā)的效率，但與此同時(shí)前端開發(fā)工程師的學(xué)習(xí)成本卻在成倍增加，“又更新了，實(shí)在學(xué)不動(dòng)了”一定程度反映了前端同開發(fā)的悲哀和無奈。

02

技術(shù)的升級(jí)正在不斷模糊工作和生活的邊界

早年時(shí)候的工作溝通除了面聊以外主要靠郵件，非工作時(shí)段老板給你發(fā)郵件你有各種正當(dāng)理由不用及時(shí)回復(fù)，可是現(xiàn)在及時(shí)通訊工具IM（那個(gè)消息已讀提示，你懂的）再結(jié)合各種ChatOps實(shí)踐，已經(jīng)讓工程師已經(jīng)無法區(qū)分什么是工作什么是生活了，這難道是我們想要的嗎？

隨著在研發(fā)效能領(lǐng)域的不斷投入，會(huì)有越來越多的研效工具誕生，所有這些工具都使人與工作之間的鏈接更加緊密，人越來越像工具，而工具越來越像人。我們之所以創(chuàng)造工具是想減輕我們自己的工作，但現(xiàn)實(shí)卻很可能發(fā)展成，我們最終淪為被親手創(chuàng)造的工具奴役。我們致力于的研發(fā)效能，究竟會(huì)成就我們，還是毀了我們？值得我們深入思考。

對(duì)于研發(fā)效能，實(shí)施的思路不對(duì)，方法不對(duì)會(huì)搞垮一個(gè)團(tuán)隊(duì)，我們需要的是體系化的方法論和相應(yīng)的工程實(shí)踐。請期待我們的下篇文章對(duì)此作出解讀，讓我們拭目以待！

作者：茹炳晟

簡介：騰訊T4 級(jí)專家，騰訊研究院特約研究員，業(yè)界知名實(shí)戰(zhàn)派研發(fā)效能和軟件質(zhì)量雙領(lǐng)域?qū)＜?。騰訊云、阿里云、華為云最具價(jià)值專家，Certified DevOps Enterprise Coach ，年度 IT 圖書最具影響力作者，暢銷書《測試工程師全棧技術(shù)進(jìn)階與實(shí)踐》和《高效自動(dòng)化測試平臺(tái)：設(shè)計(jì)與開發(fā)實(shí)戰(zhàn)》作者，極客時(shí)間《軟件測試 52 講—從小工到專家的實(shí)戰(zhàn)心法》作者。