Олександр Піхтовніков – проєктний менеджер з п’ятирічним досвідом і міжнародними клієнтами. Він вміє запевнити кого завгодно, в чому завгодно. А тепер ще й склав курс з проєктного менеджменту для Beetroot Academy. Ми вирішили поставити Сашкові як очевидні, так і вузькопрофільні питання. Запитали – що краще, Agile, чи Waterfall. Дізналися, як спрацюватися продакту й проджекту. Поговорили про перспективи зростання, співбесіди та заробітні плати.
Проєктом може бути що завгодно – будівництво мосту, дороги, будинку. Це не обов’язково пов’язано з ІТ. Проєкт має критерії: дата старту, відповідальний, спонсор й дата очікуваної здачі.
Я так не вважаю. В Agile – це людина, яка спрямовує розробників в потрібному напрямку. Він радить, але не вказує, що робити. Хтось може зі мною не погодитися, але для мене проєктний менеджер – не начальник.
Є старі формати в дусі: “Лише я володію інформацією. Лише я знаю, що ми маємо зробити”. Всі сидять і чекають, доки менеджер щось скаже. Він може маніпулювати даними, знає потреби замовника, всі вважають його за боса.
Насправді на проєкті має бути цілковита прозорість. Ти ділишся інформацією з командою та залучаєш усіх. Ти не можеш самостійно відповідати за весь проєкт. Якісь зони відповідальності делегуєш, отримуєш зворотний зв’язок від команди. В реаліях Agile ти не можеш звільняти людей, але можеш вплинути. Якщо хтось недопрацьовує, треба поговорити зі стейкхолдерами й з командою. Якщо після цього ситуація не змінилася, потрібно робити заміну.
В класичному проєктному менеджменті начальником є спонсор. Він каже, що його не влаштовує, диктує формат роботи, каже, чи потрібно когось замінити. Він не відповідає за фінанси, але має важелі впливу. При цьому замовник і спонсор – це можуть бути дві різні людини.
Все залежить від проєкту, від його рівня складності, від кількості людей, від специфіки. В зрілій команді до 4-5 людей, можливо, проєктний менеджер і не потрібний. Завдання програміста – написати класний код, щоб все добре працювало. Програмісти не завжди цікавляться – чого хоче бізнес. Але, якщо розробнику це подобається, він виконує роль проксі-проджект-менеджера.
Коли з’являються міні-проєкти, завдання ускладнюється. Налагоджування процесів і комунікація з клієнтом займають багато часу. Програміст припиняє кодити, виявляється, весь час пішов на спілкування. В такому випадку краще найняти людину, яка розбирається в бізнес-аспектах, фільтрує інформацію та тримає баланс між програмістами й бізнесом.
Продакт-менеджер – це дуже “бізнесова” людина. Він добре знається на продукті та на потребах клієнта. Розбирається в цифрах, любить аналітику. Наприклад, змінили колір кнопки й посунули на 7 пікселей вліво – він перевірить, чи стало краще, або гірше, чи вплинуло це на форми реєстрації або на систему оплати.
Продакти багато спілкуються з кінцевим користувачем, з клієнтом, з програмістами. Продакт-менеджер може працювати над покращеннями системи, він знається на дизайні. Проєктний менеджер, як правило, не впливає на кінцевий дизайн. Він не заглиблюється так, як продакт. Якщо проєкт складний та є багато даних, проєктний менеджер налагоджує зв’язок зі стейкхолдерами та координує сам проєкт. Продакт каже, які потрібні фічі, виходячи з аналітики. У великих проєктах це тандем, але вони можуть працювати й окремо.
За наявності готового продукту наймайте продакт-менеджера. Він дивитиметься на цифри, спілкуватиметься з користувачами. Якщо проєкт лише розпочався – потрібен проджект. Він розбереться в процесах, налагодить комунікацію зі стейкхолдерами й командою.
Я не вважаю, що хтось крутіший, а хтось гірший. Кожний по-своєму крутий. Можна перейти з однієї посади на іншу, якщо тобі це подобається. Продакт любить дизайн і естетику. Проджект налагоджуватиме комунікацію.
Олександр з командою
Я працював віддалено з командою з 16 осіб. Ти маєш повністю довіряти людям. Потрібно частіше зідзвонюватись, аби бути в курсі. Якщо команда зріла – все вийде.
Я навчався в Німеччині й в Молдові – вивчав економіку та менеджмент, а потім – інформаційні технології. Гарною базою буде економічна освіта, але все залежить від школи. Мені зустрічалися люди, які переходили з інших галузей. Не думаю, що потрібна профільна вища освіта – те, чого навчають в інститутах, не завжди можна застосувати.
Є програм-менеджмент – коли в тебе з’являється більш ніж 2-3 проєкти, ти відповідаєш за постановку, є декілька проджектів в підпорядкуванні. Або ж можна зростати в делівері менеджменті. Вище – програмний директор і СЕО компанії.
Це непогано, але не обов’язково. Потрібно розуміти, що таке баг, як проходить цикл розробки. Навчитися розмовляти із розробниками однією мовою. Я знаюся на архітектурі застосунку, циклі розробки, практиках на проєкті. Це приходить із досвідом. Не потрібно мати диплом або вміти кодити – в реальності це не знадобиться. Робота проєктного менеджера на 40% – комунікація.
Waterfall добре пасує до великих індустріальних проєктів. Agile на 90% використовується в ІТ – ринок динамічний, потрібно якось адаптуватися. Agile – це той самий Waterfall, але менший. В Waterfall ми за три місяці після початку розробки дізнаємося, що щось не так, а вже маємо готову архітектуру. Тут менше гнучкості. В Agile команда підписується на певний проміжок часу, наприклад – 10 робочих днів. По завершенню – отримує відгуки клієнтів, користувачів, аналізує ринок та розуміє, чи у вірному напрямку рухається.
Які проєкти він чи вона вели? Складності, розмір команди, чи випадала нагода вирішувати проблемні кейси. Адже, зазвичай, всі проблеми на PM валяться. Якщо щось іде не так – це провина проєктного менеджера. Якщо все добре – це заслуга команди. Проєктний менеджер тримається в тіні.
Можуть запитати, чи спілкувалися зі стейкхолдерами безпосередньо, за яким фреймворком працювали.
Цікаві запитання – ситуаційні. Часто питають: “Як би ти поводився в цій ситуації?” Відповідь допомагає зрозуміти, чи підходите ви під структуру компанії, команди, самого проєкту.
Мені на співбесіді цікаво дізнатися, що керує людиною, які її принципи. Дивлюся на поведінку – важливо зрозуміти динаміку співбесіди. Одне з улюблених питань: “Уявіть, що команда виконує все вчасно без проєктного менеджера. Що керує людьми?” У відповідь проєктний менеджер скаже про власну приховану мотивацію.
Зрозуміти й пробачити. Потрібно бути готовим до того, що не стане коштів. Або ж тебе не влаштує культура компанії, хоча проєкт подобається. Або ж ти просто не розвиваєшся.
Я намагався доводити до завершення всі проєкти, але одного разу пішов через токсичне середовище в команді й в компанії. Було складно спілкуватися, але мені все одно вдалося налагодити процеси.
Налагоджуйте гарні стосунки із клієнтом. Якщо ви довго працюєте й розумієте один одного, можна пояснити, чому саме ці технології важливі. В нашому випадку проєктний менеджер виступає від імені компанії, але він має враховувати інтереси клієнта. Потрібно розуміти, який зиск з цих технологій, обговорювати нюанси з технічними фахівцями. Коли клієнт тобі довіряє та бачить результати, він готовий слухати.
Якщо команда залучена до бізнесу, можна обговорити ризики, але, як правило, клієнт краще знає свій бізнес. Потрібно дослуховуватися до клієнта так само, як і він дослуховується до програмістів, коли мова йде про технічні нюанси.
Agile потрібний, аби розуміти, чи рухаємося ми у вірному напрямку. На восьмий день ми показуємо, над чим працюємо. Отримуємо фідбек й можемо адаптуватися під вимоги клієнта.
Потрібно зрозуміти, чому взагалі виникла така ситуація. На моєму проєкті люди розуміють, чому кожен з них отримує ту чи іншу суму. Різниця в зарплатах може бути до 20% при однакових функціях. Або ж хтось когось дурить.
Я люблю систему оцінки “360” – кожен робить крос-фідбек. Ми розуміємо, що покращити, в кого які слабкі сторони. Тоді не виникає питання, що хтось отримує більше. Створюється культура довіри.
Я даю співробітнику ту суму, яку він просить, навіть якщо вона нижча за ринкову. Якщо за якийсь час він зрозуміє, що не оцінив об’єм та складність робіт та попросить про підвищення – я підвищу. В ІТ поширений синдром самозванця, тому люди можуть занижувати заробітну плату. Мені й самому іноді не зрозуміла, як так цінується моя робота. Але гірше, коли людина без досвіду має завищені вимоги. Страшно уявити, що буде, коли вона набуде більшого досвіду.
Буває, зарплату підвищують тільки тоді, коли ти маєш офер від іншої компанії. Раптом з’ясовується, що роботодавець має гроші на все. Це проблема культури компанії. Я вважаю, що 10-15% за рік – нормальне зростання.
Проєктний менеджмент підійде не всім. Не зможуть працювати інтроверти, ті, хто не любить спілкуватися. Підійде тим, хто хоче більше дізнатися про бізнес, зрозуміти, що “під капотом” у розробників та бути містком між бізнесом й технічними фахівцями. Це тонка навичка, не в кожного виходить. Але з часом ти вибудовуєш власний підхід, вчишся читати емоції, працювати з людьми та давати їм можливості зростання й розвитку
