Ти рухаєшся швидко. Задачі злітають з дошки. Slack-повідомлення отримують миттєві відповіді. Деплої летять щойно код скомпілювався. Це відчувається як швидкість. Це виглядає як прогрес.

Більшість цього — ілюзія.

Є вислів із військових операцій: 'Slow is smooth, smooth is fast' — повільно значить плавно, плавно значить швидко. Ідея: поспіх породжує помилки, помилки породжують переробку, а переробка займає більше часу, ніж зробити правильно з першого разу. Рухатися обдумано — не повільно, саме обдумано — дає швидший результат, ніж рухатися хаотично.

Раніше я з цим не погоджувався. Потім почав рахувати цифри. 🧘

Податок на поспіх

У жовтні 2025 я логував кожну задачу протягом місяця. Кожна отримувала два таймстемпи: коли я її 'закінчив' і коли вона була реально завершена — без доробок, без багфіксів, без 'ой, я забув про цей edge case'.

Розрив між 'закінчив' і 'реально завершив' — це те, що я називаю податком на поспіх.

Тип задачі Час до 'готово' Податок на поспіх (переробка) Загальний час Якщо робити обдумано
Розробка фічі 4 години 2,5 години (баги) 6,5 годин 5,5 годин
Зміни конфігу 15 хв 45 хв (не те середовище) 60 хв 25 хв
Відповіді на листи 2 хв 15 хв (уточнення) 17 хв 8 хв
Деплой 10 хв 90 хв (відкат + фікс) 100 хв 20 хв
Документація 30 хв 3 години (виправлення) 3,5 години 1,5 години

Патерн: поспіх економив 20–40% на першому проході і коштував 50–200% на переробці.

Подивися на рядок з деплоєм. Деплой — це коли ти пушиш код на живий сервер, щоб користувачі побачили зміни — займає 10 хвилин на швидку руку, щось ламає, і загалом обходиться в 100 хвилин з відкатом. Обдуманий 20-хвилинний деплой з перевірками коштує 20 хвилин. Поспішна версія в 5 разів повільніша.

За весь місяць податок на поспіх склав приблизно 12 годин на тиждень. Це 30% продуктивного часу, витрачені на виправлення самозавданих збитків. DORA State of DevOps report підтверджує цей патерн у масштабі: команди з вищою частотою деплоїв, але з належними запобіжниками, стабільно випереджають команди, які просто пушать швидко і моляться. ⚙️

Правило трьох вдихів

Побачивши жовтневі цифри, я почав робити дещо просте: перед будь-якою дією, що торкається продакшену — живої системи, від якої залежать реальні користувачі — або надсилає повідомлення більш ніж 5 людям, або комітить код, я роблю три вдихи. Десять секунд. Не медитація. Просто пауза.

За ці десять секунд одне питання: 'Що я зараз збираюся зробити, і що може піти не так?'

Між жовтнем 2025 і березнем 2026 це правило запобігло чотирьом інцидентам:

  • Листопад 2025, перед деплоєм: 'Стоп — я ж не прогнав міграції локально.' Міграція — скрипт, що змінює структуру бази даних — мала баг, який би незворотно видалив колонку з даними на живій системі.
  • Грудень 2025, перед листом клієнту: 'Це звучить агресивно. Треба пом'якшити другий абзац.' Ця пауза врятувала відносини з клієнтом.
  • Січень 2026, перед зміною конфігу: 'Це продакшен-конфіг, не staging.' Staging — це тестова копія твоєї системи. Я збирався запушити тестові налаштування на бойовий сервер. Сервіс би ліг.
  • Березень 2026, перед мерджем PR: PR (pull request) — це зміна коду, що чекає на схвалення команди. Чотирнадцять файлів змінено, я переглянув вісім. Я дорев'ювив решту — і знайшов SQL-ін'єкцію у файлі 11. Це вразливість, через яку зловмисник може маніпулювати базою даних через поля вводу.

Сорок секунд пауз. Це запобігло двадцяти з гаком годинам переробки. Ось вона, математика.

Чому швидкість відчувається продуктивною

