今天在与团队成员沟通过程中，有人提了一个问题：现在团队的开会是不是有点多？
现在会议或者说讨论会，确实有些偏多，特别中层管理者被拉入了很多讨论会议中。对于这个疑问，我相信团队中的很多人都会有。我当时简单解释了一下，但是事后，感觉当时解释的还不够清晰，于是写这篇心得补充完善一下。
现在我们这个ZX团队正在从一个“小作坊”战队形式转变为“正规军”形式。（很多人会说，我们要保持敏捷小团队，这是一个误解。转型为正规大团队并不是意味着不敏捷，不高效）。正规大团队，不仅要继续保持高效，还必须在高效的情况下，保持稳定、保持可持续。那就必须形成一套适合团队自身的“运作结构”以及配套的各种流程、机制。
一年多前，我们还只是一个不到十人的小团队。那时候不需要任何管理机制，仅凭借“快速沟通”和“紧密配合”，很多事情，三言两语沟通完就卷起袖子开始干了。但今天我们已经是一个四五十人的大团队了，要让几十个人朝着一个目标高速前进，唯一个方法就是“规范化、流程化、标准化”，俗称“正规化”。（一提到“正规化”，大家本能反应就是“效率低下”。这是一个误区，也是一个错误的认知。今天我们实行了几个月的“版本迭代计划”，就是“正规化”的体现，执行效率并没有降低。）
但是，很不幸，我们原来没有任何“体系化的积累”，也没有形成一套自我合适的“正规化”体系，甚至我们周边可以借鉴的也没有 （同集团内的兄弟公司中，我们已经算是较为规范化在做事了，但依然远远达不到“正规化”的高度）。
从“小作坊”形式转变为“正规化”形式，唯一的方式就是“宣讲、沟通、演练、总结”这样的反复循环、反复尝试、反复总结，在这个过程中，各种讨论、各种会议是必不可少。
举个近期的例子，来和大家讲解一下“规范化”和“小作坊”的区别
最近我让Server团队着手梳理“实时监控项”。
第一次先找了叶凯沟通，跟他讲解了 梳理实时监控项的目的，让他安排下去，我只提了要“梳理全”。叶凯组织Server团队开会，讲解并安排下去了。
三天之后，当各个模块负责的研发把梳理的结果呈现在wiki上时，就暴露出非常严重的问题：
1、研发同学全部是按照“系统实现的接口”顺序一个个梳理的
2、梳理的内容很多，但是却很难直观的判断“监控项”是否完备了，是否能够覆盖真正的业务过程了
第二次我找了叶凯沟通，指出研发同学在梳理过程中的问题，要求他，让研发必须依照“业务、实现组件、监控项”这种层次化的结构来梳理，而且是围绕“业务流程”的。同时要求一些关键的业务，必须有业务流程图或者序列图，之前没有的，这次必须补上。叶凯安排了党同学（负责用户系统）先尝试按照这个模式梳理，当然这里面包括叶凯与党同学的沟通。
党同学在重新梳理过程中，与我有过2次沟通。准确讲是我依据自己的理解，对党的梳理结果进行了Review并提出改进要求。
第三次我找了叶凯沟通，让其看了党同学重新梳理的业务化的实时监控项，并告诉这么做的价值意义，特别对后续完整性检验的价值。并要求其安排下去，让所有研发重新按照新的格式和方法重新梳理。叶凯再次组织所有研发人员学习党同学完善后的整理格式，并安排重新进行梳理。
2天之后，叶凯组织所有Server研发对梳理的结果进行Review。其中发现一部分同学的个别模块梳理没有按照规范执行。安排这些同学重新完善。
接下来，我还需要对这些进行再次Review，并且找Server和运维负责人，执行上线前对监控想审核的机制和规范。估计还需要几次沟通和讨论。
看看上面，这么一件“监控梳理”规范化的事情，最终经过了至少10次以上沟通、讨论。今天为了达成这样的规范，所进行了多次沟通和开会，就是为了在未来不再开会，不再讨论，只需要遵循规范的执行。大家只要遵循规范，就能够有意识的在实现业务系统过程中，完善监控。
今天，我们缺少太多这种的“规范”和“机制”。所以我们不得不需要额外非常多的“沟通和讨论”会议来确定规范，推动大家认识规范，遵循规范。
网友评论