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