团队的发展过程中，组织架构需要及时动态调整，以适应业务和人员管理的变化。



刚入职的时候，公司还是一个十几人小团队，那时候基本每个人承担起一个端的能力，比如后台一个人，市场一个人，产品一个人...但也正是这一年，小团队的业绩开始让整个公司的盈利能力有了实质的增长，也就是这年之后，公司开始了剧烈的扩张时期。笔者有幸见证了一个小团队是如何一步步走向近百人的大公司的全部过程。

小团队时期的运行逻辑

十几人的小团队时期，每个端最多两个人，所以基本上大家过完产品需求之后，就开始各干各的，大家座位也近，根本不需要什么专门的通讯工具，人与人之间的沟通保持着人类最原始最热闹也是最高效的沟通方式--声波。那时候也不觉的是影响，大家有说有笑的把一天的工作做完。



这个时期的版本周期运行周期大约是产品设计需求--需求评审--开发--测试--上线Review--发布。整个流程一气呵成，浑然天成，运行起来如风般轻盈，自然。



然后2018年开始团队快速扩张至50多人。老的一套流程慢慢变得适应不了节奏，人员的增多最明显的变化就是沟通越来越多，运营中的变量因素比如需求开发中变动导致需求开发时间延长，版本周期开始变得越来越长，有时接近7周一个版本。特别是产品团队，和开发团队由于新人较多，需求的定义和理解，包括变动在整个版本周期开始多了起来。一切开始变得紊乱。



大团队时期组织结构调整

管理层已经意识到人员增多，导致协作的效率产生负面的影响在增加，于是果断的挑选人马，组成了一只实验小组，该小组的主要目标就一个：敏捷化开发，内部代号“闪电部队”。小队的主要任务不但要完成版本的敏捷开发，还要在日常的协作，沟通中积累经验，为之后的整个团队业务线演化提供高质量的经验。就这样，由笔者作为核心成员并承担项目经理角色的“闪电部队”在2018年底，悄悄登场。



经过整个一年的迭代沉淀，沉淀出敏捷开发“5-3-1”参考模型，即五天的开发时间，3天测试上线，1天下版本调研。并且一个业务线小组核心成员产品，前端，后台，测试4个人组成小组核心成员在长期的磨合中确定的基本的协作时间节点，比如产品在当前版本进入开发的第一天就进入下个版本的评审，需求开发也是边开发边测来提高敏捷开发运转效率。这个时候产品经理角色就退化为一个协作自动化的协作标准，大家参考协作标准，完成自己的内容，整个实验小组以一种近乎自动化的方式高速迭代了一年。完成了27版本，比主版本足足多出了16个版本，人员只有是主版本的20%，但是却完成了公司全年营收增长部分的40%。成绩如此的突出，以至于2020年公司全面推行业务线化组织架构演进。



所以，当互联网公司开始大规模扩张的时候，如何保持团队的高效，敏捷。业务线化是一个被实践了的可选项。

最后

有时候人员的增加并不直接代表着效率必然增加，及时的根据当前团队所处的规模，采取合适的团队管理策略和组织架构设计，才能运用好每一位人才的价值。实现团队效益最大化。



题图来自Unsplash，基于CC0协议。