dev.ua продовжує цикл матеріалів про IT-професії. Сьогодні про професію Project Manager розповідає Senior Project Manager у Sigma Software Ліза Головіна. Далі — розповідь від першої особи.
dev.ua продовжує цикл матеріалів про IT-професії. Сьогодні про професію Project Manager розповідає Senior Project Manager у Sigma Software Ліза Головіна. Далі — розповідь від першої особи.
Ми схильні романтизувати професії, про які мало знаємо. Звісно, цікаві й особливі дні інколи трапляються та осяюють шлях. Саме такі історії люди розповідають, про них пишуть статті та книжки чи знімають фільми. І тим самим у масовій свідомості закріплюється міф, що саме так і виглядає типовий робочий день спеціаліста.
Робота поліційного — це не суцільні погоні. Не всі журналісти кожного дня беруть інтерв’ю в селебрітіз у розкішних інтер’єрах. Шеф-кухар ресторану не кожного дня готує для президента.
Якщо ви розглядаєте для себе кар’єру проєктного менеджера в IT, то пропоную ознайомитися з типовим робочим днем такого спеціаліста та приміряти на себе цей костюм.
Можна шукати відповіді в собі на такі запитання:
Отже, один день із життя проєктного менеджера в IT.
10-00. Відкрила ноутбук, прочитала особисті повідомлення в робочих месенджерах і пошту.
Нічого, що має критичний вплив на проєктні плани, не побачила. Відповіла на всі листи, які потребували до 5 хвилин на відповідь, і ще на один лист від керівника, на який треба було відповісти до обіду.
Працювати з іншими буду протягом дня.
11-00. Наша щоденна статус-зустріч із командою. Пів години, де наші 8 членів команди розповідають, чим займалися вчора, чим планують займатися сьогодні, чи є блокери, і просять про допомогу, якщо її потребують.
Також сьогодні вітали на цій зустрічі одну з колежанок із днем народження, уся команда прийшла у святкових капелюхах за нашою домовленістю та дуже вчасно кур’єр зробив доставку квітів. Організовувати сюрпризи було легше, коли вся команда працювала з України.
11-30. На зустрічі з командою прояснили важливу деталь технічної реалізації одного модуля. Про це варто написати замовнику. Те рішення, про яке ми раніше з ним домовлялися, призведе до зниження перфомансу окремих операцій для певних користувачів. Йому це не сподобається. Добре, що в техліда є бачення, як це можна обійти, але нова реалізація потребує трохи більше часу. Пишу листа, де коротко описую проблему та можливі рішення та пропоную зустрітися на 15 хвилин найближчим часом, щоби обговорити ситуацію та визначитися з фінальним варіантом.
12-00. У джуніор-розробника на наступному тижні кінець випробувального терміну. Треба заповнити чекліст, щоби оцінити відповідність позиції, поділитися зворотнім зв’язком: що виходить добре, яким навичкам ще треба приділити увагу, а що негайно виправити, бо це заважає роботі команди.
Планувала над цим завданням працювати годину без перерви з повним фокусом. Та вже за 20 хвилин один із членів команди пише, що залишився без світла вдома, не зможе працювати, поки не дадуть. Це може вплинути на наші плани, бо реліз уже скоро, а це завдання на критичному шляху.
Варіантів рішення в цьому випадку багато різних: це й запропонувати попрацювати з офісу, який має генератори на такі випадки, і відпрацювати цей час, коли дадуть світло, і передати це завдання комусь іншому в команді, хто наразі працює над менш критичною для успіху проєкту таскою. У кожного рішення є свої наслідки, кожне потребує переговорів і зміни планів.
У цьому випадку домовилися, що колега сьогодні поїде в офіс і подбає про додаткове джерело живлення для комп’ютера вдома на схожі випадки.
Попереджаю тестувальника, що може бути затримка зі зданням цієї частини роботи на тестування сьогодні ввечері й обговорюємо альтернативне завдання, щоби не було простою в роботі.
13-00. Повертаюся до чекліста після закінчення випробувального терміну.
Потім відправляю його ейчару.
14-00–15-00. Перерва на обід. Щоби трохи перемикнутися та підзарядитися, краще вийти подихати повітрям, аніж займатися думскролінгом. Ігнорую цю пораду для себе, жадібно читаю новини та нотатки з менеджменту в телеграм-каналах.
15-00. Підготовка до щотижневої зустрічі із замовником. Адженду я відправила заздалегідь. Та тепер хочу додати обговорення тієї технічної проблеми з перфомансом і зібрати свіжі метрики за якістю для обговорення з клієнтом.
15-30–16-30. Зустріч із клієнтом. Усі важливі питання обговорили, прогрес розказали та частково показали.
Замовник погодився на тимчасові проблеми з перфомансом, бо для нього наразі важливішим є вчасно зробити реліз. Запланувати роботу з технічним боргом на наступний спринт. Метриками з якості клієнт задоволений. Дефекти тепер «живуть» менше, отримуємо менше звітів про баги від кінцевих користувачів і за останній місяць суттєво збільшили покриття інтеграційними та авто тестами важливих елементів системи.
16-30. Зустріч віч-на-віч із тестувальницею. Обговорили професійний розвиток, скарги на окремі процеси, питання, які соромилася поставити при всіх. Бачу, що людина втомилась. Домовились, що після релізу візьме декілька днів відпустки, щоб трохи відпочити. І що в наступному релізі пошукаємо нові завдання для неї, які допоможуть швидше прокачувати навички, яких наразі не вистачає. Записую домовленості собі в систему, щоби не забути про них і промоніторити виконання наступного тижня.
17-30. Повертаюсь до листів, які чекали на пошті. Відповідаю ще на декілька, передаю необхідну інформацію команді, планую декілька зустрічей, щоби закрити питання.
Допомагаю одному з розробників переписати листа до замовника, щоб прояснити недостатньо деталізовані вимоги. Виправляю англійську ще в одному листі до замовника від команди.
18-15. Документую домовленості із замовником на нашій сьогоднішній зустрічі. Відсилаю meeting minutes (протокол зустрічі) листом, прошу перевірити інших учасників, що все правильно занотувала. Також дублюю цю інформацію на Confluence, щоб у всіх зацікавлених сторін був доступ до цієї інформації та вона збереглася для історії.
18-45. Планую наступний день. Завтра буде інтерв’ю розробника до нас на проєкт — плануємо ротацію спеціаліста, який уже професійно переріс наш проєкт і прагне нових викликів.
А також декілька внутрішніх зустрічей щодо оптимізації процесу тестування. Також хочу підготувати опитувальник задоволеності клієнту, щоби розуміти, на чому варто концентруватися протягом наступного релізу.
Чи бувають більш активні та динамічні дні? Звісно! Бувають проєктні кризи, які треба швидко вирішувати. Трапляються відрядження до клієнтів чи воркшопи, які треба вміло фасилітувати. Бувають пекельні релізи, коли вся команда працює понаднормово.
Та якщо вам не до душі типовий робочий день ПМа, то я би пропонувала розглянути для себе інші професії в індустрії, щоби не страждати через невиправдані очікування та не шукати собі нову професію через рік.
Ви все ще читаєте? Тоді припускаю, що рутина менеджера вас не злякала й тепер ви потребуєте більше корисної інформації:
Отже, почнемо з вимог до джуніор-спеціалістів:
За що відповідає ПМ на проєкті? Проста та швидка відповідь — за все.
Починаєте ви як Junior PM. Для мене джуніор — це ще не повністю самостійна одиниця. За ним наглядають більш досвідчені ПМи: валідують рішення та розрахунки, дають поради щодо виходу з кризових ситуацій, допомагають розібратись зі складними питаннями.
Middle PM — це вже самостійний керівник, якій опанував усі необхідні навички та може звернутися по допомогу, якщо її потребує. Успішність такого спеціаліста вимірюється успішністю його проєктів і текучкою кадрів.
Senior PM — це, власне, той, хто веде складні проєкти з великими командами або керує цілими програмами в компанії. Хто навчає та наглядає за junior- і middle-PM-ами. Перед фахівцями Senior-рівня зазвичай уже стоять бізнес-цілі, як-от здобуття нових клієнтів, розширення наявного бізнесу, зростання кількості працівників у компанії тощо.
По-перше, в університетах. Глибока економічна освіта зайвою не буде 😊 Зараз університети активно співпрацюють з IT компаніями та запрошують практиків викладати. Авторка й сама регулярно працює зі студентами окремих ВНЗ. Якщо це ваш кейс, то беріть максимум і шукайте можливості отримати управлінську практику паралельно. Роботи з людьми навчитися лише за підручниками не вийде.
По-друге, курси. О, як багато цього на ринку… Зазвичай вони тривають близько 3 місяців, там галопам по Європах розказують про всі області знань, рідко перевіряють домашні завдання та дають персональний зворотний зв’язок. Такі курси дають змогу краще зрозуміти, про що професія, вивчити терміни й ознайомитися з інструментами. Краще, ніж нічого!
Для тих, хто вміє самоорганізовуватися та тримати дисципліну самостійно, є купа варіантів на Coursera, Udemy й українському Prometheus, у тому числі безоплатних. Недолік — не буде викладача, якому можна ставити питання, якщо це записані курси. Та це можна вирішити й іншим шляхом. Наприклад, знайти собі ментора серед друзів-практиків.
Шукайте інтернатури від великих IT-компаній. Там вже буде інше ставлення до навчання, бо вони навчають для себе. Ось тут уже можна очікувати виправлення помилок, розбір питань, перевірку домашок тощо. У кандидатів, які пройшли попередньо курси, значно вищі шанси потрапити на такі інтернатури.
Компенсація для починаючих спеціалістів, згідно зі статистикою на DOU та Djinni, складає $500–600. Та, на мій погляд, на вході можна погодитись і на менше, бо перші пів року — це швидше про ваше навчання та купу інвестованого часу інших спеціалістів компанії у ваш розвиток. Важливо отримати цей перший досвід управління проєктами. Далі буде легше, попит на вас буде більший, і тоді вже можна порушувати питання про перегляд зарплатні.
Професія PM — непроста, але дуже цікава та різноманітна. Вона для тих, хто готовий до великої відповідальності та постійного вдосконалення. Та врешті-решт, ви он таку довгу статтю стягнули дочитати до самісінького кінця! Здається, долати труднощі — у вашій природі. Тому бажаю вам легкого старту, цікавих проєктів і команд вашої мрії!
