Дедлайн — запозичене слово з американського словника. Раніше так називали межі перебування злочинців. Якщо переступити через лінію — вважай, що провалив правило і втік.
Нині про дедлайни говорять у двох значеннях. Перше і синонім дедлайну — конкретний термін здачі проекту, домашнього завдання. Друге — щось страшне, після чого фахівець підвів клієнта, керівника і колег.
Як справлятися з дедлайнами і що це означає для фахівця: потрібно гасити пожежу чи час для здачі роботи? Ділимося порадами у статті.
Важливо пам'ятати, що проєкт завжди йде не за планом
Уявімо ситуацію: проджект-менеджер компанії погоджує з клієнтом розробку мобільного застосунку.
Перед зустріччю менеджер пише план: потрібно зробити все максимально добре — розробники зможуть продумати кілька оновлень наперед, встановити останню версію антивірусного софту.
Задоволений менеджер представляє пропозицію перед клієнтом. Тому все подобається.
🔥 Коли справа доходить до виконання роботи, все йде не за планом:
-
Голова відділу кібербезпеки пішов у відпустку. Тільки він розумівся на проектуванні системи безпеки для мобільних додатків.
-
Зробити кілька оновлень наперед — невдала затія. Ще не було тестування продукту, а вже збираємося оновлювати. А час — гроші.
-
Деякі розробники сидять без діла, бо не отримали завдань.
Залишається кілька місяців до здачі, а проект не готовий. Терміни та ціну узгодили, і підводити клієнта дуже не хочеться: можна втратити заможного клієнта, репутацію. Але що можна зробити?
👉 Метафора з розробкою мобільного застосунку умовна. Але відображає реальні приклади дедлайнів у діджиталі: керівник взяв проект і не розрахував строки, хочеться зробити всього побільше або один зі співробітників відтягує здачу етапу проєкту до останнього дня. У результаті терміни затягуються, компанія не встигає, а клієнт обурюється.
Жити складніше, ніж усе розписати на папері. Планування в голові і на папері завжди ідеальне. Але можна неправильно розрахувати вартість, можливі терміни, неправильно розставити пріоритети.
IT працює не стільки з кодом, скільки з людьми. У них теж свої потреби, тяга до прокрастинації та причини перенести дедлайн.
Дедлайн потрібно прийняти й обговорити
Повернемося до прикладу з менеджером. Планування провалилося і потрібно рятувати проект. Клієнт чекає на результат і підтвердження, що гроші не витратили даремно. Одне з можливих рішень — показати клієнту проблему.
Якщо зараз виправити нічого не вийде — краще розповісти клієнту про ситуацію:
Миколо Семеновичу, вибачте що турбуємо. У відділі розробки сталася НП: частина програмістів захворіла, тому не встигаємо вчасно здати проєкт. Чи можемо ми зустрітись та обговорити перенесення термінів, якщо це можливо?
Чи обуриться Микола Семенович? — звісно. Людина витратила гроші і час на співпрацю. Але також для нього важливо отримати проект. Він піде на зустріч і продовжить терміни. Мобільний застосунок буде, що вже добре. Нехай пізніше, з правками за кошторисом.
Можливо, що Микола Семенович вважатиме менеджера безвідповідальним і ніколи не звернеться до його будівельної компанії.
Ось що в інтерв'ю редакції порадив засновник Ed-Tech-компанії Visotsky Inc Олександр Висоцький:
Цього року команда випустила IT-платформу з автоматизації інструментів управління. Ми давно мріяли про такий продукт.
Щоб клієнти могли користуватися платформою поза офісом, вирішили зробити мобільний застосунок. Тут з'явилися проблеми: тести показали багато багів. Додаток допрацьовується, тим самим зриваємо терміни презентації.
Головне для нас — відкрита комунікація з клієнтами. Ми відкрито зізналися, що зрив дедлайнів — наша проблема. Клієнти поставилися до затримки з розумінням. А ми продовжуємо роботу.
👉 Важливо те, сторони прояснили ситуацію: проблема є і її готові виправляти. Якщо цього не зробити — результат непередбачуваний. Можуть і в суд подати за зрив умов договору.
Можна презентувати функціональну частину проекту
У діджиталі купа стадій: від планування до продакшена. Деякі етапи можуть відтягувати презентацію: потрібно зробити косметичні коригування продукту, подумати над оновленнями, спростити код тощо.
Якщо за дедлайном неможливо зробити все, а результат потрібен зараз — здайте функціональну частину. На прикладі з мобільним застосунком: можна відмовитися від остаточного дизайну, продуманого до дрібниць UX-дизайну. Показати тільки функціональну частину, щоб клієнт міг поклікати на кнопки і відчути — застосунок працює.
Важливе правило дедлайнів:
🔥 Між «здати ідеально» і «здати вчасно» завжди схилятись до «вчасно».
Розробники, як і будівельники: після випуску продукту вносять правки і переробляють. Нормально перенести косметичну роботу, але показати працюючий продукт зараз.
Щоб бути в очах клієнта більш відповідальним, можна розповісти про причини перенесення плану.
Миколо Семеновичу, на нараді помітили, що розробка застосунку неможлива за минулими термінами. Ми перенесли етап повторного тестування, щоб зараз показати вам робочу архітектуру. Решту встановимо, поки об'єкт тестуватимуть.
Клієнт задоволений, що є результати. А менеджер зберіг репутацію і клієнта, позбавив колег стресу від дедлайну. Навіть якщо компанія винна, і 6-місячну роботу можна було зробити за 6 тижнів.
Допоможіть, якщо людина в команді не може впоратись із дедлайнами
На одному з етапів менеджер бачить: співробітник відділу зашивається. Двоє колег пішли у відпустку, а начальник відділу захворів. Він не встигає закінчити код, бо йому вчасно не передали макети. Можливо, тому стажери-розробники сидять без завдань.
❌ Можна пройти повз. Це справа конкретного відділу. Якось встигнуть, а якщо ні — штрафуємо.
✅ Або запропонувати якусь допомогу. Не робити роботу за співробітника, а дати пораду або показати інструмент автоматизації. Можна попросити директора перевести частину співробітників, тому що ті сидять без діла і п'ють каву по три години.
Василю, давай я допоможу. Можемо підключити наших стажерів. Давай їм стандартні завдання, а сам берися за складнішу роботу.
Головне — не залишатися осторонь. Завдання написати код — Василя. Але здати мобільний застосунок потрібно вчасно і це спільна справа.
👉 Може здатися, що порада зі світу фантазії. Часто співробітники або проджект-менеджери передають завдання і чекають на результат. «Мої співробітники — дорослі люди зі своїми обов'язками. Якщо в них щось не виходить, то прийдуть і попросять допомоги». Але так ніколи не буде: страшно, соромно і всі на словах самостійні.
Ось що радить засновник Ed-Tech-компанії Visotsky Inc Олександр Висоцький:
Щоб тримати колег «на гачку», у хорошого керівника є інструменти: наприклад — щоденні зідзвони з командою. На зідзвонах важливо не тільки запитати про стан завдань, а й поцікавитись внутрішнім станом співробітника.
Іноді варто зняти з колеги рутинні завдання, а залишити роботу над проектами. Важливо підтримувати і мотивувати, щоб співробітник відчував важливість своєї роботи: це не тільки гроші, а й взаємини.
Бігти і рятувати не потрібно. Досить запитати: на якому етапі перебуває проєкт співробітника, що можна презентувати і з якими проблемами зіткнулися. Ще краще - підказати, як вирішити негаразди.
Дедлайн — це нормальна практика. Його потрібно не боятися, а продумувати заздалегідь
Перенесемося на зустріч менеджера і замовника.
❌ Менеджер розуміє, що компанія може здати проект за 3 місяці. Так і передасть клієнту: без урахування можливих проблем, НП і того, що застосунок будують новою мовою програмування, а розробники не встигли її досконально вивчити.
✅ В іншій реальності менеджер пам'ятає про 3 місяці. Але розуміє, що часто все йде не за планом. Клієнта засмучувати не можна: це велика відповідальність і гроші. Замість 3 місяців менеджер пропонує проект за 5 місяців. Клієнт погоджується.
Людина в другому прикладі підготувала майданчик для вирішення проблем. А якщо час залишиться, можна зробити косметичні правки. Або презентувати проект раніше, від чого клієнт буде в захваті. Ще й поділиться гарним відгуком.
Часто такі рішення приходять не в момент узгодження термінів. Потрібно подумати годину, дві, а то й день.
Ось що радить Head of Software Engineering Данило Толмачов:
Хорошому інженерові не важливо, звідки з'явився дедлайн: встановив керівник чи це примха клієнта. Краще завжди брати додатковий час і глибоко оцінити завдання.
Ви нікого не образите і не засмутите, якщо перенесете узгодження дедлайнів. Часто це показує професіоналізм: фахівець не мчить робити роботу, а грамотно підходить до вирішення завдання.
Ще тайм-аут допомагає визначити: що реально зробити до терміну, а що краще перенести. Можна розставити пріоритети і розповісти керівництву, колегам. Це теж показує людину, як професіонала.
З дедлайнами в роботі та навчанні завжди можна впоратися. Краще — приймати й обговорювати проблему. Або ставити дедлайни із запасом, якщо вправність і досвід дають маневрувати. Наприклад, люди роблять сайти за тиждень, а фахівець — за 5 днів. Можна поставити той самий тиждень і здати раніше.
Якщо хочете отримати професію в IT і грамотно розподіляти робочий час, контролювати дедлайни — записуйтесь на курси IT STEP.
👉 За посиланням знайдете список і програми курсів.