Цю ситуацію неможливо закласти в план. Людина, на якій тримався напрямок, раптом зникає з процесу: лікарняний, мобілізація, вигоряння, заява про звільнення, переїзд. А проєкт, дедлайни й клієнт нікуди не зникають.
Ділимося підходом, яким користуємося самі. В його основі — фреймворки Андрія Чумаченка, які ми не раз перевіряли на практиці.
Перша реакція майже завжди однакова: «усе пропало, проєкт горить». Мозок добудовує найгірший сценарій і змушує пережити його як подію, що вже сталася. Андрій описує це як подвійну помилку: ми одночасно очікуємо найгіршого результату і переконуємо себе, що не впораємося з ним.
Тому перед тим, як щось робити, випишіть фактами:
Такий список зазвичай показує, що зупинилися дві-трі конкретні сфери, а решта проєкту працює у звичайному режимі. З цими напрямами й працюємо далі.
Заміну найчастіше шукають людині, хоча шукати варто заміну ролі.
Посада, роль і повноваження — три різні речі. Посада — як називається професія. Роль — що вона насправді робила і за що відповідала. Повноваження — що мала право вирішувати без погодження. Коли ці три речі не збігаються, компанія втрачає гроші й час навіть у спокійні періоди, а в кризу це стає помітно одразу.
Тому складіть не один список, а три:
Третій список зазвичай найдовший і найменш очевидний. Від того, наскільки швидко вдасться його відновити, залежить, триватиме криза тиждень чи квартал.
Далі — фреймворк RASCI, але переписаний під нову реальність, а не той, що лежить у вас із початку проєкту.
Responsible — виконує задачу.
Accountable — приймає роботу й відповідає за результат.
Supportive — допомагає.
Consulted — консультує.
Informed — має бути в курсі.
На кожну задачу — рівно один R і один A. Порожні клітинки в матриці — це нормально, заповнювати кожну не треба. А коли за один результат відповідають двоє, задача з високою ймовірністю залишиться незакритою: кожен розраховує на іншого.
Той, хто підхоплює чужу задачу, не має контексту. У нього є тільки формулювання, і якщо воно допускає кілька трактувань, людина обере простіше.
Тут допомагає Definition of Done. Саму задачу формулюйте одним реченням із трьох частин: хто робить, що на виході, до коли. Обмеження й посилання винесіть в опис. А наприкінці додайте короткий DoD: що має бути зроблено, щоб вважати задачу закритою.
Формулювання на кшталт «підхопити звітність по клієнту» кожен зрозуміє по-своєму.
Робоча версія звучить приблизно так: «аналітик до четверга віддає звіт за форматом з минулого місяця, з коментарями по кожному каналу і висновком на одну сторінку».
Якщо задача не вміщується в одне речення, там склеєно кілька задач. Розберіть їх, і в кожної зʼявиться свій DoD. На це піде година-дві, зате ви не витратите тижні на переробку.
Найпоширеніший сценарій кризи: керівник забирає задачі того, хто вибув. Мотивація зрозуміла, адже так швидше й надійніше. Наслідок теж зрозумілий: керівник стає вузьким місцем, і кожна затримка в його календарі перетворюється на затримку всього проєкту.
Андрій називає це «гарячою картоплею» — грою, в яку з менеджером намагається зіграти кожен.
❌ — Я спробував, вийшло погано, не знаю, що робити далі. — Дякую, далі я сам.
✅ — Що саме вийшло погано? Чому тобі самому не подобається? — Окей, подивись, як це зроблено в трьох останніх проєктах, випиши відмінності й переробʼ за ними.
Завдання менеджера тут — показати шлях, яким людина розбереться сама і наступного разу зробить уже без нього. У кризу це ще й спосіб не обмежити проєкт на одній людині.
Делегувати заважає довіра: віддати чужу задачу складно, а свою — ще складніше.
Тому робоча схема виглядає так: розбийте задачу на блоки, роздайте їх команді, а фінальне складання в готовий результат залиште собі.
Окремо про новачків у задачі. Якщо людина ніколи раніше цього не робила, пишіть чекліст, тобто нумерований список кроків до результату. Без нього є два типові фінали: формально закрита задача без суті або два тижні роботи там, де вистачило б трьох днів.
У кризу кількість питань до керівника зростає, а часу на них стає менше. Тут допомагає формула 1-3-1: одна проблема, три варіанти рішення й одна особиста рекомендація.
Питання «у нас проблема з клієнтським звітом, подивишся?» перекладає всю роботу на керівника.
У форматі 1-3-1 те саме звучить так: «звіт не встигаємо до пʼятниці, бо немає доступів. Бачу три варіанти: попросити доступи у клієнта, зібрати з того, що є, або перенести на понеділок. Рекомендую перший, лист уже написав».
Так людина приносить сформульовану проблему з готовими варіантами, а керівник витрачає час лише на рішення.
Якщо ви бачите, що термін зміститься, скажіть про це одразу, а не за день до дедлайну.
Формат той самий: що сталося, які є варіанти, що рекомендуєте.
Клієнти зазвичай нормально сприймають людський фактор.
Окремий випадок: ключовий спеціаліст не вибув тимчасово, а написав заяву. Спокуса утримати його грошима чи новими умовами велика.
За досвідом Андрія, це не працює. Якщо людина вже прийняла рішення піти з поточної посади, з поточними обовʼязками й у поточній компанії, вона піде. Підвищена ставка лише відкладе це на кілька місяців і ускладнить стосунки всередині команди.
Ресурс краще вкласти в тих, хто хоче лишитися й рости.
Будь-яка проблема має закінчуватися двома кроками: виправленням і аналізом причини. Без другого кроку ситуація повториться в наступному кварталі.
Найпростіший спосіб перевірити стійкість — відправити ключового спеціаліста у відпустку на два тижні й подивитися, що станеться. Якщо проєкт хитається, у вас є час підготуватися до наступної кризи заздалегідь.
Тимчасова криза здебільшого не ламає проєкт сама по собі. Вона показує ті процеси, які ніде не були описані й трималися на памʼяті конкретної людини.
Тому: спочатку зафіксуйте факти, опишіть роль, а не людину, перескладіть матрицю відповідальності та переформулюйте задачі під DoD. Не закривайте задачі собою. А коли все стабілізується — перевірте, які напрями знову тримаються на одній людині.
.svg)
