Як підвищити шанси вкластися в строки до дедлайну?
Ви, мабуть, зустрічали в своїй карʼєрі ситуацію, коли розуміння про неможливість вкластися в дедлайн формувалося саме в день цього самого дедлайну?
Не знаю, як ви, але я такі ситуації зустрічав часто, тому поділюсь одним нескладним і немагічним трюком як підпищити шанси виконати вимоги проєкту.
Ситуація з майже проваленим дедлайном
Почну з історії, реального кейсу, який відбувся кілька років тому. Саме після цього випадку я почав використовувати підхід яким зараз хочу поділитися.
Ми готувалися до важливої презентації продукту і однією з задач було підготувати пдфку з описом переваг і ключового функціоналу. Часу було 2-3 дні. Досить малий строк, тому цю задачу віддали тому, з яким такі проєкти реалізовували вже кілька разів і, важливо, людина була в контексті продукту. Отже, задачу проговорили, ніби все узгодили і з відчуттям впевненості розійшлись, попередньо домовившись подивитися перший результат приблизно через добу.
Я думаю, що ви вже здогадуєтесь, що було в той самий момент, через добу, коли ми почали дивитися результат. Все виглядало так, що нам потрібно додати ще як мінімум добу до часу проєкту і, можливо, залучити кількох людей, щоб встигнути все зробити…
Причини, чому дедлайни можуть не виконуватися.
В описаному мною кейсі зійшлось відразу кілька зірок важливих моментів, які потрібно враховувати в плануванні задач.
По-перше, це закон Паркінсона: “Робота розширюється так, щоб заповнити весь відведений для неї час”.
По-друге, це щось з людської психології, (можливо навіть є якийсь закон чи правило з цього приводу): під час першої оцінки задача виглядає простішою ніж виявляється потім в процесі реалізації.
По-третє, прокрастинація. Зусилля і фокус на задачі, часто, розподіляються не рівномірно – максимальна увага і фокус досягається при наближенні дедлайну.
З цього випливає, що я в своєму кейсі (той, що вище курсивом), як керівник помилився в наступному: я неправильно зафіксував строк для першої оцінки прогресу по проєкту. В цьому випадку це було аж через 50% відсотків часу відведеного на роботу.
Далі моя помилка потягнула за собою ті наслідки, про які я писав вище - попередня робота забрала весь виділений час, задача дійсно виявилась складнішою ніж здавалася на перший погляд, ну і третє, мій дизайнер почав готуватися до нашої зустрічі значно пізніше.
Як зменшити ймовірність проблем з дедлайнами?
Після описаного кейсу (ми вклалися в дедлайн, але ціною безсонної ночі) я почав використовувати наступний підхід.
Оцінку плану виконання задачі, її складність та доступність ресурсів, потрібно провести максимально швидко після власне постановки задачі. Тобто, першу робочу зустріч (це може бути також комунікація в імейл чи слек) потрібно провести не пізніше ніж після того, коли спливе 5%-10% відсотків відведеного часу.
Тобто, мені потрібно було зконтактувати з дизайнером через дві години після початку роботи над задачею і обговорити всі можливі нюанси. Такий підхід нівелював би дві з трьох проблем: такий короткий строк (дві години до першого дедлайну) не дав би розгулятися Паркінсону, а ще це спонукало б мого колегу заглибитись в задачу відразу без прокрастинації і “розкачки”.
Які проблеми такий підхід допоможе виявити?
Нижче я опишу проблеми чи нюанси, які можна виявити за такий короткий строк, а це в свою чергу дасть змогу значно збільшити шанси вкластися в дедлайн, або хоча б сповістити стейкхолдерів про зміни в строках раніше, а не в момент, коли вони будуть очікувати результат.
1. Зрозумілість задачі. Те що колега вам киває і говорить “все зрозуміло” ніяк не гарантує, що задача дійсно зрозуміла. Дайте швидко заглибитись в задачу і виникнуть питання, які краще проговорити і вирішити якомога раніше.
2. Якість постановки завдання. Ви можете бути чудовим менеджером, але нема гарантій, що ви з першого разу врахуєте всі нюанси задачі. Майже сто відсотків, що ви можете щось пропустити і не донести всі важливі складові. Швидкий зворотній звʼязок від виконавця дасть змогу цінити чи є тут проблеми і при наявності ви їх виправите на початку.
3. Наявність всієї інформації. Швидкий аналіз покаже чи дійсно є вся інформація, яка потрібна для реалізації задачі. В цей список потрапляють також доступи до файлів на різних драйвах. Всі ж бачили мем, де в день дедлайну герой розуміє, що доступу до робочих файлі нема :)
4. Потреба в залученні додаткових ресурсів і людей. Іноді задача потребує залучення інших людей (копірайтери, бізнес-аналітики, перекладачі) чи ресурсів - це потрібно виявити якомого раніше.
5. Неправильність попередньої оцінки строків. Це найважливіший пункт з усих. Найчастіше дедлайни порушуються через відсутність повної інформації на початку. Швидкий старт дасть можливість зробити таку оцінку набагато раніше і знайти рішення як обійти обмеження.
+Бонус
А ще цей підхід працю в дві сторони – ви можете його використовувати у випадках, коли виконавець задачі ви і отримуєте якесь завдання від свого керівника. Швидке занурення в роботу дасть змогу якнайшвидше підняти питання, з відповідями на які можуть виникнути проблеми в майбутньому.