DevOps｜從特拉斯辭職風波到研發效能中的不靠譜人乾的荒唐事
今天發生了一件大事特拉斯辭任英國首相，我想借著這件事情說下我看到的一件研發效能的荒唐事，這其中的關聯也許就是「都用了不靠譜的人」。
兩件事情
今兒一早就聽到，2022年10月20日英國第78任首相伊麗莎白·特拉斯宣布辭職。特拉斯上任後任命她的「密友克沃滕」出任財政部長推出「迷你預算」結果引來英國金融大震蕩，英鎊對美元匯率跌幅達3%，股市和英國國債均大幅下挫。最後架不住投資者、保守黨和民意，辭去英國保守黨黨首職務，自動卸任英國首相職務，任職45天，也是英國歷史上任期最短的首相。
迷你預算這事乾的真不靠譜，一發出來股市、匯市、國債齊跌。具體原因大家可以自行搜索，總之這就是不靠譜的人不專業的人才能捅出來的大窟窿，但凡有點花生米也不至於如此。我做研發效能這麼多年，也見過一件只有不靠譜的研發效能團隊才能幹出的事。
這件事就是把全公司「90%」的程式碼倉庫設置成全 internal 。什麼意思呢？只要你是 gitlab 的用戶並且登錄，那麼公司除了少部分被設置成 private 的程式碼倉庫，其它 90% 以上的倉庫你都可讀(可以克隆到本地）。當很多公司都在梳理倉庫許可權，建議把許可權設置成 private 的時候，居然有人推動把公司的絕大部分倉庫開放出去。我了解了一下，這樣做的目的是項目公司內部開源。當時我內心的想法是「擦….老闆又被不靠譜的人給忽悠了」。
內部開源(Inner Source)
我找了一些資料列下來。這也許就是他們忽悠老闆的理由吧，可是仔細一看這些都站不住腳啊。
內部開源（Inner Source）簡稱內源，指把開發開源軟體中學到的經驗教訓應用到公司或組織內部開發軟體的實踐。公司和組織可以在內部開源的同時開發專有軟體。
荒唐做法理由之「開放式協作」
- 在推行內源的公司，所有員工都必須可以訪問所有需要的開發製品（例如，程式碼、文檔、問題跟蹤等）。基於開放式協作的原則（平等的、精英領導的、自組織的），通常歡迎願意為內源項目提供幫助的所有貢獻者。
- 公開討論決策時，開放式溝通也實現了精英制度。儘管組織不一定要變成徹底的自組織來適應內源，但是內源允許個人，組織單元和項目團體具有更高程度的自組織。
企業內部程式碼庫全部內部開源，期待有人關心，感興趣，看了程式碼後能幫修復個bug添加個功能，和原有負責團隊一起討論、形成方案。真的會出現這種情況么？
企業內部每個工程都是分工明確，職責清晰的團隊在維護。內部公開後，真的有其它團隊去看、克隆下來學習學習、有空的時候幫修復個bug添加個功能？沒事幹閑得慌了么？如果真的有這樣的情況且這樣的情況很多，我覺得我們更應該反思為啥有這樣的情況出現。為啥有這麼多閑著的人，不忙自己的業務，去跟其它的團隊一起討論功能、修bug、添加功能、保證品質。
荒唐做法理由之「開放式溝通」
- 開放式的溝通可以讓內源項目和軟體中的所有成員能夠公開參與所有的交流互動。開放式溝通是公開的（在公司內部）、書面的、有存檔且完整的。目的是允許與內源項目有關或感興趣的任何個人或團體參與溝通。開放式溝通是會被存檔的，軟體的詳細文檔會被收集起來，團隊可以回顧當時的討論和決策。
公司內部的公共組件可以把自己的文檔、源碼公開這倒是沒問題。本來有一些幫助文檔也是要公開的，以便大家閱讀。其它的真有必要麼？比如平台的需求、PRD、設計稿、測試用例、程式程式碼、編譯腳本…..其它團隊真的想去插一腳？除非兩個團隊負責的系統之間有依賴或者協同，否則實際很少出現這種情況。即便系統之間有介面調用，也都是在介面維護平台上查看參數和文檔，而不是去扒拉對方的程式碼。我就用一個介面，你讓我了解你的平台，這效率也忒低了。
荒唐做法理由之「通過分離角色保證產品品質」
- 專門的程式碼審查以及貢獻者和提交者（擁有寫入許可權的集成者、開發者）分離，可以確保開源項目的品質，也可以保證內源項目的品質。
很難想像有人給其它團隊PR。不要對團隊外的其他人抱有能提升產品品質的想法，他們沒義務，也沒興趣。
企業內源不靠譜、不適合國情
我覺得上面的做法非常不適合國情。企業內部開源和社區開源根本就不是一回事。開源社區真是靠興趣、靠愛在發電，而中國的企業內部根本不存在這樣的土壤。
- 中國工作節奏快，每個人都很忙。這種讓人每天加班到深夜，還要用愛去給別人發電的做法非常不靠譜。
- 中國一個蘿蔔一個坑，自己的坑自己填。別人不給你挖坑就很好了，千萬不要指望別人給你填坑。
- 另外這種目的不明確邊界的介入，很容易讓負責的團隊認為是「搶活」
可能的「解」
最近我也寫過一篇文章《研發效能之技術治理》，我覺得「技術治理架構師」這個崗位可以來承擔、完成企業內部開源的工作，「也許是」最可能達到目的的人選。
技術治理的目的：
梳理公司技術現狀、制定技術治理方向
協調制定技術選型、研發流程等技術類規範
解決公司業務發展過程中遇到的共性問題和技術挑戰
為不同業務場景提供全面的技術解決方案
進行規章制度、規範、平台使用的宣傳、培訓、佈道、配套工具推廣等
文章總結
分工明確、職責清晰、各司其職、高效協同是最好的狀態。 中國外情況不同，很多做法都需要仔細斟酌。這種不假思考直接生搬硬套的做法非常不合適，也不安全。說不定哪天程式碼就「意外」跑到 github 上去了，還很難查是哪裡泄漏出去的，全公司的人都有許可權啊。我覺得哪怕干過一天源碼管理的人都整不出這事，各位看官還是招點靠譜的人吧。
另：特拉斯真要是找個靠譜的財政大臣，結局是否會不一樣？
延展閱讀
