【研发管理101军规002】特种部队——更符合不确定业务的组织架构...
DevOps
共 2158字，需浏览 5分钟
·
2021-03-09 19:23
内容来源：PingCode作者：Anytao研发管理101军规——PingCode（Worktile）CEO王涛拓展阅读：研发管理101军规#001 两周迭代，形成团队持续习惯 | IDCF这是研发管理的第2条军规，我迫不及待地将组织架构的设计作为基础理念推荐给尽可能多的研发管理者。在阿里有个习惯性的动作，战略调整的第一步是组织架构的调整，可见组织如何排列组合是个极其重要的事情。让张飞去负责后勤，就和安排孙悟空挑扁担一样，对团队都是负价值，进而让西天取经这件事变得更难了。因此，研发管理的002篇，我们优先谈谈更符合不确定业务的组织架构设计，我称之为特种部队。现在管理思想，很多来源于军队的组织建设，从过去100年的战争史来看，以美军建制为例，从一战二战，到越南战争，再到海湾战争，几十万人死磕的堡垒时代结束了，现在更多是特种部队编制，十几个人的海豹突击队就能发起突然的小型战役，并可能控制战争胜负的走向。
回到研发团队的现实情况，通常在组织架构上的不认真，会带来管理上无比复杂的麻烦，而且往往草率的组合会拼凑出乌合之众，而不是能战之师。如何设计研发团队的组织架构，是个大大的思考题。Worktile 团队经历过好几次不同的组织形态，也经常性的将研发团队进行组织调整，简单说，一个研发团队的角色主要是以下几类：- 产品经理
- 设计师
- 服务端工程师
- 前端工程师
- 测试工程师
- 运维工程师
- 其他
以什么样的组织方式调配以上资源，是个非常考验团队管理的事情，例如很多公司会将设计团队作为完全独立的部门，其他团队和项目按需调配设计资源，设计团队就像公司的乙方角色，通过资源调配来匹配执行。而另一种形态则是广泛存在于Facebook、谷歌、小米、阿里、头条等互联网公司，设计、产品经理、开发、测试组成短小精悍的特种部队，在研发团队中以小组形态组合，就像一个研发业务的接口一样，有清晰的输入和清晰的输出，有清晰的目标和清晰的边界。Facebook的数万名工程师并不是像集团军一样制造Facebook，更多的反而是十几个人的小团队形成自组织单元，信息流、消息、账户管理、广告系统、群组、图片分享，被切分成无数可大可小的业务单元，每个业务单元由完整编制的开发者团队负责，产品经理、设计师、前端、服务端、测试组成完整精悍的特种部队，向一个业务单元的目标和结果负责，又能灵活聚焦的驱动业务迭代。在Worktile研发团队，我们根据自身业务特性，组成了数十个不同的研发特种部队，例如基础架构组、开放API组、敏捷产品组（Agile）、测试产品组（Testhub）、Wiki产品组（Wiki）、项目集产品组（Plan）、后台服务组、客户研发组、增长组等等，每个小虎队跟进业务复杂度通过以下的基本配置来组织开发工程师。（ps:小虎队是我们内部对特种部队的称谓）
显然，打起仗来，特种部队方式的小组，从执行到目标都是超级强悍的，也同时能方便研发组织绩效考核的落地与激励。新业务成立时，我们通常从其他小组选拔优秀的工程师来当唐僧，领导和开拓新的业务组，他需要自己去五指山找孙悟空，去高老庄救猪八戒，去通天河招沙和尚，而不影响其他业务的资源占用。因为不同的特种小虎队有清晰的目标、职责和边界，因此不同小组之间的配合与协作将变得清晰有效，基础架构层的问题将自然由基础架构组负责和解决，而Plan产品和Agile产品直接的高密度数据打通，则在两个小组之间进行接口协调即可。特种部队的组织文化，适配业务快速迭代和不确定性加剧的时代，一个特种部队有全副武装的能力，有聚焦的方向和目标，有自组织和自驱动的文化，而特种小虎队也完全匹配了奖罚分明的研发绩效管理逻辑。干得好的唐僧会迅速得到更多真经的激励，而没用结果的业务会快速撤掉重组。总结来说，特种部队式的组织架构设计，价值在体现在：- 适应需求的变更和业务的不确定
- 可以聚焦业务和目标
- 持续配合的团队更默契，组织更有效
- 方便绩效考核
- 跨团队的配合，能够方便定义清晰的边界，进而实现对业务有效的组织和分割
- 不同的特种部队，能自动形成竞争机制
- 培训和成长，会在一个特种部队单元里形成完整的闭环
- 不断扩展的小虎队，也自然形成了开发工程师的上升通道，为有潜力的孙悟空提供了在新业务单元发挥的空间和可能
想要提升敏捷DevOps技能，来场DevOps黑客马拉松！想要寻找第二增长曲线实现创新增速，来场DevOps黑客马拉松！2021年4月24-25日，IDCF DevOps黑客马拉松走进天府之国-成都赶紧报名参加吧~可自己报名，也可公司组团参加哦！
评论