新晉總監生存指南系列：
原計劃第五篇人才運營結束後，這個系列就完結，通看一次後發現少了一個板塊：如何構建團隊的資訊通道。猶豫了很久要不要寫這個，因為所謂資訊通道，說白了就是兩個字：開會，長篇大論容易變得神神叨叨，因為開會重點無非就是（誰還不會開會呀）：
1）主題明確；
2）todolist清晰；
3）強力控節奏的主持人；
但考慮系列完整性，這裡還是簡單介紹一下。
在第一章的管理五維能力模型中，我們介紹過“資訊”能力的重要性，對於團隊來說，組織資訊通暢度也非常重要，企業結構越複雜，其溝通成本越高，因為資訊本身是可修剪的：
所以一些大公司有了以下論述：
多提供context，減少control，決策指令不是單純的上傳下達，而是讓同事之間通過提供上下文，通過內部資訊透明來解決問題、做出決策、提高效率。
公司規模到一定階段後，很多角色及會議都會因為資訊傳遞而產生，如：
1）PMO，很多公司會有個PMO跟進專案資訊；
2）各種煩人的會議，週會、月會、彙報會、專案例會、OKR會......
尤其是公司級專案、跨越多個部門、參與人數上1000人，光是資訊同步就會耗費大量成本，這個時候簡單的事情也會變得不簡單。
資訊通暢是一個高效率團隊的重要特質，也是管理機制乃至團隊文化的塑造，資訊閉塞，資訊渠道單一，偏聽偏信，是團隊氣氛壓抑的根因，不可不慎：
一、認識資訊傳遞
從溝通方式來說分為兩類：
1）口頭溝通，1V1的員工聊天、八卦、電話；1VN 的會議通知、培訓、宣講；
2）書面溝通，文件如wiki，程式碼，入職說明單；電子郵件；IM工具如微信，釘釘；專案管理工具如tapd，trello；
技術團隊的業務資訊口口相傳在某個階段一定是常態，引發“單點問題”後會被管理手段介入，處理方式多為備份加文件沉澱。口頭溝通效率高、成本低，但是極易流失；文件沉澱維護成本較高，整理不當也可能導致尋找不易，各有優劣，最好兩者都有......
從溝通目的和結果或者說資訊目的和結果又可以分為：
1）保障專案成果執行；獲取專案資訊，專案會議；
2）保障OKR成果執行；獲取OKR資訊，OKR會議；
3）管理層保障團隊健康運轉；獲取所有專案資訊，解決跨部門協作問題，團隊週會；
4）管理層保障團隊發展方向正確；獲取團隊總體資訊，收集抽象類團隊問題，團隊月會；
5）管理層保障團隊錯誤規避；獲取團隊執行類錯誤資訊，收集工程或組織問題，CaseStudy+專案覆盤；
6）管理層保障leader認知對齊；團隊文化輸出，制度根因對齊，幹訓班會議；
7）為決絕具體事項而召開的專題討論會，如底層框架確定，移動框架選擇，評優設計等；
8）管理層保障團隊健康運轉；讓全員瞭解團隊發展狀況，未來發展方向，制度宣發；半年彙報會；
9）管理層為保障基層員工工作狀態，讓一線心聲（吐槽）有反饋渠道，防止leader不合格封鎖資訊，一線負責人直通車機制；
10）為更瞭解團隊資訊；八卦拉近距離；個人八卦行為（不予理睬即可）。
暫時只能想到這些，需要大家補充。
從物件來說又可以分為：
1）平級之間，leader與leader，一線與一線；
2）上下級之間
3）......
每個切面都可以深入探討，這裡選取溝通目的與結果切入進行深入，其實說白了還是開會......。
二、通用會議模型設計
效率高的會議大同小異，一般由幾個要素組成：
1）明確的會議主題，要解決的問題；
2）能把握節奏的強力主持人，資訊量較全（聰明點的）的會議紀要者；
3）明確的會議結論或者會議後續；
4）有時間、唯一負責人的todolist；
5）有對會議結論持續追蹤的機制；
6）控制會議總時間，最好不要超過2小時（1小時最佳）；
這裡以大家最熟悉的週會為例，做一個demo，這裡需要回答的第一個問題是週會的主題是什麼？
PS：注意，不同團隊對會議的定義不一樣，這裡只是打樣，不可完全套用。
一般來說，週會是每個團隊一定會存在的一個會議，他是幫助團隊瞭解團隊情況的重要且不可替代的會議，也是一些專案及跨團隊問題暴露的重要場所，所以：
週會是同步團隊資訊，包括專案資訊，暴露團隊問題包括專案問題並求助的重要會議
如果對週會目標的定義是同步資訊、暴露問題及風險，那麼就不能在週會上大談解決方案是其一，其中產生的問題，無論是團隊問題或是專案風險問題或是工程建設問題，都應該指定到相關領域的專家，寫定todolist，每次週會跟進執行情況即可，我們現在週會模板大概是這樣的：
質效指標
這塊詳情見新晉總監生存指南二——建立指標，資料指標一定是反應當前團隊情況不可或缺的一部分。
線上問題
線上問題即上週發生的所有線上問題一覽，原則上每個線上問題都需要做CaseStudy，並且CS機制本身就會對問題打標籤，這裡可能的標籤會很多，比如：
-
資料庫相關
-
快取操作
-
指令碼相關
-
測試程式碼未刪除
-
測試用例未覆蓋
-
測試用例未執行
-
測試場景未覆蓋
-
自動化測試用例未覆蓋
-
無法測試
-
......
這裡每個團隊不一樣，不詳細給出。
CaseStudy的會議標準依舊按照之前專案執行指南專案覆盤的來即可：
CIO週報
CIO的目標受眾是一般的使用者，是線上問題的重要來源渠道。隨著業務快速發展，功能越來越複雜，線上問題也是多且雜。
CIO規範定義技術類線上問題的處理步驟，目的是建立技術類問題線上問題的處理標準，提升問題處理的時效性，提高IT服務質量，提升使用者體驗。
並且負責各種場景問題的收集、記錄，聯絡模組負責同事，組建應急人員處理框架，並推動問題落地解決，處理流程如下：
問題專案
重點關注在專案執行過程中所爆發的問題，比如這裡詳述的，所有這些問題在專案覆盤時候都會形成todolist，沉澱到週報中：新晉總監生存指南四——專案執行指南
其他問題
上述沒有涵蓋的問題，比如leader的一些反饋抱怨都可以放到這裡。
todolist
todolist是比較重要的模組，todolist的完成度是監督每次會議是否有意義的一個重要指標，這裡的關鍵點和專案日報差不多，都是把責任定位到人，把跟進時間定清楚即可：
重點還是誰在什麼時候達成什麼目標。
接下來的專案概述乃至工程建設以及OKR概述都是應該有專項會產生會議結果，最後加入週會即可，這裡的重點反而不是暴露問題，而是同步資訊。
至此，一次會議模板便結束了。
三、其他的話
3.1 特殊的會議
當然，在權責利不清的時候，在上層打架的時候，會產生很多扯犢子的事情，比如：
1）一個專案中會有負責人由於某種原因“缺失”的時候；
2）也有兩個部門之間由於資源問題（可能是內卷，也可能是不想吃虧）而來回拉扯，而專案都岌岌可危的時候；
在參與這種會議或者這種時候，你如果是其中的關鍵角色，雖然這麼說未必很好，請一定做好會議紀要，並且跟多方確認，發出郵件，留下“證據”，這類專案失敗的風險極高，要留下一些材料免責......
節奏控制不好的專案容易耗時費力效率低，並且多數人一頭霧水，這個大家應該有所感受，這類不再贅述。
領導力的另一個關鍵也是能不能把一件大的事情分解為幾個小的模組，讓多數的人有事可做，並且產生好的結果。
3.2 資訊洩露
資訊通暢是好事，但是關鍵戰略洩露或者說私密資訊洩露，也會非常致命，特別是對於很多有協調者或者外交家屬性的leader，這裡要分輕重，有些資訊還是不能完全告訴對方，不同團隊對於資訊洩露的標準不一，反正注意就好。
另一方面，公司層面要做一些技術或者說基建防止公司資訊（業務資訊）洩露，甚至是程式碼洩露，一個是防堵一個是找補，真的當這類資訊洩露了的應對措施是什麼需要提前定義。
3.3 偏聽偏信
leader要切忌偏聽偏信，這裡的重點有兩個：
第一是資訊渠道要足夠多，保證自己有一個足夠的資訊量；
第二是要有一個自己的判斷模型，在相對足夠的資訊量下，有一套自己的判斷標準，不要輕易的給一個人一件事打標籤，要有更立體更巨集觀的看法，接受一件事、一個人的好也能用他的好，而有一些機制去規避他們的不好；
這裡有個點要注意，leader是一塊蛋糕，所有人都會盯著，想要建立“特殊”聯絡的人很多，這個時候很看leader給自己營造的人設。
如果你的人設是都可以聊，都可以打成一片，只不過你有自己的判斷，讓人看不出明顯的親疏；
如果你的人設就是不輕易“親密”；
兩者都需要注意自己身邊是不是被一個人完整的包圍了，是不是跟一個人建立的聯絡特別牢固，而這個人由於一些客觀目的又會到處“炫耀”，而面臨衝突的時候你又會不小心拉偏架，這種情況對整個團隊不會太好，當然這種情況常見於leader與女下屬......
當然，誰都有幾個得力下屬，如何處理跟他們之間的關係，也很重要，這裡不展開......
3.4 月會
如前所述，月會跟週會的目標又不一樣，週會更關注日常事務，一般不涉及人事問題，因為週會一般是第一圈層+第二圈層，人數較多，公開評價某人如何如何很不好，一些業務上敏感的資訊也不能完全透傳，容易引發恐慌，畢竟真相可能不好看。
月會一般是團隊第一圈層少數人蔘與，比例在5%左右，目標有：
1）暴露業務問題，跨團隊問題，甚至公司問題，管理層的壓力會部分下放到這個圈層，把業務風險赤裸裸的放出來；
2）暴露團隊人員類風險，梯隊問題，核心人員離職問題；
3）業務建設、工程建設情況，在月會中佔有很重的比例，而且必須持續投入；
4）問題專案覆盤，團隊問題暴露，與週會大體相同，但是這裡會更徹底一些，可能會將遮羞布扯下來，也會討論應對方案，好的案例會作為幹訓班材料；
按照以上目標做材料整理，會更希望做資料化的呈現而不是空口無憑，單資料化又希望多維度論述，總之月會規格會高很多。
3.5 其他
幹訓班、專案之類的會議請看之前文章。
貌似沒太多可以說的了...
四、結語
這裡花了一個月的時間，對之前幾年工作中管理的相關經驗做了一些分享，幾篇文章圍繞著下圖展開：
依次從管理意識，建立認知，再到如何做事做專案，再到如何解決團隊造血問題的一些思考。
該系列內容雖然繁多，但無非還是實際工作中的人事物，管理的本質依舊是系統的解決複雜的問題，越高的層級解決的問題越大，這個點是大同小異的。
小釵才疏學淺，文中的介紹多有錯漏，還望大家多多指教，也希望各位把自己的管理框架丟擲來一起學習，至此，本系列就正式結束，希望對大家有用。