Клієнт каже: «зробіть швидше». Розробники кивають, беруться до роботи — і за два тижні здають щось, що технічно «стало швидше», але не те, що бізнес мав на увазі. Ніхто не збрехав. Просто «швидше» — не завдання, а відчуття, і кожен, хто отримує таке відчуття без конкретики, добудовує його по-своєму.
«Швидше» означає щонайменше чотири різні речі
Коли бізнес каже «швидше», команда розробки чує один із щонайменше чотирьох різних запитів, і кожен веде до зовсім іншої роботи:Швидше відкривається сторінка для користувача (frontend performance, time to interactive).Швидше обробляється запит на бекенді (query optimization, кешування, індекси).Швидше виходять нові фічі (deployment frequency, CI/CD).Швидше команда реагує на баги й запити (процес, а не код).Розробник, який отримав абстрактне «швидше», обирає один із цих напрямків навмання — часто той, який найлегше показати як «зроблено», а не той, що болить бізнесу найбільше.
Без цифри «швидше» неможливо ні виконати, ні перевірити
«Зробіть швидше» не має критерію завершення. Скільки — достатньо? На 10%? У два рази? Без порогу команда не знає, коли зупинитись, і клієнт не знає, чи отримав те, за що заплатив. Обидві сторони покладаються на суб'єктивне відчуття — а відчуття після оптимізації завжди краще, ніж до, незалежно від того, наскільки реально змінились цифри.Порівняйте: «Сторінка кошика має завантажуватись за 2 секунди на p95 для 95% користувачів на 4G» — це вимога, яку можна виконати, виміряти і закрити.
Оптимізація без мети найчастіше б'є не туди
Класичний сценарій: команда отримує «зробіть швидше», дивиться на систему і бачить кілька очевидних точок для покращення — важкий SQL-запит, неоптимізований бандл, повільний сторонній API. Вони оптимізують те, що технічно найпростіше виправити, а не те, що користувач фізично відчуває. Продукт стає швидшим у профайлері й лишається таким самим повільним для клієнта, бо вузьке місце було зовсім не там.
Що запитати замість «зробіть швидше»
Три питання переводять абстрактний запит у виконуваний:Який саме сценарій користувача повільний — а не система загалом?Наскільки повільно зараз, і яке число вважати «достатньо швидко»?Що важливіше — швидкість відповіді зараз чи стабільність під навантаженням пізніше?Відповіді на ці три питання і є технічним завданням. Усе, що команда отримує без них, — це здогадка, яку доведеться переробляти, коли з'ясується, що «швидше» означало щось інше.
Швидкість — це завжди компроміс, а не подарунок
Останній момент, який часто губиться: пришвидшення рідко буває безкоштовним. Кеш додає складність інвалідації. Попередній розрахунок з'їдає пам'ять. Паралелізація ускладнює дебаг. Хороша команда розробки не просто виконує «зробіть швидше» — вона показує, чим саме доведеться заплатити за конкретний виграш у швидкості, і дає бізнесу вирішити, чи цей компроміс виправданий.«Зробіть швидше» звучить як завдання, але насправді це відчуття, яке команда мусить розшифрувати замість вас. Найкращі результати отримують ті, хто замінює прикметник на конкретний сценарій, поріг і критерій готовності — до того, як хтось почав писати код.