新晋总监生存指南终章——构建技术团队信息通道
新晋总监生存指南系列：
原计划第五篇人才运营结束后，这个系列就完结，通看一次后发现少了一个板块：如何构建团队的信息通道。犹豫了很久要不要写这个，因为所谓信息通道，说白了就是两个字：开会，长篇大论容易变得神神叨叨，因为开会重点无非就是（谁还不会开会呀）：
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 其他
貌似没太多可以说的了…
四、结语
这里花了一个月的时间，对之前几年工作中管理的相关经验做了一些分享，几篇文章围绕着下图展开：
依次从管理意识，建立认知，再到如何做事做项目，再到如何解决团队造血问题的一些思考。
该系列内容虽然繁多，但无非还是实际工作中的人事物，管理的本质依旧是系统的解决复杂的问题，越高的层级解决的问题越大，这个点是大同小异的。
小钗才疏学浅，文中的介绍多有错漏，还望大家多多指教，也希望各位把自己的管理框架抛出来一起学习，至此，本系列就正式结束，希望对大家有用。