当谈论Feature Team时我们在谈些什么

特性团队

“对手刚出了个新功能, 这个功能咱们之前也讨论过, 这次要做起来, 要快, 大约什么时候能上线?"

“得去找个人做需求和设计, 还要约运营聊一下具体需求; 现在产品经理手头都有别的事, 要等; 需求出来后评审, 评审完开发, 单开发工作量, 目测三天差不多, 但得找研发负责人要资源, 现在不一定有, 要等另外几个功能做完之后, 现在每个人手头都好几件事. 这个功能同时涉及新的计费模式和账号体系, 这两个模块是另外一个部门在维护, 得出人对接, 最终也要等他们的工作量预估和排期."

什么是特性团队?

特性团队是跨专业的, 面向最终用户交付完整价值的团队.

为了能够高效的完成工作, 团队成员通常在一起面对面办公, 紧密合作, 专注的一起完成当前任务.

为了能够高效的完成工作, 团队通常有一定的授权, 能自组织的做出决策, 并对结果负责.

可能的话, 他们会保持稳定, 长期专注于相同领域的不同任务.

特性团队是新事物吗?

不是, 特性团队早就出现在社会的各个角落, 只不过有不同的名字.

第一个名字是公司. 是的, 几乎所有公司都经历了特性团队的形式, 这就是每个公司的初创阶段. 在这个阶段, 公司作为一个整体, 几乎满足特性团队的每一个特点: 跨专业, 面向最终用户交付完整价值, 在一起面对面, 专注, 拥有全部的决策权, 及承担全部后果. 也就是说, 公司在人类社会中存在的历史即特性团队存在的历史.

第二个名字是全栈工程师. 历史上那些著名的个人软件, 很多都是一个人努力的结果. 这一个人承担了设计研发测试营销运维, 所有的一切. 这种个人软件研发的组织形式, 几乎满足特性团队的每一个特点: 跨专业, 面向最终用户交付完整价值, 在一起面对面, 专注, 拥有全部的决策权, 及承担全部后果. 也就是说, 全栈工程师在人类社会中存在的历史即特性团队存在的历史.

公司和全栈工程师, 是一根标尺的两端, 是特性团队的两个极端, 一个是范围最大的特性团队, 一个是范围最小的特性团队. 实际运作中的特性团队, 就在这根标尺上滑动, 其范围介于公司和个人之间, 另一个例子就是业务线/产品线.

第三个名字是业务线/产品线. 业务线也是全功能的, 面向最终用户, 各种专业技能都具备; 业务线的员工不会去做别的业务线的事情, 保持专注. 只要规模允许, 同一业务线就在一起办公, 面对面. 拥有较为自主的决策权, 并对自己的业务结果负责.

所以问题来了, 公司是最小的作战单元吗? 业务线是最小的作战单元吗? 顺着问下去, 就会一直到全栈工程师, 这确实是最小的作战单元.

所以特性团队其实是一种分形结构, 存在于社会组织的各种尺度上.

</img>

特性团队的高效, 帮助公司度过初创阶段存活下来. 但可惜的是, 大部分公司在后来的扩张过程中, 却抛弃了这一高效的组织方式, 真是一件奇怪的事. 那么公司扩张过程中, 都采用了哪些组织方式?

特性团队之外的组织方式有哪些?

• 职能团队(也叫专业团队, Discipline Team, Function Team), 比如研发团队, 测试团队, 设计团队, 运营团队, 市场团队, 销售团队.
• 地域团队(Location Team), 比如北京团队, 南京团队, 印度团队, 欧洲团队
• 组件团队(Component Team), 比如计费团队, 订单团队, 支付团队

各有各的适用场景. 那特性团队的优势有哪些? 特性团队的应用场景有哪些?

特性团队的优势有哪些?

快速响应

其它团队组织形式如职能团队, 组件团队等, 每个团队都只负责价值链的一环, 一个问题是容易造成上下游之间的博弈, 如开发人员和产品经理, 开发人员和测试人员之间旷日持久的争执. 特性团队将各种角色的人员组织在同一个目标下, 可以使其上下同欲.

