5 челенджів проджект-менеджера, який перейшов в IT | Бізнес-школа Laba (Лаба)
Для відстеження статусу замовлення - авторизуйтесь
Введіть код, який був надісланий на пошту Введіть код із SMS, який був надісланий на номер
anastasiiasytar@gmail.com
Код дійсний протягом 2 хвилин Код з SMS дійсний протягом 2 хвилин
Ви впевнені, що хочете вийти?
Сеанс завершено
На головну

Пошук

Зміст

5 челенджів проджект-менеджера, який перейшов в IT

Розповідає Technical Program Manager у Booking.com — Тарас Федорук.

cover-6481c0838ba8a096802697.png

Робота проєктного менеджера — це про постійне жонглювання задачами та необхідність тримати в пам’яті терабайти даних. А ще робочий день PM'а в IT починається задовго до того, як він стартує у команди. 

Розібралися з Тарасом Федоруком, до яких челенджів треба бути готовим, якщо ви проджект-менеджер, який хоче або перейшов в IT з іншої сфери (наприклад, з маркетингу).

Тарас — Technical Program Manager у Booking.com та президент українського представництва PMI. Пройшов понад 10 професійних сертифікацій, зокрема PMP (Project Management Professional) та PSM ІІ (Professional Scrum Master ІІ). Отримав нагороди «Найкращий керівник проєктів в IT» за версією Ukrainian IT Awards у 2019 році та PMI Rising Leader у 2022. 

*Скоро в Тараса стартує онлайн-курс у Laba «Проджект-менеджмент в IT». 

Як проджекту швидко адаптуватися після переходу в ІТ з іншої сфери 

Project Management Institute (PMI) визначає навички менеджера проєктів за допомогою концепції «трикутник талантів PMI». Згідно з ним проджект втілює сукупність трьох груп навичок:

  • Ways of working: способи організації роботи на проєкті. Сюди відносять навички прогнозування, гнучкість, дизайн-мислення. 
  • Power skills: навички та компетенції, які сприяють ефективній співпраці з людьми (емпатія, активне слухання, побудова довіри та вміння працювати в команді). 
  • Business acumen: навички та компетенції, які дозволяють менеджеру проєктів орієнтуватися в індустрії або домені.  

Якщо проджект-менеджер переходить в IT з банківської сфери, ритейлу чи будь-якої іншої, business acumen — те, до чого фахівцям необхідно буде найбільше адаптуватися та заповнити прогалини в знаннях. Деякі способи організації роботи (ways of working) також треба буде змінити, але не суттєво, на рівні практик та окремих підходів.

Ось 5 викликів, до яких варто бути готовим керівнику проєктів в IT:

#1. Багатозадачність і необхідність швидко реагувати на термінові завдання

Розплющити очі, взяти телефон — перевірка пошти, якщо немає заголовків URGENT — піти чистити зуби. Під час сніданку перевірити пошту, розсортувати. Відповісти на URGENT. Приїхати на роботу, дізнатися, що в команді розробки зламалося сьогодні. Зрозуміти, хто це чинитиме, та адресувати таски. Зайнятися беклогом. З’ясувати, хто лагодитиме те, що зламалося щойно. Адресувати. Зайнятися беклогом знову. 

Робота проєктного менеджера — це завжди про багатозадачність, уважність і необхідність враховувати великі обсяги даних. А ще буває, що проджект веде 3–4 проєкти одночасно. Зрозуміло, що людина просто фізично не може однаково добре працювати над кількома проєктами паралельно і якийсь із них точно «відставатиме». 

Щоб уникнути такої ситуації, варто:

  • Братися за проєкти, які знаходяться на різних стадіях життєвого циклу. Наприклад, один проходить етап ініціації, а інший вже підійшов до завершення. 
  • Все записувати. Навіть найменшу та незначну справу потрібно записувати, якщо ви не займаєтеся нею прямо зараз.
  • Використовувати таск-трекери та сервіси для управління проєктами: наприклад, Asana, Active Collab, Basecamp, Trello, Monday, Notion. Згідно з дослідженням, 77% високоефективних проєктів було реалізовано за допомогою програмного забезпечення для проджект-менеджменту.

#2. Зміна парадигми замовника 

При переході в IT з іншої сфери проджект-менеджерам не завжди вдається змінити підхід до роботи в бік взаємодії клієнта з підрядником. 

Уявімо, що людина працювала PMO в банку, займалася внутрішніми проєктами. Її «клієнтами» завжди були фахівці з цієї ж установи. Це не те саме, що працювати на когось ззовні, хто замовляє продукт, платить вашій команді гроші та може будь-якої миті розірвати контракт, якщо щось пішло не так. 

