传统企业，如何构建性能测试技术体系

之前有朋友介绍，帮一家知名的美妆零售企业，做过一次技术咨询，给我的个人感触还是比较大的。

可能是我在互联网企业工作的比较久，已经习惯了尝试新鲜技术和方法，通过快速的工程实践去落地解决问题。而这家零售企业的业务现状和系统架构，却给我上了一课。

这篇文章，聊聊传统企业在数字化转型过程中，如何构建性能测试技术体系。

传统企业和互联网的区别

互联网企业的特点，如果用一个词来形容，就是小平快新。怎么理解呢？

• 小：做一个不太复杂的项目，一般拉几个关键角色组一个小团队就能快速展开工作。

• 平：扁平化管理，汇报和决策路径比较短，不需要太久的审批等待和复杂的前期调研。

• 快：追求效率，无论是 mvp 方案快速迭代验证，还是开会沟通某些事项，很少开大会长会。

• 新：愿意尝试新的技术手段、工具和方法，对新的东西保持好奇心，有尝试的想法和行动。

当然，这几个特点是相比于我所熟知的传统企业。我曾在 2 家不同类型的零售企业工作过几年，无论是做项目的团队规模还是汇报决策效率，甚至对新技术的认知和接受程度，都远远比不上互联网企业。

以我接触到的传统零售业为例，它们具备如下几个特点：

• 团队构成复杂：有些传统企业还是采用的自己人做管理，系统外包采购的方式。做一个项目有时候是好几个供应商的人在协作，团队规模大，沟通成本高，各自还有各自的利益诉求。

• 汇报决策效率低：一个想法或者方案，从提出到调研到评审到审批通过，经常一周过去了。甚至中间还要开好几次调研评审会，当然这样做会更严谨细致，但某个角度来说对新需求的交付或者新想法的尝试无疑中泼了一盆冷水。

• 技术架构和组织方式保守：一方面是老系统比较多，系统架构甚至还是单体服务类型的，迭代频次很少有低于半个月的；另一方面组织架构和管理层级多，对会议和邮件的重视程度高于面对面沟通。

传统企业落地技术体系的挑战

以我做咨询的这家企业为例，介绍下整个案例背景：

1. 有个重大的系统重构和服务上线，时间比较紧，不足一个月；

2. 从咨询的需求传递给我，到我出方案和供应商第一次面谈，一周内就通过了；

3. 约甲方 CTO 沟通汇报，约了半个月时间不止，中间还伴随着各种临时需求和拉扯；

4. 最后才知道，甲方这边只负责管理人员，正常的工作开展还是供应商的人员为主；

5. 方案是否执行需要甲方评审通过，但技术实践是需要时间落地和验证的，风险在不断后延；

当然，这个案例不能代表所有的传统企业，我也知道部分数字化转型做得好的企业内部的技术实践方案和效率做的不错。让我诧异的是，我所服务的这家企业很知名，他们也认识到以前的技术架构太落后，重构后要承接大量的流量。找我做咨询的目的也是希望我帮他们搭建完整的性能测试和容量保障技术体系。

但在实际的项目落地过程中，繁琐亢长的决策流程，复杂的团队构成和低效的管理方式，让我认识到一点：传统企业要很好的落地技术体系，解决系统老旧和业务发展问题，最大的挑战其实不是技术问题，而是组织管理方式和决策效率。

工程实践推动技术体系落地的想法

其实无论是传统企业，还是互联网企业，从零开始搭建性能测试和容量保障技术体系，其实没太多区别。

很多时候技术工程实践无法落地解决问题，主要原因如下图：

而且性能测试体系本身都是很成熟的方案，从需求到线上交付，主要就是如下几点：

用成熟的技术方案，解决业务问题，其实本质上需要组织和管理决策进行调整。否则再好的技术也无法解决技术以外的影响因素。

技术最终要解决的是效率和收益问题

很多新技术的出现，是因为以往的技术无法更好的解决问题，才倒逼技术进行了迭代演进。

当然成熟的技术落地，在企业中要解决的其实是效率和收益问题。做技术改造能否为业务带来更好的收益，能否提高业务的迭代效率，是很多人首先考虑到的。

但业务的发展并不仅仅只靠技术就能解决，更需要的，还是组织管理方式的优化以及理念的认可。否则只会成为拿着锤子眼里都是钉子的人，困守一隅。