这是最后一个灵魂拷问，但是这个问题回答起来简单，“不一定”，软件研发效能提升，技术驱动是次要的，更多时候是业务驱动。
我们不否认在软件研发中工程师文化盛行，工程师喜欢新技术，喜欢在工作中引入新的技术和新的工具、构建新的平台，以提高研发效能。但是，在实际工作中，这往往只是一种愿望或一厢情愿，因为工程师们首先要完成手头上当前的任务，更何况任务总是难以按计划完成的，加班是常事，996是习惯，所以多数情况下，团队没有时间去研究新的技术，没有时间去尝试新的技术，而且采用新的技术风险也很大，万一尝试失败了，如何交代？
但是，如果业务上有需求，公司就会安排相关资源去进行技术攻关，给团队时间来研究新的技术、学习和试用新的工具。如果业务上需要快速交付、持续交付，公司就愿意让团队引入Jenkins 2.0、Docker、K8s等新的工具，去构建支持持续交付的平台、构建DevOps工具链等。所以在大多数情况下，技术是被动的，是被业务驱动的。从表面看，持续集成平台或DevOps工具链构建起来之后，研发效能的确提升了，感觉是技术驱动的研发效能提升，其实背后是业务驱动的。
当然，我们也不完全否定技术驱动效能提升。软件技术发展的同时，软件研发的技术往往也同步得到发展；当产品技术升级时，软件研发的技术也会跟着升级，从而驱动研发效能的提升。虚拟机技术、容器技术、云平台、微服务、服务化、人工智能（AI）等在产品线上得到应用之后，这些技术也会应用到研发环境中，例如，在测试环境会全面使用虚拟机技术、容器技术、云服务，我们也会将AI技术嵌入到IDE中推荐代码、对代码进行深度分析、让自动化测试更智能等。
技术的解决方案有它的长处，有时能一劳永逸地解决问题，例如代码的静态分析工具，能自动检测出安全漏洞、违反代码规范的问题等，不需要人工检查或大大降低人工代码评审的时间。接口测试工具、性能测试工具、渗透测试工具甚至开发人员使用的IDE等都显示了技术的力量，在不断提升研发效能。
但技术也有其应用场景，如果采用了不合适的先进技术，不仅不能提升效能，而且可能会降低研发效能。例如，像腾讯这样的大公司会构建测试中台或测试服务平台，提升了整个研发团队的测试效率和交付速度，但一般中小型软件企业，如果去构建测试中台，不仅劳民伤财，而且让简单问题复杂化，也无法提高测试效率。又比如，微服务架构在Amazon上推动很好，包括整个研发也都在云上，但不一定适合你的公司。
许多时候，效能不能提升并不是技术问题，而是人的问题，例如这篇文章 “实现自动化测试，首先不是一个技术问题” 所谈到的。这就是我们经常说的 “人是决定的因素”，这里也不仅仅是人的技能所带来的（正面或负面的）影响，而且也包括组织结构和组织文化，如质量文化、协作精神等。良好的质量文化、齐心协力的团队往往更能驱动效能的提升。
之前在讲课时，常提到从三个方面去找问题、解决问题、持续改进，这三个方面概括为PPT，容易记，那就是People、Process、Technology，所以技术只是其中一个方面。前面我们谈到了人，那还有流程的改进，也能驱动效能的改进。如果正确实施敏捷或精益开发模式，的确能提升效能，这其中也包括流程的提升。例如，精益思想就是在流程上强调 “最小积压”，理想状态下是做到零库存，即没有需求积压。如果业务持续不断地接收到产出物，同时看到新需求不断进入处理过程，整个研发过程从接受需求到软件交付出去的整个过程没有积压、流程、持续地进行，效能是很高的。
但是，新流程的引入一定不能给团队增加新的束缚，而是最大程度地释放开发者的创造性和积极性，加速价值流的移动，消除一切阻碍研发的障碍，减少各种浪费，特别是消除等待、抛弃一切不产生价值的活动，让研发的各个环节交接顺利，整个研发流程顺畅，那么研发效能就一定能提升。
最后一个问题，就简要谈到这里，还有更重要的文章要写，如《软件质量报道》公众号2020年回顾与2021年展望、2020年国内软件质量调查报告等，敬请关注。另外，《持续测试白皮书》基本完成，我们要搞一个正式的发布仪式，所以元旦前大家看不到了，初步定在元月23日，也敬请关注。
推荐阅读