我在前幾家公司任職cto時都推行過研發文化。主要推的三個文化就是：工具文化、**文化、資料文化
一、文化提出
為什麼推著三個文化？推這三個文化的初源是什麼？
1、工具文化提出的初源：
1.1、很多人寫**，都是copy、修改。但引發的問題就是：copy源的一些**沒有刪減乾淨，致使異常觸發，致使**難以被新來的人看懂為啥會寫這些**
1.2、有規範，但很難被大家記住，並統一按規格全息落地執行。所以需要把規範轉換成可生產過程中使用的工具
2、**文化提出的初源：
2.1、過去大家總是花很多時間空對空討論、對著想象的設計寫成的文件進行反覆的層層道道評審，最後花了大量時間做出來的開發終於發版了，使用者一試用發現和自己最初討論的想象的東西根本不一樣，於是又進入新一輪的空對空討論、想象性設計文件、趕工的開發和漫長的嚴謹的測試。
為啥不去先做個原型大家先來給大家乙個直觀呢？有人又說了，原型**在正式開發時扔掉按照商用**重新架構設計重新開發呢，還是做商用產品時就在原型**上繼續修改呢？
3、資料文化提出的初源：
3.1、過去銷售、實施、客服、產品、開發、測試，各說各有理，討論會上繪聲繪色的講某個具體客戶有某個具體不爽的使用場景，企圖來證明這個問題很重要很嚴重，需要立即處理。其實事實上是不是如此，根本沒有多人佐證這是事實。那就看誰會說了、誰會現場靈機應變了。
所以我提了出來，到底需求是不是普遍的，到底問題是不是常犯的，拿資料來證明。
但是，三個文化是提出來了，也在各種場合各層次員工群體中反覆的宣講了，也事對事及時提醒了，也拍桌子了，但有個毛用。
看來需要實措施才能落地虛文化。
二、工具文化的關鍵落地措施：
1、明確定義leader的工作職責就是：工具/模板/**框架/規範/高效協同流程的制定和推廣落地應用；實現方案總體設計與把控；團隊實現分工分任務、整體推動與協調；團隊專案覆盤總結、經驗知識分享傳播、新人指導。
過去是缺乏高階程式設計師和leader，leader實際上是高階程式設計師，但因為乙個團隊總需要乙個頭，於是他也是leader。leader和高階程式設計師融為一身，平時主要做專案中最核心的模組，從設計到開發全部搞定，最難的異常分析、修改也是他乙個人搞定，其他人都搞不來。這就出現了他是瓶頸，他是最忙的，中級程式設計師都是熟練手，新人沒人指導成長緩慢。
這樣職責明確定義後，leader就幹這些事，本來高階程式設計師要做的最核心最難的模組，分成兩人配合：leader設計和實現**框架，中級程式設計師來填具體細節實現**。
2、定義leader的kpi：專門有一項是工具/模板/**框架/規範/高效協同流程的制定和推廣落地應用的情況怎麼樣，專設kpi
但這個kpi是個定性的分數區間，由他的上級來打分。但上級打分這樣的方式不好。我本來是希望讓他的下級來評，但被總監級、以及hr以評價太複雜、大家工作太忙為由而阻止了。
該不該設kpi，怎麼評價，誰來評價，希望大家能給我一些好建議
3、榜樣推廣、獎金激勵：kpi是一方面，我也設了軟性的激勵手段。如：公司內網部落格邀請他寫總結文章，在研發電子期刊上對他和他的工具模板成果進行介紹與推廣，在公司大講堂上分享他的成果使用方法。而且設了獎金獎項，每個季度都有獎金和獎品。
二、**文化關鍵落地措施：
1、code review會：
過去做code review，是leader偶爾做不固定做，不像國外軟體公司，**check進主庫前必須leader或同級來交叉做code review，在中國這行不通。而且過去也是某些leader靠自己對自己團隊的自我期許要求做，有的leader對自己團隊的產出要求高，他就做，有的leader是趕活交差他就不做。
我曾經也想把codereview的職責安給leader，但是做不到啊。
於是我想了乙個辦法，讓leader帶著大家做codereview。而且是從本月或上月自己團隊犯的最嚴重的乙個錯誤bug入手，開啟**，大家一起，一起來過**，大家一起來找問題根源，大家一起來討論改進措施。
這樣做codereview，目的就不是檢查**質量了，也不是找bug根源了，而是leader和大家一起，拿著真實**，拿著真實問題，來一起討論**質量的提高。這本質就成了團隊學習提高會了。這個方法非常有效，對大家自我的警醒促進作用也非常的大。
我還制定了固定制度：每個月必須留出兩個半天，來做團隊學習會。而做團隊學習會，可以是codereview、可以是專案知識提前學習、可以是團隊經驗總結分享。這樣就避免了有的團隊留住時間瞎做團隊學習，因為曾經出現過有的團隊一開始做團隊學習會，上來就搞了乙個讀書心得分享會。這就有些脫離具體生產了。
三、資料文化關鍵落地措施：
1、研發開放需求系統、開放bug系統：
到底哪些需求被人們反覆提，到底多少人提，是哪些客戶提，到底問題有多嚴重，現在有了統計。
現在再制定研發計畫、放入研發需求，就不會誰嗓門大、誰跟誰關係好、誰能說會辯，而是看庫做統計。
2、開發底層埋點功能：
提需求這事吧，和人有關。有的人墨跡、有的人大方，有的人希望自己被關注，有的人希望設坎卡別人，都各有各的屁股各有各的利益想法，但他不會光明正大的說出真正他想要的目的，而是包裝以光明正大的理由讓你去修改，往往產品經理和程式設計師不省人事背後的複雜，按需求按事改，改來改去還不滿意。很多時候我們急著趕著開發完，後來這個功能他們也沒用多少次。
所以我就著手平台研發，開發底層埋點日誌框架，自動記錄我們想跟蹤的資料，比如功能點使用量、業務處理平均時長、資料變更量、資料增長量等等。根據統計對比來看我們辛辛苦苦做出來功能是否被真的業務利用上了，是否加快了他的工作效率。
IPU到底是個什麼鬼？
在 i.mx6 應用處理器中，有乙個很重要的單元 ipu image processing unit 影象處理單元。影象處理單元的目標是提供從影象輸入 攝像頭感測器 電視訊號輸入等 到顯示裝置 lcd顯示屏 tv輸出 外部影象處理單元等 端到端的資料流訊號處理的全面支援。ipu庫 ipu libra...
volatile到底是個什麼鬼 詳解
先看乙個現象，main執行緒對run變數的修改對於t執行緒不可見，導致了t執行緒無法停止 static boolean run true public static void main string args throws interruptedexception t.start sleep 1 r...
關於Redux到底是個什麼鬼
我們故事的主人公，小明。小明大學剛畢業，擺脫了宿舍的集體生活，自己在外面租了個一室一廳的小公寓住。這是客廳的平面圖 一天小明邀請小馬來家裡做客。小馬說 呀你家的家具擺放位置好奇特！這種通過眼睛看到的視覺效果，就是react。每乙個家具都是乙個component，各種不同的components組成了乙...