微服务和组织该如何搭配? (2)

  从上图的技术与组织架构对比可以知道,组织技术员工好比技术的物理服务器,都是架构的基建,一个员工的品质好比服务器的质量,并不是说有了上层对基础资源的统一管理,淡化了每一个独立个体的重要性就不代表不需要好的员工或服务器了。当然,好的东西都贵,但性价比高的还是值得不断去追求的。

 

● 技术部门

  技术部门好比LaaS,是对所有独立个体的统一管理和协调,最对资源效能最大化的手段。部门有企业级别的实践方针和指南,结合企业的目标定制了一套最适合自己的组织与技术管理办法,这些规章制度并非一成不变,是站在企业的角度跟随市场不断去完善和修正的。所以,组织并非一成不变,既然技术与架构是相互的,那么技术架构的稳健、灵活、易扩展等特性应该同样要应用于组织架构。

 

● 研发小组

  研发小组跟PaaS一样,是技术组织效能的“加速器”,增加了上层的业务或应用的灵活性和增加快速适应市场的能力。我们研发小组的贡献主要集中在两个层面。一方面是不断完善和提高自己组织的内部效能,主要体现在我们当前自主研发的“统一工作台”,这个统一工作台主要是结合我们各种职能流程和软件工具(如SVN,Docker等)打造的一个统一规范工作流平台。另一方面是不断通过业务驱动积累我们研发的业务产品(如我们“微服务应用中台”的服务沉淀),为企业增效,提高市场竞争力。

 

● 职能小组

  我们部门的人员架构是一个“矩阵型”架构,横向为技术职能小组,纵向为以项目经理带领的项目小组(下面会介绍)。按职能维度,整个部门划分为项目经理组、需求组、UIUE组、前端组、后端组,测试组、实施维护组等职能小组。有点类似于微服务架构里面的服务一样,分工合作,自己独立部署独立负责。职能小组内部会根据规模而进一步细分小小组。这些小小组会是企业发展而又有可能归类为事业线小小组或业务领域小小组。组员到组长一层层向上按自己领域范围的技术规范和项目质量负责。

 

● 项目小组

  项目小组是我们“矩阵型”架构的纵向划分维度,由各职能小组成员组成,由项目经理以业务为统筹和主导。在纵向维度,职能会存在一个“项目职能负责人”,确保自己的职能价值在项目中最大化体现。哪怕项目再小,职能只需分配一个人或半个人,而那个人就默认充当了这个“项目职能负责人”的角色。就像微服务架构一样,有了我们“微服务应用中台”的支撑,顶层的应用场景可以更加灵活、高效、快速地实现。我们的项目小组在职能小组明确分工的基础上,同样也能灵活、高效、快速组件出打造顶层应用场景的项目团队。

 

  看到这里,可能有人会有疑问,我们只是一个小企业,那有这么多人。其实问题这个问题的人,等同于问“微服务是否只能适用于大型系统”的问题一样。我在《小型系统如何“微服务”开发》中也做过介绍,微服务是一种方法,适用于任何应用和项目,跟项目规模没有关系,哪怕我目前只有一台物理服务器,或者我只有一个技术人员,都完全能按照我们以上的“技术与组织结构”方式去运行和操作。要明确一点的是:方法跟规模没有关系。当今在技术圈比较流行的一个词叫做“DEVOPS”,其实就是一种“降本”手段。我们的组织架构是跟人数没有关系的,更多是我们的管理办法,因为做事情需要顶层方法去引导我们更好地执行。就算我们技术组织只有我一个人,也不妨碍我属于研发人员,同时又兼容前端、后端、测试、实施、维护的职能,以及作为项目经理主导自己去开发项目。

 

  方法还只是属于“虚幻”层面的东西,具体还是要考自己的实践去验证和发展,就算我说得多牛X,如果不亲自去体会、感受和总结,我们持续实践了千万级用户数应用平台近10年的时间,以及我们所开发的应用系统足足比别人降低数倍乃至数十倍的时间和金钱成本,都不关你们的事,这是我们每个同事通过汗水和努力所换来的成效。但我们的不足还很多,没事,时间还很漫长,一步步主动去学习、改变和完善就是了。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wppjww.html