Part I: What and Why
“对手刚出了个新功能,这个功能咱们之前也讨论过,这次要做起来,要快,大约什么时候能上线?'
“得去找个人做需求和设计,还要约运营聊一下具体需求; 现在产品经理手头都有别的事,要等; 需求出来后评审,评审完开发,单开发工作量,目测三天差不多,但得找研发负责人要资源,现在不一定有,要等另外几个功能做完之后,现在每个人手头都好几件事。 这个功能同时涉及新的计费模式和账号体系,这两个模块是另外一个部门在维护,得出人对接,最终也要等他们的工作量预估和排期。'
特性团队是跨专业的,面向最终用户交付完整价值的团队。
为了能够高效的完成工作,团队成员通常在一起面对面办公,紧密合作,专注的一起完成当前任务。
为了能够高效的完成工作,团队通常有一定的授权,能自组织的做出决策,并对结果负责。
可能的话,他们会保持稳定,长期专注于相同领域的不同任务。
不是,特性团队早就出现在社会的各个角落,只不过有不同的名字。
第一个名字是公司。是的,几乎所有公司都经历了特性团队的形式,这就是每个公司的初创阶段。 在这个阶段,公司作为一个整体,几乎满足特性团队的每一个特点: 跨专业,面向最终用户交付完整价值,在一起面对面,专注,拥有全部的决策权,及承担全部后果。 也就是说,公司在人类社会中存在的历史即特性团队存在的历史。
第二个名字是全栈工程师。 历史上那些著名的个人软件,很多都是一个人努力的结果。 这一个人承担了设计研发测试营销运维,所有的一切。 这种个人软件研发的组织形式,几乎满足特性团队的每一个特点: 跨专业,面向最终用户交付完整价值,在一起面对面,专注,拥有全部的决策权,及承担全部后果。 也就是说,全栈工程师在人类社会中存在的历史即特性团队存在的历史。
公司和全栈工程师,是一根标尺的两端,是特性团队的两个极端,一个是范围最大的特性团队,一个是范围最小的特性团队。 实际运作中的特性团队,就在这根标尺上滑动,其范围介于公司和个人之间,另一个例子就是业务线/产品线。
第三个名字是业务线/产品线。 业务线也是全功能的,面向最终用户,各种专业技能都具备; 业务线的员工不会去做别的业务线的事情,保持专注。 只要规模允许,同一业务线就在一起办公,面对面。 拥有较为自主的决策权,并对自己的业务结果负责。
所以问题来了,公司是最小的作战单元吗? 业务线是最小的作战单元吗? 顺着问下去,就会一直到全栈工程师,这确实是最小的作战单元。
所以特性团队其实是一种分形结构,存在于社会组织的各种尺度上。
特性团队的高效,帮助公司度过初创阶段存活下来。 但可惜的是,大部分公司在后来的扩张过程中,却抛弃了这一高效的组织方式,真是一件奇怪的事。 那么公司扩张过程中,都采用了哪些组织方式?
职能团队(也叫专业团队,Discipline Team,Function Team),比如研发团队,测试团队,设计团队,运营团队,市场团队,销售团队。
地域团队(Location Team),比如北京团队,南京团队,印度团队,欧洲团队
组件团队(Component Team),比如计费团队,订单团队,支付团队
各有各的适用场景。 那特性团队的优势有哪些? 特性团队的应用场景有哪些?
快速响应
其它团队组织形式如职能团队,组件团队等,每个团队都只负责价值链的一环,一个问题是容易造成上下游之间的博弈,如开发人员和产品经理,开发人员和测试人员之间旷日持久的争执。 特性团队将各种角色的人员组织在同一个目标下,可以使其上下同欲。
其它团队组织形式如职能团队,组件团队等,存在沟通和决策瓶颈,比如所有问题都要经过职能部门 leader 协调,沟通是不必要的网状,特性团队将沟通收敛在团队内部,缩短决策周期,消除决策瓶颈,将极大减轻更高一级领导者的决策负担。
用户价值导向
由于特性团队是围绕着产品特性,从用户角度建立的,也就天然使得团队更关注用户价值和市场价值。
其它团队组织形式如职能团队,组件团队等,每个团队都只负责价值链的一环,成员容易只关注自己相关的部分,另外一个问题是容易造成信息传递过程中的曲解,如开发人员,产品经理,测试人员,运营人员对同一个需求理解的不一致。 特性团队同地办公,可以随时面对面交流的特点,可以使信息尽可能保真。
激发创新
特性团队需要对最终结果负责,以交付用户需要的价值为己任,这给了团队创新的紧迫感。 而一定范围的授权,又给了团队创新的主动性。 跨专业技能的融合,有了创新的土壤。 特性团队从以上方面,有助于激发创新。
落实责任
特性团队对用户负责,对结果负责,将有助于减少很多事情无人跟进,最终给公司带来损失的后果。
驱动学习
由于一个特性团队需要对某一特性负责,并且团队将坐在一起工作,这样的场景从多个方面驱动了个人和团队主动学习更多的知识:
专业领域方面,由于个人与特性相关的专业领域关系更为明确,责任更强,从而促使员工再专业领域方面继续钻研以满足职责所需。
横向扩展方面,由于一起工作的成员都是不同领域的专家,从而提供了一个很好的学习场景和氛围。
部分情况下需要帮助其它专业的成员一起完成工作,或是阶段性接手其工作,这从实战中促进了其技能增长。
从长期考虑,学习型组织的文化搭建对于企业的成长和改进都是非常有助益的。
激励员工
研究表明,当一个团队对一个完整的用户导向的工作单元负有端到端的责任时,员工将更有动力也更有成就感,而这恰恰是提高生产率和走向成功的一大关键。
特性团队在很多场景下都有应用。
市场环境快速变化的场景
在变化速度快,充满不确定性的市场,对组织的要求是响应速度,并交付用户真正需要的功能,此时应尽可能缩短决策周期,尽可能消除沟通和执行中的等待,尽可能避免沟通中的信息失真。
特性团队快速响应和用户价值导向的优点将帮助我们前进。
未知,需要探索创新的场景
有时我们面对一个全新的领域,以前的方案全都不工作,甚至用户是谁都不知道。 此时需要快速试错。 特性团队激发创新以及对结果负责的特点将帮助我们前进。
不把所有鸡蛋都放在同一个篮子里。 组建特性团队进行探索,激发个人潜能,保持组织的反脆弱性。
特性团队探索成功后,将会发展为新的业务线,子公司等。
组织扩展,整体决策机制存在瓶颈的场景
组织迅速发展壮大的一个常见现象,就是初创阶段的领导者和管理者成为决策瓶颈,领导梯队没有建立,难以应付市场的快速变化。 如果公司扩展新业务,则对新业务领域知识的缺乏也会影响决策效率。
通过将一定的决策权下放给特性团队,高层领导者和管理者可以从部分日常事务和业务细节中解脱出来,专注于更重要的事情。
需要集中兵力攻坚的场景
有时我们面对一个难题,需要多方合作,此时采用职能团队,组件团队,地域团队的组织方式都将大大减缓问题的攻克。 临时搭建跨专业的,全职的,在一起工作的特性团队将是在效率上唯一可行的办法。
竞争激烈的场景
竞争激烈的环境通常融合了上述多个场景: 快速变化,不确定,需要集中兵力对战。 在这种场景下,每个交火点,都应该以特性团队来组织,慢必赔。
责任缺失的场景,公共事务推动
当组织壮大后,不可避免的有些公共的责任分摊到每个内部子组织身上,但没有人整体负责。 长此以往,一些不紧急但重要的工作将被贻误。 组建特性团队,明确的赋权和赋责,将有力推动此类事情的解决。
需要持续打磨高品质产品的场景
只有持续的根据反馈调整设计,才会更有可能获得产品和技术洞见,商业洞见,从而打磨出高品质的产品。 职能团队将人力看做资源池的视角,容易使领域知识随着人员的轮换而流失。 特性团队通过长期的工作,可以深度挖掘领域知识,并使之固化在产品设计中,防止知识流失。
持续学习对成长至关重要的场景
如果组织未来的增长不取决于物质资源,而是成员的能力,组织的能力,那么拥有决策权和对结果负责的特性团队将是最好的练兵场。
如上,特性团队从结构上,为响应速度,创新,以及责任进行了优化,但也因此有它固有的问题。
围绕着特性团队有很多质疑,比如对人员能力的要求提高,成员归属感的减弱,考核和激励不好搞等。 这都不是特性团队的问题,特性团队只是让这些你本来并没有很好解决的问题暴露出来。 也就是说,这些问题之前就存在,但原来的组织方式掩盖了这些问题的严重性,其后果就是,虽然表面上风平浪静,但实际上组织效能并没有达到最优。
而特性团队作为一种组织结构,其固有的结构性问题只有三个: 概念一致性,人员利用率,及公共资源争夺。
概念一致性
为了响应速度,特性团队按照端到端的价值链来组织团队,串起所有环节,这必然造成同一环节内部一致性的减弱。 比如不同特性团队负责的功能可能采用不同的交互方式,造成用户的学习成本,体验的破坏。
人员利用率
为了响应速度,减少依赖,特性团队要求成员保持全职,专注,避免异地办公。 这必然造成从全局来看,人员利用率可能达不到 100%。 这是由特性团队的价值观决定的: 响应速度高于人员利用率。 关注等待的事,而不是等待的人; 关注接力棒,而不是运动员。
公共资源争夺
业务线会争夺公司的公共资源,各特性团队会争夺业务线的公共资源。 这是结构性的,没有太好的办法。
对于这三类固有的结构性问题,无法依赖特性团队自身来消除,都需要特性团队之外的组织形态来帮忙。 而一类常见的形态就是决策委员会。
对于概念一致性来讲,决策委员会的表现形式可以是首席架构师,首席设计师等,也可以是架构委员会,设计委员会,定期或按需 review 设计问题。
对于公共资源争夺来讲,需要高一级的决策机构,对于公司来讲,就是总裁办,由总裁办来协调各业务线的争夺,对于业务线来讲,也可以有自己的决策委员会来协调业务线内部各 FT 的问题。
顾名思义,Feature Team,按照 Feature 来划分。
这个回答不解决问题。 Feature 的粒度是多大? 其涵义可能很广,而其实现所涉及的技术栈深度又可能很深,那么边界在哪? 所以问题有两个,Feature 的广度和实现的深度。
Feature的广度
当我们谈到 Feature 时,更多的是面向最终用户的软件上的功能特性,比如下图:
但软件的功能特性太多了,这样岂不是要分出很多特性团队?
这里引入一个”需求领域(Requirement Area)”的概念: 从客户角度考虑的相关需求的集合。 比如上图的”漂流瓶”,“摇一摇”,“附近的人” 就可以作为一个需求领域”交新朋友”来交给一个特性团队开发维护。
Feature 实现的深度 (当特性团队遇上微服务架构)
而每个功能的完整实现,通常涉及众多技术和模块,那么边界在哪? 比如”摇一摇”和”附近的人”,都要用到定位服务,朋友圈发照片也可以带地点,那么定位服务的开发是否放到某一个 FT 里? 还是单独的团队? 放到 FT 的话,放到哪一个 FT? 几乎每个功能都会涉及的数据存储,消息发送,放到哪?
回答这个问题,需要回到 FT 的初心: 最大化响应速度,最大程度减少依赖,降低沟通成本。 而在实现层面,依赖以及沟通成本,跟软件系统架构密切相关。
如果你的系统是大泥球,还没有所谓的定位服务,那么定位服务的开发应该放到第一个涉及定位服务的 FT 里。 即使你做了系统设计,单独划分了定位服务,但只要接口还不稳定,还需要跟使用方密切沟通,那还是应该跟第一个使用方在同一个团队中合作,在合作中打磨接口。 而一旦将服务接口打磨到一定的稳定程度,服务使用者只需要根据手册就能很好的把服务用起来,不需要跟服务的开发者有过多交流,那么服务团队就可以独立出来,就跟我们用到的第三方框架,第三方服务一样。
随着功能的深入,同一个服务的接口需要增加和演化,那么采取同样的过程: 只要接口还不稳定,服务开发人员就进入第一个使用方团队一起开发,稳定后撤出。
当划分 FT 时有多种选择时,有一个简单的实践原则来帮助判断: 看看不同的划分方式中,哪一种沟通成本更低,响应速度更快。 如果差不多,那就根据其它维度如概念一致性等选择即可。
那是特性团队的 KPI,而不是划分维度,因为业务目标和功能特性往往是多对多的关系,互相有交叉,难以在团队层面按照业务目标去划分,尤其是基础业务目标。
所谓基础业务目标,如活跃用户数,差评率,NPS 等,涉及所有功能,如果成立一个特性团队来做,将囊括组织内所有成员,这没有意义。 如果真要成立,那也主要是有团队成员盯着这方面的问题,将任务分解到各个真正的特性团队去完成。 但依然比不成立要好: 因为在很多组织中,很多公共的问题都没人跟进。
基础业务目标应分解到各个特性团队共担,比如每个团队都需要关注跟自己功能相关的活跃用户数,差评率,NPS 等。
特定业务目标对应特定需求领域的,那么按照需求领域划分和按照业务目标划分其实是一致的,没有区别。
初创公司 CEO 的能力要求。
从前面的讨论,特性团队某种程度上,就是一个内部创业的公司,作为这个团队的 Leader,首先从责任上,需要对结果负责。 其次从能力上,需要整体的领导力,包括对业务的把握,对产品技术的理解,对团队的管理,都有要求。
上面说的是最高要求,包含了决策和执行两部分。
实际情况中,公司内部的支持一定程度上会降低对特性团队Leader决策能力方面的要求,更多的是需要其执行能力,根据分解下来的目标把事情搞定的能力。
初创公司员工的能力要求: 全局视角,把事搞定的能力,快速学习的能力。
某种程度上,这并不是多特殊的能力要求,如果你的组织不需要员工具备这样的能力,组织日常的低效可想而知,应对快速变化的能力可想而知。
'全公司就几个设计师,几个DBA,这么多特性团队,怎么分?'
我们是否有必要为每个特性团队所需的每种技能都配备全职的人员? 人员利用率是特性团队的弱点之一,但不意味着我们不能做些什么。 我们可以主动规划一些共享资源,而避免付出无谓的人力成本。 这里的关键点在于分清哪些可以共享,哪些尽量不要共享。
可以共享的资源有几个特点。
第一个是工作占比在整个链条中比例不高,比如 5~10%。
第二个是所需技能有一定门槛,人员较为稀缺,成本较高。
第三个是可直接使用其成果而无需频繁交流,每天都要交流的不合适共享。
第四个是共享排期等待的起。
这几个条件需要同时满足,否则应该通过招聘和快速的能力培养来解决,而不是共享。 举个例子:
2007年的时候,我所在的团队正在进行一个开源的持续集成工具的开发。 团队的成员都对 Web UI 的各种界面样式和效果不精通,仅仅能使之功能正确,但很难看。 当时招聘和快速学习 CSS 都达不到要求,我们当时雇佣了一个这方面的专家作为 Contractor,他每周四上午来半天,跟我们一起工作,把我们攒了一周的样式和效果问题在两三个小时内全部解决。
通常公司的运维人员,DBA等,满足上面四个条件。 事实上对于有一定体量的互联网公司来讲,不建议招聘工作经验较为缺乏的运维人员/DBA。 这个岗位永远都应该是在其它地方经过历练的专家。
这个问题并不关键。 建议跟着产品/Feature/任务走,随需要自然扩张或自然缩减,不必刻意打散或保持。
保持长期有好处。 出于稳定性的考虑,磨合成本的考虑,熟悉之后配合更高效的考虑,'成员归属感'的考虑,你可能会选择保持长期的团队。 这没问题,但依然要关注新鲜血液的注入,以及老成员正常的轮换。
事实上你对长期团队的偏爱并不是特定于特性团队的,即使其它的团队形态,你也会因为上面那些理由倾向于长期。 因此你的选择与特性团队无关。
事实上其它的团队形态,如职能团队,地域团队,你都没办法短期,也因此不得不长期,从而享受不到短期团队的好处。
而特性团队根据面向用户的Feature组队的特点,反而提供了另外一种灵活性,让成员有机会接触更广阔的业务和知识,接触其他的成员,从而更全面。
It's up to you。
可以认为团队在封闭期间的组织形态较为接近特性团队,所有相关的人都关在一起,最小化对外界的依赖,此时效率较高。
当我们谈论封闭开发时,并不是所有封闭都是晚上不能回家的那种,更多的是在公司找个大点的会议室,团队搬进去一起工作,还是正常上下班。 所以这也是一件很奇怪的事: 如果认为封闭是高效的,为什么日常不采用这种方式呢? 包间不够? 大厅里的桌子也可以啊。
范围不同,其它都一样,如果你的组织是产品研发组织的话。
Feature 是从 Product 分解下来的,因此一般 PO 的负责范围比 FTO 要大一点。
如果你的 FT 负责一个完整的产品,那么 FTO 就是 PO。
还是像在 特性团队是新事物吗? 一节中解释的,FT 存在于社会组织的各种尺度上,因此,FTO 也就是 CEO,GM,PO....
PO是甲方的,FTO是乙方的,如果你的组织是IT服务组织的话。
联系客服