[recovery mode] Из инженера в менеджеры: быть или не быть
… А если да, то как?
Автор статьи: Юлия Белозерова
Юлия БелозероваTechnical Program Manager
Сегодня поговорим про развилку: что делать инженеру, когда старые задачки уже нет так радуют, а куда дальше двигаться пока не понятно, но есть желание попробовать проектно-менеджерское.
Вопросы «на берегу»:
Что делает менеджер?
Какие навыки нужны?
Как стать менеджером?
Ну стал я проектным менеджером, и что дальше?
Что почитать?
Давайте разбираться.
Контекст:
Disclaimer 1: я не инженер и никогда им не была. Но все равно считаю, что имею право говорить на тему, потому что а) видела достаточно за 12 лет карьеры в проектном управлении и б) воспитала N менеджеров.
Disclaimer 2: мой взгляд на проектный менеджмент несколько деформирован. В первую очередь потому, что я какое-то время уже не управляю инженерами или командами напрямую.
Disclaimer 3: все сказанное ниже не всегда применимо к очень техническим конторам типа Facebook, где менеджер тоже пишет код. Я рассказываю скорее про сферический менеджмент в вакууме.
Чем на самом деле занимается менеджер
Пример 1:
В моем резюме написано: «Delivering a 9 months Fix-Price project from initiation to live launch, with 40 FTEs assigned, 300+ external technical dependencies involved, reporting to VP and Directors level»
В реальности: в тот период я трекала две огромных эксельки + назначала совещания и делала так, чтобы умные дяди договорились. Еще я собирала оценки по задачам в один страшный Gantt chart. Ну и пинала всех сочувствующих о прогрессе, стараясь не получить тапком по лицу от Его Величества Заказчика. Задавала неудобные вопросы про «почему не готово / не можем», не понимая ничего в продукте. Менторила тимлидов на пути к роли scrum master. То есть большая часть рабочего времени проходит в координации других. По факту, когда вся команда в отпуске, я ничего толком не могла сделать. Потому что моя работа сильно зависела от других.
В резюме написано: «Delivered on time and within budget 7 payment integrations with revenue more than £800k overall for cross-system and technologies, cross-location (5+) < .. >»
В реальности: было две команды внутри большой программы, один заказчик с 5 офисами в разных локациях и хреналион фич / интеграций. Мы каждый день жонглировали мандаринами чтобы впихнуть невпихуемое. Вынимали из Product Owner-а приоритеты, по пути проводили scrum-церемонии. Большую часть времени я задавала всем вокруг все те же неудобные вопросы про «Что дальше» и «А ты поговорил с В. про Х?».
Пример 3:
В резюме написано: «Optimised release lead time for 8 teams from 6 weeks to 4 days by gathering time wasted and collaborating with departments involved»;
В реальности: инженеры жаловались-жаловались, да дожаловались чтобы я побежала собирать инфу по другим командам и затем принесла Самому Главному в зубах циферки что мол мы тут бабло на ровном месте теряем. Он нажал куда надо и процесс р-р-раз и автоматизировали. Две недели моей беготни.
Пример 4:
В резюме написано:»Improved environment provision lead time from 60 to <3 w/days for an enterprise in SAFe environment”;
В реальности: Примерно то же что в примере выше. Где-то 50 писем за месяц в выяснении процесса as is + два митинга с принимающими решение.
Ну, вы поняли.
Обертка звучит сладко, но у менеджера редко есть влияние что-то реально менять. Можно собирать циферки, можно строить презентации, но я не принимаю решений что мы делаем, когда и почему так. Я могу только вопросики задавать. Про приоритеты — заказчику, про требования — аналитику, про сроки — команде.
Основная задача — это поднять флажок.
И это все сложно, это требует скиллов. Но не тех, что вы думаете.
Коллега как-то хорошо сказал: «Если тебе в какой-то момент показалось, что в проекте все наладилось, под контролем и шестеренки вращаются как надо — просто поднимись со своего рабочего места и спроси лично у каждого члена своей команды, какую задачу и как он в сию секунду делает и какие у него проблемы. Обещаю немало открытий.»
Как выглядит день из жизни проектного менеджера:
Вот слепок моей реальной средней рабочей недели в роли менеджера проектов, во времена управление одной или двумя командами.
Подготовить слайд о проекте для отчета одному из Самых Главных;
Набор регулярных 1:1 с продуктовыми чуваками, c кем у меня много пересечений;
Встреча с 5 командами про документирование одного end-2-end процесса;
Назначить / послушать Architecture review и сначала выяснить, а затем подробно расписать что мы делаем дальше (те самые вопросы, приближающие к сакральному «когда поймем когда будет готово» / «давайте пилить на фичи»);
Набор Weekly status calls с продуктами, где я танцую как могу, рассказывая что класненького все продуктовые команды принесли на этой неделе. Стараемся не ударить в грязь лицом и готовимся заранее;
Рассказать очередному не-пойми-кому кто я, зачем я и как мы будем друг другу полезны. Потому что задолбал бегать кругами отвлекая продуктовых чуваков;
Назначить / посетить набор Discovery sessions чтобы а) разобраться в техническом решении и зависимостях чтобы спокойно потом это трекать и понимать что происходит и б) держать руку на пульсе по прогресу. Сессии лидают аналитики / продуктологи;
Написать Weekly status reports для каждого из моих проектов;
Написать Monthly program report — это сложное письмо на 100+ народу;
Подготовить Q3 Program scope summary: сбегать, собрать, уложить в одну картинку, разослать на 50+ человек;
Словить две эскалации, побегать и разобраться;
Написать 14 фидбеков в рамках ежегодного расшаркивания на Performance review;
Получить 4 жалобы одних на другого, (почти) помирить всех и сразу;
100500 раз спросить 100500 людей в личку и чатах «что дальше?», «на когда в плане?», «что мы им ответим?», «а давай <встреча name > проведем!»;
Можно заметить, что реальность проектного менеджера это в первую очередь коммуникация и установка ожиданий. А еще фасилитация всего вокруг и какие-то файлики. Если вам это близко, вам понравится менеджерская роль!
А если серьезно, у проектного менеджера обычно одна-две своих команды и много коммуникации снаружи, но ответственность только за достаточно ограниченный кусок. Я сейчас не говорю про Program manager и Delivery manager. У них другие задачи и уровень абстракции.
Пример: отвечать за команду из 8 человек, где мы пилим только платежи для одного магазина, принимать «заказы» от одного Product Owner и трекать задачи масштаба только одной команды.
Набор навыков:
Проектный менеджмент — это не про инструменты, Gantt или Status reports. Это Expectations Management + Account Management. Все остальное — шелуха.
Можно плохо деливерить и постоянно опаздывать по срокам, но иметь такие офигенные отношения с клиентом и всеми вокруг, что они будут довольными танцевать на голове при появлении вашей команды в комнате. И это успех. А деливери придет, просто не сразу.
Можно офигенно деливерить, но регулярно получать за воротник потому что вы не решаете проблему клиента, а просто пилите фичи, которые он просит. Качайте скиллы про Partnership management и наблюдайте как работают люди, ответственные за отношения со сторонними организациями.
Можно идеально управлять командой по учебнику, но не иметь авторитета. Лидерство — это скилл и его реально прокачать.
Можно быть PMP-certified и следовать теории на зубок, но не быть хорошим менеджером с точки зрения результатов и не понимать, а что мы тут делаем и зачем. Теория не делает вас хорошим управленцем, но без нее сложнее.
Проектный менеджер — это супер организованный человек, который умеет выяснить что реально скрывается за запросом заказчика, подстроиться под ценности заказчика и команды, способен привести команду к решению проблемы мирным путем, офигенный коммуникатор, видит лес за деревьями, немножко психолог, иногда няня и вообще молодец.
Другое определение, со слов коллеги:»Проектный менеджер — это про getting things done. А еще нужна стрессоустойчивость и понимание, что с необходимостью принимать по 100 решений в день и идеальной 99% эффективностью, у тебя будет минимум один реальный косяк в день. А скорее всего — больше. Если у тебя комплекс отличника и желание, чтоб тебя хвалили и чесали за ушком — будет тяжело.»
Подвиды менеджеров
В зависимости от организации и личной харизмы, у менеджера может быть один из вариантов власти:
Уровень 1:»Секретарша» aka проектный координатор
Задачи: Поставить встречу в календарь, написать письмо, послушать, провести стендап. Никакого влияния на решения.
Ареал обитания: встречается в почти любой организации, особенно если у вас Agile на всю голову. Scrum-master это отсюда, если Agile занимает бОльшую часть вашего времени.
Уровень 2: «Проектный менеджер обыкновенный» aka менеджер проектов
Задачи: все, что выше + разблокируется способность договориться с заказчиком и продать выгодное команде решение. Иногда получается даже сказать нет на хотелку заказчика. Здесь вас уже подпускают к другим stakeholders дальше аналитика или вашего личного продуктолога.
Ареал обитания: особь встречается там, где проектов и команд не слишком много и они в целом не особо потоковые. Решения все еще принимает почти кто угодно кроме ПМа.
Уровень 3: «Супермен» aka Delivery manager
Задачи: к предыдущим уровням добавляется способность влиять на решения по продукту. Обычно здесь человек находится в смеси ролей с добавлением немножко от архитектора, аналитика или продуктолога, в зависимости от компании, заказчика и проекта.
Уровень 4: «Бог» aka программный директор.
Задачи: самый главный человек на проекте.
Ареал обитания: чаще встречается вне ИТ. Например в архитектуре или приборостроении. Мне таких живьем в роли ПМа в ИТ встретилось ровно двое. Но они оба быстро стали Product Director, что лучше отражает реальность в их случае.
Реально вырасти из одного в другое, но основная проблема останется: от конторы к конторе в одно название должности пихают совершенно разные уровни. Об этом прямо не говорят и часто не понимают. А зарплаты очевидно отличаются. И это боль! Внимательно читайте вакансии между строк и наблюдайте за менеджерами вокруг.
Как стать менеджером
Путь А:
Найти в своей зоне ответственности конечную задачу с зависимостями и несколькими потоками работ. Желательно с внешними к команде заказчиками. Самое простое — внедрение процесса или миграция из А в Б. Отнестись к этому как проекту: важно аккуратно задраивать и заделиверить с основными артефактами.
Повторить упражнение раза два-три, чтобы у окружающих сложилась картинка что вы можете в координацию. В этот момент к вам придут. И предложат проект за пределами вашей прямой зоны ответственности. Где-то здесь пора просить формальную смену должности. Здесь или чуть позже логично менять работу уже на новую должность «по трудовой».
Срок исполнения: от полугода до трех лет, в зависимости от величины шила в Ж и доверия начальства.
Способ провалиться: от вас будут ожидать, что вы будете отлично работать свою работу ПЛЮС фигачить эти проекты. А интерес будет только на менеджемент. Так что работать придется за двоих и местами себя заставлять.
Путь Б:
Попроситься к действующему ПМу в подаваны, чтобы помочь ему в обмен на менторинг по ходу пьесы. Потому что менторинг ради теории неэффективен, это должно быть про решение задач сегодня. При этом любому ПМу всегда есть что свалить на падавана.
Хорошо работает на берегу сказать, что интересно узнать новую область чтобы заиметь набор скиллов, вот это все. Если спустя несколько месяцев все идет хорошо, составить план что вы должны уметь чтобы ментор мог подписаться что вас уже можно ставить на проект как самостоятельную единицу.
Срок исполнения: от полугода до бесконечности, в зависимости от навыков ментора и качества контакта с падаваном. Менторов можно и нужно менять.
Способ провалиться: да много их. Ментор не торт, ожидания ментора не сопоставимы с реальностью, начальник не поддерживает. Самое важное — это выстроить план и ожидания с боссом И с ментором. Иначе в момент когда вы прокачаетесь, должности вам никто не даст. Еще многое от конторы зависит, не везде такой сценарий вообще прокатит.
Путь С:
Быть хорошим технарем, дорасти до главного инженера проекта и сидеть на берегу реки. Рано или поздно случится расширение организации или куда-то уйдет существующий ПМ, а вам предложат небольшой проект в качестве ПМа.
Срок исполнения: 5…10 лет.
Способ провалиться: вас мало кто будет воспринимать как ПМа. В том числе спонсор проекта. То есть полномочий немного, а ответственность уже есть.
Ресурсы
Теория учится по книге Риты (Rita’s Course in a Book for Passing the PMP Exam). Лучше ничего не придумали. Но Рита сложна для начинающих. Ей лучше полирнуть картину мира когда уже есть хотя бы какая-то практика;
Конференция Agile Days полна стольких сокровищ по решению ежедневных проблем, что в первые 3–5 лет карьеры записи оттуда можно смотреть бесконечно;
Agile project management изучается по разным entry-level курсам онлайн. Там нет ничего сверх-сложного. Добавьте книги Dao Toyota + The Goal + Project Phoenix и хватит. Я преподаю на курсе Agile project manager от школы OTUS. На рынке много других предложений. Ищите что нравится!
Книга Щедровицкого «Оргуправленческое мышление» это мега-ресурс для управленцев любого уровня, начиная с ПМов. Но там язык непростой, ее нужно медленно читать и утрамбовывать в голове отдельными кусками. Иначе не ляжет;
Книга The First 90 days поможет разобраться в альянсах и корпоративной политике. В начале пути это чуть больше и глубже, чем стоит копать;
Приправьте видосами от Стратоплана. Они вообще дело говорят, особенно в части soft-skills;
Как только у вас появился первый проект, найдите ментора например на GetMenor, чтобы он помогал разбирать реальные случаи. Так со временем появится уверенность в том, что вы делаете.
Посмотрите, что просили клиенты в прошедших проектах компании. Там могут встретиться разделы про Cost Control, Schedule Management, Quality Control и т.п. . Как только обнаружились незнакомые слова, по ним стоит прицельно посмотреть небольшие описания.
Я написала закрытый пост-сборник про ресурсы для разных менеджеров. Вероятно, там найдется еще интересное!
Не проектным менеджментом единым!
Проектный менеджмент это надолго. Это интересно даже спустя 10 лет в карьере. Но только если у вас есть координационная жилка и вам искренне нравится добавлять понятности в мир вокруг. Если это «не мое», то есть другие пути в менеджмент, но не проектный.
Управлять командой разработки / тестирования в тайтле руководителя отдела. То есть выстраивать инфраструктуру, branching strategy, release strategy, выбирать тулзы и думать стратегически, но чаще всего иметь в довесок пункт 2. В итоге у вас этого проектного менеджмента будет хоть отбавляй, просто название другое.
Resource management, или другими словами заниматься драками за ресурсы «нам нужно +2 инженера, а их негде взять» + собесы + трения про зп / отпуска + менторинг и развитие людей вверх. Часто совмещено с п.1.
Архитектура разработки. Часто вижу что Principal Engineer занимается архитектурой нескольких систем, но в масштабе ограниченного куска зоопарка. Например, сделать инфраструктуру только для платежной системы и синхронизировать ее со скрепами Core Infra department. Или придумать архитектуру нового маленького продукта. Или вписать в имеющуюся какой-то новый проект, который затрагивает 10 систем. В аутсорсинге обычно тот же человек носит тайтл Solution design engineer OR Solution Architect. Есть еще роль Staff Engineer, но это сильно далеко от координации. Следующий уровень архитектуры — Enterprise Architect. Это придумывание технического решения например как 20 продуктов с 40 системами будут вместе мигрировать в условный AWS с перелопачиванием всей архитектуры.
Product Manager или аналитик. Здесь можно долго говорить чем они занимаются, хоть отдельный пост пиши.
Business Development Manager с упором на поиск новых сфер развития компании. Но тут тоже, кто что подразумевает под такой позицией.
В долгосрочной перспективе
Если вы все же решили стать проектным управленцем, я вам завидую и сочувствую одновременно :)
Подводные камни
Ничего не поделать руками если только вы не супер-технический манагер на супер-техническом проекте, что редкость. Я слышала много жалоб что через год-два управления проектами ПМ хочет снова руки в код по локоть засунуть, а уже сложно / нельзя / потерял хватку. И команда не всегда к такому готова. Исключение — гиганты мысли типа Microsoft / Facebook и возможно Google.
Чем дальше от команды, тем выше уровень абстракции и меньше конкретики. Нет требований, не понятны приоритеты и не получается превратить неопределенность в определенность с первого раза. И слишком много коммуникаций. Технарей бывших не бывает, так что это будет вас раздражать.
Дальше вы может быть станете управлять проектным офисом. Или уйдете в продуктовую ветку. Или случится что-то внезапное типа Account Manager. В CTO / CIO из ПМа сложнее, чем из Software Development Manager.
Более подробно про альтернативные ветки развития: https://stratoplan.ru/blog/directions-of-manager-growth/
Выводы
По опыту, хорошим проектным менеджером становится тот бывший инженер, который смог переключить фокус на продукт и заказчика, strategic thinking, обладает хорошими soft skills, а не пытается решить проектные задачи в лоб. И может нести ответственность за то, чтобы тащить всех и вся в светлое будущее.
P. S.: приглашаю на бесплатный открытый урок 11 мая. Изучим отличия продукта от проекта и поймем разницу между проектным и продуктовым менеджментом. Посмотрим как между ними распределяются обязанности и поговорим про разницу soft-скиллов для этих ролей.
Зарегистрироваться на вебинар