#3. Завищені очікування та небажання робити «відкат» у кар’єрі

Багато фахівців, переходячи до іншої сфери, переконані, що мають достатньо досвіду та можуть претендувати на аналогічні позиції на новому місці. Вони не готові сприймати те, що на повноцінний перехід потрібно принаймні 6–12 місяців і що нова сфера — завжди про крок назад. 

Звісно, це не вимагає від фахівця погоджуватися на позицію Intern/Junior Project Manager після роботи директором проєктів. Проте у вас все одно перевірять загальний обсяг знань в індустрії та, найбільш імовірно, переведуть на Middle-рівень, навіть якщо до цього ви були директором. Хоча вас, скоріше за все, досить швидко підвищуватимуть, у міру вашого занурення в новий бізнес і домен, а також опановування нових способів роботи.

#4. Складність розробки проєктної документації в IT

Один з обов’язків PM'а в IT — фіксувати основні етапи роботи над проєктом та вчасно надавати фідбек команді, керівництву та клієнту. У цьому фахівцю допомагає документація. Вона відрізняється залежно від проєкту, ІТ-компанії та підходів самого менеджера. У роботі можна використовувати власні шаблони або стандартизовані — усе залежить від цілей, домовленостей з клієнтом, керівництвом та командою.

Рекомендуємо прочитати:

img-64775d5beb262261271328.png

Як вести IT-документацію, щоб тримати порядок на проєкті

Читати

Три обов’язкових документи за версією лектора Laba:

  • Статут проєкту (Project Charter)

    Це паспорт проєкту, що розкриває цілі, вимоги, учасників, цінність для бізнесу, структуру команди, базові ризики, обмеження на проєкті. Project Charter створюють для апруву основними зацікавленими особами. Його оновлюють упродовж усього життєвого циклу проєкту. Документ містить цілі, показники успішності, перелік стейкхолдерів та ролі, обсяг та бюджет, віхи та очікувані результати тощо.

  • Дані про хід робіт (Work Performance Data)

    Це початкові вимірювання та деталі роботи, зібрані під час виконання проєкту в будь-якій формі. Ці дані дозволяють робити обʼєктивні судження про перебіг подій та вчасно втручатися за потреби. Прикладом служитимуть фактичні витрати бюджету, тривалість робіт, кількість дефектів, запитів на зміни тощо.
  • Вивчені уроки (Lessons Learned)

    Список рекомендацій, напрацьованих керівником проєкту під час роботи. Ця інформація покликана покращити процеси управління й виконання проєктів всередині компанії в майбутньому.

Цих документів достатньо для контролю основного процесу, але є ще й інша документація, наприклад:

  • Project Status Report. Звіти про статус — це своєчасні, лаконічно написані повідомлення, за якими стейкхолдери та команда розробки можуть отримати уявлення про те, як просувається проєкт: за планом, у зоні ризику чи відстає. Відштовхуючись від цього, можна вносити корективи для покращення або підтримки поточної ситуації в проєкті.
  • Project Schedule. Це розклад проєкту, в якому вказані всі пов’язані завдання і терміни виконання. За ним контролюють темпи просування: чи йдете ви за графіком, що вже було зроблено, які наступні контрольні точки. Визначити, коли проєкт буде закінчено та доставлено клієнту, досить складно. Згідно зі звітом PMI Pulse of the Profession, приблизно 48% проєктів не завершуються в початково запланований термін.
  • Risk Register. Тут враховують ризики. Це важливий документ для кожного проєкту, незалежно від його моделі життєвого циклу: Waterfall, Agile чи Hybrid. Саме ризики допомагають проджекту уникати «гасіння пожеж», доводячи проєкт до успішного релізу.
  • Communication Matrix. Це опис передачі інформації всередині та ззовні проєкту, зі вказаною специфікою спілкування: способу передачі, типу інформації, частоти та залучених стейкхолдерів.
  • RACI Matrix. Список стейкхолдерів або їхніх груп із зазначенням ролей та дій, за які вони відповідають. 
  • Meetings Notes / Minutes. Це міністатус після мітингу. Наприклад, ви зустрілися з клієнтом, обговорили поточні завдання та дійшли якихось рішень. Далі це записуєте в листі та відправляєте замовнику. Так ви знижуєте ймовірність щось забути й фіксуєте домовленості, щоб у випадку спірних питань мати можливість врегулювати ситуацію на свою користь.

