对于互联网行业的工程师，常思考的是系统的 Scalable，例如，流量、计算、存储增长时如何改进系统，有各种水平、垂直扩容的方案。除了服务，团队的 Scalable 也是十分关键的。本篇主要思考的是，如何组织团队，在一定规模下，通过加人能够提升团队的事务处理能力。
1. 人事分离
对于小公司，通常是少数的 Top 员工支撑起整个团队的 KPI 。想要做到人事分离，并不容易。但极度依赖少数员工，对整个团队来说，并不是一种健康的状态。人和事情不能绑定在一起。一个人单点处理事务，确实很快，也容易上瘾。用惯了就一直用，熟悉了就沿用惯例。这样其他人就很难接手这类事务，更重要是无法提升其他成员相关的能力。不用等到事务量上去，一旦个人休假或者离开，都会对整个团队都会造成很大影响。人事分离，就是要将流程固化，处理事务就是在启动流程。分为下面三个步骤:
2. 端到端交付
没有交付价值之前，都是无意义的。
如上图，在一个流程中涉及 A -> B -> C 。很多团队的划分是 A 一个人负责，B 一个人负责，C 一个人负责。这样的架构在互联网公司很难适应，他们没有达成一致的价值交付。A 的价值是交付给 B ，但却忘了只有 C 完成了交付，才能给客户提供价值。同时，在交付要求越来越多的情况下，A、B 都可能不足以支撑 C，而成为瓶颈。一个人负责一件足够小的能独立完成的事。如果不能，那么就拆分这个事；如果还是不能，那么劝退这个人。一人一事，全程跟进，完成主要的工作，剩下的可以请其他成员协助，而不是要求全能。这并不是一个能力的要求，而是交付意识的要求。在没有上线、没有抵达客户之前，事情就没完，需要不断地关注、改进、推动。每个人都实践端到端的交付，在交付增长的情况下，团队加人是可以应对的，满足 Scalable 。
3. 使用外部服务
在设计软件架构时，有一个优化点就是将存储分离出去，使用第三方提供的存储，这样业务层就可以通过增加副本数，应对增长的流量。在组织团队时，也有类似的场景。引用之前的一篇文档: 为什么要使用远端构建 ，下面是其中的一些要点:
使用公共的外部服务，能避免事务对个人的依赖，满足 Scalable 。