Швидкість генерує видиму активність. Задачі відмічаються. Повідомлення летять. Код потрапляє в репозиторій. Дашборд виконаних задач росте. Це відчувається як перемога.

Але задача, яку зробили і потім переробили — через баг, непорозуміння, пропущену вимогу — мала нульовий результат. Вона з'їла час двічі, а принесла цінності нуль разів.

Можна працювати 60 годин і відвантажити менше реальної цінності, ніж за 35-годинний тиждень, проведений обдумано. Я жив в обох режимах. У 35-годинний тиждень я завершував кожну задачу один раз, правильно. У 60-годинний тиждень я робив половину задач двічі — спочатку швидко, потім правильно.

Найефективніші оператори, яких я знаю, виглядають повільними. Вони читають весь спек перед тим, як писати код. Задають уточнювальні питання перед стартом. Деплоять у понеділок вранці, а не в п'ятницю ввечері. Вони закривають менше задач за день і майже нічого не переробляють. За місяць вони відвантажують більше. За рік — різниця колосальна. 📋

Повільність як система

'Будь уважнішим' не працює. Наступна криза знову штовхне тебе до поспіху. Принцип має жити в інструментах, а не в намірах.

Хірург Атул Ґаванде обґрунтував це для медицини та авіації у книзі The Checklist Manifesto. Та ж логіка працює для ops.

Чеклісти деплою. Скрипт — не твоя пам'ять — перевіряє: тести пройшли, міграції протестовані локально, health check оновлений, відкат готовий. П'ять хвилин. Запобігає більшій кількості інцидентів, ніж будь-яка кількість поспіху зможе компенсувати.

Затримка повідомлень. Пиши листи та Slack-повідомлення одразу, але плануй їх відправку через 30 хвилин. За цей час ти зловиш проблеми з тоном, відсутні вкладення та неправильні цифри, які інакше обернулися б незручними follow-up'ами.

Період охолодження PR. Жоден pull request не мерджиться протягом 2 годин після відкриття. Навіть якщо рев'ю займає 10 хвилин, він чекає. Свіжий погляд — навіть твій власний — працює краще з дистанцією.

Затримка реагування на інциденти. Коли спрацьовує алерт, зачекай 2 хвилини перед дією (якщо це не повний аутедж). Google's SRE handbook документує ту ж інтуїцію: близько 30% алертів автоматично вирішуються протягом хвилин. Реагування на алерт, що сам зникне, витрачає час і ризикує погіршити ситуацію. Дві хвилини терпіння усувають 30% хибних спрацьовувань.

Принцип капібари

Капібари не поспішають. Вони не панікують. Вони сидять у гарячих джерелах, поки світ навколо гуде. І якимось чином вони — один з найуспішніших видів у Південній Америці, процвітаючи там, де більш агресивні тварини не витримують.

Капібара виживає не завдяки швидкості. Вона виживає завдяки послідовності, спокою та обдуманості. Вона не витрачає енергію на штучну терміновість. Вона зберігає ресурс для моментів, які справді потребують дії.

Майже ніщо не є таким терміновим, як здається. Slack-повідомлення, що 'потребує відповіді зараз', може зачекати годину. 'Критичний' баг зазвичай важливий, але не часо-чутливий. Деплой, який 'має вийти сьогодні', зазвичай просто має вийти цього тижня. Справжня терміновість — сервіс лежить, витік даних, активний інцидент безпеки — трапляється може раз на місяць. Все інше — це результат поганого планування, нечітких пріоритетів або культурного припущення, що швидше завжди означає краще.

Коли перестаєш ставитися до всього як до термінового, відбуваються дві речі. Якість роботи зростає. І коли щось справді термінове, у тебе є ресурс впоратися — бо ти не спалив резерви, ставлячись до рутинних задач як до надзвичайних ситуацій. 🍵

Рухайся обдумано. Будуй речі, які не ламаються. Команда, що спокійно деплоїть у понеділок, завжди буде випереджати команду, що панічно деплоїть у п'ятницю — не тому, що вони талановитіші, а тому, що вони не витрачають половину тижня на розгрібання самозавданих збитків.

Повільно — це плавно. Плавно — це швидко. А швидко, як не парадоксально, — це повільно. 🫶