是不是现在开会有点多?

今天在与团队成员沟通过程中,有人提了一个问题:现在团队的开会是不是有点多?

现在会议或者说讨论会,确实有些偏多,特别中层管理者被拉入了很多讨论会议中。对于这个疑问,我相信团队中的很多人都会有。我当时简单解释了一下,但是事后,感觉当时解释的还不够清晰,于是写这篇心得补充完善一下。

现在我们这个ZX团队正在从一个“小作坊”战队形式转变为“正规军”形式。(很多人会说,我们要保持敏捷小团队,这是一个误解。转型为正规大团队并不是意味着不敏捷,不高效)。正规大团队,不仅要继续保持高效,还必须在高效的情况下,保持稳定、保持可持续。那就必须形成一套适合团队自身的“运作结构”以及配套的各种流程、机制。

一年多前,我们还只是一个不到十人的小团队。那时候不需要任何管理机制,仅凭借“快速沟通”和“紧密配合”,很多事情,三言两语沟通完就卷起袖子开始干了。但今天我们已经是一个四五十人的大团队了,要让几十个人朝着一个目标高速前进,唯一个方法就是“规范化、流程化、标准化”,俗称“正规化”。(一提到“正规化”,大家本能反应就是“效率低下”。这是一个误区,也是一个错误的认知。今天我们实行了几个月的“版本迭代计划”,就是“正规化”的体现,执行效率并没有降低。)

但是,很不幸,我们原来没有任何“体系化的积累”,也没有形成一套自我合适的“正规化”体系,甚至我们周边可以借鉴的也没有 (同集团内的兄弟公司中,我们已经算是较为规范化在做事了,但依然远远达不到“正规化”的高度)。

从“小作坊”形式转变为“正规化”形式,唯一的方式就是“宣讲、沟通、演练、总结”这样的反复循环、反复尝试、反复总结,在这个过程中,各种讨论、各种会议是必不可少。

举个近期的例子,来和大家讲解一下“规范化”和“小作坊”的区别
最近我让Server团队着手梳理“实时监控项”。
第一次先找了叶凯沟通,跟他讲解了 梳理实时监控项的目的,让他安排下去,我只提了要“梳理全”。叶凯组织Server团队开会,讲解并安排下去了。
三天之后,当各个模块负责的研发把梳理的结果呈现在wiki上时,就暴露出非常严重的问题:
1、研发同学全部是按照“系统实现的接口”顺序一个个梳理的
2、梳理的内容很多,但是却很难直观的判断“监控项”是否完备了,是否能够覆盖真正的业务过程了

第二次我找了叶凯沟通,指出研发同学在梳理过程中的问题,要求他,让研发必须依照“业务、实现组件、监控项”这种层次化的结构来梳理,而且是围绕“业务流程”的。同时要求一些关键的业务,必须有业务流程图或者序列图,之前没有的,这次必须补上。叶凯安排了党同学(负责用户系统)先尝试按照这个模式梳理,当然这里面包括叶凯与党同学的沟通

党同学在重新梳理过程中,与我有过2次沟通。准确讲是我依据自己的理解,对党的梳理结果进行了Review并提出改进要求。

第三次我找了叶凯沟通,让其看了党同学重新梳理的业务化的实时监控项,并告诉这么做的价值意义,特别对后续完整性检验的价值。并要求其安排下去,让所有研发重新按照新的格式和方法重新梳理。叶凯再次组织所有研发人员学习党同学完善后的整理格式,并安排重新进行梳理

2天之后,叶凯组织所有Server研发对梳理的结果进行Review。其中发现一部分同学的个别模块梳理没有按照规范执行。安排这些同学重新完善。

接下来,我还需要对这些进行再次Review,并且找Server和运维负责人,执行上线前对监控想审核的机制和规范。估计还需要几次沟通和讨论。

看看上面,这么一件“监控梳理”规范化的事情,最终经过了至少10次以上沟通、讨论。今天为了达成这样的规范,所进行了多次沟通和开会,就是为了在未来不再开会,不再讨论,只需要遵循规范的执行。大家只要遵循规范,就能够有意识的在实现业务系统过程中,完善监控。

今天,我们缺少太多这种的“规范”和“机制”。所以我们不得不需要额外非常多的“沟通和讨论”会议来确定规范,推动大家认识规范,遵循规范。

你可能感兴趣的:(是不是现在开会有点多?)