83 lines
7.0 KiB
Markdown
83 lines
7.0 KiB
Markdown
|
||
# 虚实结合的 Feature Team 实践
|
||
|
||
作者：高莹
|
||
|
||
部门：效能改进
|
||
|
||
|
||
背景
|
||
每个公司不同的成长历史、不同的业务架构和管理风格，造就了不同的公司组织架构。组织架构是为公司发展服务的，所谓“定战略，搭班子，带队伍”。互联网时代注重快速响应市场变化的能力，组织架构也需要满足更灵活的协作模式。本篇文章主要介绍有赞的实践，职能型团队与Feature Team（简称FT）模式相结合，通过建立不同层级的虚拟组织，使协作模式更加敏捷，来应对未来市场环境带来的机遇和挑战。
|
||
|
||
|
||
一、职能组织架构的问题
|
||
职能型组织架构是按职能来组织部门分工，即从高层到基层，均把承担相同职能的管理业务及其人员组织在一起，设置相应的管理部门和管理职务。其好处显而易见：分工明确、人员调动灵活、相同专业的组织利于专业能力的提升。如图：
|
||
|
||
这种形式运作会有几点问题影响协作效率：
|
||
|
||
1.1 团队不断扩张，规划协调成本高，响应变慢
|
||
团队扩大，统一的待办计划就会变得庞大。协调不同职能角色进行规划评估成本非常高，即便规划做的非常完美，也难以避免个别紧急插队的项目，启动项目时因缺少某端资源，需要等待或协调的情况屡见不鲜，影响了响应业务的速度。
|
||
|
||
1.2 临时组建项目组对项目长期目标感知较弱
|
||
当前项目组成员较关注本项目的目标，项目完成对于整体业务来说仅是阶段性成果。延续性的项目，项目成员发生了变化。长此以往，对于项目背后的长期目标，项目组成员难以感知。
|
||
|
||
1.3 相对业务目标更关注部门目标
|
||
各职能部门都各有其内部规划的日常工作，所以个人优先考虑的往往不是整个公司业务的目标，而是部门的目标。这就会造成项目中那些在部门目标范围之外的问题很有可能被冷落，导致项目得不到足够的支持。
|
||
|
||
很多公司通过组织架构调整来解决上述问题，例如「大中台，小前台」的组织架构、Spotify松耦合紧密联盟的小分队squad,本质上都是将大规模组织细分成多个可以端到端负责业务的小团队。有赞在各业务发展节奏不同的情况下，在需要小步快跑的前台业务中尝试虚实结合的组织架构，利用两者的特点趋利避害，来提升部门间的协作效率。
|
||
|
||
二、虚实结合组建高效团队
|
||
2.1 适合FT的应用场景是什么？
|
||
在推动FT虚线组织之前，首先要分析什么样的业务团队适合FT的形式。
|
||
可以归纳为几个特点：
|
||
|
||
竞争激烈，需要快速响应市场变化
|
||
未知领域，需要创新探索
|
||
组织扩展, 跨职能协作链路长，整体决策机制存在瓶颈的场景
|
||
2.2 如何划分FT？
|
||
在考虑如何划分FT之前不妨先复习一下什么是FT？
|
||
|
||
Feature Team 是一个 长期存在的、跨功能的、跨组件的团队，他们一个接一个地完成许多端到端的客户功能。
|
||
|
||
组建FT的初衷是为了最大化响应速度， 最大程度减少依赖，降低协作成本。想要提升业务的响应速度和协作效率，除了产品研发以外，市场、销售、服务等角色的协作同样至关重要。有赞的实践过程中我们组建了不同层级的FT，业务级FT像是一个创业小团队。产研FT更聚焦产品本身，按照产品的用户使用链路、功能模块来垂直划分，并效能平台（自研项目管理系统）上做FT配置，维护了一套虚线组织架构，明确了各个可独立作战的单元。
|
||
|
||
|
||
|
||
2.3 如何虚实结合？
|
||
2.3.1 对齐业务目标，职能团队作为后盾更专注专业能力提升
|
||
FT的OKR要基于整体业务OKR进行拆解以保持目标一致性。FT所有成员为FT OKR负责，避免各职能团队在拆解业务目标过程中的存在偏差。产研、销售、服务等实线职能部门OKR会更专注于如何提升团队专业领域的能力，避免因某个专业领域对业务发展造成瓶颈。具体OKR实践方式参见《如何用OKR促进跨团队协同》这篇文章。这样一来，既解决了职能组织跨部门协调响应慢的问题，又解决了FT成员专业成长不足的问题。
|
||
|
||
|
||
2.3.2 团队协作：团队自组织
|
||
FT组内在迭代过程中会不断地复盘和总结，经过长时间的磨合，会逐渐沉淀出FT内部的约定，形成FT自己的文化。一些最佳实践的案例，还可以通过PM推广到其他团队中，互相借鉴成长。解决了职能组织模式临时项目组归属感较弱的问题，协作沟通成本高的问题。
|
||
|
||
2.3.3 建立各FT规划沟通机制，灵活安排资源
|
||
为了减少外部依赖， FT要求成员保持全职专注。从全局来看，必然造成人员利用率可能达不到满负荷。这是由FT的价值观决定的：响应速度高于人员利用率。关注等待的事，而不是等待的人。在有赞的实践中，我们仍然保留了月度规划的动作，但范围缩小在FT内部，将有外部依赖的项目标识出来，统一沟通协调。在保障FT项目可满足的情况下，视人员安排情况支持外部项目。从而解决FT组织形式中，人员利用不足的问题。具体实践详见《大规模产品技术团队需求管理实践》。
|
||
|
||
|
||
2.3.4 公共资源如何分配到FT？成立决策组
|
||
FT会争夺那些未被划分的公共资源，如设计师、中台技术。这类问题无法通过FT自身来消除，需要更高层面的组织来决策，通常的形式是成立决策组，来协调各业务的资源分配。对于业务层面来讲，也可以成立自己的决策组来协调业务内部各FT的问题，一般由业务负责人和各职能TL组成。除此机制之外，还需要一些沟通机制定期对齐各业务的规划，提前做好资源分配，减少后期临时协调的可能性。
|
||
|
||
三、总结
|
||
是“做事用人”还是“用人做事”?答案是肯定的，一切都是关于“人”，在引入变革时，需要考虑组织的接受程度。有赞的实践结合了两者的特点，建立了FT虚拟团队和职能团队实线管理的混合模式，职能团队根据业务合理分配人力投入，并成为专业能力提升的组织，而FT为一个业务导向的独立作战单元。需要结合自身业务情况做出最适合的组织优化方向。
|
||
|
||
### reference
|
||
- [虚实结合的 Feature Team 实践](https://cloud.tencent.com/developer/article/1684562)
|
||
|
||
|
||
|
||
前台无力推动技术
|
||
中台不对结果负责
|
||
到后面前台觉得没技术成长
|
||
到后面中台觉得没有跟着业务成长
|
||
中台怎么分配资源，都会有前台觉得阻碍发展
|
||
沟通成本增高
|
||
本质上KPI不一致，就无法高效地做事
|
||
在这个事儿上，我只看到节约成本来着，不考虑招聘难带来的效率损失，本质上是在降低效率的
|
||
然而事实上，阿里想推动的，可能只是节约部分公共资源的成本，真做到大中台，是非常难的
|
||
|
||
大中台：子弹能快速输送到位吗
|
||
小前台：特种部队能有效作战吗
|
||
|
||
|