应用程序性能：操作产品的人的日常生活发生了什么变化

性能通常被视为一个事件：专门的冲刺、工作组、“让我们在本季度优化应用程序”。但任何操作数字产品的人都知道事实并非如此。绩效是例行公事，而不是项目。

她在周二早上出现，当时支持人员开始收到缓慢的投诉。它出现在周五晚上，当一个活动的流量翻倍并且应用程序开始阻塞时。它出现在匆忙做出的小决定中，将另一个网络调用添加到已加载的屏幕上。

本文讲述的是性能如何融入那些保持产品播出的人们的日常生活中。不是理论，而是操作。对于那些已经了解其重要性并想知道它在实际日常生活中如何体现的人来说。

性能是一个症状，而不是一个数字

在日常生活中，仪表板上的性能很少以干净的数字呈现。它作为一种症状出现。

用户没有开票说“列表渲染时间增加了200毫秒”。它说“应用程序崩溃了”，“它没有加载”，“我放弃了”。运营者有责任将这些模糊的抱怨转化为技术诊断。

这种翻译是一项被低估的技能。有关缓慢的投诉可能是服务器、用户网络、特定屏幕或旧设备的问题。懂得如何读表、定位原因，是绩效管理人员的日常工作。

成熟的团队不等待抱怨。它会在用户感觉到信号之前对其进行监控。但即使是最好的监控也首先要理解，在实践中，性能首先是一种人类体验，然后才是一种指标。

操作性能意味着持续观察产品，而不仅仅是在出现故障时观察。

这意味着定期遵循一些信号。主屏幕需要多长时间才能响应。发生了多少错误以及发生在何处。应用程序在受众的真实设备和区域上的行为方式，而不是在开发人员的理想机器上。

这种监控的价值不在于查看漂亮的数字。这是关于注意到趋势。一个速度很快并开始逐渐退化的屏幕讲述了一个故事，也许是数据库增长了，也许是一个新功能增加了重量。任何观察日常生活的人都会在危机发生前捕捉到这一点。

常见的错误是设置了没有人看的精心设计的面板。只有转化为行动，监控才值得。没有所有者和没有审查程序的指标只是装饰品。

表演操作在重复的情境中变得具体。

想象一下一个不断壮大的团队使用的内部管理应用程序。一开始，一切都在飞。随着客户群的增加，特定的屏幕（报告屏幕）开始需要时间。

没有人立刻注意到。这是渐进的。直到有一天，团队抱怨“报告不再打开”。这个问题已经持续了几个月。任何关注日常生活的人都会看到曲线上升并在崩溃之前采取行动。

想象一下运行促销活动的商务应用程序。营销团队在未通知技术团队的情况下发起了该活动。流量在几分钟内增加两倍。该应用程序的大小适合正常使用，但在最大的销售机会时开始出现故障。

日常教训：性能是区域之间沟通的工作，而不仅仅是工程。不说话的营销和技术将营销活动的成功变成了一次事件。

考虑一个向重要屏幕添加有用功能的团队。它在测试中完美运行。但在实际使用中，每次屏幕打开时，它都会进行一次开发中没有人注意到的额外搜索。

几周后，屏幕速度明显变慢。罪魁祸首是小决定的总和，每个决定本身都是无害的。这种侵蚀只有那些关注日常生活的人才能追踪到。

表现良好的团队会遵循一个简单的原则：将速度视为不可超出的预算。

这个想法是建立一个上限。主屏幕需要在一定时间后打开。该列表需要流畅地滚动。当更改有可能打破这个上限时，在到达用户之前会重新考虑。

这个习惯改变了文化。性能不再是可以稍后修复的东西，而是成为每次更改都必须尊重的标准。这就是扑灭火灾和预防火灾之间的区别。

在运营热潮中，人们很容易对任何投诉做出快速反应并立即进行优化。小心。

在没有衡量的情况下进行优化是一种浪费，在日常工作中，这种陷阱甚至更加危险，因为快速响应的压力迫使团队在了解什么之前就“做某事”。

日常纪律就是抵制这种冲动。行动前先诊断。在浪费精力之前先确认问题是否真实存在以及问题所在。一个在黑暗中做出反应的团队总是很忙碌，但解决的问题却很少。

本文的中心论点是：日常生活中的表演不是孤立专家的工作。这是运营该产品的整个团队的责任。

添加功能的开发人员、批准营销活动的经理、选择上传更多图像的设计人员，都会做出影响性能的决策。当理解了这一点后，绩效就成为文化，而不是外包任务。

快速产品并不是经过优化冲刺的产品。这使得整个团队习惯于每天在每一个小决定中考虑速度。

如果你的产品给人一种性能“来来去去”的感觉，而没有人真正理解其中的原因，那么也许缺少的是常规，而不是天赋。这里还有其他关于数字产品的运作和工程文化的文本讨论了这个主题。