性能测试和工程通常被认为是纯粹的技术问题。然而，根据我们在许多不同行业和组织中的经验，关键非技术角色的人员可以对最终产品的性能和交付团队的理智产生最大的影响。

转移性能（进一步）

许多系统质量问题（包括性能）可以追溯到交付项目生命周期早期的重大决策。这种理解正在推动整个行业的左转趋势 - 在生命周期的早期推动质量活动。

不幸的是，Performance Engineering中的左移通常会停止在开发人员身上。开发团队与测试人员和运营团队密切合作，尽早调整和缓解性能问题。但我们需要更进一步 - 回到产品负责人认为“哎呀，我敢打赌我们的客户会喜欢功能X，让我们为此做一个商业案例”。从那时起，每个人都应该在计划和做出决策时开始考虑性能。

很多时候，从构思到开发（有时甚至是过去），功能性都是很酷的孩子。每个人都很容易对花哨的新功能X及其可以做的很酷的事情感到兴奋，并且简单地假设类似Google的速度和规模将免费提供。功能X获得批准，通过通常的分析和设计过程，开始开发。这通常留给那些必须成为坏消息的承担者的测试人员和开发人员，他们说，'嘿功能X非常棒，但如果超过5个人尝试同时使用它，则响应时间超过2分钟'。

在经历了所有的努力和兴奋之后，可怜的旧功能X已经从今年的英雄功能版本发布到了将项目烧毁到地面的性能垃圾火灾。最重要的是，现在你有：

愤怒的产品负责人甚至不知道这可能是一个问题

一个吓坏了的PM，他没有分配足够的时间或预算来调整性能问题

一个迷茫的BA在非功能性需求上做一个速成课程

一个沮丧的用户体验设计师认为这与他们无关

性能思维

通常关于这一点，我们的测试和优化专家会被召唤来帮助灭火。大多数时候，我们可以弄清楚如何使它全部工作和嗡嗡声，并实现产品负责人首先设想的功能X的潜力。但是，当每个人都有一个表现思维时，对于每个人来说，在考虑性能时，它会更加轻松（通常也会更便宜）。

拥有“表现心态”究竟意味着什么？它不是要成为性能调优专家。这意味着在接近您的日常任务时考虑性能和功能。

具体而言，产品负责人，PM，BA和UX设计师可以做些什么来帮助避免上述情况？以下是将伟大与单纯善良分开的一些关键行为。

产品所有者：

请记住，用户要求的性能与酷炫的新功能一样多，甚至更多。如果功能不执行，用户将讨厌功能X.

请注意，某些功能会导致性能折衷。尽早向您的工程师提供X特征X，以确定是否需要进行成本/收益分析。

考虑功能X将如何影响用户数量和行为。您期望有多少新用户？您是定位移动用户吗？他们会生活在农村地区，网络连接不稳定吗？

功能X将如何推出？随着大张旗鼓和公布的开始日期/时间？ （认为​​人口普查）。或者在无数天/小时或用户群中交错？

项目经理：

预算时间在开发冲刺/阶段内预先进行性能优化，而不仅仅是“必要时临时”。

在进入下一个sprint /阶段之前，确保性能标准是“完成定义”的必要部分。

通过采购和推动及时提供，确保您的团队装备精良，提前计划并节省浪费的时间

适合用途的性能测试环境。

充分的应用和基础设施性能监控。

数据依赖性和要求。

适当的凭据，许可证和访问权限。

业务分析师：

专注于实时和理解非功能性需求。了解它们是什么以及它们为何重要。在设计和开发之前准备好这些，以便工程师可以准确地估计广告，围绕他们的系统架构做出最佳选择。

研究详细的指标以告知详细要求。模糊的非功能性要求是非常无用的，例如“功能x应在3秒内响应”。目标是“功能x应在3秒内响应，同时在50,000个用户会话的持续负载下，每秒520个请求”。

熟悉与性能相关的多种信息来源。即使您无法自己捕获信息（例如原始日志数据），也要了解要查找的内容，并让其他人捕获它。

历史用法例如营销分析，应用程序性能监控，操作日志分析。

预测用量，例如产品所有者，业务案例，使用报告，财务预测。

UX设计师：

研究并了解前端性能的原理。

探索设计师通过巧妙地使用（或避免）诸如旋转器，启动页面，骨架图像/图标等内容来使应用程序“感觉”高效的方式。

考虑屏幕上元素数量对性能的影响。

尽可能减少图像文件的大小

使用巧妙的设计吸引注意页面/功能的关键部分，而背景或屏幕外元素可以继续加载而不被注意。

使命

我们作为测试和优化顾问的使命不仅仅是'测试x'或'让你快速'。这是为了使我们的专业知识尽可能有价值，这意味着帮助您首先避免这些性能火灾。有点像那部精彩的电影'Inception' - 如果你能早点进入并在所有利益相关者中灌输'表现心态'，那么每个人都会获胜。