Вакансії переважно вимірюють різницю між junior, middle та senior проджект-менеджерами у кількості — років досвіду чи успішно закритих проєктів. А що про це думають самі РМ?
Про якісні відмінності між проджектами різного рівня у колонці для Laba розповідає Артем Шаповал — senior PM, що керує відділом із 80 менеджерів у компанії зі списку S&P 500*, та лектор курсу Laba.
У цьому тексті Артем зосереджується на аналізі ролі проєктних менеджерів саме в IT, але текст буде актуальний для керівників команд в інших вертикалях бізнесу.
Джунів цінують за готовність вчитися, а синьйорів — за здатність працювати автономно
Насправді компанії не очікують багато від інтернів або junior PM. Наприклад, в IT основні вимоги — базове розуміння SDLC (Software Development Life Cycle), гнучкість, бажання вчитися та набувати досвід. На початку кар’єри вам допомагатимуть більш досвідчені колеги, і ваша основна відповідальність — швидко засвоювати нову інформацію та навички.
Також важливо, щоб інтерн або джун мали майндсет «для мене не існує нецікавих задач» — це прокладає шлях до масштабніших та амбітніших проєктів. Коли джун отримує найпростіше та найрутинніше завдання, програма мінімум — виконати його згідно з вимогами. Програма максимум — принести компанії більшу цінність, ніж від нього очікують.
Наприклад, готуючи щомісячні репорти для клієнта, хороший PM спершу подумає, як це прописати й реалізувати по процесах. А потім — спробує автоматизувати процес, щоб ця частина роботи забирала якнайменше часу.
Перехід від джуна до мідла в середньому триває кілька років. Звісно, ви можете і 10 років бути джуном, це питання мотивації. Але в моєму відділі людям потрібно приблизно 2–3 роки, щоб навчитися працювати самостійно, без нагляду і супервізії.
Якщо хочете прискорити розвиток, беріть більше відповідальності. У кожного менеджера вищої ланки є низка задач, які б вони воліли комусь делегувати. Запитайте свого керівника, чи має він такі, візьміть їх на себе та виконайте. Ви здобудете потрібний досвід швидше, а також проявите свою мотивацію та готовність до більших викликів.
Джуни та синьйори приносять компаніям різну цінність
Якщо перехід від джуна до мідла вимірюється рівнем автономності, то зростання від мідла до синьйора — цінністю для компанії та масштабом проєктів. Зазвичай чим більше відповідальності проєктний менеджер може на себе взяти, тим більше він коштує як спеціаліст. Це просте й універсальне правило, але на практиці воно реалізується по-різному. Одні компанії визначатимуть вашу цінність як РМ у кількості грошей, які ви приносите, а інші — у числі нових або утриманих клієнтів.
Щоб на старті мати перевагу над іншими кандидатами та змогу приносити компанії більшу цінність, зосередьтеся на поглибленні теоретичних знань. PM в ІТ не потрібно вміти кодити або ґрунтовно розбиратися у мовах програмування. Але базове розуміння платформ, фреймворків та клауд-рішень — це те, що допоможе вам не лише отримати перевагу над іншими джунами, але й на рівні спілкуватися з проєктною командою. На початку всі ці слова можуть виглядати страшно, але вам і не треба розбиратися в них досконало. Присвятіть бодай кілька годин дослідженню кожної такої теми на рівні Вікіпедії — і цього вже буде достатньо.
Звісно, ви можете вчитися і на досвіді, щоразу винаходити велосипед. У моєму відділі є класні спеціалісти, які ніде не здобували теоретичні знання і прекрасно виконують свою роботу. Але кількість синців на лобі від грабель, на які вони наступали, говорить сама за себе. Тому раджу паралельно з практичними навичками удосконалювати й теоретичне підґрунтя. Наприклад, методи підвищення мотивації в команді, нові фреймворки чи автоматизовані інструменти — все це потрібно і стане в пригоді.
Джуни знають базу, синьйори — мають спеціалізації
Існує стереотип, що для новачків або світчерів в IT найскладніше завдання — ведення документації, але я з цим не згоден. Документація — ключова частина роботи, але не найважча. Коли є базове розуміння циклу розробки та мінімальні теоретичні знання, написання документації не буде для вас надзавданням. Крім того, існує багато шаблонів, які суттєво спрощують роботу. На мою думку, набагато складніше на початку зрозуміти специфічні ролі, які є тільки в IT, та системно опанувати життєвий цикл розробки.
Розуміння SDLC (Software development life cycle) — це база для джуна. Кожен проєкт складається з етапів: ініціація, виконання, контроль і моніторинг, тестування, завершення та звітування. На словах це все дуже просто, але на практиці вам буде потрібно кілька років досвіду, щоб зрозуміти усі нюанси.
Тож спершу ви опануєте базу, а потім — зможете зростати або горизонтально, або вертикально. У вертикальному розвитку ви будете здатні вести масштабніші проєкти. Зазвичай на рівні синьйора РМ може впевнено і без паніки керувати роботою 60–70 людей, тобто кількома командами та проміжною ланкою РМ-ів.
Якщо оберете горизонтальний розвиток, тут йтиметься про здобуття спеціалізації. Вона може стосуватися певного технічного напрямку: наприклад, РМ, який знається саме на мобільній розробці. Також спеціалізація може полягати у знанні певного бізнес-домену, як-от edtech або fintech.
Весь бізнес-контент у зручному форматі
Джуни переоцінюють можливості, синьйори — враховують ризики
Коли джуни заходять у новий проєкт чи колектив, часто зустрічаєш вайб: «Егегей, зараз ми зробимо все і навіть більше, я такий молодець, ніколи нічого не фейлю». Але чим досвідченіший спеціаліст, тим більше у нього розуміння ризиків. Саме тому синьйори (тобто люди з багатьма синцями) замість необґрунтованого оптимізму 10 разів продумають, що може піти не так.
Робота з ризиками дозволяє не лише точніше спрогнозувати можливі труднощі, але й розрахувати додаткові буфери. Усе це допоможе уникнути несподіванок для клієнта, а також зробити так, щоб форс-мажори, що так чи інакше трапляються на проєкті, не мали суттєвого впливу на делівері.
Моя порада джунам: не втрачати оптимізму, але й не будувати на ньому план. Щоб не переоцінити свої та командні можливості, побудуйте правильну взаємодію з колегами — це саме їм потім виконувати ваші плани. Зберіться з ключовими спеціалістами проєкту та пройдіться по флоу. На основі їхнього досвіду ви зможете підсвітити ризики чи потенційні вузькі місця, підготуватися до труднощів або зрозуміти, як їх уникнути.
Джуни шукають знання, синьйори — діляться ними
Коли я починав у 2005, щоб навчитися програмувати, треба було поїхати на книжковий ринок і відшукати там єдині три книги, які містили актуальну на той момент інформацію. Якби я починав зараз — відкрив би пошуковик і побачив би у видачі щонайменше 3 тис. сторінок. Якщо 15 років тому джерела потрібно було шукати, зараз — треба вміти їх фільтрувати й обирати ті, що найкраще закривають ваші потреби.
В нашій компанії, як і в багатьох інших, для цього працює менторинг. Щоб зростати кар’єрно і не набивати ґуль, не соромтеся запитувати колег, які пройшли схожий шлях, про те, як вони це зробили. Їхні підказки про те, де шукати інформацію та здобувати скіли, заощадять ваш час і спростять шлях вгору.
Джуни йдуть за трендами, синьйори їх вивчають
Софт-скіли — це більш-менш сталий набір навичок, змінюються лише обставини їхнього застосування. Наприклад, якщо до пандемії ми всі сиділи в одному офісі, то зараз у команді з десяти людей вісім можуть перебувати в різних країнах. Проте щоби порозумітися з ними, вам потрібна все та ж емпатія, конфліктний менеджмент і розуміння того, як мотивувати людей.
Що ж стосується технічного боку, тут зміни стаються значно швидше — і те, що було в тренді рік тому, сьогодні вже відходить. Масивний потік змін, за яким треба встигати, — це одна з ключових проблем для поточного покоління РМ. Наприклад, раз на квартал виходить оновлений фреймворк у фронтенді (Node.js, React.js), і всі швиденько біжать перевчатися та переписувати під нього свої проєкти.
РМ важливо вміти серфити на хвилі трендів, щоб не опинитися під нею. Якщо ви бачите, що всі переходять на інший фреймворк, дослідіть його особливості. Звертайте увагу на теоретичне підґрунтя, на переваги, але особливо — на недоліки. Звісно, ви не зможете опанувати зміни на рівні технічних спеціалістів, але це й не потрібно. Ваш рівень знань має бути достатнім для того, аби підтримати розмову з клієнтом, переконати його запровадити зміни або обґрунтувати, чому змінювати підхід не варто.
Джуни вчаться казати «ні», синьйори — вміють не лише відмовляти, але й пропонувати альтернативу
На мою думку, для РМ софт-скіли важливіші, ніж хард. Без технічних знань ви якось та й вирулите, але без вміння спілкуватися з різними типами людей — ні.
Один із найбільших викликів для PM, що стосується софт-скілів, — це комунікація з конфліктними або токсичними людьми, а також вміння казати «ні». Відмовляти складно та стресово, але цю навичку можна і треба опанувати. Спершу ви навчитеся відмовляти, потім — додавати мотивацію, чому саме «ні». А коли зможете ще й запропонувати альтернативне рішення — вважайте, що опанували мистецтво відмов. Відмови потребують впевненості у своїй правоті, а вона приходить із досвідом. Мені забрало два-три роки, щоб навчитися не лише казати «ні», але й пояснювати причину.
На старті у мене були відверто слабкі софт-скіли, тому я цілеспрямовано їх пропрацьовував. Тож коли згадую, як я комунікував раніше, і бачу, як можу зараз розв’язувати специфічні кейси, бачу суттєвий прогрес. Нині я здатен вмовити людину залишитися в команді або, навпаки, змінити проєкт, навіть якщо не маю прямих важелів впливу. Це я кажу не для того, аби похвалитися, а щоби показати на власному прикладі, що м’які навички — не те, з чим ви народжуєтесь. Звісно, є люди, в яких початковий рівень є високим, але навіть якщо ви не з цієї категорії — не засмучуйтеся, ви можете покращити свої софт-скіли.
Бажаєте отримувати дайджест статей?
