注册 / 登录

应对微服务带来的组织变革挑战

分会场:  工程文化/团队增长/绩效考核

分享时间: 2017年11月9日 - 12日

案例来源 :

案例讲师

Andrew Luo

LinkedIn 资深软件工程经理

• 互联网构架以及技术团队管理专家 • 现 LinkedIn(领英)资深软件工程经理,负责基础构架和工具团队 • 前乐视美国视频平台工程技术总监 • 前Netflix( 奈飞)视频内容平台工程技术负责人 • 前PayPal 资深软件工程构架师

扫描二维码分享案例

 

案例简述

 

领英的 2C 业务部门在几年前转向微服务构架后,整个组织构架也向微服务变化。基本的变化是各个微服务业务部门有自己的工程团队,这个工程团队负责怎个自己微服务的各个流程。这个组织构架是为了更好的强调微服务的独立性。在一段过程中,发现这个组织构架有缺陷,主要是各个微服务部门其实是有些公共的东西,有时候需要有些公共的工具。 另外有些工程师,其实是更喜欢做面向工具和基础构架的开发,而不是微服务业务开发。

 

案例目标

 

我们要解决工程师离职率升高(对于不喜欢做业务,而是喜欢工具开发工程师),基础开发重复-每个业务团队开发自己的一些工具,以及一些需要各个微服务团队协作才能完成任务处于没法有效落实阶段。

 

成功(或教训)要点

 

为了解决以上问题,我们成立了专门的二级基础构架和工具团队。这个团队负责整个大业务部门的通用基础构架、工具以及需要多部门协作的任务。那些喜欢基础构架和工具的工程师也找到自己的方向。

 

案例ROI分析

 

update...

 

案例启示

 

1. 人是最关键的因素,不能为了追求技术构架的转变,而忽视个人的兴趣。
2. 刚不可以久,柔不可以守。对于一个管理者来说,不能单纯的追求技术的极致和业务开发的速度,要综合考虑。