其它团队组织形式如职能团队, 组件团队等, 存在沟通和决策瓶颈, 比如所有问题都要经过职能部门 leader 协调, 沟通是不必要的网状, 特性团队将沟通收敛在团队内部, 缩短决策周期, 消除决策瓶颈, 将极大减轻更高一级领导者的决策负担.

用户价值导向

由于特性团队是围绕着产品特性, 从用户角度建立的, 也就天然使得团队更关注用户价值和市场价值.

其它团队组织形式如职能团队, 组件团队等, 每个团队都只负责价值链的一环, 成员容易只关注自己相关的部分, 另外一个问题是容易造成信息传递过程中的曲解, 如开发人员, 产品经理, 测试人员, 运营人员对同一个需求理解的不一致. 特性团队同地办公, 可以随时面对面交流的特点, 可以使信息尽可能保真.

激发创新

特性团队需要对最终结果负责, 以交付用户需要的价值为己任, 这给了团队创新的紧迫感. 而一定范围的授权, 又给了团队创新的主动性. 跨专业技能的融合, 有了创新的土壤. 特性团队从以上方面, 有助于激发创新.

落实责任

特性团队对用户负责, 对结果负责, 将有助于减少很多事情无人跟进, 最终给公司带来损失的后果.

驱动学习

由于一个特性团队需要对某一特性负责, 并且团队将坐在一起工作, 这样的场景从多个方面驱动了个人和团队主动学习更多的知识:

• 专业领域方面, 由于个人与特性相关的专业领域关系更为明确, 责任更强, 从而促使员工再专业领域方面继续钻研以满足职责所需.
• 横向扩展方面, 由于一起工作的成员都是不同领域的专家, 从而提供了一个很好的学习场景和氛围.
• 部分情况下需要帮助其它专业的成员一起完成工作, 或是阶段性接手其工作, 这从实战中促进了其技能增长.

从长期考虑, 学习型组织的文化搭建对于企业的成长和改进都是非常有助益的.

激励员工

研究表明, 当一个团队对一个完整的用户导向的工作单元负有端到端的责任时, 员工将更有动力也更有成就感, 而这恰恰是提高生产率和走向成功的一大关键.

特性团队应用场景是什么?

特性团队在很多场景下都有应用.

市场环境快速变化的场景

在变化速度快, 充满不确定性的市场, 对组织的要求是响应速度, 并交付用户真正需要的功能, 此时应尽可能缩短决策周期, 尽可能消除沟通和执行中的等待, 尽可能避免沟通中的信息失真.

特性团队快速响应和用户价值导向的优点将帮助我们前进.

未知, 需要探索创新的场景

有时我们面对一个全新的领域, 以前的方案全都不工作, 甚至用户是谁都不知道. 此时需要快速试错. 特性团队激发创新以及对结果负责的特点将帮助我们前进.

不把所有鸡蛋都放在同一个篮子里. 组建特性团队进行探索, 激发个人潜能, 保持组织的反脆弱性.

特性团队探索成功后, 将会发展为新的业务线, 子公司等.

组织扩展, 整体决策机制存在瓶颈的场景

组织迅速发展壮大的一个常见现象, 就是初创阶段的领导者和管理者成为决策瓶颈, 领导梯队没有建立, 难以应付市场的快速变化. 如果公司扩展新业务, 则对新业务领域知识的缺乏也会影响决策效率.

通过将一定的决策权下放给特性团队, 高层领导者和管理者可以从部分日常事务和业务细节中解脱出来, 专注于更重要的事情.

需要集中兵力攻坚的场景

有时我们面对一个难题, 需要多方合作, 此时采用职能团队, 组件团队, 地域团队的组织方式都将大大减缓问题的攻克. 临时搭建跨专业的, 全职的, 在一起工作的特性团队将是在效率上唯一可行的办法.

竞争激烈的场景

竞争激烈的环境通常融合了上述多个场景: 快速变化, 不确定, 需要集中兵力对战. 在这种场景下, 每个交火点, 都应该以特性团队来组织, 慢必赔.

