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服务组织的话。
联系客服
