Чи потрібен технічний бекграунд проектному менеджеру в ІТ?
Якщо коротко, то — ні. Не обов’язково. Ані для проходження співбесід, ані для отримання офферу, ані для виконання своїх обов’язків проектному менеджеру не обов’язково знати якісь мови програмування. З ними просто легше, приємніше та цікавіше!
В першу чергу цінуються та вимагаються навички та досвід саме проектного менеджменту. Чим більше років досвіду, різних галузей, типів компаній (стартап / продуктова / аутсорс / аутстафф), сертифікатів — тим краще.
Серед приблизно рівних за досвідом менеджерів, під різні проекти компанії стараються підібрати собі такого менеджера, який мав би досвід (експіріенс / бекграунд) в галузі, пов’язаній з проектом. Чим більш довготривалий та складний проєкт, тим більше вимоги до наявності специфічних галузевих знань у РМ-а на цьому проекті.
На невеличких проектах, або там, де Рroject Мanager веде одночасно декілька проєктів, таких вимог практично не ставлять. І мова зараз йде не про «технічний бекграунд», а саме про ступінь знайомства та розуміння певної галузі (gamedev, e-commerce, fintech, blockchain і т.д.).
Технічний бекграунд для керівника проектів у сфері IT також має ряд переваг. Ось декілька ключових аспектів, які можуть виділити менеджера з досвідом програмування на тлі інших:
• Легше спілкуватися з командою розробників, бо можна розмовляти з ними «однією мовою»;
• Краще розуміння викликів та можливостей допомагає у плануванні, оцінюванні ризиків та ухваленні рішень;
• Більш обґрунтоване прийняття рішень допомагає ефективніше обирати технології та підходи;
• Розуміння процесу розробки дозволить краще підтримувати команду;
• Технічні менеджери отримують більше довіри з боку клієнту та команди;
• З технічним бекграундом легше адаптуватись під будь-який проект, тому вибір можливих проектів стає значно ширшим.
У мене є технічний бекграунд. Я займався розробкою, сам писав код на багатьох мовах програмування. На співбесідах я кажу, що цей бекграунд надає мені можливість краще розуміти проблеми та потреби розробників, а також допомагає краще орієнтуватися в естимаціях. Бо я можу собі уявити об’єм коду, який треба написати, чи проаналізувати, скільки варіантів причини виникнення багу може бути.
Але навіть якби я не мав власного досвіду, я б зміг підрахувати продуктивність своєї команди за 2-3 місяці роботи з ними, і так само знав би, скільки кому часу потрібно на яку з задач.
Тому мої роки технічного бекграунду і знання мов програмування — досить відносна перевага. Це скоріше приємний бонус, ніж значний плюс, хоч як не шкода це визнавати.
Цей текст з особистого блогу, опублікований з дозволу автора.
Блогер та розробник Джозеф Круз розповів, чому не варто писати ідеальний код та чому це…
Днями я завзято нила про щось ChatGPT (експериментую між сеансами з живим терапевтом). І от…
«Крутіть колесо, щоб отримати знижку до 50%!» «Натисніть тут, щоб відкрити таємничу пропозицію!» «Зареєструйтесь зараз,…
Дуже хочеться робити якісь десктопні апки. Сумую за часами коли всі програми були offline-first, і…
Надсилаючи криптовалюту, багато новачків ставлять запитання: як працюють комісії та чому вони відрізняються в різних…
Нова афера набирає обертів — ось детальний розбір того, як фальшиві потенційні роботодавці намагаються вкрасти…