责任缺失的场景, 公共事务推动

当组织壮大后, 不可避免的有些公共的责任分摊到每个内部子组织身上, 但没有人整体负责. 长此以往, 一些不紧急但重要的工作将被贻误. 组建特性团队, 明确的赋权和赋责, 将有力推动此类事情的解决.

需要持续打磨高品质产品的场景

只有持续的根据反馈调整设计, 才会更有可能获得产品和技术洞见, 商业洞见, 从而打磨出高品质的产品. 职能团队将人力看做资源池的视角, 容易使领域知识随着人员的轮换而流失. 特性团队通过长期的工作, 可以深度挖掘领域知识, 并使之固化在产品设计中, 防止知识流失.

持续学习对成长至关重要的场景

如果组织未来的增长不取决于物质资源, 而是成员的能力, 组织的能力, 那么拥有决策权和对结果负责的特性团队将是最好的练兵场.

如上, 特性团队从结构上, 为响应速度, 创新, 以及责任进行了优化, 但也因此有它固有的问题.

特性团队有哪些固有问题?

围绕着特性团队有很多质疑, 比如对人员能力的要求提高, 成员归属感的减弱, 考核和激励不好搞等. 这都不是特性团队的问题, 特性团队只是让这些你本来并没有很好解决的问题暴露出来. 也就是说, 这些问题之前就存在, 但原来的组织方式掩盖了这些问题的严重性, 其后果就是, 虽然表面上风平浪静, 但实际上组织效能并没有达到最优.

而特性团队作为一种组织结构, 其固有的结构性问题只有三个: 概念一致性, 人员利用率, 及公共资源争夺.

概念一致性

为了响应速度, 特性团队按照端到端的价值链来组织团队, 串起所有环节, 这必然造成同一环节内部一致性的减弱. 比如不同特性团队负责的功能可能采用不同的交互方式, 造成用户的学习成本, 体验的破坏.

人员利用率

为了响应速度, 减少依赖, 特性团队要求成员保持全职, 专注, 避免异地办公. 这必然造成从全局来看, 人员利用率可能达不到 100%. 这是由特性团队的价值观决定的: 响应速度高于人员利用率. 关注等待的事, 而不是等待的人; 关注接力棒, 而不是运动员.

公共资源争夺

业务线会争夺公司的公共资源, 各特性团队会争夺业务线的公共资源. 这是结构性的, 没有太好的办法.

对于这三类固有的结构性问题, 无法依赖特性团队自身来消除, 都需要特性团队之外的组织形态来帮忙. 而一类常见的形态就是决策委员会.

• 对于概念一致性来讲, 决策委员会的表现形式可以是首席架构师, 首席设计师等, 也可以是架构委员会, 设计委员会, 定期或按需 review 设计问题.
• 对于公共资源争夺来讲, 需要高一级的决策机构, 对于公司来讲, 就是总裁办, 由总裁办来协调各业务线的争夺, 对于业务线来讲, 也可以有自己的决策委员会来协调业务线内部各 FT 的问题.

特性团队的划分标准是什么?

顾名思义, Feature Team, 按照 Feature 来划分.

这个回答不解决问题. Feature 的粒度是多大? 其涵义可能很广, 而其实现所涉及的技术栈深度又可能很深, 那么边界在哪? 所以问题有两个, Feature 的广度和实现的深度.

Feature的广度

当我们谈到 Feature 时, 更多的是面向最终用户的软件上的功能特性, 比如下图:

</img>

但软件的功能特性太多了, 这样岂不是要分出很多特性团队?

这里引入一个”需求领域(Requirement Area)”的概念: 从客户角度考虑的相关需求的集合. 比如上图的”漂流瓶”, “摇一摇”, “附近的人” 就可以作为一个需求领域”交新朋友”来交给一个特性团队开发维护.

Feature 实现的深度 (当特性团队遇上微服务架构)

