如何避免中小型团队中较为冗余的会议来节约时间?

起因

7 月份加入「商业」团队支持这边的部分前端业务,有一点和之前在「社区」那边不太一样的是,这边的会议很多。在 EP 组实习期间,虽然每天中午大家也会在饭前开一次站会,同步一下当日工作进度,但已然感觉这边的会议给我带来更多的打断和疲劳感。分析一些原因,写在这里

大概有哪些会议?

  • 每日中午站会 13:00 PM
  • 周一中午站会会有比较详细的进度同步,包括这周可能会做些什么 14:00 PM
  • 周五下午商业组有技术团队的会,16:00 PM,大家一起过一些本周的问题,过 OKR

乍一看还可以,除了站会同步,一周似乎也没有多少大型会议。但问题是当周五前端上午的「周会」和下午的「内部分享会」加起来后,整个周五就陷入了一种不停开会、几乎没有几个小时用于工作。除此之外,小项目组依然可能会开一些小会,比如「brain storm」的会、需求评审、设计评审,还有一些前端内部的技术评审。

即便不依赖 KPI,我们依旧需要评估自己的产出,给自己的「Objects」和「Key Results」完成度来打分,众多冗余的会议下,你本可以完成的事情,就变得大打折扣。

周折

和 yshuo 聊了几次,包括 one on one 也和 xdy 提到了自己对减少开会的期望,但由于种种原因,可能个别会议时间缩短了,但整体形式暂时没有改变。开会依旧扮演着「打断工作」的角色,我最期望的当然是几乎不开会,但大家已经能完成进度同步、解决意见冲突。

  • 看看什么人最需要/爱开会?

产品,leader,老板。分析一下三个角色的开会需求

产品 – 各类评审、写文档继续大家都干了什么,根据实际情况处理需求
leader – 了解团队各个成员的进度,解决成员的困难,合理分配任务
老板 – 大局观,我们的产出,是什么进度,遇到了什么问题,让团队了解到底在干什么

  • 大家一起开同步会问题在哪呢?
  1. 时间
    会议确实可以通常情况下开得很短,比如二十几个人,每个人都是几十秒说一下今天的做了什么,还是很快的。但偶尔总是会遇到啰嗦的人,表达能力并没有那么好,不能作出简短总结的情况。

  2. 内容混杂
    当团队成员角色比较复杂时,如同时有销售、运营、前端、后端、设计、产品,这样的同步会议可能会开得云里雾里,并不是说你不知道他们在说什么,而是你不知道他们提出的信息能给你带来多大的帮助。一个 leader 可能能对自己手下各个业务线有清晰的了解,但对专门做某一项开发的人,运营有多少动作、销售卖出了多少钱、其他产品有什么新进展,就属于「噪音信息」了

  3. 虽然简短,依旧是打断
    当你一天处在不停开会的状态里,你的角色可能是一个团队的 leader,或者是一个老板,再或者你可能是一个需要协调多个技术线的产品,你的主要工作是解决宏观的问题。编程是一件需要集中注意力的事情,在做开发的人肯定都会深有体会,当你在深思某个算法的瓶颈、或者尝试探索某一种优雅的实现方式,突然打断你,再想恢复状态就很难了。这是很 致命 的,你不能保证它不会影响你在代码上犯错,或者减缓你思考的速度。

同步会弊端

  • 要同步的真的同步了吗?比如 A 要做某件事 a,有一个 ad hoc 的 b 事情插进来,他去做 b 了,那谁来接手 a?有的人可能就不会管了。过 OKR 的时候同样有这个问题,我们列了很多,有的事情不解决最后就不了了之。
  • 如果你几天、一周都在做一个任务,每天同步的都是「在继续做 xx」,「进度?给 deadline?」,「x 天之后」。来回重复,意义也并不是很大
  • 噪音信息太多,解决的可能也并不是你关注的事情。当我们依赖团队以外的服务、工具、人员,我可能确实遇到问题了,但我最需要的是抽时间联系可以帮我解决问题的人,花时间在要解决事情上。你开完会了,别人可能去开会或者也有别的事情要 focus。

开会是一个需要完整时间段来做的,你要离开工作位置,进入开会状态,到达开会地点,表达自己观点,提出可能有的问题,结束开会回到你之前的工作位置,我相信 线程切换上下文是有很大开销的

可能的解决方式

  • 每个人 comment 一个周会 task,说这周干了什么,减少频率,异步交流
  • 专注在一件事情上,完成了再去搞下一个事情。规划自己的 due,关心和自己做同一件事情的人,给出 deadline 和 progress
  • 产品更加主动,project team 一般不会很大,从开会的方式改为去找大家单聊,或者简单在 channel 里讨论(对产品的表达能力和思维能力有要求)
  • 简化过 OKR 和每周问题的方式,大家还是关注大目标,而不是细节小问题。比如 service 一个月出了 5 次 downtime,那需要跟着反省、总结、讨论的就不是设计师了

大家目前的方式就是过每个人负责的 task,去操作这个人每个事情的完成程度。其实大家可能关注的还是自己,因为我们也并不清楚别人头上有什么。

也许我们需要的是这个?

due graph

每个人都在并列的 timeline 上,每行是一个人的时间,每个颜色是同一种事情,可能有不同的人负责一个事情,还会交叉做事情。那么我们来跟进的时候,关注每个人对事情的完成,你在拖动这个人的「进度条」的时候,也能看到其他人的进度,每个人可以自己操作,可能就有一个比较好的全局观。progress bar 只是一种形式,可能还是连续的 card,或者其他。

末尾

团队里每个人都不太一样,有的人聪慧敏捷能迅速解决技术问题,有的人善于交流总结带领大家前进,有的人可能不善于找到自己的位置对要做的事情迷茫,有的人可能 cover 了太多事情导致不能及时反馈…种种都有,不过我们是不是可以用新的工作方式来尝试解决问题呢?
很多新公司、小团队的效率很高,并不是因为人少,而是大家始终坚持着「简洁」的工作方式和「敏捷」的协作,当公司逐渐长大,我们是不是也要像 BAT 那样白天开会、晚上干活?我相信不少人都经历了不简单的面试,在 HR 甚至老板那一关,我们给出了满意的解决问题的答案,但真的到现实里,你是不是愿意去推动?去解决繁琐的问题?