«Терміново» і «на вчора» — це не пріоритет, а діагноз 🌚
#longread #обговорення

Знайома ситуація?

👀
Прилітає задача з позначкою «ТЕРМІНОВО!!!», а в коментарі: «треба було ще вчора».
Команда кидає все ➡️ перемикає контекст ➡️ сидить до ночі. І всі роблять вигляд, що це нормальний робочий процес.

Але давайте чесно:
❗ Задачі рідко стають терміновими самі собою.
Зазвичай «на вчора» означає, що хтось провтикав на ранніх етапах.

🔍 Як це зазвичай відбувається:
▫️ хтось не уточнив вимоги, коли був час
▫️ хтось тримав запит у пошті тиждень
▫️ хтось пообіцяв клієнту дедлайн, не спитавши тих, хто реально робитиме роботу
▫️ хтось сподівався, що «якось само розрулиться»
Не розрулилося.

😤 Найнеприємніше: ціну цього провтику платить не той, хто його допустив, а той, хто стоїть у кінці ланцюжка. Розробник, дизайнер, аналітик, підрядник. Ті, хто виправляє чужі помилки ціною свого часу, нервів і якості результату.

⚠️ Поспіх ніколи не буває безкоштовним.

✅ Що з цим робити?
▫️ Не шукати винних, а шукати точку збою.
Після кожної «пожежі» спитайте: на якому етапі ми могли дізнатися про цю задачу раніше? І що завадило?

▫️ Закладати час на уточнення, а не лише на виконання.
Половина «термінових» задач виникає через те, що на старті ніхто не поставив кілька незручних питань?

▫️ Не погоджуватися на дедлайни без участі виконавців.
Обіцянка, дана за когось іншого, — це не план, а лотерея.

▫️ Перестати романтизувати аврал.
Героїчно гасити пожежі — це не професіоналізм. Професіоналізм — це коли пожеж просто немає.

💡 Терміновість іноді справді буває виправданою.
Але якщо у команді «на вчора» — це щотижневий стан, то проблема не в швидкості виконавців. Проблема в тому, що відбувається задовго до того, як задача до них потрапляє.

А як у вас?
Скільки «термінових» задач на тиждень — і скільки з них справді не можна було передбачити?

👇