而每个功能的完整实现, 通常涉及众多技术和模块, 那么边界在哪? 比如”摇一摇”和”附近的人”, 都要用到定位服务, 朋友圈发照片也可以带地点, 那么定位服务的开发是否放到某一个 FT 里? 还是单独的团队? 放到 FT 的话, 放到哪一个 FT? 几乎每个功能都会涉及的数据存储, 消息发送, 放到哪?

回答这个问题, 需要回到 FT 的初心: 最大化响应速度, 最大程度减少依赖, 降低沟通成本. 而在实现层面, 依赖以及沟通成本, 跟软件系统架构密切相关.

如果你的系统是大泥球, 还没有所谓的定位服务, 那么定位服务的开发应该放到第一个涉及定位服务的 FT 里. 即使你做了系统设计, 单独划分了定位服务, 但只要接口还不稳定, 还需要跟使用方密切沟通, 那还是应该跟第一个使用方在同一个团队中合作, 在合作中打磨接口. 而一旦将服务接口打磨到一定的稳定程度, 服务使用者只需要根据手册就能很好的把服务用起来, 不需要跟服务的开发者有过多交流, 那么服务团队就可以独立出来, 就跟我们用到的第三方框架, 第三方服务一样.

随着功能的深入, 同一个服务的接口需要增加和演化, 那么采取同样的过程: 只要接口还不稳定, 服务开发人员就进入第一个使用方团队一起开发, 稳定后撤出.

当划分 FT 时有多种选择时, 有一个简单的实践原则来帮助判断: 看看不同的划分方式中, 哪一种沟通成本更低, 响应速度更快. 如果差不多, 那就根据其它维度如概念一致性等选择即可.

特性团队难道不是按照业务目标来划分的吗?

那是特性团队的 KPI, 而不是划分维度, 因为业务目标和功能特性往往是多对多的关系, 互相有交叉, 难以在团队层面按照业务目标去划分, 尤其是基础业务目标.

所谓基础业务目标, 如活跃用户数, 差评率, NPS 等, 涉及所有功能, 如果成立一个特性团队来做, 将囊括组织内所有成员, 这没有意义. 如果真要成立, 那也主要是有团队成员盯着这方面的问题, 将任务分解到各个真正的特性团队去完成. 但依然比不成立要好: 因为在很多组织中, 很多公共的问题都没人跟进.

• 基础业务目标应分解到各个特性团队共担, 比如每个团队都需要关注跟自己功能相关的活跃用户数, 差评率, NPS 等.
• 特定业务目标对应特定需求领域的, 那么按照需求领域划分和按照业务目标划分其实是一致的, 没有区别.

特性团队对Leader的能力要求是什么样子的?

初创公司 CEO 的能力要求.

从前面的讨论, 特性团队某种程度上, 就是一个内部创业的公司, 作为这个团队的 Leader, 首先从责任上, 需要对结果负责. 其次从能力上, 需要整体的领导力, 包括对业务的把握, 对产品技术的理解, 对团队的管理, 都有要求.

上面说的是最高要求, 包含了决策和执行两部分.

实际情况中, 公司内部的支持一定程度上会降低对特性团队Leader决策能力方面的要求, 更多的是需要其执行能力, 根据分解下来的目标把事情搞定的能力.

特性团队对成员的能力要求是什么样子的?

初创公司员工的能力要求: 全局视角, 把事搞定的能力, 快速学习的能力.

某种程度上, 这并不是多特殊的能力要求, 如果你的组织不需要员工具备这样的能力, 组织日常的低效可想而知, 应对快速变化的能力可想而知.

有哪些资源是可以在特性团队间共享的?

"全公司就几个设计师, 几个DBA, 这么多特性团队, 怎么分?"

我们是否有必要为每个特性团队所需的每种技能都配备全职的人员? 人员利用率是特性团队的弱点之一, 但不意味着我们不能做些什么. 我们可以主动规划一些共享资源, 而避免付出无谓的人力成本. 这里的关键点在于分清哪些可以共享, 哪些尽量不要共享.

可以共享的资源有几个特点.

