打造可伸缩的技术团队-可伸缩Web开发第三技术

创业公司刚开始时，通常不过两三个工程师，围绕核心业务，开发一个简单的版本就发布上线开始运营了。随着业务不断发展，服务器数量必定是越来越多、技术越来越复杂，对应的，公司规模也是越来越大，工程师团队越来越多人。一般说来，一家互联网公司能做到上市，工程师团队的人数大概从数百人到数千人不等，技术团队规模和创业时相比扩大数百倍。这就要求必须有效组织工程师团队，打造可伸缩的技术团队，使技术团队的成长和公司业务成长、技术水平进步保持一致。

1. 团队拆分

制约一个团队人数规模的主要因素是沟通路径，沟通路径越多，信息传递越慢，传递过程中引入的噪音越多，团队越趋于混乱。一个5人团队，沟通路径是10=(5*4)/2，一个9人团队，沟通路径是36=(9*8)/2，沟通路径随团队规模呈指数级增长。所以当技术团队人数增长到一定规模，和构建可伸缩的Web架构中需要对服务进行拆分一样，需要对团队进行拆分，将一个大团队拆分成几个小团队，使每个小的团队保持一个比较少的人数。

团队拆分有两种方案，一种是按职能拆分，前端工程师、后端工程师、测试工程师、运维工程师、数据仓库工程师各种工程师分别构成一个个的小团队，这种拆分的好处是团队结构比较稳定，团队成员都是使用同样技术的“自己人”，团队内部沟通交流更快速高效;带来的问题是开发过程是按照产品和项目组织的，而开发一个产品需要用到前端、后端、测试、运维各种工程师，开发过程会遇到各种跨团队的交流与合作，带来更多的沟通成本。另一种是按照产品和项目拆分，团队围绕产品展开，每个团队内部拥有开发维护一个产品所需的各种技术角色，从开发到测试发布运维都在团队内部搞定，不需要太多跨团队合作，这种拆分也存在一些问题，特别是创业公司早期，产品不稳定，管理层决定要上一个新产品，于是迅速招人开发，但是很多时候产品刚上线不久甚至还没上线，管理层的决定又有变化，产品不做了，团队解散，这种朝令夕改会对技术团队造成较大伤害，所以某些互联网公司特别将“拥抱变化”上升到公司价值观高度，让员工对这种情况做好心理准备。

对于公司而言，前一种方案带来的问题是沟通低效、人员冗余、开发进展缓慢;后一种方案带来的问题是员工情绪低落影响士气。显然前一种方案对公司发展影响更大，所以实践中，更多公司采用后一种团队组织方式。为了应对这种方案带来的消极影响，公司会积极组织各种培(xi)训(nao)，提供各种员工福利员工关怀，让员工忘记各种不快，投入到下一个产品开发中。不过对创业公司而言，从本质上，员工利益和公司利益是一致的，只有公司活下去、做大做强，所有人才能更好的获益，不过这也要求创业公司尽可能做到决策透明，让所有员工能理解管理层的决定，并自觉维护、执行管理层的决定。

2. 保持敏捷

创业团队白手起家，不但表现在缺资金缺用户缺人才，也表现在缺管理缺标准缺规范，于是采用各种“野路子”的管理手段。但是公司发展到一定规模，这些手段就开始捉襟见肘，出现各种问题，于是公司开始从各种名企外企引入各类『管理人才』，进行规范化管理。不过在这个规范化的过程中，有时候会出现某种矫枉过正，导致公司僵化笨拙，还没成为大公司却得了一堆大公司的病。

举两个极端但是真实的例子。某公司要求代码单元测试覆盖率必须达到一定比率，并且写了工具专门扫描工程师提交的代码是否达到要求的单元测试覆盖率，于是就看到有些工程师为getXXX和setXXX方法写测试用例。某公司要求设计阶段必须写设计文档，并提供了设计文档模板，这个模板有一章叫做『数据库设计』，某个项目不需要数据库，因此设计文档不通过评审，为此工程师不得不设计了一个永远不会用到的数据库。

某位伟人曾经说过：教条不如狗屎，狗屎可以肥田，教条屁用没有。有些『管理人员』自己不曾在一线实践过，却为一线人员制定各种规章制度，效果可想而知。对创业公司而言，最好的管理不是流程规范，而是最佳实践。某个项目迭代管理做得好，某个项目设计文档写得好，拿来在全公司分享，大家一起学习改进，在实践中提高，产生更好的实践继续分享。从实践中来到实践中去，而不是从PPT来到Word中去。

总结

本文限于篇幅，概要描述了Web应用可伸缩架构技术，期望创业公司工程师在创业早期就能明了网站技术发展的一般模式，更好地规划自己公司的技术发展道路。关于网站可伸缩架构的更多技术细节，可以根据这篇文章提到的技术点按图索骥阅读更多资料，更重要的当然是在实践中学习，随着公司逐步壮大，自己也逐渐成长为网站技术方面的卓越人才。期待未来最伟大的互联网公司出现在中国，期待未来最顶尖的互联网技术人才出现在本文的读者当中，祝福大家。

相关推荐：

构建可伸缩的Web架构-可伸缩Web开发第一技术

使用可伸缩的基础技术产品-可伸缩Web开发第二技术

打造可伸缩的技术团队-可伸缩Web开发第三技术