Project Management: очікування VS реальність

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Приблизно два роки тому я розглядав Project Management в ІТ як щось незвичайне і здавалося, що це не піддається логіці. Переглядаючи ряд курсів, мені просто не вдавалося зрозуміти всю цю систему Agile, планування, естимації та інше. Цікаво, що на той момент я вже мав кілька років досвіду як проектний та продакт менеджер, але не в ІТ. Сьогодні, з додатковим 1,5 роками досвіду в ІТ, я хочу поділитися своїми думками щодо ІТ-менеджменту. Отже, летімо!

Хто такий проджект взагалі і які його обов’язки?

Загалом, це, мабуть, найчастіше запитання, яке я чую від людей, що не мають досвіду в ІТ.

Очікування: людина, яка контролює все і всіх, проставляє цифєркі і складає звіти для стейкхолдерів й звичайно відповідальна за реалізацію проекта.

Реальність: людина-оркестр, що робить все — від малювання дизайну аплікації до вирішення конфліктних ситуацій та допродажу додаткових фіч клієнтам. PM — завжди відповідальний за все те, що відбувається усередині команди і його проекті, і звичайно кінцева мета — реалізація проекта.



Зона відповідальності менеджера просто не має меж і суттєво відрізняється від компанії до компанії, хочете свободи — працюєте в малій компанії, але все більше нагадуєте швейцарський ніж, а хочете більш чітких правил — го в велику компанію, але не нийте на зайву бюрократію.

Проджектом може бути кожен?

На перший погляд, це певне найпростіша професія в ІТ з відносно низьким порогом входження.

Очікування: вивчив англійську, Скрам, почитав РМbook, заюзав Джиру та кілька фреймворків і окєй, ти вже в світі рожевих фламінго та смузі по п’ятницям.

Реальність: нє, хардскіли важливі, але куди важливіше вміти комунікувати з різними групами людей, вміння брати відповідальність на себе та мати міру часу. Так, так це надважливо, в мене був кейс, коли джуніор РМ не зміг користуватися елементарним Гугл-календарем та навіть не розумів, що вчасно прийти на міт — це вже півсправи для менеджера.



Чи може тут бути виключення? Ні. Менеджер це управлінець і в певних людей просто немає певних рис, ніхто в цьому світі не може робити все, на моє глибоке переконання

Головне матчастина, а інше то вже не важливо?

Гайдів, книг, статей та відео по РМству стільки, що дуже важко не вивчити хоча б одну-дві методології та пару фреймворків.

Очікування: головне реалізувати Скрам/Канбан/Чейн на практиці з дейліками, грумінгом, ретро і так далі. Запланував, написав таску, перевірив виконання, потім поговорили про це на ретро узагалом — от і ок.

Реальність: в розробці головний ресурс — це розробник, це людина. Ти маєш комунікувати з людиною завжди і не тільки за робочими питаннями, будувати відносини, щоб краще розуміти один одного. Якщо у вас є улюблене домашнє тварину, ви повинні знати її породу та ім’я. Ще один важливий аспект — ти менеджер, ти не просто переставляєш таски в Jira, ти захищаєш свою команду перед зацікавленими сторонами, бо ти відповідальний за все, що відбувається усередині твоєї команди.

Не секрет, що дедлайни іноді дуже жорсткі і тобі доводиться просити команду попрацювати понаднормово. Життя, так буває. Ви можете уявити успішного менеджера, який байдужий до команди, і люди такі — ок, він попросив? Треба розуміти, що всі ці фреймворки створені заради ефективної комунікації над проектом, тож я завжди ставлю спілкування в центрі усього процесу.

Проектне планування працює?

Очікування + реальність:


А ось це працює, завжди і в будь якому проекті!

Це виключно моє бачення, засноване на моєму досвіді. А як бачите реальність ви?