• 第一个是工作占比在整个链条中比例不高, 比如 5~10%.
• 第二个是所需技能有一定门槛, 人员较为稀缺, 成本较高.
• 第三个是可直接使用其成果而无需频繁交流, 每天都要交流的不合适共享.
• 第四个是共享排期等待的起.

这几个条件需要同时满足, 否则应该通过招聘和快速的能力培养来解决, 而不是共享. 举个例子:

2007年的时候, 我所在的团队正在进行一个开源的持续集成工具的开发. 团队的成员都对 Web UI 的各种界面样式和效果不精通, 仅仅能使之功能正确, 但很难看. 当时招聘和快速学习 CSS 都达不到要求, 我们当时雇佣了一个这方面的专家作为 Contractor, 他每周四上午来半天, 跟我们一起工作, 把我们攒了一周的样式和效果问题在两三个小时内全部解决.

通常公司的运维人员, DBA等, 满足上面四个条件. 事实上对于有一定体量的互联网公司来讲, 不建议招聘工作经验较为缺乏的运维人员/DBA. 这个岗位永远都应该是在其它地方经过历练的专家.

特性团队需要保持长期稳定还是根据任务打散重聚?

这个问题并不关键. 建议跟着产品/Feature/任务走, 随需要自然扩张或自然缩减, 不必刻意打散或保持.

保持长期有好处. 出于稳定性的考虑, 磨合成本的考虑, 熟悉之后配合更高效的考虑, "成员归属感"的考虑, 你可能会选择保持长期的团队. 这没问题, 但依然要关注新鲜血液的注入, 以及老成员正常的轮换.

事实上你对长期团队的偏爱并不是特定于特性团队的, 即使其它的团队形态, 你也会因为上面那些理由倾向于长期. 因此你的选择与特性团队无关.

事实上其它的团队形态, 如职能团队, 地域团队, 你都没办法短期, 也因此不得不长期, 从而享受不到短期团队的好处.

而特性团队根据面向用户的Feature组队的特点, 反而提供了另外一种灵活性, 让成员有机会接触更广阔的业务和知识, 接触其他的成员, 从而更全面.

It's up to you.

封闭开发算特性团队吗?

可以认为团队在封闭期间的组织形态较为接近特性团队, 所有相关的人都关在一起, 最小化对外界的依赖, 此时效率较高.

当我们谈论封闭开发时, 并不是所有封闭都是晚上不能回家的那种, 更多的是在公司找个大点的会议室, 团队搬进去一起工作, 还是正常上下班. 所以这也是一件很奇怪的事: 如果认为封闭是高效的, 为什么日常不采用这种方式呢? 包间不够? 大厅里的桌子也可以啊.

FTO(FT Owner) 和 PO(Product Owner) 的关系是什么?

范围不同, 其它都一样, 如果你的组织是产品研发组织的话.

• Feature 是从 Product 分解下来的, 因此一般 PO 的负责范围比 FTO 要大一点.
• 如果你的 FT 负责一个完整的产品, 那么 FTO 就是 PO.

还是像在 特性团队是新事物吗? 一节中解释的, FT 存在于社会组织的各种尺度上, 因此, FTO 也就是 CEO, GM, PO...

PO 是甲方的, FTO 是乙方的, 如果你的组织是 IT 服务组织的话.

对于 PO 这个角色进一步的解释, 请参见: Scrum: 死马? (一) 三种角色

FT 成员的汇报关系是怎么样的?

每个组织不一样, 各有各的实际情况. 回到初心, FT 是为了提高响应速度, 如果 FT 成员直接汇报给 FTO 有助于提高响应速度, 那么可以选择让成员汇报给 FTO. 如果你有其它的约束, 那你需要综合考虑.

FT 对于提高响应速度的假设, 建立在全功能带来的沟通成本的降低上, 赋权带来的决策瓶颈的减少上, 专注带来的无谓等待的避免上, 并不直接建立在汇报关系上. 如果你的组织, 赋权需要借助汇报关系来完成, 那就可以设计对应的汇报关系.