1. 首頁 > 生活百科 > >

DevOps｜從特拉斯辭職風波到研發效能中的不靠譜人干的荒唐事

生活百科

今天發生了一件大事特拉斯辭任英國首相，我想借著這件事情說下我看到的一件研發效能的荒唐事 ， 這其中的關聯也許就是「都用了不靠譜的人」 。
兩件事情
今兒一早就聽到，2022年10月20日英國第78任首相伊麗莎白·特拉斯宣布辭職 。特拉斯上任后任命她的「密友克沃滕」出任財政部長推出「迷你預算」結果引來英國金融大震蕩，英鎊對美元匯率跌幅達3% ， 股市和英國國債均大幅下挫 。最后架不住投資者、保守黨和民意，辭去英國保守黨黨首職務，自動卸任英國首相職務 ， 任職45天，也是英國歷史上任期最短的首相 。
迷你預算這事干的真不靠譜，一發出來股市、匯市、國債齊跌 。具體原因大家可以自行搜索，總之這就是不靠譜的人不專業的人才能捅出來的大窟窿，但凡有點花生米也不至于如此 。我做研發效能這么多年 ， 也見過一件只有不靠譜的研發效能團隊才能干出的事 。
這件事就是把全公司「90%」的代碼倉庫設置成全 internal。什么意思呢？只要你是 gitlab 的用戶并且登錄，那么公司除了少部分被設置成 private 的代碼倉庫，其它 90% 以上的倉庫你都可讀(可以克隆到本地） 。當很多公司都在梳理倉庫權限，建議把權限設置成 private 的時候，居然有人推動把公司的絕大部分倉庫開放出去 。我了解了一下，這樣做的目的是項目公司內部開源 。當時我內心的想法是「擦....老板又被不靠譜的人給忽悠了」 。
內部開源(Inner Source)
我找了一些資料列下來 。這也許就是他們忽悠老板的理由吧 ， 可是仔細一看這些都站不住腳啊 。

內部開源（Inner Source）簡稱內源，指把開發開源軟件中學到的經驗教訓應用到公司或組織內部開發軟件的實踐 。公司和組織可以在內部開源的同時開發專有軟件 。
荒唐做法理由之「開放式協作」
  • 在推行內源的公司，所有員工都必須可以訪問所有需要的開發制品（例如，代碼、文檔、問題跟蹤等） ?；陂_放式協作的原則（平等的、精英領導的、自組織的），通常歡迎愿意為內源項目提供幫助的所有貢獻者 。
  • 公開討論決策時，開放式溝通也實現了精英制度 。盡管組織不一定要變成徹底的自組織來適應內源，但是內源允許個人，組織單元和項目團體具有更高程度的自組織 。
企業內部代碼庫全部內部開源，期待有人關心，感興趣，看了代碼后能幫修復個bug添加個功能，和原有負責團隊一起討論、形成方案 。真的會出現這種情況么？
企業內部每個工程都是分工明確，職責清晰的團隊在維護 。內部公開后，真的有其它團隊去看、克隆下來學習學習、有空的時候幫修復個bug添加個功能？沒事干閑得慌了么？如果真的有這樣的情況且這樣的情況很多，我覺得我們更應該反思為啥有這樣的情況出現 。為啥有這么多閑著的人，不忙自己的業務，去跟其它的團隊一起討論功能、修bug、添加功能、保證質量 。
荒唐做法理由之「開放式溝通」
  • 開放式的溝通可以讓內源項目和軟件中的所有成員能夠公開參與所有的交流互動 。開放式溝通是公開的（在公司內部）、書面的、有存檔且完整的 。目的是允許與內源項目有關或感興趣的任何個人或團體參與溝通 。開放式溝通是會被存檔的，軟件的詳細文檔會被收集起來，團隊可以回顧當時的討論和決策 。
公司內部的公共組件可以把自己的文檔、源碼公開這倒是沒問題 。本來有一些幫助文檔也是要公開的，以便大家閱讀 。其它的真有必要么？比如平臺的需求、PRD、設計稿、測試用例、程序代碼、編譯腳本.....其它團隊真的想去插一腳？除非兩個團隊負責的系統之間有依賴或者協同，否則實際很少出現這種情況 。即便系統之間有接口調用，也都是在接口維護平臺上查看參數和文檔，而不是去扒拉對方的代碼 。我就用一個接口，你讓我了解你的平臺，這效率也忒低了 。
荒唐做法理由之「通過分離角色保證產品質量」
  • 專門的代碼審查以及貢獻者和提交者（擁有寫入權限的集成者、開發者）分離，可以確保開源項目的質量，也可以保證內源項目的質量 。
很難想象有人給其它團隊PR 。不要對團隊外的其他人抱有能提升產品質量的想法，他們沒義務，也沒興趣 。
企業內源不靠譜、不適合國情
我覺得上面的做法非常不適合國情 。企業內部開源和社區開源根本就不是一回事 。開源社區真是靠興趣、靠愛在發電，而國內的企業內部根本不存在這樣的土壤 。

推薦閱讀