Если с должностью проектный и продуктовый менеджер все относительно понятно, то программные менеджеры встречаются не так часто. Чтобы разобраться с тем, что это за профессия, какими навыками должен владеть специалист и как им стать, взяли интервью у спикера Dao PM — Александра Коваленко.
Александр — сертифицированный CSM/CSPO, бывший Head of PMO. Сейчас Program Manager в Parimatch Tech, отвечает за направление CRM и за отдельные проекты внутри него. В его подчинении три PM-а, а команда разработки состоит из 30+ человек.
Program Manager отвечает за управление программой, которая в свою очередь состоит из нескольких проектов. При этом непосредственно с командой и задачами проектов больше работает Project manager, а Program контролирует самые сложные из них, задает направление развития и занимается улучшением процессов.
Поговорили о том, как попасть в сферу IT, и почему отсутствие технического бэкграунда никак не помешает развитию, а даже наоборот. Также Александр рассказал о том, куда можно вырасти из проектного менеджера на собственном примере.
«Доайтишный» период
Как связаны университетское образования и IT
В моем случае — никак! Я — магистр международного права, но ни дня не работал по специальности.
Первый проект
После окончания университета я начал работать в сфере «зеленой энергетики», где у меня не было абсолютно никакого опыта. У компании была советская ТЕЦ, которая была модернизирована под древесную треску, и получила «зеленый тариф». Компания хотела расширяться — купить станцию европейского производства на «зеленом топливе», демонтировать и заново собрать в Украине.
Как я уже говорил, опыта у меня не было, зато был хороший английский, который помог получить должность менеджера по закупкам. В первую неделю мне давали различного рода задачки, но никто толком не понимал, в каких конкретных целях меня можно «использовать». Через неделю пришел руководитель и сказал, что нужно изучить американский сайт. А затем добавил: «Через полчаса у нас созвон с этими инвесторами, будем просить 10 миллионов евро для нашего проекта». Я должен был не только грамотно презентовать проект, но и синхронно переводить разговор, потому что кроме меня и подключенного консультанта с нашей стороны никто не говорил по-английски.
Успех в новом деле
Стресс и отсутствие опыта не помешали провести встречу успешно, потенциальные инвесторы заинтересовались и попросили больше документации. После этого руководство «навесило» на меня задачи по подготовке документов, сбору информации, общению с другими потенциальными вкладчиками: Европейским банком реконструкции и развития, Мировым банком, частными фондами и инвесторами. Так я погрузился в проект с головой, а уже через полгода поехал в свою первую командировку в Манчестер и Тадкастер (Англия) — смотреть электростанции, обсуждать условия покупки, искать генеральных подрядчиков. За мной закрепилось место проджект менеджера, хотя изначально я шел на совсем другую должность и был далек как от энергетики, так и от ведения бизнеса в целом.
После первых инвестиций в проект я ощущал себя уже на 100% проектным менеджером: вел переговоры с подрядчиками из Англии, Польши, Германии, помогал в транспортировке и подготовке площадки в Украине, синхронизировал все между двумя странами. Каждые 2-3 месяца я летал на площадку до окончательной перевозки станции к нам. Часто приходилось вставать в 4-5 утра, чтобы ехать на объект и попутно вносить изменения в договор, составлять план или готовить презентацию. Было сложно, но я благодарен полученному опыту и ни о чем не жалею.
Переход в IT
Я понял, что мое профессиональное развитие остановилось, когда проект был на финальной стадии. Новых не предвиделось в ближайшее время, так как компания сосредоточилась на оптимизации текущей станции, а меня этот процесс уже не драйвил. Я начал думать, что делать дальше, и переход в IT был одним из вариантов. С одной стороны, я понимал что IT-сфера не резиновая и желающих много, а с другой — что я потеряю, если попробую?
Я закончил курсы проектного менеджмента, начал «вливаться» в IT-тусовку и рассылать резюме. Отказов было много, а еще больше — тишины в ответ на резюме. Я понимал причину: никто не хотел к себе в команду новичка без опыта в IT. У меня, когда я собеседую PM-ов, разработчиков или QA, другой подход: я наоборот выделяю для себя тех, кто кардинально меняет специализацию либо отрасль. У таких людей может быть крутой опыт в управлении командой или космическими кораблями, а еще амбиции и понимание, что им нужно работать усерднее. Пусть даже проседают хард скилы в IT, зато, возможно, они видели больше, чем те, у кого целых 3 года опыта в небольшой веб-студии и два маленьких проекта за плечами.
Первая работе в IT-компании
С поиском работы было непросто из-за отсутствия опыта работы в IT сфере. Но когда понимали, что я свободно владею английским, вектор разговора менялся. Собственно, взяли меня именно тогда, когда решили все-таки оценить мой предыдущий опыт: «Как долго вы планировали проект?», «Сколько он длился в итоге?», «Сколько было неучтенных расходов?» После моих ответов руководство решило рискнуть и дать мне шанс. Так я попал в маленькую украинскую IT-компанию, которая занималась аутсорсингом.
Аутсорсинг — передача функций или процессов компанией, которая не является специалистами в какой-то области на компанию, которая в этой области разбирается. Исполнитель работает на своей территории при помощи своих ресурсов. Компания-заказчик взаимодействует с компанией-исполнителем, а не с ее представителями. Оплата производится по факту выполненной работы. Например, вы заказываете мобильное приложение, а аутсорсинговая компания вам его разрабатывает.
Из руководителя проекта в Middle PM-ы
Максимум, что обещали в других компаниях и на что надеялся я сам — это Junior PM. Я изначально был готов начинать с джуна, потому что был уверен, что быстро продвинусь благодаря накопленному опыту. С другой стороны, я понимал, что опыт управления непростым высокобюджетным проектом с большим количеством стейкхолдеров, рисков и непредвиденных ситуаций неправильно было бы «делить на ноль». В итоге должность в новой компании мне дали на уровне middle.
Сфера IT — это не только разработка и написание кода: это и о бизнесе, и об умении работать с людьми. До IT вы где-то работали, сталкивались с разными ситуациями и у вас точно есть багаж полезных знаний.
Проблемный проект как фактор роста
Буквально через месяц после начала работы мне дали очень проблемный проект. У заказчика был стандартный набор претензий: скоуп, качество, сроки, и все это тормозило оплаты последних инвойсов. Усложняла ситуацию другая ментальность заказчика, разница в часовых поясах и то, что это был его первый проект в IT-разработке.
Вот такой проект и я — без навыков в IT, только курсы по Project Management. У меня было какое-то понимание о декомпозиции, оценке и прочем, но реального опыта и знания тонкостей SDLC — 0. Несмотря на трудности, мы вышли на стабильный ход развития проекта, а заказчик вернулся к состоянию, когда он плюс-минус доволен, все инвойсы оплачены и хочется добавлять новый функционал. Мы не только успешно завершили этот проект, но и получили еще три крупных от этого же клиента.
На должности PM-а мне удалось побыть недолго: в компании начали происходить структурные изменения, освободилась позиция Head of PMO, и ее предложили именно мне. Пришлось опять компенсировать отсутствие необходимого опыта тем, что уже умел: я активно участвовал в продажах и внедрил услугу Discovery Phase, которую компания начала активно продавать. Это был достаточно быстрый рост, хотя параллельно я еще вел другие свои старые проекты. Честно, эта идея была так себе: я нигде не успевал, давал скудные фидбеки PM-ам в подчинении, не мог все и сразу контролировать.
Из PM-ов в программные менеджеры
Я знакомился с людьми, меня начали рекомендовать в другие компании. Так я получил оффер от Parimatch и начал работать Project Manager-ом. Хотя это было понижение по должности, условия и масштаб компании в целом были несравнимы. На тот момент там работало около 800 человек. Когда я пришел, я не был знаком ни со сложностями внутреннего продукта, ни с тем, как работать в составе подобных команд, но я увидел четкую стратегию и глобальную цель компании — это меня и зацепило.
Через полтора года я вырос до программного менеджера, хотя все еще на автомате представляюсь проджектом. Не сказал бы, что это какая-то ошибка, ведь если начинаешь с проектного менеджмента, то повышай человека или нет, PM в нем будет жить вечно (можно бить тату с такой надписью).
Зачем расширять зону ответственности
Когда ты отвечаешь за проект или команду (может даже и не одну), есть понимание, где твоя зона ответственности заканчивается. И здесь всегда есть выбор: сказать «Все, стоп, дальше я не пойду» или выйти за пределы и взять на себя больше. Я практикую второй вариант. Один раз переступил черту, второй, третий… А потом у людей складывается впечатление, что ты всегда там и был. Так и происходит рост. Как минимум ты притягиваешь к себе новые обязанности, зоны ответственности, а за ними уже идут карьерные сдвиги, новый опыт, горизонты или оффер.
На курсе Dao PM я всегда говорю студентам: вы не управляете бюджетом напрямую, это не ваша зона ответственности, и бывает, что вас даже не посвящают в цифры, которые крутятся в проекте, но погружаться в это нужно!
Зная всё это, вы можете правильно расставить приоритеты и не подвести ваш проект. Как только вы помещаете себя за черту комфортной зоны ответственности, вы начинаете заведовать этими вопросами. А дальше, когда вы знаете детали и пытаетесь на них влиять, ответственность растет, а вместе с ней и перспективы, опыт, компенсация, бенефиты.
Я сам всегда переступаю эти линии — беру на себя больше и другим советую так делать. Опыт, который можно получить за чертой твоей привычной ответственности, в зоне комфорта не получишь. Часто это трудно и даже больно, но быстрый рост не может быть безболезненным.