工作了三年多,才亲身体会到什么叫“拉群和@”:内部推进横向项目时,涉及的相关方实在太多了,又不能不让大家知悉,所以每一个小细节拉的群都人数庞大。
我是项目owner,在所有群里毫无问题,我清楚地知道哪些群要盯着同步信息,哪些群开免打扰被@再看就行,哪些群得定期扫一遍。但是项目组其他成员,乃至普通协作相关方,没有那么多精力和上下文去主动管理信息,所以就需要很多的@。
另外群聊人数变多后,讨论细节就不在大群了,因为不好意思所有人接受信息轰炸,得拉个小群。但是小群又会因为涉及到相关方逐渐变大,失去了小群的意义。
如果想尽量清晰定义每个群的功能,分别拉一个小群的话,又一定会涉及到某个问题需要不同角色在一起讨论。如此排列组合,群的数量就太多了,更加搞不清楚应该在哪个群里沟通,沟通效率就变得更低了。
群聊如此,会议参加范围更是如此,都会遇到同样的人数庞杂的问题,而且会议的问题会更加严重。
然后我现在的解决思路是抓大放小:
会议对人的打扰程度和独占程度更高,因此会议尽量人数少(参会方小于5人),在不影响会上讨论的情况下,尽量按照讨论事项、详细程度和角色把大会拆分成多个小会。
我参加多个小会分别跟各方对齐以后再做大会汇总,哪怕我因此要参加更多会议也没关系:因为大会不仅浪费非核心参与方的时间,仅对我而言也经常超时浪费时间,而且由于超时,难以讨论到更深层次的细节。
几个半小时内可控的小会,整体开会时间差不多,而且因为主题聚焦,参与方会更认真准备,讨论也更彻底,有效减少了平时文字沟通,更节约我的时间。
至于群聊,按照项目相关角色的参与程度,粗略拉几个场景群和项目大群项目小群,我做好所有项目信息汇总并转发同步到该同步的群即可。
至于群里有没有领导被吵到、是不是有其他角色不需要收到消息、会不会因为细节讨论消息过多找不到重要消息等问题,都不需要在我的考虑范围内。
因为每个人都有自己做好消息管理的责任:认为这个群没有需要关注的信息,免打扰或退出都可以。如果有需要关注的信息被遗漏了,那是自己信息管理不到位的责任。
总之我已经竭尽全力做好了消息同步和信息降噪,没有必要再操心别人🥱