#5. Загальна technical awareness

Межа між IT Project Management і проєктним менеджментом в інших галузях стає дуже тонкою. Припустимо, фахівець переходить в IT з банківської сфери. Проте він уже має досвід розвитку IT-системи в банку. Або приходить в айті з ритейлу — чим він займався на попередньому місці роботи? Розвивав інтернет-магазин. 

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

Проте, звичайно, IT передбачає специфічні підходи до роботи, розробки продукту, набір технологій тощо. Це як із фітнес-клубом: уявіть, що ви намагаєтеся ним керувати, але не знаєте різниці між функціональним тренуванням та силовим або не можете пояснити клієнту різницю між типами абонементів. Чи будете ви ефективним адміністратором? 

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

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

Тому розібратися з ітеративно-інкрементальним підходом до розробки теж не буде зайвим. Найбільш імовірно, вас спитають на співбесіді про ключові принципи цього підходу. А ще про те, як планувати роботу, контролювати прогрес і проводити типові зустрічі або події на кшталт ретроспектив, опрацювання беклогу (грумінг), демо тощо.

З якими проблемами в ІТ Project Management я стикався на початку кар'єри:

  • Відсутність наставника

В ідеальному світі старт роботи новачка в Project Management виглядає так:

Ви працюєте проєктним менеджером, а ваш керівник — Head of PM чи Senior Project Manager, тобто людина з вашого функціонального поля, яка займається тими ж проблемами, що й ви, лише в більших масштабах. Він може надати кар’єрні поради або допомогти в розв’язанні робочих завдань. Це критично важливо для джуна. 

Натомість перший мій справжній наставник (який спеціалізувався на проджект-менеджменті) з’явився в мене аж через 5 років роботи. До цього моїми керівниками були власник компанії, операційний менеджер відділу, де я виконував роль PM'а, тощо. У такому випадку навчання та розвиток стають проблемою самого фахівця. Йому немає до кого піти, у кого запитати поради, немає людини, яка допоможе скласти індивідуальний план розвитку.

  • Проблемні клієнти 

Великі компанії мають можливість відмовлятися від співпраці з невигідним з фінансової точки зору або токсичним клієнтом. Малі компанії такої опції не мають, вони «тримаються» за кожного замовника. Тому проджект у таких організаціях стикається з великою кількістю маніпуляцій, погроз, токсичності тощо. На початку кар’єри це особливо складно витримувати. 

Стандартний привід для маніпуляцій — scope creep, або неконтрольоване розширення обсягу робіт: клієнт вимагає за той самий час або бюджет зробити більший обсяг роботи. На старті кар’єри проджект ще може не знати, як вести документацію та фіксувати всі домовленості так, щоб відстояти себе й команду, довівши свою правоту. Як наслідок отримуємо багато негативу, овертайми та загальне виснаження IT-команди. 

  • Виконання завдань, які не мають відношення до Project Management 

У маленьких компаніях PM'у часто доводиться виконувати роботу інших фахівців: керувати  вимогами (робота аналітика), найманням (робота HR), розвʼязувати загальні офісні проблеми (робота офіс-менеджера).

У таких компаніях PM — це такий собі god object: приймає проєкт, пише документацію, проєктує UI та API, планує, виступає в ролі Scrum Master у команди, веде звітність щодо проєкту, виставляє інвойси клієнту. Якщо треба, може й тести написати для API, мануально потестити, намалювати кнопочки в Adobe Photoshop, іноді навіть закодувати.

Я починав свій шлях саме в маленьких компаніях — як у принципі це робить переважна більшість проєктних менеджерів. На мене «повісили» ще ролі тестувальника, бізнес-аналітика та інших фахівців. Логічно, що мені треба було дуже багато всього вивчити. 

А коли я перейшов у нову, вже велику компанію — зрозумів, що на початку карʼєри дуже «втратив фокус». Виявилося, що на попередньому місці роботи я виконував 40% задач із проєктного менеджменту, тоді як 60% взагалі не стосувалися моєї ролі. Крім того, ця проблема може призвести до того, що у вас банально бракуватиме знань із власне Project Management.    

Бажаєте отримувати дайджест статей?

Один лист з найкращими матеріалами за місяць. Підписуйтесь, аби нічого не проґавити.
Дякуємо за вашу підписку!
Курс з теми:
«Business English для проджект-менеджерів»
Бізнес і управління
Веде Ludmila Fenota, Inna Polishchuk
3 червня 2 вересня
Ludmila Fenota, Inna Polishchuk