Сегодня поговорим про развилку: что делать инженеру, когда старые задачки уже нет так щекочат пузико, а куда дальше двигаться пока не понятно.
Это противоречивый пост с однобокой перспективы не-инженера. Я уже слышу как вы строчите критические комментарии и очень их жду! Мне тоже хочется учиться =)
Осторожно, ОЧЕНЬ длинный текст!
Одним из потенциальных направлений может стать менеджмент. Вуаля, у инженера возникает 100500 вопросов формата:
- Что делает менеджер?
- Какие скиллы нужны?
- Как стать менеджером?
- Ну стал я ПМом, и что дальше?
- Что почитать?
Давайте разбираться.
Disclamer 1: я не инженер, я вообще из саппорта когда-то вылупилась. Но все равно считаю, что имею право говорить на тему, потому что а) видела достаточно и б) воспитала N менеджеров.
Disclamer 2: мой взгляд на проектный менеджмент несколько деформирован, в первую очередь потому что я какое-то время уже не управляю инженерами или командами напрямую.
Disclamer 3: все сказанное ниже не всегда применимо к очень техническим конторам типа Facebook где менеджер тоже пишет код. Я рассказываю скорее про сферический менеджмент в вакууме.
Призываю в комментарии проектных менеджеров для сбора других точек зрения. Как обычно, хочется сравнить свой опыт с реальностью.
Чем на самом деле занимается менеджер
В резюме 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 потому что команда из 40 человек это зло, а распилить просто так низзя. Долгая история, не про нее здесь.
В резюме 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-церемонии и задавая все те же неудобные вопросы про "Что дальше" и "А ты поговорил с В. про Х?".
В резюме Optimised release lead time for 8 teams from 6 weeks to 4 days by gathering time wasted and collaborating with departments involved;
В реальности Инженеры жаловались-жаловались, да дожаловались что я побежала собирать инфу по другим командам и затем принесла Самому Главному в зубах циферки что мол мы тут бабло на ровном месте теряем. Он нажал куда надо и процесс ррраз и автоматизировали. Две недели моей беготни.
В резюме Improved environment provision lead time from 60 to <3 w/days for an enterprise in SAFe environment;
В реальности Примерно то же что в примере выше. Где-то 50 писем за месяц в выяснении процесса as is + два митинга с принимающими решение.
Ну, вы поняли. Обертка звучит сладко, но у менеджера редко есть влияение что-то реально менять. Можно собирать циферки, можно строить презентации, но я не принимаю решений что мы делаем, когда и почему так. Я могу только вопросики задавать. Про приоритеты - заказчику, про требования - аналитику, про сроки - команде.
И это все сложно, это требует скиллов. Но не тех что вы думаете.
UPD из комментов:
"Если тебе в какой-то момент показалось, что в проекте все наладилось, под контролем и шестеренки вращаются как надо - просто поднимись со своего рабочего места и спроси лично у каждого члена своей команды, какую задачу и как он в сию секунду делает. Обещаю немало отрытий."
Как выглядит день из жизни манагера
Вот слепок моей последней рабочей недели:
- Подготовить слайд на продукт x 6 для отчета одному из Самых Главных
- Набор регулярных 1:1 с продуктовыми чуваками, где у меня много пересечений
- Митинг с кажется 5 командами про документирование одного E2E процесса
- Назначить / послушать Architecture review и сначала выяснить, а затем зафолоуаппить что делаем дальше (те самые вопросы, приближающие к сакральному "когда поймем когда будет готово" / "давайте пилить на фичи")
- Набор Weekly status calls с продуктами, где я танцую как могу, рассказывая что классненького все продуктовые команды принесли на этой неделе. Стараемся не обосраться и готовимся заранее.
- Рассказать очередному не-пойми-кому кто я, зачем я и как мы будем друг другу полезны. Потому что задолбал бегать кругами отвлекая продуктовых чуваков.
- Назначить / посетить набор Discovery sessions чтобы а) разобраться в техническом решении и зависимостях чтобы спокойно потом это трекать и понимать что происходит и б) держать руку на пульсе по прогресу. Сессии лидают аналитики / продуктологи.
- Weekly status reports x 6 (два слайда на продукт. Один продукт = 5+ проектов)
- Monthly program report (сложное письмо на 100+ народу)
- Q3 Program scope summary (сбегать, собрать, уложить в одну картинку, разослать на 50+ человек)
- Словить две эскалации, побегать и разобраться
- Написать 14 фидбеков в рамках ежеполугодного расшаркивания на Performance review
- Получить 4 жалобы одних на другого, (почти) помирить всех и сразу
- 100500 раз спросить 100500 людей в личку и чатах "что дальше?", "на когда в плане?", "что мы им ответим?", "а давай <митинг name > проведем!"
Как не сложно заметить, я делаю что угодно кроме радостного выпиливания продукта. И это реальность многих менеджеров. Презентации, коммуникация и митинги. Все!
Другими словами, это снова коммуникация, фасилитация и какие-то файлики.
UPD из комментов:
У проектного менеджера одна-две своих команды и много коммуникации снаружи, но ответственность за достаточно ограниченный кусок. Пример: отвечать за команду из 8 человек, где мы пилим только платежики для одного магазина, принимать "заказы" от одного Product Owner и трекать задачи масштаба одной команды only.
Program manager же ставит / трекает задачи менеджерам команд и почти наверняка не имеет своей. И точно не общается напрямую с инженерами. Плюс разница в гранулярности задач: то, что для меня выглядит как одна сравнительно маленькая задача, может оказаться проектом / эпиком на несколько месяцев на несколько команд. Пример: программа по платежам для 6 продуктов с разными сценариями и заказчиками.
Есть еще проблема в названии. Часто то что есть program management делает человек в тайтле project-a. И наоборот.
Вот тут хорошо про разницу Program vs Project
Набор скиллов
Проектный менеджмент - это не про тулзы, Gantt или Status reports. Это Expectations Management + Account Management. Все остальное - шелуха.
Можно хреново деливерить и постоянно опаздывать по срокам, но иметь такие офигенные отношения с клиентом и всеми вокруг, что они будут довольными танцевать на голове при появлении вашей команды в комнате. И это успех. А деливери придет, просто не сразу.
Можно офигенно деливерить, но регулярно получать за воротник потому что вы не решаете проблему клиента, а просто пилите фичи, которые он просит. Качайте скиллы про Partnership management и наблюдайте как работают люди, отвественные за отношения со сторонними организациями.
Можно идеально управлять командой по учебнику, но не иметь авторитета. Лидерство - это скилл и его реально прокачать.
Можно быть PMP-certified и следовать теории на зубок, но не быть хорошим менеджером с точки зрения результатов и не понимать а что мы тут вообще делаем. Теория не делает вас хорошим управленцем, но без нее сложнее.
Проектный менеджер - это супер организованный человек, который умеет выяснить что реально скрывается за запросом заказчика, подсториться под ценности заказчика и команды, способен привести команду к решению проблемы мирным путем, офигенный коммуникатор, видит лес за деревьями, немножко психолог, иногда няня и вообще молодец.
UPD из комментов: "Проектный менеджер - это про getting things done. А еще нужна стрессоустойчивость и понимание, что с необходимостью принимать по 100 решений в день и идеальной 99% эффективностью, у тебя будет минимум один реальный косяк в день. А скорее всего - больше. Если у тебя комплекс отличника и желание, чтоб тебя хвалили и поглаживали - будет тяжело."
Подвиды менеджеров
В зависимости от организации и личной харизмы, у менеджера может быть один из вариантов власти:
- Уровень:Секретарша. Поставить митинг, написать письмо, послушать, провести стендап. Никакого влияния на решения. Встречается в почти любой организации, особенно если у вас Agile на всю голову. Scrum-master это отсюда, если Agile занимает бОльшую часть вашего времени.
- Уровень: Координатор. Все что выше + открывается абилка договориться с заказчиком и продать выгодное команде решение или даже сказать нет на хотелку. Здесь вас уже подпускают к другим stakeholders дальше аналитика или вашего личного продуктолога. Особь встречается там, где проектов и команд не слишком много и они в целом не особо потоковые. Решения все еще принимает почти кто угодно кроме ПМа.
- Уровень:Delivery manager. Добавляем способность влиять на решения по продукту. Обычно здесь человек находится в смеси ролей с добавлением немножко от архитектора, аналитика или продуктолога.
- Уровень:Бог. Самый главный человек на проекте. Чаще встречается вне ИТ. Например в архитектуре или приборостроении. Мне таких живьем в роли ПМа встретилось ровно двое. Но они оба быстро стали Product Director, что лучше отражает реальность.
Реально вырасти из одного в другое, но основная проблема останется: от конторы к конторе в один тайтл пихают какой-то уровень и не говорят (даже не понимают, чего уж там) об этом, а зарплаты очевидно отличаются. И это боль! Внимательно читайте вакансии между строк и наблюдайте за менеджерами вокруг.
Как стать менеджером
Путь А: найти в своей зоне ответственности конечную задачу с зависимостями и несколькими потоками работ. Желательно с внешними к команде заказчиками. Самое простое - внедрение процесса или миграция с чего-то на что-то другое. Отнестись к этому как проекту, задрайвать и заделиверить с основными артефактами. Повторить раза два-три, чтобы у окружающих сложилась картинка что Имярек может в координацию. В этот момент к вам придут. И предложат проект за пределами вашей прямой зоны отвественности. Где-то здесь пора просить тайтл. Здесь или чуть позже логично менять работу уже на новый тайтл.
Срок исполнения: от полугода до трех лет, в зависимости от величины шила в жопе и доверия начальства.
Способ оказаться в Ж: от вас будут ожидать что вы будете отлично работать свою работу ПЛЮС фигачить эти проекты. А интерес будет только на менеджемент. Так что работать придется за двоих и местами себя заставлять.
Путь Б: попроситься к действующему ПМу в подаваны чтобы ему помочь в обмен на менторинг по ходу пьесы. Потому что менторинг ради теории не эффективен, это должно быть про решение задач сегодня. А ПМу всегда есть что свалить на подавана. Хорошо работает на берегу сказать что интересно узнать новую область чтобы заиметь набор скиллов, вот это все. Если спустя несколько месяцев все идет хорошо, составить план что вы должны уметь чтобы ментор мог подписаться что вас уже можно ставить на проект как самостоятельную единицу.
Срок исполнения: от полугода до бесконечности, в зависимости от навыков ментора и качества контакта с подаваном. Менторов можно и нужно менять.
Способо оказаться в Ж: да много их. Ментор не торт, ожидания ментора не сопоставимы с реальностью, начальник не поддерживает. Самое важное - выстроить план и ожидания с боссом И с ментором. Иначе в момент когда вы прокачаетесь, должности вам никто не даст. Еще многое от конторы зависит, не везде такой сценарий вообще прокатит.
Жду ваших историй как вы конвертировались в проектных менеджеров.
Путь С из комментов: Быть хорошим технарем, дорасти до главного инженера проекта и сидеть на берегу реки. Рано или поздно случится расширение организации или куда-то уйдет существующий ПМ, а тебе предложат небольшой проект в качестве ПМа.
Срок исполнения: 5...10 лет.
Способ оказаться в Ж: тебя мало кто будет воспринимать как ПМа. В том числе спонсор проекта. То есть полномочий немного, а ответственность уже твоя.
Ресурсы
Теория учится по книге Риты. Лучше ничего не придумали. Но Рита сложна для начинающих. Ей лучше полирнуть картину мира когда уже есть хотя бы какая-то практика.
Конференция Agile Days полна стольких сокровищ по решению ежедневных проблем, что в первые 3-5 лет карьеры записи оттуда можно смотреть бесконечно.
Спрашивать про ресурсы других проектных менеджеров. Они вам всякого накидают.
Agile project management изучается по разным entry-level курсам онлайн. Там нет ничего сверх-сложного. Добавьте книги Dao Toyota + The Goal + Project Phenix и хватит.
Книга Щедровицкого Оргуправленческое мышление это мега-ресурс для управленцев любого уровня, начиная с ПМов. Но там язык непростой, ее нужно медленно читать и вкуривать отдельными кусками. Иначе не ляжет.
Книга The First 90 days поможет разобраться в альянсах и корпоративной политике. В начале пути это наверное over-kill.
Добавьте парочку практических курсов по переговорам и один по продажам или работе с возражениями.
Приправьте видосами от Стратоплана. Они вообще дело говорят, особенно в части soft-skills.
А давайте сообразим список ресурсов для менеджеров?
Большой UPD из комментов:
Обязательно внутренние: спрашивать других менеджеров, искать задокументированные lessons learned прошлых проектов.
Внешние: софт-скиллы от Стратоплана, плюсую. Рядом - помогающий Стратоплану с ПМ экспертизой Иван Селиховкин, у него есть свой сайт и небольшая простая книга для начинающих PMов.
Еще посмотреть, что в прошедших проектах компании требовали клиенты. Увидишь там разделы про Cost Control, Schedule Management, Quality Control и т.п. - прочти их и иди искать курс по каждому - для того, чтобы хотя бы уметь поддерживать разговор с клиентами об этом "за стойкой бара". В PMP/Рите это тоже есть, но б продублировать.
Чуть позднее можно посмотреть на Школу системного менеджмента и Левенчука. Товарищи вещают иногда замудренно, но охват стандартов/методологий впечатляет - я нашел для себя несколько схем и чек-листов, полезных в ежедневной работе. В этом году у них вышел онлайн-учебник за символические тысячу рублей, рекомендую.
«Договориться можно обо всём»
«Сначала скажите нет»
«Общаться с ребенком как» - лучшее пособие по управлению инженерами. Потому что мотивация очень похожа. Да, цинично =)
А вот "Как пасти котов" это не очень хороший ресурс, как по мне.
Альтернативные ветки развития
Призываю в комментарии Software Development Managers и прочитх руководителей разработки для раскрытия картины мира изнутри. А то знаете, я ненастоящий сварщик.
Не менеджментом единым!
- Управлять командой разработки / тестирования в тайтле руководителя отдела. То есть выстраивать инфраструктуру, branching strategy, release strategy, выбирать тулзы и думать стратегически, но чаще всего иметь вдовесок пункт 2. В итоге у вас этого проектного менеджмента будет хоть отбавляй, просто название другое.
- Resourse management, или другими словами заниматься драками за ресурсы "нам нужно +2 инженера, а их негде взять" + собесы + трения про зп / отпуска + менторинг и развитие людей вверх. Часто совмещено с п.1.
- Архитектура разработки. Не мне объяснять инженерам чем занимается архитектор. Сами разберетесь.
- Product Manager или аналитик. Здесь можно долго говорить чем они занимаются, вон недавно даже пост был.
UPD: Все же давайте поговорим про архитекторов. Часто вижу что Principal Engineer занимается архитектурой нескольких систем, но в масштабе ограниченного куска зоопарка. Например, сделать инфраструктуру только для платежной системы и синхронизировать ее со скрепами Core Infra department. Или придумать архитектуру нового маленького продукта. Или вписать в имеющуюся какой-то новый проект, который затрагивает 10 систем. В аутсорсинге обычно тот же человек носит тайтл Solution design engineer OR Solution Architect.
Следующий уровень архитектуры - Enterprise Architect. Это придумывание технического решения например как 20 продуктов с 40 системами будут вместе мигрировать в условный AWS с перелопачиванием всей архитектуры.
UPD из комментов:
Business Development Manager с упором на поиск новых сфер развития компании. Но тут тоже, кто что подразумевает под такой позицией.
В долгосрочной перспективе
Если вы все же решили стать проектным управленцем, я вам сочувствую.
Ничего не поделать руками unless вы супер-технический манагер на супер-техническом проекте, что редкость. Я слышала много жалоб что через год-два управления проектами ПМ хочет снова руки в код по локоть засунуть, а уже сложно / нельзя / потерял хватку. И команда не всегда к такому готова. Исключение - гиганты мысли типа Microsoft / Facebook и возможно Google.
Чем дальше от команды, тем выше уровень абстракции и меньше конкретики. Нет требований, не понятны приоритеты и не получается превратить неопределенность в определенность с первого раза. И слишком много коммуникаций. Технарей бывших не бывает, так что это будет вас раздражать.
Дальше вы может быть станете управлять проектным офисом. Или уйдете в продуктовую ветку. Или случится что-то внезапное типа Account Manager. В CTO / CIO из ПМа сложнее, чем из Software Development Manager.
В комментах подсказали почитать еще вот тут: https://stratoplan.ru/blog/directions-of-manager-growth/
Вывод
Не идите в менеджеры. Точка.
Или идите, дело ваше. Моя задача - показать картинку "а что будет если".
По опыту, хорошим проектным менеджером становится тот бывший инженер, который смог переключить фокус на продукт и заказчика, strategic thinking, обладает хорошими soft skills, а не пытается решить проектные задачи в лоб. И ответственность может нести за то чтобы тащить всех и вся в светлое будущее, да.
P.S.: в два часа ночи мне пора спать. Исправление опечаток и добавление ссылок случатся позже.
Очередной шикарный пост, спасибо, @Covectb_cobaka.
Пару комментариев с моей колокольни:
Так и есть, задавание вопросов, отвечание ответов. Managing by walking around рулит - если тебе в какой-то момент показалось, что в проекте все наладилось, под контролем и шестеренки вращаются как надо - просто поднимись со своего рабочего места и спроси лично у каждого члена своей команды, какую задачу и как он в сию секунду делает. Обещаю немало отрытий.
Буфер и конвертор интерфейсов между стейхолдерами и проектной командой и внутри проектной команды.
Дааа. Только файлики еще могут быть результатом работы твоей команды. Ты несешь ответственность за продукт проекта, ты ставишь свою подпись в графе "Approved by", ты первый потом поймаешь фидбек. Будь добр, пробегись хотя бы по диагонали глазами по каждому исходящему документу и прилетающим комментариям заказчика.
А еще, помимо тактики и тушения пожаров, хорошо бы подняться чуть выше над ситуацией и поработать с рисками. То есть подумать о плохом, представить (и попросить свою команду) самые вероятные причины, почему твой проект может провалиться, и накидать план действий, чтобы предотвратить, смягчить или осмысленно забить и довериться судьбе.
Тоже да. Проектный менеджер - это про getting things done. А еще нужна стрессоустойчивость и понимание, что с необходимостью принимать по 100 решений в день и идеальной 99% эффективностью, у тебя будет минимум один реальный косяк в день. А скорее всего - больше. Если у тебя комплекс отличника и желание, чтоб тебя хвалили и поглаживали - будет тяжело.
Все-таки ПМ должен быть главным на проекте в рамках выделенных ему ограничений по ресурсам-срокам-объемам. Точка принятий решений должна быть одна. Когда у проекта больше одного хозяина, сильно размывается ответственность. Понятно, что умение вовремя сделать эскалацию вопроса и идти к спонсору за поддержкой должно быть всенепременно.
План C: быть хорошим технарем, дорасти до главного инженера проекта и сидеть на берегу реки. Рано или поздно случится расширение организации или куда-то уйдет существующий ПМ, а тебе предложат небольшой проект в качестве ПМа. Срок исполнения: 5...10 лет. Способ оказаться в Ж: тебя мало кто будет воспринимать как ПМа. В том числе спонсор проекта. То есть полномочий немного, а ответственность уже твоя.
Обязательно внутренние: спрашивать других менеджеров, искать задокументированные lessons learned прошлых проектов.
Внешние: софт-скиллы от Стратоплана, плюсую. Рядом - помогающий Стратоплану с ПМ экспертизой Иван Селиховкин, у него есть свой сайт и небольшая простая книга для начинающих PMов.
Еще посмотреть, что в прошедших проектах компании требовали клиенты. Увидишь там разделы про Cost Control, Schedule Management, Quality Control и т.п. - прочти их и иди искать курс по каждому - для того, чтобы хотя бы уметь поддерживать разговор с клиентами об этом "за стойкой бара". В PMP/Рите это тоже есть, но б продублировать.
Чуть позднее можно посмотреть на Школу системного менеджмента и Левенчука. Товарищи вещают иногда замудренно, но охват стандартов/методологий впечатляет - я нашел для себя несколько схем и чек-листов, полезных в ежедневной работе. В этом году у них вышел онлайн-учебник за символические тысячу рублей, рекомендую.
Добавил бы Business Development Manager с упором на поиск новых сфер развития компании. Но тут тоже, кто что подразумевает под такой позицией.
Напрашивается PMO, да. Можно тут почитать еще:
https://stratoplan.ru/blog/directions-of-manager-growth/
Думай трижды, идти или нет в ПМ, вот какой вывод. Это совсем не обязательно повышение и не единственный пусть карьеры. Ответственности больше, говорильни больше. Частое ощущение - нечего сказать про результаты прошедшей недели, хотя не поднимал головы и пахал как Папа Карло. А что сделал то? Ответил на тыщу писем? Принял 50 звонков (каждый входящий - микро-стрессовая ситуация, никто ж не звонит тебя просто похвалить и сказать, что все идет как надо)? Был на 11 совещаниях? Так себе метрики.
Сам не жалею, но понимаю и про себя хвалю коллег, которые отказались от подобных моих предложений и продолжают расти как технари.
У хорошего технаря ценность на рынке труда или на трактор куда больше. Всем нужны хорошие технари, кому нужен ПМ с улицы?
Очень редко видел выделеного человека, у которого в тайтле было "архитектор". Но я и не работал ни разу в жизни в энтерпрайзах, где они есть и не очень хочу.
А в некоторых конторах ещё есть Staff Engineer, Principal Engineer – чем они отличаются и зачем нужны?
А так вообще для большинства контор, Senior или Lead это потолок карьеры для технического специалиста. Тут ещё большой вопрос, если не хотите в менеджмент, то ещё ок просто наращивать глубину знаний и опыт.
Можно свичнуться ещё в SRE и девопсы и там жить, если пилить продуктовые фичи надоело.
Нужно ещё добавить что широко используется совмещение ролей, так что альтернативные пути развития становятся составляющими одной должности со сложным описанием.
Знаю не одну контору где Delivery подразумевает также управление командой и от этого ещё больше едет крыша так как в теории у Resource manager и Project manager разные задачи при управлении людьми. Не дай бог ещё придумают какие-то KPI.
Спасибо за крутейший материал, @Covectb_cobaka . Много полезной инфо для начинающего менеджера, понятно куда двигаться дальше. Буду изучать книги которые вы посоветовали.
Я стал Product Marketing Manager почти один в один по плану А из статьи. До этого был интернет-маркетологом 5 лет.
Все началось с разработки позиционирования продукта и с защиты этого позиционирования перед стейкхолдерами. После этого привёл первых заказчиков и внедрил систему продвижения и продаж продукта.
Параллельно помогал Product Owner искать интересные фичи, показывать их нужность для заказчика и как следствие - внедрять их в продукт.
Вместе с моим руководителем - директором по маркетингу - выстроили ожидания от моей работы. Я узнал что мне нужно сделать чтобы получить эту должность. Полгода времени и все вышеописанные действия спустя получил должность)
Как и пишет автор - менеджерской работы больше. Но руками делать свою часть все ещё нужно (настраивать рекламу, писать статьи и т.д.). И это радует =)
P.S.
Пришлось прокачать навыки управления проектами, умение проводить пре-сейлы, софт скиллс и тайм-мененджмент. Сложновато, но справляюсь.
крутая статья, спасибо!
Я правильно понимаю, что Program manager - это высокоуровневый Project Manager? Что входит в его обязанности сверх обычной для проджекта рутины? Или это те же яйца только в профиль?
приветы!
ставлю класс за очередную статью, с интересом прочитал.
на одно никак не могу найти ответ: а что по conflict resolution? то есть глобально, чья это должна быть роль, кто и как должен в этом, на твой взгляд, разбираться?
спрашиваю, потому как сам на позиции team lead/delivery manager с завидной регулярностью урегулирую конфликты между командами, особенн очасти между стримами разработки или frontend<->backend командами.
спасибо!
В копилочку книжек добавил бы «Договориться можно обо всём» и «Сначала скажите нет». Помогают как разобраться с реальными, а не озвучиваемыми, ожиданиями заказчика, так и качают скилы хреново деливерить с сохранением офигенных отношений.
И из неочевидного. Когда придёт понимание, что вся ваша команда, включая 40-летнего тимлида, — не отличается по своей внутренней мотивации от банды детей с их внутренними конфликтами, добавил бы в библиотеку «Общаться с ребенком как». Очень помогает построить правильный диалог на 1:1 .
Ну вот давайте поговорим про архитекторов. На самом деле это такой PM который как бы не PM и вообще не мендеждер (но в ряде компаний для этих людей ОБЯЗАТЕЛЬНАЯ сертификация по треку PM).
Названий у этого хоть отбавляй, но реально за ними никакого смысла. Одно и то же может значить как всё так и ничего. Поэтому пойдём просто по иерархи.
Часть времени из "закрывания тасок" уходит на то, чтобы посмотреть на них всех, увидеть общую картину и понять что в этой картине не так.
При этом эта задача не пересекается с лидом. Лид он таски распределяет, смотрит что они грамотно сформулированы, возможно следит за оценкой (опыт!) и проверяет качество исполнения. То есть лид не обязан (и чаще всего это так) видеть всю картину целиком.
В этот момент помимо всех технических скилов начинают требоваться софтскилы, так как с вашим виденьем мира многие могут быть не согласны, оно многим может быть не понятно и надо объяснить/показать/доказать что вот так реально лучше.
Вот эта точка - начало конца. :) Но вы всё ещё "закрываете таски".
Тут помимо того, что надо таски идущие в пределах одной команды грамотно пилить (то же самое что в п. 1) надо придумать как эти таски разделить между командами и как наладить "технический интерфейс" (команды между собой плотно уже не общадтся) чтобы то, что делает каждая работало вместе.
Помимо всего что требовалось в п. 1 тут появлятся требование уметь связывать между собой разные системы, причём не только "здесь и сейчас", но и через полгода-год.
Позиция "объяснить/показать/доказать" остаётся, но только уже мало кто понимает о чём идет речь. Каждый видит только свою сторону проблемы и тянет одеяло на себя. В митингах и обсуждениях проходит треть времени. Ещё треть проходит в создании проектной дкоументации и описании интерфейсов.
Но да, вы всё ещё закрываете таски.
На этом этапе вы уже представляете все модули и что они делают, представляете как это правильно мониторить, интегрировать друг с другом и офигенно лепите квадратики в Visio/DrawIO.
Треть времени всё так же встерчи и разговоры. Треть - документация и диаграммы.
Но дополнительно ко всему что было раньше к вам приходят PMы с вопросом "а сколько это будет стоить". То есть горе нетехнических людей надо будет цифрами (а это стоимость at the end of the day) обосновывать почему вот именно сейчас "лучше час потерять".
Ко всему что надо было раньше на этом этапе лучше очень хорошо уметь в оценку задач, декомпозицию их и прочие PMские фокусы.
Где-то здесь начинаются конфликты бюджетов: это либо разные департаменты с разными бюджетами, либо отдельные суб-подрядчики за отдельные деньги. Ваша задача провести оценку их квалификации (выбрать тех, кто может делать то, что надо), сформировать для них тех. требования и ТЗ. На этом этапе вы - одна из фигур "уминающих по ценам".
Сейчас, наверное, в меня полетят камни, но правило "если ты не можешь сделать какой-то элемент руками и не понимаешь как его делать, то именно в этом месте твой подрядчик тебя нае..т" оно золотое.
Это так. Даже не со зла. Это просто природа людей.
И так как PM - он больше рулить, то ты как архитектор для него глаза, уши и мерило адекватности.
На этом этапе 2/3 времени - это встречи с командами, мендежерами, подрядчиками и бесконечные разговоры и попытки состыковать это "технически". Решение конфликтых ситуаций между командами. Вдумчивый разбор почему когда всё собралось вместе ничего не работает и кто будет это править.
Ну и да. Всё ещё закрываем... эти... таски. :)
5 Ну и адище. Enterprise Architect.
У вас есть платформа на 100-150 виртуалок с 20+ клиентов которые используют её уже лет 5. Этакий PaaS
И вы мигрируете эту платформу в "multicloud". То есть развернуть "копию" в AWS, GC, Azure и уметь разворачивать это на железе заказчика не более чем за месяц.
Это всё ещё техническая роль, вы всё ещё можете каждый элемент платформы и вообще всю миграцию запилить в одно лицо. Но так как оценочная стоимость проекта где-нибудь 4000 человеко-часов, а нужен он "вот к концу года" то как бы...
Группа которая пилит каждое из решений - это несколько команд, в которых есть п. 1-3 описанные выше. Ваша задача понимать что они пилят и пытаться срастить нестыкуемое.
Ваша задача объяснить чувакам, пилящим AWS что надо поднимать свой, допустим, DNS для унификации с bare metal (они смотрят друг на друга как на гавно при этом!).
Над вами стоит Заказчик (у него сроки), владелец лавки (ты промахнулся в оценке проекта на $1M и тебя за это не любят, хотя это был изначально озвученный риск).
Это роль чисто PM. Хотя PM на этом проекте - отдельный человек. И, опять же, твоя задача объяснять ему понятным (для PM) языком почему всё так, а не иначе (а за это он будет прикрывать твою Ж и водить заказчика в ресторан из денег проекта).
Ну и да, у тебя всё ещё есть беклог и ты всё ещё закрываешь таски. :)
Ночью. Пока все спят и не задают дурацких вопросов. Вот когда east cost уже затихли, а west coast ещё не раскачались. :)
P. S. Офигеть я графоман. Это мой самый большой текст за год точно....
😱 Комментарий удален его автором...
Отличная статья, спасибо!
Могу рассказать про FB, возможно применимо и к другим большим компаниям.
Кроме Engineering Managers в разработке есть Product Managers (у нас нет), Technical Program Managers (у нас есть два на несколько команд) и возможно какие-то еще
P. S. В менеджеры пока не хочу :)
Все больше прихожу к выводу, что при уходе от ролей конечного исполнителя уходит и узкая специализация. Берем тот же тимлид роадмап: https://github.com/tlbootcamp/tlroadmap
Норм тимлид имеет какие-то компетенции в совершенно нетехнических сферах: проджект-менеджмент, продукт, и т.п. Естественно техничекое не ограничивается кодингом - хорошо бы и в админстве что-то понимать.
Аналогичное и заметно у хороших продуктологов и проджектов: умение залезть в базу и пошариться по структурам данных, хотя бы общее понимание, как нынче разрабатывается софт, насмотренность в дизайне и вот это все.
По сути, каких-то должностей и узких специализаций нет - есть роли. Сегодня можешь одну роль выполнять, завтра другую. Если хочешь ограничиваться чем-то узким и одним, то либо ты должен это знать прямо глубоко и быть самым ценным аутистом в офисе, либо будешь очередным заменяемым винтиком.
И как всегда все упирается в способность мотиироваться на всякое непрерывное образование и узнавать действительно новое независимо от лет. Open minded вот это все
Какая крутая статья, спасибо!
Понравилась идея расшифровки формулировок из резюме, теперь хочу почитать посты в таком же стиле про другие роли в ИТ и около... Если кто-то напишет или уже — киньте плз ссылкой или давайте заведем раздел а-ля "Роли/Профессии в ИТ"?
Спасибо за толковую статью!
Популярная боль с которой я сталкиваюсь как продуктоид - в компании не понимают зачем нужен проджект менеджер, и ожидают связку "продакт+проджект" в одном человеке.
Был ли у кого-то из коммьюнити успешный опыт лечения этой боли? Поделитесь плиз ;)
О, прикольно, я как раз недавно добавил себе к инженерским задачам ещё пмство на другом проекте. Ощущаю, будто взял понемного из всех трёх путей А, Б, C, ну и солидно ещё Ж от каждого. Всё осложняется тем, что я всё ещё программирую и отказываться пока не собираюсь, хотя бы потому, что это у меня всё ещё получается лучше других (жаль только скорость 1х, так что в команда всё равно нужна). Всё упрощается тем, что ещё нет детей, поэтому удаётся даже жонглировать разными хобби в свободное время. :) шило очень большое.
От себя докину простой советик: запускать пет-проекты и участвовать в хакатонах со своей идеей очень развивает навык тащить проект и учит в приоритизацию. Если добавить коммуникативных способностей – вуаля, вы новоиспечённый джуниор ПМ с горящими глазами
Как обычно, классная статья и все прям четко!
Могу немного про Delivery Manager, Implementation Manager, Change Manager и Technical Product Manager расскащать, т.к. носил все эти шляпы 🕵🏻♂️
Delivery Manager
Про это автор немного уже сказала. По собствпенному опыту, это такой немного микс проектного и продуктового менеджера. Обычно присутсвует на больших проектах. Тоже занимается сроками и задаванием неудобных вопросов. Но c более техническим бэкграундом и может говорить за команду вполне компетентно на кабах(CAB - change advisory board). Часто рабоает с вендорами. То есть руководит не своей внутреней командой разработчиков, а командой вендоров на проекте. У этой команды может быть свой менеджер. Все сложно, да. Отвечает головой за внедрение того или иного продукта на проекте.
Implementation Manager
Я так подозреваю, что в разных компаниях может быть разное определние для этой должности, да и редкий зверь это. Расскажу про себя. Я руководил несколькими командами, которые состояли из Implementation Consultants. Эти ребята - технические специалисти довольно узкого профиля. Мы внедряли наш софт заказчикам. Работа заключалась как раз в том, чтобы общаться с заказчкиами и проектными менеджерами с обеих сторон. Плюс, руководить командами и задавать им приоритеты. Я старался минимизировать общение моих ребят с заказчиками, чтобы не тратить ничье время. Так что опять требуется очень хорошее знание продукта, которое внедряешь. Плюс быть немного продажником, т.к. нужно учавствоать в pre-sales.
Change manager
Далеко не во всех компаниях такое есть. Обычно в крупных и тех, которые совмещают hardware and software changes. Например, telcos. Если вам знаком термин ITIL, то скорей всего вы знаете кто этот человек.
Предствьте, что в такой компании кому-то нужно установить новую вышку, а кто-то запускает новую версию IVR (голосовй робот, обычно отвечает вам когда в саппорт звоните), а кто-то третий пытается запустить новую капмпанию по продаже последнего айфона. И вот, чтобы все эти изменния друг другу не мешали и существует такая должность. Этот человек следит чтобы никаких изменения в компании не были сделаны без его/ее внимания. Для этого есть специальный митинг - CAB, Change Advisory Board. На этом митинге и обсуждаются планируемы изменения. И решается вопрос о том когда и как их делать. Звучит ужасно, но когда сделано ок, он скорей помогает, чем мешает. Конечно бывает и обратная ситуация.
Technical Product Manager
Про продуктовых менеджеров многие знают и некоторые даже знаю чем они отличаются от Product Owner'ов.
А вот TPM - это редкий зверь. По сути тот же продакт, но как видно из названия, с техническим уклоном. Часто с техническим бэкграундом, либо из девелоперов, либо из архитектов и иже с ними.
Обычно отвечает за технические продукты компании - APIs, Data Science-related, Machine learning, вот это все.
Бывает, что основными юзерами для этого TPM являются внутренние пользователи - те же девелоперы. Поэтому очень важно понимать что они хотят и что им надо. Например Джира и ОКР. бгг.
Бывает так, что подчиняется сразу двум C-level чувакам - CPO и CTO, отчего получает супер конфликтные запросы.
В случае, если еще и синьор-помидор, может иметь команду продактов, которая работает под его руководством, делая примерно то же самое.
Привет, я слоупок (нет, просто сначала завал на работе а потом отпуск) и добрался до комментов - я тот самый Sowtware Engineering Manager (или просто Engineering Manager который тут уже призывался). Тот опыт который я описываю характерен для больших продуктовых компаний (или тех кто думает что они такие) - всяких FAANG и так далее.
PS На вопросы обещаю отвечать оперативно.
Не знаю, насколько их пихают всем, но вот:
Это в топку переоцененных книг