Перш за все, давайте розберемося, що ж таке дедлайн. Вікіпедія дає досить чітке і просте визначення цього терміна: «Крайній термін (дата і / або час), до якого повинна бути виконана задача».
Дедлайн може бути обумовлений банальними «хотєлками» замовника (найчастіше безпідставними), маркетинговою кампанією замовника, обіцянками перед топ-менеджерів компанії та іншими можливими обставинами. Причина дедлайну грає важливу роль у переговорах з клієнтом.
Менеджмент — це мистецтво досягнення цілей в умовах обмеженості ресурсів
У нашому випадку у нас дуже обмежені ресурси, але як же ми потрапили у таку неприємну ситуацію? Тут можуть бути такі причини:
- Неправильна оцінка обсягу робіт. Але не можна звинувачувати тих, хто оцінював. Оцінку завжди просять дати до початку робіт, а дати оцінку тому, чого ти ніколи або частково робив, дуже складно.
- Було прийнято рішення будь-яким способом роздобути замовника для портфоліо компанії. Тут навіть складно уявити, наскільки можуть розходитися реальний обсяг і оцінка. Втрати компанії можуть досягати мільйонів доларів.
- Проджект-менеджер або його керівництво вирішило: «Ну і що, що оцінка більше терміну дедлайну, як-то вирулимо, ще й з прибутком». Це один з найбільш непрофесійних підходів, які призводять за собою сумні наслідки для команд (та) розробників.
- Обсяг робіт постійно збільшується, кожен раз замовник нам щось приносить: «А ось тут ще цей дріб'язок додати», «Тут потрібно, щоб воно по-іншому відкривалося» ... При такому підході ви ніколи не закінчите, і правильний проджект- менеджер всі такі зміни проводить як Change Request до оригінального обсягу. І за кожен такий CR клієнт платить додатково. Але якщо клієнт вимагає, щоб ви вклалися при цьому в термін, то це важкий клієнт, і з ним треба вміти розмовляти.
З вхідними даними ми розібралися, але що ж тепер робити, якщо ми розуміємо, що ми не встигаємо?
Перш за все потрібно про цей ризик повідомити вище керівництво, може, у них будуть якісь додаткові ідеї. Варіантів вирішення даної проблеми не так вже й багато, і всі вони зводяться до комбінації або розширення наступних:
- Урізання скоупу проекту. Це один з найкращих і поширених способів потрапити в терміни без збільшення витрат. Тут можна згадати і принцип Парето, і відрізання «хвоста» скоупу, коли найменш корисний функціонал йде в кінці проекту і його можна не робити без шкоди для продукту.
- Перенесення дати закінчення проекту. Якщо вам вдасться домовитися про це із замовником, ви молодець. На початку ми говорили, що причина встановленої дати закінчення проекту дуже важлива. І якщо можна її зрушити без непоправної шкоди для замовника і вас, це дуже хороший варіант, так як не варто вдаватися в такому випадку до решти варіантів нижче.
- Збільшення кількості співробітників на проекті. Це допомагає до якоїсь критичної точки, коли ефективність взаємодії людей нівелюється кількістю зв'язків між ними. Іншими словами, у вас на проекті буде стільки людей, що вам буде важко ними керувати і координувати їх взаємодію. Але збільшення кількості людей добре працює, якщо частини проекту не пов'язані або слабо пов'язані між собою.
- Овертайми на проекті. Вам доведеться вичавлювати з команди останні соки, працювати по суботах, вечорами, а, може, і ранніми ранками, у свята і т.д. Це випалює в команді мораль, знижує якість продукту, і співробітникам потрібно платити за підвищеними рейт.
- Збільшення seniority-піраміди на проекті, тобто залучення більш кваліфікованих людей, ніж є на даний момент. Але врахуйте, що час входу \ адаптації на проекті варіюється від одного до трьох місяців. Якщо проект закінчується через місяць, то такий підхід є безглуздим.
- Зупинити проект. Це, напевно, найгірший варіант для обох сторін: замовник не отримає продукт, а підрядник — суми, що залишилася за контрактом. Але цей варіант підходить, якщо вигода при закритті проекту для однієї зі сторін перевищує витрати на його продовження. Наприклад, якщо у замовника не залишилося грошей на вас, тоді вихід очевидний. Якщо ви працюєте з фіксед прайс проекту і сильно помилилися з оцінкою обсягу робіт, то краще вже заплямувати репутацію, ніж піти у збиток. Особливо такий варіант підходить для маленьких замовників.
Ви не повинні йти на компроміс якості продукту, «хотєлок» замовника або підписувати людей на овертайми. Потрібно тверезо зважувати свої можливості і відповідально підходити до коммітментів, і тоді ваша команда буде вас любити як батька свого. До того ж ваше вміння виконати мету у стислі терміни без втрат для компанії буде цінувати топ-менеджмент.
