認清它，承認它，然后改變它。
1. 前言
原本以為三部曲之后，相關的話題算是有了個結論。但恰恰相反的是隨著輸出總結的增加，再次審視當下的研發(fā)流程，發(fā)現(xiàn)相關人員存在非常大誤解。
其中比較典型的誤解就有：
- 我這每天忙得喝水時間都沒有，這效率還低得了？
- 相較于以前，我們現(xiàn)在已經(jīng)形式了基本流水線式的分工協(xié)作，這效率還不高？
- 問題解決慢是因為人手不足導致的。
2. 先回答問題
- 忙不等于效率高。
這個觀點，說起來都認同，但實際執(zhí)行起來就完全兩碼事。
坐那神經(jīng)高度集中，喝口水的時間都沒有，同樣的工作今天做了明天接著做，第一次解決時候花費一周，第十次解決的時候還是需要五天；然后同樣的問題換個團隊成員又是從零開始摸索，花費甚至更長的時間；凡此種種，你說這種忙，除了感動得自己之外，它的有效價值能夠有多少？哪個冤大頭又會愿意為此買單？
另外一個例子就是，需求來了，哎呀限期一周，時間太緊張了，趕緊代碼敲起來，不然又得加班了。于是需求大概瞟一眼，"哪有時間看那么細致，做到那里了再說吧"，另外溝通也太耗時了，有什么疑問就直接按照自己認為的方向做就行了，甚至根本不會意識到這個點會存在疑問。
最后到了要交付東西的時候了，這怎么能不是你要的呢？ 我就是按照你的要求做的啊，期間我這還加了兩次班呢。 最后就只能讓領導出面和客戶協(xié)商再寬限幾日，然后研發(fā)這邊加班加點地重新實現(xiàn)。
確實很辛苦，但是，這效率高嗎？
- 由三十分優(yōu)化到現(xiàn)在的六十分，看著確實進步不小，能夠想象到做出這樣的改進，各崗位人員，尤其是關鍵節(jié)點人員，付出的辛勞肯定不少；但是，這和效率高沒有半毛錢關系，畢竟你這也就是剛剛及格，上面還有著相當?shù)倪M步空間。
我們團隊確實剛經(jīng)歷過一次這樣的優(yōu)化，現(xiàn)在還對當時改良期間壓力最大的那段時間心有余悸，不過好在最后走出來了。
相較于我們過往的團隊，研發(fā)效能確實有了一定提升，如果只是以自身為參照物，可以說是提升巨大。但是正如初中學過的《資本論》里“商品的價值由社會必要勞動時間決定”， 你覺得自己能牛逼那沒用啊，你最終還是要和整個行業(yè)平均進行比較。
- 人手少不是問題解決太慢的原因。
首先明確下這個"問題解決太慢"的含義：問題整體數(shù)量多，消化慢，甚至出現(xiàn)問題出現(xiàn)的速度快于修復的速度，蓄水池水位不斷上升的情況。
很多人，包括不少領導認為問題太多，解決太慢是因為人手不足導致的，但在多年的研發(fā)經(jīng)驗，實際觀察下來，我始終無法茍同類似的觀點。
誠然，增加人手在直覺上可以加快進度，而且在實際中也確實發(fā)生了無數(shù)次這樣的場景。但是，如果仔細回顧和復盤，你就會發(fā)現(xiàn)這類場景通常是業(yè)務比較簡單，系統(tǒng)維護時間較短，中途介入的人需要了解更多的前置知識就可以上手。
軟件開發(fā)不是搬磚，十個母親不能在一個月內(nèi)生出一個孩子。
而且更重要的是我們是不是要思考下：解決問題太慢會不會是應該解決問題的效率太低了?
- 正如上面已經(jīng)論述完畢的：不是說你忙到喝水時間都沒有就是效率高。
- 一個問題花費三天時間解決和一個問題花費半小時解決，這兩者有著云泥之別。
軟件問題調(diào)試這塊存在一個共識："解決問題簡單，但定位問題很難"。這也是為什么現(xiàn)在的云原生里如此強調(diào)"可觀測性"。
如何縮短問題解決慢的問題：
- 不斷加強系統(tǒng)的"可觀測性"，除了在系統(tǒng)設計之初，根據(jù)過往經(jīng)驗和業(yè)內(nèi)的最佳實踐加入對于可觀測性的架構考量；也需要在系統(tǒng)的實際迭代過程中不斷增強其可觀測性，增加系統(tǒng)透明性。
- 持續(xù)強化針對問題定位的反饋環(huán)執(zhí)行效能。這里舉個最近發(fā)生在我身上的例子。在接到問題報告，明確問題表現(xiàn)后(這其中還經(jīng)歷了一次X-Y問題)，第一輪反饋環(huán)從上午十點一直到下午四點才完成，耗時六小時。也就是說如果按照這個效率，第二輪反饋環(huán)到下班都是無法完成的。試想在這樣的反饋環(huán)周期下，問題解決的效能怎么高起來？五分鐘的反饋環(huán)周期和一天，甚至一周的反饋環(huán)周期，兩者之間有著千萬倍的差異。
- 至于如何加快問題反饋環(huán)效能，除了上面所說的基礎設施完善，系統(tǒng)架構優(yōu)化，還有相關的人員技能培養(yǎng)也是應該被逐步規(guī)范化，流水線化的。
3. 補充一些現(xiàn)狀說明
上面的誤區(qū)一里，我們主要是從個人角度去探討研發(fā)效能，但其實站在整個團隊的角度，傳統(tǒng)軟件行業(yè)也存在著一個非常隱蔽的，導致大量研發(fā)效能損失的問題 —— 研發(fā)小組的各自為戰(zhàn)，以及基礎設施的缺失導致研發(fā)人員寶貴的時間和精力被大量消耗在所謂"技術難點解決"，以及基礎依賴環(huán)境維護等細枝末節(jié)上。
3.1 "技術難點"？
首先，傳統(tǒng)軟件公司很難有所謂的技術難點。
其次，這里所謂的"技術難點"，基本只能算是對于當事人而言之前沒有接觸過，如果站在整個研發(fā)團隊層面，就會發(fā)現(xiàn)其實類似問題，已經(jīng)解決過很多次了。
但因為團隊缺乏相關的沉淀，分享的制度和氛圍，小組之間各自為戰(zhàn)，導致整個團隊始終在低維度問題上循環(huán)反復，疲于應對項目工期，無法對問題做進一步的深入；組長覺得研發(fā)團隊效能低，組員又覺得團隊技術low，進步慢。各方都對現(xiàn)狀不滿，相互抱怨。
研發(fā)人員需要耗費大量精力在這些所謂的技術難點上，工期又那么緊張，那溝通上當然能推就推，畢竟功能沒實現(xiàn)出來是一眼能看出來的量化標準。
但缺乏溝通導致最終結果不滿足最終要求，你能拿我咋滴，我還說你需求表訴不清楚，另外一邊人不行，不配合，你確定在用戶追著屁股問進度的情況下，你要和我掰扯為什么溝通不暢的問題？
3.2 基礎設施缺失
很多時候，我在團隊里強調(diào)"基礎設施缺失"概念的時候，組員甚至領導的第一反應是：我們機器確實不足。
缺乏足夠的機器資源確實是基礎設施缺失的一個很大的方面，但是如果將問題始終歸結于這種短期內(nèi)很難有所改進的現(xiàn)狀，這不是個想要解決問題的態(tài)度。
-
基礎設施缺失的一個表現(xiàn)是，對于傳統(tǒng)軟件行業(yè)技術團隊而言，面對復雜的業(yè)務特點，經(jīng)常出現(xiàn)一個人要應對多個項目的情況，經(jīng)常需要和多種設施對接的情況，例如ftp，各類數(shù)據(jù)庫，oss，短信服務等等。
研發(fā)人員在遇到類似需求的時候，經(jīng)常無法得到團隊層面的支持，甚至這些依賴的下載地址都得自己去找，于是不知道從哪個犄角旮旯找到個版本，然后自己找臺機器，甚至就只能在自己本機上安裝，然后還要自己去尋找相關的對接操作手冊（嗯，這個問題又回到上一個"技術難點"）。
如果一切順利，那么本機測試通過之后，生產(chǎn)環(huán)境上也通過；但現(xiàn)實往往不會如此完美，經(jīng)常出現(xiàn)的一種情況是研發(fā)找到的版本和實際生產(chǎn)環(huán)境版本不一致，或者安裝配置方式有差異（最典型的就是數(shù)據(jù)庫的編碼），導致或者本地測試始終詭異失敗，或者本地成功的版本，在生產(chǎn)環(huán)境下始終無法成功。
這樣的操作只要來個兩回，對行業(yè)或公司多大的熱情都能給澆得透心涼。畢竟整場復盤下來，和所謂技術成長，能力提升，問題解決沒有半毛錢關系，有的只是一個人孤軍奮戰(zhàn)，被小水坑折磨出面對汪洋大海的挫折感。
-
基礎設施缺失的另外一個表現(xiàn)就是CICD基本為零，這導致研發(fā)團隊基本都是研發(fā)運維一擔挑，測試階段的版本控制(如果有的話)，安裝部署，更新替換，配置更改等等都是研發(fā)人員你就自己來吧，所以那些驚為天人的class文件替換，本地環(huán)境配置和測試環(huán)境配置使用同一套等等基本也就是情有可原了。
在這樣的研發(fā)測試環(huán)境下，明明更新了代碼但問題表現(xiàn)還是和之前一樣，這樣的幽靈問題就并不是什么新鮮的事情了。
試想在這樣的氛圍下組織起來的團隊，你怎么能去奢望所謂的集體榮譽感，團隊氛圍良好？
4. 突破
以上背景下，我們要從行業(yè)認知，職責確認，基礎設施搭建等多個維度發(fā)力。
4.1 實際的開發(fā)中，編碼工作量只有1/6
以上結論來自《人月神話》。
首先，需求反復導致的編碼過程反復，這里的工作量只有1份， 而不是 1 + 1 + 1 + .... 。
前期偷懶不進行需求詳細了解，上來就直接干活導致的編碼反復，這不應該算在編碼工作量里。
傳統(tǒng)業(yè)務型軟件公司項目特點很大部分都是前期需求不明確，這個是現(xiàn)實，在編碼時依據(jù)經(jīng)驗多想一步（注意這里的量詞），或者按原型方式編碼；至于你說我哪能想到云云，公司按照工作經(jīng)驗評定職級，所看重不正是這個嗎？另外我們從來沒未奢望誰可以第一次作到勝任，毫無改進的重復才是最不被容忍的。
然后就是架構設計時，編碼工作量的多少不應該是被主要考慮的問題。但根據(jù)過往的經(jīng)驗，喊聲最大的就是這些研發(fā)人員，這些聲音會給架構師常常造成困惑，雖說代碼越少，BUG越少；但代碼量多少不應該成為架構是否合理的重要指標，架構的重點是落腳于公司的實際業(yè)務情況，來進行相應的抉擇和各要素間的平衡。所謂代碼量問題，完全可以通過代碼生成器，二方庫等進行補充。
4.2 一個問題：中層技術管理者的責任是什么，應該做什么？
除了技術上的沉淀，以及架構上的不斷迭代外，另外一個我們需要重新審視的問題：中層技術管理者的責任到底是什么？
所謂的“技術難點突破，培訓新人，對結果負責”等等這些說爛的詞這里我不想再嚼甘蔗渣。以下我想要重點強調(diào)的是一個我們隱約能夠感覺到，但實際執(zhí)行時卻經(jīng)常置之腦后的職責 —— 想盡一切辦法提升研發(fā)人員的研發(fā)效能，極力避免他們在必要工作之外的精力分散。
上面說法比較抽象，讓我們來定義一下必要工作：理解業(yè)務需求，將業(yè)務邏輯轉換為代碼。
上面這種說法依然有點抽象，那么讓我們再具體一點，理想情況下，假設現(xiàn)在有一個對接阿里云OSS的需求，相應的業(yè)務研發(fā)人員需要怎么做？
- 從團隊提供的研發(fā)測試資源管理頁面，找到團隊預先購買好的阿里云OSS測試賬戶和密碼。 這個過程耗時一分鐘。 （相對應的，我見過不少團隊里，從阿里云賬號申請，資源購買都是當事組員自力更生，然后下一個組員繼續(xù)）
- 從WIKI中找到部門沉淀的附件操作二方庫，在入門操作文檔的指引下，完成對于阿里云OSS的業(yè)務對接。這個過程耗時半小時。（相對應的，依然是組員自行尋找阿里云OSS的 API文檔，然后對照著文檔一個個坑地這么踩過去，完成對接）
- 該組員將上一步中二方庫的使用心得，以及相應操作文檔感覺不完善的地方，在相應評論進行回復，給后來者以提示。（相對應的，我這孤軍奮斗搞出來的東西，現(xiàn)在只是看著像實現(xiàn)了，我自己心理都沒底，還想讓我沉淀，這從零開始寫篇文檔多費勁，你給錢嗎？）
依然以上面的例子引申，在上述理想操作流程之下：
- 研發(fā)測試資源管理頁面（也就是所謂的資源黃頁）以及背后提供支撐的一系列資源。
- 附件操作二方庫的發(fā)起和迭代，相應使用手冊的維護，組件的宣講培訓等等。
以上這些，都是中層技術管理者的責任，而且除此之外，CICD以及周邊一整套諸如版本管理，版本發(fā)布等等，也都是需要中層技術管理者在實踐中不斷實踐和演化的，總而言之，組員的研發(fā)效能是非常關鍵的考核指標。如果只想著“我把任務分給你了，除了上交成果外，其它的問題你都自己解決，別來煩我”，這樣的技術管理者無疑是非常失職的。
只有如此，團隊向心力，凝聚力，團員幸福感才不至于是無根之水，才能最大程度地維持住團隊梯度的穩(wěn)定性，不至于組員離職造成整個業(yè)務的劇烈震動。
5. 應該什么樣？
讓我們匯總下，一個新入職的業(yè)務研發(fā)人員，應該是如何適應團隊：
- 一個月之后，任何新人只在業(yè)務理解上需要詢問別人，其它絕大部分技術類問題都可以自行從部門的知識庫中找到答案。
- 研發(fā)人員主要精力應該在理解業(yè)務上，不應該太多的任何技術難點需要解決。
- 除了理解業(yè)務和將業(yè)務邏輯轉換為代碼，其它的都不需要關心。什么打包，發(fā)布，版本管理，下載，部署，都已有一套標準化的流程，提交代碼之后，整個流程會自動生產(chǎn)相應的制品包，測試通過之后納入制品版本管理系統(tǒng)，供各方下載使用。待使用出現(xiàn)問題時，借助禪道等管理平臺開始下一輪迭代。
- 對于生產(chǎn)環(huán)境下反饋的問題， 80%都應該在運維層面就被解決掉，只有剩下的20%問題踩能擊穿地方運維，售后，測試構筑的層層防護網(wǎng)，達到研發(fā)這，并且這20%問題下次就會變成前80%問題。
6. 參考
- 作為中層領導，你要做的是盤點/整合資源，讓下屬有活干，成就他們，幫助公司提高基層員工的工作效率。
- 為什么國內(nèi)開源氛圍這么差？大廠都在卷自己的輪子？ - 為解決自己在特定場景下的某個問題寫一段代碼很容易；為解決大家在多種場景下的某個問題寫一段代碼真踏馬煩。
- 能大規(guī)模商用的技術，都不需要智商，否則這種技術就不可能規(guī)?；?。
- 傳統(tǒng)軟件行業(yè)中技術團隊的發(fā)展(現(xiàn)狀篇)
- 傳統(tǒng)軟件行業(yè)技術團隊的發(fā)展 - 做好技術棧統(tǒng)一
- 傳統(tǒng)軟件行業(yè)技術團隊中如何做好知識沉淀
- 《軟技能2》讀后感
