1
4.6

Оцінити

Статті 4.6 6 голосів 1502

Як встигнути до дедлайну проекту, якщо обсяг робіт перевищує його

Статті: Як встигнути до дедлайну проекту, якщо обсяг робіт перевищує його

Перш за все, давайте розберемося, що ж таке дедлайн. Вікіпедія дає досить чітке і просте визначення цього терміна: «Крайній термін (дата і / або час), до якого повинна бути виконана задача».

Дедлайн може бути обумовлений банальними «хотєлками» замовника (найчастіше безпідставними), маркетинговою кампанією замовника, обіцянками перед топ-менеджерів компанії та іншими можливими обставинами. Причина дедлайну грає важливу роль у переговорах з клієнтом.

"Менеджмент — це мистецтво досягнення цілей в умовах обмеженості ресурсів"

Террі Гібсон

У нашому випадку у нас дуже обмежені ресурси, але як же ми потрапили у таку неприємну ситуацію? Тут можуть бути такі причини:

  1. Неправильна оцінка обсягу робіт. Але не можна звинувачувати тих, хто оцінював. Оцінку завжди просять дати до початку робіт, а дати оцінку тому, чого ти ніколи або частково робив, дуже складно.
  2. Було прийнято рішення будь-яким способом роздобути замовника для портфоліо компанії. Тут навіть складно уявити, наскільки можуть розходитися реальний обсяг і оцінка. Втрати компанії можуть досягати мільйонів доларів.
  3. Проджект-менеджер або його керівництво вирішило: «Ну і що, що оцінка більше терміну дедлайну, як-то вирулимо, ще й з прибутком». Це один з найбільш непрофесійних підходів, які призводять за собою сумні наслідки для команд (та) розробників.
  4. Обсяг робіт постійно збільшується, кожен раз замовник нам щось приносить: «А ось тут ще цей дріб'язок додати», «Тут потрібно, щоб воно по-іншому відкривалося» ... При такому підході ви ніколи не закінчите, і правильний проджект- менеджер всі такі зміни проводить як Change Request до оригінального обсягу. І за кожен такий CR клієнт платить додатково. Але якщо клієнт вимагає, щоб ви вклалися при цьому в термін, то це важкий клієнт, і з ним треба вміти розмовляти.

З вхідними даними ми розібралися, але що ж тепер робити, якщо ми розуміємо, що ми не встигаємо?

Перш за все потрібно про цей ризик повідомити вище керівництво, може, у них будуть якісь додаткові ідеї. Варіантів вирішення даної проблеми не так вже й багато, і всі вони зводяться до комбінації або розширення наступних:

  1. Урізання скоупу проекту. Це один з найкращих і поширених способів потрапити в терміни без збільшення витрат. Тут можна згадати і принцип Парето, і відрізання «хвоста» скоупу, коли найменш корисний функціонал йде в кінці проекту і його можна не робити без шкоди для продукту.
  2. Перенесення дати закінчення проекту. Якщо вам вдасться домовитися про це із замовником, ви молодець. На початку ми говорили, що причина встановленої дати закінчення проекту дуже важлива. І якщо можна її зрушити без непоправної шкоди для замовника і вас, це дуже хороший варіант, так як не варто вдаватися в такому випадку до решти варіантів нижче.
  3. Збільшення кількості співробітників на проекті. Це допомагає до якоїсь критичної точки, коли ефективність взаємодії людей нівелюється кількістю зв'язків між ними. Іншими словами, у вас на проекті буде стільки людей, що вам буде важко ними керувати і координувати їх взаємодію. Але збільшення кількості людей добре працює, якщо частини проекту не пов'язані або слабо пов'язані між собою.
  4. Овертайми на проекті. Вам доведеться вичавлювати з команди останні соки, працювати по суботах, вечорами, а, може, і ранніми ранками, у свята і т.д. Це випалює в команді мораль, знижує якість продукту, і співробітникам потрібно платити за підвищеними рейт.
  5. Збільшення seniority-піраміди на проекті, тобто залучення більш кваліфікованих людей, ніж є на даний момент. Але врахуйте, що час входу \ адаптації на проекті варіюється від одного до трьох місяців. Якщо проект закінчується через місяць, то такий підхід є безглуздим.
  6. Зупинити проект. Це, напевно, найгірший варіант для обох сторін: замовник не отримає продукт, а підрядник — суми, що залишилася за контрактом. Але цей варіант підходить, якщо вигода при закритті проекту для однієї зі сторін перевищує витрати на його продовження. Наприклад, якщо у замовника не залишилося грошей на вас, тоді вихід очевидний. Якщо ви працюєте з фіксед прайс проекту і сильно помилилися з оцінкою обсягу робіт, то краще вже заплямувати репутацію, ніж піти у збиток. Особливо такий варіант підходить для маленьких замовників.

Ви не повинні йти на компроміс якості продукту, «хотєлок» замовника або підписувати людей на овертайми. Потрібно тверезо зважувати свої можливості і відповідально підходити до коммітментів, і тоді ваша команда буде вас любити як батька свого. До того ж ваше вміння виконати мету у стислі терміни без втрат для компанії буде цінувати топ-менеджмент.

Схожі матеріали

Подпишитесь на рассылку
Компьютерной школы Hillel

Ви отримаєте:

  • Інформацію про корисні галузеві заходи
  • Цікаві статті IT-сфери
  • Новини Комп'ютерної школи Hillel