软件测试领域的中心化与去中心化

在文章开始，我想大胆预测，未来市场对测试总监岗位的需求量将会越来越少，根本想给文章取个极具噱头的名字：测试总监将消失，但是的确害怕被拍砖头。

关于中心化与去中心化，从事互联网行业的朋友一定不陌生，当然我也没有资格在此大谈何为中心化和去中心化，毕竟我也只是略知一二罢了。简单点讲，中心化（Centralization）和去中心化（Decentralization）就是集权与分权，在互联网上，就是指从我说你听的广播模式，向人人有个小喇叭的广场模式转变。中心化的典型例子是门户网站，去中心化的典型例子是blog、UGC用户生产内容如自媒体、社交媒体等。

对应到软件测试领域，如果从集权和分权来看，那就很好理解了。但是在说这个之前，还需要涉及到公司架构如何满足产品快速迭代的内容。如果一个机构越来越大，层级关系愈来愈深，其决策速度就会愈来愈慢，不管是从上往下传达战略还是从下往上反馈信息等，都会变慢，而面对互联网时代以短平快著称的模式，如果想要快速决策并做出产品的雏形，发布上线让用户介入体验，快速试错，在证明拥有市场时快速迭代，一个庞大的机构组织是难以站稳脚跟的，这时候集权就必然走向分权，把业务分拆成多个子单元，每个子单元是一个部门，此部门独立配置各职能人员，以加速产品研发上市。而这在传统软件时代可能并不明显，也许一个Windows版本或者Oracle数据库需要一两年的时候才会更新换代，甚至更长，而通过小米的手机操作系统就可以看出每周一次迭代发布，新功能或应用及时让用户体验到，米粉参与其中以改善优化产品，其周期大大缩短。这也基于小米公司弱化KPI以及精简组织架构的工作方式所带来的巨大革新，大家都知道，小米层级之少，大家入职之后发现都是工程师，没有什么经理，总监稀少，分权带来的就是高效率运转。对于京东来说去年底发生的研发部门跟随业务线的架构调整也是基于提高效率考虑，这也就是所谓的去中心化。

那么，对于测试人员的部署情况，也会随之发生变化，业务部门会被独立成一个一级部门，因为业务部门的负责人极有可能并不太懂软件技术，在此部门下会安放各种职能岗位的人，比如运营，产品，研发，客服，配置HR等，所以在此部门下也许只有一个开发总监负责产品及研发，如果再另外独立出一个测试部门已不可能，倘若按10人左右的QA团队，开发测试比为3：1甚至是4：1计算的话，三四十人的开发团队已经能做出不少产品了，可能足以应付业务部门的发展需要了。对于这样一个QA团队，一个测试经理足以应付，如果业务发展快速部门壮大，需要更多研发人员时，QA团队可能就需要一个测试总监来把QA团队分拆成几个小组，与不同的研发团队配合工作，当然这还是好的情况，坏的情况就是研发团队各自配备QA团队，研发总监来管理QA团队，那么测试总监就失业了。这可能就是软件测试领域的去中心化。

当然，万物皆有利弊两面性，去中心化的优势就是效率的提升，毕竟每个研发团队下面的项目可以及时的排上测试排期保证上线，当然这是在人手充沛的情况下。举个例子，假如此时研发A部门正在做一个公司战略级的产品，但是QA人手不够，但是想要保证排期的话就只好向其他部门比如研发B部门借人，而B部门也不是闲着，在同时做好几个项目，只是其重要性低于A部门的产品，这个时候肯定就需要A,B两个部门共同的顶头上司来协调了，但是更多的时候A部门是不会反馈这个问题的，因为人员招聘流失等都属于部门负责人的工作，大部分情况就会导致此重要项目的延期上线或者质量较差就流入用户。这时候如果有一个与AB部门同级的QA总监的话，我想他一定会权衡对应所有项目的重要性，合理调配资源，就完全不会出现A部门那种情况了。当然，QA团队分离的另外一个坏处就是很多公共测试平台及知识分享都需要单独组织搭建，所谓重复造车轮，所以在很多公司，这时候又会出现局部中心化的情况，有为全公司服务的安全测试团队，性能测试团队，持续集成团队等等， 这在京东，百度，腾讯等大公司都是如此，毕竟把专业化很强的人聚集起来有助于团队的交流发展及人才培养及晋升。

当然，中心化与去中心化在什么样的状态才最有利于业务的发展，实在不能一概而论，但是有一点不容否认，随着业务部门的分拆，研发产品团队进入业务部门之后，不只是测试总监岗位的需求在变少，对于CTO的职位或者权力一样面临着减少，这种趋势在互联网时代尤为明显。

文章同步发布在我的个人博客:www.oktest.me上，同时收录全网海量测试相关文章，欢迎阅读。