Из программистов в менеджеры: как и зачем. Vol.2
Менеджеры, которые выросли из программистов, тестировщиков и других технических специалистов, рассказали DOU, почему они выбрали именно такой путь развития, как обучались и чем принципиально менеджмент отличается от инженерной работы.
Мы собрали много интересных историй менеджеров, поэтому вслед за первой частью публикуем вторую.
Евгений Власюк, Delivery manager в EPAM Ukraine
ЕРАМ — мое первое место работы. До него у меня был опыт научно-технических разработок при университетах. Сотрудничая с компанией более 6 лет, я прошел все позиции от Intern до Team lead.
Последние 1,5 года выполняю обязанности Delivery Manager. До того как стать DM, я работал тимлидом на Financial Services проектах. Занимался всеми уровнями девелопмента, которые только возможны, начиная с фиксирования багов и заканчивая проектированием архитектуры проекта, на котором работаю сейчас — это структура, дизайн, разработка с нуля. То есть полный спектр всех необходимых действий для успешного стартап-проекта.
На решение развиваться как менеджер повлияли сразу несколько факторов: это возможность более тесного контакта с клиентами, расширение зоны ответственности за весь проект, возможность прочувствовать все составляющие проекта, начиная от People management и заканчивая риск- и релиз-менеджментом. Delivery позволяет «заглянуть» во все уголки проекта и использовать разнообразный набор инструментов для его развития.
Значительно расширяется кругозор, ты не фокусируешься на чем-то одном и постоянно учишься новому.
О переходе. За 6 лет в ЕРАМ я работал на 4 проектах, на последнем проекте изменилась моя роль. Переход от тимлида к DM был постепенным и органичным. Это не произошло за один день. Я рос вместе с проектом. У нас численно увеличилась команда, стали поступать новые задачи от клиента, соответственно, начали появляться новые вызовы для delivery.
Об отличиях в работе. Для DM важны управления проектами и людьми, понимание архитектурных принципов, но самое главное — соблюдение разумного баланса в применении всех перечисленных скиллов. Конечная цель — это довольный клиент.
Безусловно, разница между тимлидом и DM есть. Во-первых, тимлид больше концентрируется на управлении командой и работе с людьми для достижения поставленных задач. Если говорить про наш текущий проект, мы начинали одной командой, но на данный момент это 4, а иногда и 5 команд. Реальный вызов для delivery — это синхронизировать работу всех команд между собой и сфокусировать их на достижении глобальной цели, но при этом сохранить автономность работы.
Вторым существенным отличием является степень ответственности DM. Ты должен понимать проект шире, но уровень погружения не должен становиться меньше.
На позиции тимлида мне нравилось, что была возможность и время «закопаться» вглубь конкретной части проекта, разобрать ее по косточкам. На позиции DM работать над чем-то конкретным и сосредотачиваться на чем-то одном — это непозволительная роскошь. Некоторые рекомендуют выделять, например, час времени и заниматься какой-то одной задачей. Часто приходиться отвлекаться на разные ситуации, но при этом помогать другим членам команды быть сфокусированными на более глубоких вещах.
В моем арсенале есть скиллы проектного менеджмента: могу переиграть планы, передоговориться с клиентом. Повлиять на архитектурное решение, например, что-то упростить. Могу задействовать People management скилы. Работу DM можно сравнить со швейцарским раскладным ножиком: у тебя есть многофункциональный набор инструментов, какой из них применять прямо сейчас — зависит от тебя.
Об обучении. Мне очень помогли внутренние образовательные программы ЕРАМ. Я принимал участие в Team Lead Grow и Managers’ Mentoring Program.
Дополнительно занимался самообразованием. Вот некоторые книги, которые я рекомендую: «Principles: Life and Work» Рэя Далио, «Delivering Happiness: A Path to Profits, Passion, and Purpose» Тони Шея, «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения» Тома де Марко и Тимоти Листера.
С чего начать? Самое главное — это желание и отсутствие страха проявлять инициативу. Старайтесь выходить за рамки своей зоны ответственности, смотреть на задачи шире. Если вы Back-end разработчик, посмотрите, как устроен DevOps. Если вы Front-end — интересуйтесь, как устроен сервер. Если вы тимлид — применяйте практики проектного менеджмента.
Вы должны быть экспертом в своей области, но нужно постепенно расширять свои профессиональные горизонты. Delivery manager не будет настолько хорош в архитектуре проекта, как Solution architect, но знания позволят ему говорить с командой на одном языке.
И, конечно, важна работа с людьми — people management. Больше общайтесь с коллегами. Они такие же, как и вы.
Нужен ли менеджеру технический бэкграунд? Однозначно нужен. Он позволит легко общаться со своей командой и быть с ней на одной волне. Исключит ситуации, когда менеджер обещает клиенту сделать невыполнимые вещи.
В общении с клиентом технический бэкграунд — это возможность продемонстрировать свою компетенцию и предложить грамотное решение. Оно не обязательно должно содержать описание технических деталей, важно на уровне архитектуры показать свое понимание технологий и бизнеса.
Евгений Васьковский, Project Manager в Astound Commerce
Мой профессиональный путь начался еще со студенческой скамьи, и он не был полностью связан с IT-индустрией. Около пяти лет я работал системным администратором, затем следующие пять лет — QA и QA Team Lead.
Наконец, последние четыре года занимаю должность PM-а в винницком офисе Astound Commerce.
Решение развиваться как менеджер происходило под влиянием различных факторов. Среди основных «за» были:
- необходимость адаптировать процессы разработки под текущие потребности отдельно взятого проекта;
- желание развиваться как специалист дальше в высоком темпе;
- возможность «свичнуться» и продолжить карьеру в пределах той же компании.
О переходе. Мой переход из QA Team Lead в Junior PM происходил в виде цепочки собеседований, нацеленных в основном на оценку soft skills. Считаю, что мой предыдущий опыт сыграл большую роль в развитии коммуникативных навыков, организаторских способностей и командной игре, что так необходимо для работы проектного менеджера.
Об отличиях в работе. Если сравнивать работу QA и PM, то принципиальная разница состоит в том, что проектный менеджер фокусируется на синергии с проектом и отождествляет свои цели и задачи с проектными. Изменяются масштабы осмысления деятельности — как своей, так и командной. PM выходит за рамки нужд департамента к программным и портфельным целям.
Что касается недостатков, у менеджеров больше бюрократических элементов в работе.
Об обучении. Я изучал теоретическую основу (PMBoK, материалы на PMI) всего того, с чем приходилось сталкиваться. Также очень сильно помог недельный курс от Влада Березина, который организовывала компания для всех сотрудников PMO (Project Management Office) приблизительно в самом начале моей РМ-ской карьеры.
К тому же на момент моего «свитча» уже существовал PMO со своим рабочим SDLC (Solution Development Life Cycle). Поэтому, приступив к работе, я имел возможность пользоваться уже существующими наработками, шаблонами, процессами и опытом всех проектных менеджеров компании.
На мой взгляд, вот необходимая база для будущего РМ-а:
- PMBoK;
- корпоративные стандарты и наработки, best-practices;
- развитая коммуникация, навыки переговоров, бизнес-переписка, хороший уровень английского и прочие soft-skills;
- доменные знания;
- общее развитие в смежных и не очень областях.
Нужен ли менеджеру технический бэкграунд? Тут не может быть категоричного и однозначного ответа. С одной стороны, PM может опираться на мнение экспертной группы, специально созданной для оценки доменной области, недоступной для менеджера. Это позволяет сосредоточиться на управлении проектом.
С другой стороны, если у PM-а есть технический бэкграунд, то он может принимать быстрые решения касательно проекта, иметь интуитивное ощущение происходящего.
Дмитро Ярмак, Release Train Engineer в SimCorp Ukraine
Ще під час навчання в університеті я майже рік працював інженером на одному великому державному підприємстві. Як мене вистачило майже на рік? Не знаю, напевно, коли молодий, то дуже витривалий :) Після цього потрапив до SimCorp, починав як девелопер фінансового ризик-менеджменту на APL та С#.
За 10 років у компанії я працював у чотирьох відділах на п’яти різних позиціях: розробник, тестувальник, тімлід, менеджер і зараз Release Train Engineer.
Остання позиція немає нічого спільного з потягами (майже) :) У Scaled Agile Framework (SAFe) ця роль нагадує Delivery Manager або Scrum Master of Scrum Masters. Зараз я відповідальний за delivery десяти Scrum-команд: чотирьох у Києві, п’яти у Копенгагені і однієї у Бад-Хомбурзі (Німеччина). Ці команди об’єднані у Agile Release Train, який є окремим value stream нашого продукту.
Можливість спробувати себе у нових ролях і є головною причиною, чому представник Generation Y залишається у компанії так довго.
Пам’ятаю, як свого часу складно було вирішити, чи продовжувати розвиватися як програміст, чи спробувати себе у leadership. Напевно, те, що це було щось нове, і вирішило долю. Таким чином, на керівнихпозиціях я працюю з 2012 року.
Зараз я анітрохи не шкодую про свій вибір. Я розумію: щоб стати гарним лідером, треба дуже багато працювати над собою і постійно вдосконалюватися. Мені подобаються складні виклики, і в leadership цього вистачає. Культура лідерства в Україні, на жаль, у багатьох компаніях автократична, і багато лідерів не можуть перелаштуватися на новий час і нові покоління робітників.
Про перехід. Мій перехід у менеджери відбувся з позиції тімліда — у тій самій компанії, де я вже працював 4 роки. Це був відкритий процес, де всі охочі могли спробувати свої сили. Я спробував, і данський керівник вирішив, що в мене є потенціал бути лідером. Так у 28 років я став Group-менеджером.
Про відмінності у роботі. Як я вже казав, мої задачі в компанії більше відносяться до позиції Delivery Manager. У процесі розробки ПЗ ми використовуємо Scaled Agile Framework, який передбачає самоорганізаційні та самодостатні Scrum-команди. І такий самий принцип застосовується до лідерських команд. Немає боса, який скаже, як тобі працювати. Натомість на всіх нечисленних ієрархічних рівнях є команди, які приймають рішення.
Принципова різниця між програмістом і лідером у тому, що лідер є набагато більш залежним від інших, ніж від себе. Несучи відповідальність, ти маєш два шляхи, як здобути рівновагу: хибний і правильний. Хибний — намагатися все контролювати, вимагати звіти, брати участь у прийманні якомога більше рішень тощо. Дуже швидко ти стаєш лідером, який гальмує увесь підрозділ, який дуже заклопотаний і не має часу на прийняття швидких, я вже не кажу правильних, рішень.
Є правильний шлях — будувати своє лідерство на принципі довіри. Розуміти, що найкраще місце для прийняття рішень там, де відбувається робота, здебільшого на рівні команд. Будувати лідерство на принципі прозорості, де інформація доступна і зрозуміла, де не потрібно витрачати час на нескінченні звіти і комунікацію непотрібної інформації.
Іншою принциповою різницею між програмістом і лідером є час збирання врожаю. Час на те, щоб лідеру побачити результати своєї роботи, є значно більшим. Для мене не бачити результати зразу, як коли ти виправив баг або зробив нову функціональність, було дуже великою і важкою зміною. Але з часом ти розумієш, що в тебе інший тип завдань і вони потребують більшого часу на виконання.
Про навчання. На мене книги мають більший вплив, ніж курси. Можу порадити стару і гарну «7 Habits of Highly Effective People» Стівена Кові, «Turn The Ship Around» Девіда Марке, «Good To Great» Джима Колінза, «The Phoenix Project» Джина Кіма, «The Five Dysfunctions of a Team» Патріка Ленсіоні, «The Soft Edge: Where Great Companies Find Lasting Success» Річа Карлгаарда.
Також раджу відвідувати конференції, спілкуватися, ділитися досвідом. Наприклад, київські друзі зі ScrumGuides проводять дуже якісні курси, конференції та інші заходи.
З чого починати? Почитайте про Servant Leadership. Також необхідно опанувати Agile-методи розробки та принципи Lean.
Чи потрібен менеджеру технічний бекграунд? Відповідь залежить від контексту компанії та позиції. Але я вважаю, що так. Технічний досвід — це великий плюс. Це не означає, що ви повинні бути експертом, але ви повинні розуміти, про ще йде мова.
Николай Ткач, Project Manager в KeepSolid
До того как перейти в менеджеры, я чуть больше года проработал на позиции QA, в том числе 11 месяцев в компании KeepSolid.
Все это время меня не покидало чувство, что я могу быть полезен компании, управляя проектами. Поэтому решил попробовать себя в менеджменте.
Как PM работаю уже в общей сложности полтора года.
Об отличиях в работе. На первый взгляд, принципиальной разницы между позициями QA и PM нет. Есть определенная, достаточно высокая ответственность перед компанией и командой за работу, которую выполняешь, и решения, которые принимаешь. Не важно, на какой позиции ты работаешь, всегда важно оставаться командным игроком.
Об обучении. У меня начиналось все стандартно. Закончил курс по управлению проектами. Читал PMBoK, «Сто правил руководителей проектов NASA» Джерри Мэддона, «Критическая цепь» Элияху Голдратта, «Deadline. Роман об управлении проектами» Тома ДеМарко.
На самом деле освоить идеально эту специальность, как и любую другую, как мне кажется, невозможно. Всегда необходимо впитывать новые знания. Благо, сейчас в интернете достаточно много блогов и полезной информации на эту тему.
С чего начать? Прежде всего, задайте себе вопрос — зачем вам это нужно? Если ответ появился сразу и он звучит убедительно — значит, можно приступать к постижению этой специальности.
Стоит понимать, что, управляя проектами, придется много общаться с людьми, задавать вопросы и не всегда с первого раза получать на них необходимые ответы, решать конфликты и т. д.
Что касается книг, в них много полезного, но книга никогда не заменит живого общения. Посещайте профильные мероприятия, мероприятия связанные с дизайном, контентом, маркетингом, общайтесь с коллегами и не бойтесь задавать вопросы.
Нужен ли менеджеру технический бэкграунд? Технический бекграунд поможет PM-у как минимум быть на одной волне с разработчиками, а также правильно собирать требования у так называемых стейкхолдеров и формулировать их команде.
Анатолий Кочетов, Delivery Director в Sigma Software
Еще в университете я начал карьеру как своего рода фрилансер: делал на заказ лабораторные, курсовые и дипломные работы :)
На втором курсе один из преподавателей меня заметил и предложил присоединиться к компании, в которой он был учредителем и руководителем. Так я стал Junior разработчиком. Писал сначала на C++ и Delphi, после на C# — освоил его дома в свободное время на pet-проектах.
Со временем дорос до позиций тимлида, а затем стал заместителем директора по разработке. Основная особенность небольших компаний — возможность совмещать много ролей сразу и пробовать себя в разных областях. Так случилось и со мной: я получил хороший опыт и в разработке, и в проектном менеджменте, и в кризис-менеджменте — как в плане развития команды, так и управления ею.
Затем я перешел в Sigma Software на позицию руководителя проектов, которая включала в себя полную ответственность за весь проект и его аспекты, удовлетворенность клиента, стейкхолдеров, команды. Это подразумевало вовлечение в весь цикл от А до Я, когда необходимо погружаться в разбор проектной ситуации достаточно глубоко. В 2009 году я стал менеджером Microsoft Solutions департамента, а в 2017 перешел на позицию Delivery Director.
Я не уверен, что мой выбор развиваться как менеджер был осознанным. Скорее, у меня неплохо получалось планировать и организовывать работу, помогать коллегам быть эффективными, и такой работы мне поручали все больше. Я видел в этом вызов и постепенно пробовал — хотя уставал от этих задач в разы больше, чем от работы с кодом. Со временем, правда, привык и начал получать кайф от работы именно с людьми — коллегами, клиентами. Для меня менеджмент — это в первую очередь люди.
О переходе. Изначально я перешел в рамках одной компании. Это были кризисные
Помню, что проходя собеседование в Sigma Software (тогда еще Eclipse SP), я ощущал странное чувство, когда непонятно, кто кого больше интервьюировал :) Но в итоге я был приятно удивлен вопросами, которые мне задавали, и понял, что хочу руководить проектами именно в этой компании. Здесь я получил совсем новое понимание международного проектного менеджмента. Это была новая планка, к которой нужно было тянуться.
Об отличиях в работе. В рабочих обязанностях и необходимых навыках менеджеров и разработчиков есть как пересечения, так и отличия. К примеру, руководители деливери работают с требованиями, SDLC, рисками, качеством ПО, метриками, строят коммуникаци, управляют ожиданиями, имеют экспертизу в коучинге, найме, командообразовании, психологии, переговорах.
В то же время эксперты в архитектуре и инженерии фокусируются на языках программирования и технологиях, но также обучают коллег, участвуют в найме и, в зависимости от позиции, много работают и ведут переговоры с клиентом, пусть и в более инженерных областях.
Если сравнивать позиции разработчика и руководителя, то, как говорил Uncle Ben, «With great power comes great responsibility» :) Это важное отличие. Необходимо помнить и оценивать, насколько человек кайфует от ситуаций, в которых есть факторы неопределенности и большая ответственность за принимаемые решения. Это также характерно и для architect-позиций: ответственность за решения очень высока и порой на кону сотни тысяч долларов.
Об обучении. Я читал книги и применял написанное на практике — исходя из собственного понимания своих недостатков и слабостей, и на базе обратной связи коллег и руководителей. Также наследовал их опыт и подходы. Иногда посещал профильные конференции, но PM-курсы никогда не проходил.
С чего начать? Если вы думаете о карьере PM, то, прежде чем выбирать это как постоянную роль или позицию, попробуйте PM-ство в качестве «пилота». Часто люди представляют себе ежедневную работу PM-а совсем не такой, какой она оказывается на самом деле. Новые знания, конечно, полезны, но инвестировать большие деньги и время в получение управленческих навыков и понять позднее, что это не твое — не самый лучший опыт.
Лучше поговорить со знакомым руководителем за обедом, узнать, чем он занимается каждый день, какие трудности преодолевает, какие навыки использует. Спроецируйте это на себя, убедитесь, что это действительно могло бы быть интересно.
Затем попросите в рамках текущего проекта дать вам ответственность за полный цикл, скажем, одной feature: выяснение требований, дизайн, координация работы front-end, back-end, контроль качества, демо и так далее. Постепенно можно развивать квалификацию, шаг за шагом получать и закреплять новые знания и опыт, приходить в PM постепенно — от ответственности за одну фичу к ответственности за все более крупные команды и проекты. Инкрементально-итеративно :)
Есть мнение, что руководители проектов обязательно зарабатывают больше, чем сотрудники на инженерных позициях. Это чаще заблуждение, чем реальное положение вещей. Потому самое важное — понять, где вы применяете свои сильные стороны больше всего и от какой работы получаете удовольствие. Деньги придут, когда, занимаясь любимым делом, вы станете экспертом.
Нужен ли менеджеру технический бэкграунд? Не обязателен, но в современных реалиях рынка труда, очень желателен. Знаю массу примеров, когда руководители без технического бэкграунда выполняют проекты высочайшей технической сложности, так что такой бэкграунд — точно не главное и не панацея.
Главное помнить, что руководитель без технического опыта нуждается в проверенных квалифицированных инженерах в команде. Если таких нет, то в совокупности с отсутствием понимания инженерных практик и принципов у руководителя это может оказаться рецептом катастрофы.
Когда же технический бэкграунд есть, то руководитель в определенных ситуациях может и заметить потенциальную проблему, и сгенерировать полезный совет в технической сфере, и сделать квалифицированное ревью оценки. Но даже в этом случае, все же, конечное решение того или иного инженерного вопроса должно быть принято архитектором или командой.
