新晉總監生存指南系列：
新晉總監生存指南開篇之總監二三事
新晉總監生存指南二——建立名額
新晉總監生存指南三——OKR實踐
新晉總監生存指南四——項目執行指南
新晉總監生存指南五——人才營運機制
原計劃第五篇人才營運結束後，這個系列就完結，通看一次後發現少了一個闆塊：如何建構團隊的資訊通道。猶豫了很久要不要寫這個，因為所謂資訊通道，說白了就是兩個字：開會，長篇大論容易變得神神叨叨，因為開會重點無非就是（誰還不會開會呀）：
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 其他
貌似沒太多可以說的了...
四、結語
這裡花了一個月的時間，對之前幾年工作中管理的相關經驗做了一些分享，幾篇文章圍繞着下圖展開：
依次從管理意識，建立認知，再到如何做事做項目，再到如何解決團隊造血問題的一些思考。
該系列内容雖然繁多，但無非還是實際工作中的人事物，管理的本質依舊是系統的解決複雜的問題，越高的層級解決的問題越大，這個點是大同小異的。
小钗才疏學淺，文中的介紹多有錯漏，還望大家多多指教，也希望各位把自己的管理架構抛出來一起學習，至此，本系列就正式結束，希望對大家有用。