对于互联网行业的工程师，常思考的是系统的 Scalable，例如，流量、计算、存储增长时如何改进系统，有各种水平、垂直扩容的方案。除了服务，团队的 Scalable 也是十分关键的。本篇主要思考的是，如何组织团队，在一定规模下，通过加人能够提升团队的事务处理能力。
1. 人事分离
对于小公司，通常是少数的 Top 员工支撑起整个团队的 KPI 。想要做到人事分离，并不容易。但极度依赖少数员工，对整个团队来说，并不是一种健康的状态。
人和事情不能绑定在一起。一个人单点处理事务，确实很快，也容易上瘾。用惯了就一直用，熟悉了就沿用惯例。这样其他人就很难接手这类事务，更重要是无法提升其他成员相关的能力。不用等到事务量上去，一旦个人休假或者离开，都会对整个团队都会造成很大影响。
人事分离，就是要将流程固化，处理事务就是在启动流程。分为下面三个步骤:
梳理责任线。例如，需要开发 A，运营 B，主播 C。在一条责任线上，处理流程、注意事项、历史事故等，都需要记录在知识库，给出 tasklist、checklist，列出 1、2、3 。
整理开启流程的原料。例如，直播完了，需要上传视频到 B 站。根据上一步的流程，需要去 Zoom 下载视频、裁减视频、添加 Logo 页、添加水印、添加字幕、导出指定格式、上传视频到 B 站、等待审核、群发通知。在这个流程中，需要登录 Zoom 和 B 站。那么这些账户信息，就需要被记录和授权，同时这些账户应该属于团队而非个人。
开启流程。有了上面两步的支撑，授权用户都可以开启流程。这样的产出物可能会因为个人能力差异无法保证一致性，但是满足 Scalable 。
2. 端到端交付
没有交付价值之前，都是无意义的。
如上图，在一个流程中涉及 A -> B -> C 。很多团队的划分是 A 一个人负责，B 一个人负责，C 一个人负责。这样的架构在互联网公司很难适应，他们没有达成一致的价值交付。A 的价值是交付给 B ，但却忘了只有 C 完成了交付，才能给客户提供价值。同时，在交付要求越来越多的情况下，A、B 都可能不足以支撑 C，而成为瓶颈。
一个人负责一件足够小的能独立完成的事。如果不能，那么就拆分这个事；如果还是不能，那么劝退这个人。
一人一事，全程跟进，完成主要的工作，剩下的可以请其他成员协助，而不是要求全能。这并不是一个能力的要求，而是交付意识的要求。在没有上线、没有抵达客户之前，事情就没完，需要不断地关注、改进、推动。
每个人都实践端到端的交付，在交付增长的情况下，团队加人是可以应对的，满足 Scalable 。
3. 使用外部服务
在设计软件架构时，有一个优化点就是将存储分离出去，使用第三方提供的存储，这样业务层就可以通过增加副本数，应对增长的流量。
在组织团队时，也有类似的场景。引用之前的一篇文档: 为什么要使用远端构建 ，下面是其中的一些要点:
- 提高自动化水平
- 有利于其他人参与
- 版本可追溯、可复现
- 更低的成本
- 适合远程办公
使用公共的外部服务，能避免事务对个人的依赖，满足 Scalable 。
