Как развивается карьера Project Manager в IT: масштаб от S до XL

Моя менеджерская карьера в сервисной IT-индустрии развивается уже более 10 лет. В 2007 году, оставив опыт разработки позади, я пришел в GlobalLogic на позицию Junior Project Manager. И за это время мне довелось руководить командами от двух человек до двух сотен специалистов из разных уголков мира.

В этой статье я бы хотел наглядно продемонстрировать, как происходит эволюция от первого ко второму. Какие зоны ответственности появляются у менеджера по мере роста, какие исчезают? Каких ошибок на этом пути важно избежать? По ходу повествования мы сделаем 4 остановки, которые обозначат уровни scale (масштаба), характерные для менеджерской карьеры в крупной международной IT-компании.

Масштаб S

Вы — начинающий менеджер. Ваш первый проект уже укомплектован, так что вам, вчерашнему разработчику и новообращенному руководителю, повезло прийти «на готовое»: контракт подписан, команда собрана, процесс запущен.

Вы попадаете в небольшую комнату с командой из 5 разработчиков и 3 тестировщиков, постепенно погружаетесь в проект. И сразу чувствуете два сильных полюса притяжения — клиента, который (почти) всегда прав, и команду, авторитет в которой ещё придётся заслужить.

Умение находить баланс между их интересами становится вашей главной задачей. Это мастерство вы оттачиваете день за днем, стараетесь как можно больше коммуницировать и с клиентом, и с командой, чтобы принимать верные решения.

Вы максимально сконцентрированы на текущих задачах и сроках их выполнения, чувствуете ответственность за каждый этап, и поэтому часто вкладываетесь в проект плечом к плечу с командой. Пишите или проверяете код, собираете требования или тестируете. Благо, ваши инженерные навыки еще совсем свежи в памяти, и это всё ещё приносит проекту больше пользы, чем вреда :)

Масштаб M

Поздравляем! Ваша команда зарекомендовала себя с наилучшей стороны, сотрудничество с клиентом дало несколько новых проектов, и теперь вы руководите целой программой.

Круг ваших обязанностей расширился, и на первый план выходит управление приоритетами. Привлечение новых людей в команду и их ротация между проектами становится привычным делом, а муки выбора — наиболее часто испытываемой эмоцией. Например, есть проект, с которого вы начинали и где остались сильные личные связи с членами команды. А есть другой, который попал к вам сравнительно недавно. И хочется отдать все самое лучшее своему «первенцу», но бизнес-приоритеты уже могут быть другими. И если раньше вам как-то удавалось совмещать рабочие задачи, но при этом оставаться «своим в доску», то сейчас всё чаще и чаще ваши решения будут непопулярными. Хотя бы для кого-то. И личная дистанция с командой (к сожалению!) начнёт понемногу расти.

Если на предыдущем этапе контракт с клиентом был подписан до вас, то теперь, с каждым новым проектом, вы все больше привлекаетесь к обсуждению вопросов соглашений.

Раньше вы, положа руку на сердце, управляли лишь сегодняшним днем и старались сделать так, чтобы хорошо было прямо сейчас. Но на масштабе M начинаете осознавать, что (почти) все проекты имеют свое начало и конец. Так что приходится все чаще больше задумываться о том, какой выхлоп они дадут в будущем, чем о насущных вопросах.

Масштаб L

Вы отлично справились с этапом M, так что переходите на следующий уровень — руководство поручает вам еще пару клиентов.

Чем раньше была компания для вас? Местом, куда вы приходили каждое утро, вашим проектом, вашей командой, клиентом, с которым вы всегда на связи. Да, вы давали себе отчет о том, что в компании много заказчиков (могли даже перечислить топ-5 названий и почти без ошибки сказать, кто чем занимается), но это понимание было где-то на периферии сознания. Теперь же, когда клиентов несколько именно у вас, картина мира выглядит совсем иначе.

К балансированию между интересами команды и клиента добавляется третий полюс — компания. Именно сейчас вы отчетливо ощущаете, что работаете на компанию, а не на клиента. А для компании все, что вы делаете в рамках взаимодействия с вверенными вам клиентами — это бизнес. Так что к вашим задачам прибавляется финансовый менеджмент, и фактор прибыльности начинает играть все большую роль в том, какие решения вы принимаете при формировании команд.

Догма о том, что клиент всегда прав, как никогда начинает подвергаться сомнению. Вы сравниваете клиентов и видите, что чем выше стратегическая важность заказчика, тем выше степень гибкости при работе с ним и тем больше ему разрешается. Ведь это вклад в долгосрочное сотрудничество, в то время как небольшой проект вряд ли сможет приносить завтра больше, чем сегодня. Внутренний голос всё чаще спрашивает: «Зачем?». В контексте «зачем это нашей компании?».

Раньше у вас даже не возникало мысли, что для клиента можно что-то сделать бесплатно (а что, и так можно было? о_О). У вас, скорее всего, даже не было таких полномочий, но сейчас понимаете, что это далеко не конец света. Вовлечь дополнительных людей на проект, приобрести программно-аппаратное обеспечение за счет компании, вложиться в разработку инновационных прототипов (когда двое инженеров в течение нескольких месяцев будут пилить proof-of-concept, и в перспективе это может перерасти в отдельный проект). Вы делаете первые инвестиции.

Масштаб XL

Один из ваших проектов достигает такого масштаба, что всю команду для клиента уже нецелесообразно держать в рамках одного города или даже в рамках одной страны. Вы становитесь руководителем распределенной многонациональной организации, и это совершенно новый виток вашего карьерного роста. К слову, IT-индустрия — чуть ли не единственная отрасль, позволяющая занимать позиции такого уровня, не покидая родной город в Украине.

В вашей повестке дня появляется межкультурное взаимодействие. Например, бросается в глаза, что понятие «good enough» в некоторых странах может иметь совершенно другой смысл, чем для украинских разработчиков (которым этот «good enough» приходится потом переделывать). Или вот неготовность людей из Западной Европы работать в неурочное время (следствие норм трудового законодательства, крепко меняющее привычки людей), хотя у нас гибкий график (овертайм перед важным релизом, отдых после) часто воспринимается как стандарт.

В то же время вы замечаете, что многим украинским специалистам очень характерен defensive mindset. Этот подход проявляется в нежелании взять на себя лишнего и идти на риски (а если и идти, то все просчитать). В условиях глобальной конкуренции он может приводить к потерянным возможностям. Все эти культурные различия вы ощущаете на собственной шкуре. Вы стараетесь переводить свою неосознанную некомпетентность в осознанную, чтобы эффективно руководить процессом и предвосхищать возможные проблемы.

К вашим обязанностям добавляются операционные моменты обеспечения рабочего процесса. Нужно арендовать офис в Сиэтле для наших ребят? Сделаем! В Бангалоре пропала сеть, есть ли там запасной канал? Узнаем! Нужно перед релизом прогнать систему на всей линейке от Apple, где взять устройства? Найдём! Поменялось законодательство Европейского Союза в сфере информационной безопасности, как это нас коснётся? Переживём! :) Большая часть ежедневных задач уходит от исполнения (execution) к рецензированию, утверждению, консультированию (review, approval, advisory). Вы концентрируетесь на старте новых направлений, формулировании стратегических целей и работе с управленческой структурой.

На этом этапе размер вашей организации становится настолько большим, что команда в том смысле масштаба S перестает быть полюсом притяжения в вашей картине мира. Когда команда переваливает за 100 человек, половину людей вы можете даже не знать по имени :( Остается только клиент и компания, которую вы представляете.

Несколько мыслей напоследок

Очевидно, что масштаб организации, которой вы управляете, постепенно растет — а это и есть ключевое мерило seniority и maturity менеджера. В то же время с каждым этапом меняются фокусы вашей ответственности.

Роль клиента присутствует всегда, вне зависимости от scale. Потому что клиент — это всегда важно. А вот роль компании на первом этапе отсутствует вовсе, но постепенно набирает обороты. Чего нельзя сказать о роли команды в изначальном понимании — индивидуальный подход к каждому участнику можно обеспечить лишь на небольшом масштабе. На первый план выходит ваша менеджерская команда.

Ведь как ни крути, чем выше уровень менеджера, тем реже ему приходится напрямую работать с каким-то отдельным аспектом жизнедеятельности организации. Если мы соберем области ответственности менеджера из всех 4 этапов, то получится достаточно длинный список. В то время как область, на которой менеджер может детально фокусироваться, ограничена. С ростом масштаба, мы можем наблюдать два тренда. С одной стороны, менеджер не стоит на месте в плане своего профессионального развития, работает над собой и расширяет рамки зоны своей фокусировки. С другой, фокус-зона движется от частного к общему, от конкретики к абстракциям. Поэтому для синьор менеджера важно это осознавать и выстраивать под собой управленческую структуру, способную подхватить те области ответственности, которые со временем выходят за рамки его прицельного внимания.

Одна из ключевых задач синьор менеджера — выращивать людей. И это не просто альтруизм или вклад в новые поколения, а конкретная бизнес-задача. Это помогает растить бизнес, за который вы отвечаете, и самому расти дальше, выше. Вперед и вверх!

IT-индустрия в Украине продолжает набирать обороты, предлагая отличную платформу для профессионального развития не только в инжиниринге, но и в менеджменте — особенно в международных компаниях. И XL — далеко не последний размерчик. Only sky is the limit! :)

LinkedIn

43 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хорошая статья! Без «воды» и легко читается. Спасибо автору.

Спасибо за отзыв! Я рад, что вам понравилось.

Хорошо написано! Было интересно почитать. Согласен с мыслями автора. Хорош менеджер тот, что хорошо выполняет свои обязанности на проекте, а лучший менеджер тот, который умеет выстраивать процессы и делегировать свои обязанности и доверять!

Интересное изложение мыслей, мне понравилось и нахожу в них смысл. Единственное, что я бы не привязывал действия к размеру жестко. Например, cross-cultural может быть и есть в S\M размере. В целом, было интересно, спасибо :)

Спасибо за отзыв, Тарас! Я рад, что вам понравилось.
Вы правы, может быть по-разному. В статье изложен мой личный опыт, пусть и слегка генерализированный.

Ольга, срібної кулі, на жаль, не запропоную. Декілько порад я давав у коментарях нижче. До цього можу додати один конкретний приклад, про який мені відомо.

Підприємець, з багаторічним менеджерським досвідом в іншій індустрії, вирішив «увійти до IT». Прийшов на співбесіду до великої IT компанії, і каже: «візьміть мене на ЗП в 1 грн на перші 12 місяців, дайте мені ментора та якісь не дуже ризиковані внутрішні проекти, я не підведу». Його взяли. План спрацював, навіть швидше, ніж через рік він вже отримав звичайну менеджерську позицію в компанії.

Хорошее изложение! Единственный вопрос — следует ли продолжать такую позицию в аутсорс-компаниях называть Manager?

Позвольте высказать мнение ...

По сути, в подавляющем большинстве случаев аутсорсеры фактически не управляют проектами заказчика (в каноническом понимании). Не управленют бюджетом заказчика, не принимают решения по scope заказанного продукта, не принимают финальные решения о достаточности уровня качества, не управляют бизнес рисками — все это в основном остается на стороне заказчика.

С другой стороны, у аутсорсера, как у коммерческой организации, есть свой интерес по ходу реализации проектов заказчика. Как минимум — заработать (деньги, репутацию, опыт, и т.д.) на таком предоставлении услуг определенного уровня качества (не путать с качеством продукта в проекте заказчика) за определенную стримость. Именно этим — поставкой услуг — такие менеджеры и управляют. Является ли это управлением проектом? По моему мнению — нет, не является.

Delivery Manager, по моему, более подходящий термин для чистых менеджеров в UA аутсорс-индустрии. А термин PM пора убирать из лексикона :)

Антон, вы правы. Если речь идёт о «классическом» аутсорсинге, аутстаффинге (и других секторах ресурсного експорта).

К счастью, украинский IT в целом и отдельные компании в частности активно уходят в сторону более комплексных моделей, способных генерировать больше пользы клиентам. Ярким примером, к которому нужно стремиться, являются случаи так называемой Digital Transformation, когда заказчик приходит с запросом вида: «Я знаю свою отрасль, свой рынок, но ничего не понимаю в IT. А вот вы — эксперты. Трансформируйте, пожалуйста, мои продукты (или даже всю мою компанию) в Digital плоскость. Любыми способами. Сами назовите сроки. Сами назовите цену.» И вот здесь, я вас уверяю, менеджеру есть, где разгуляться :) И называйте его тогда хоть PM’ом, хоть DM’ом.

Здравствуйте.

Из личного опыта могу добавить что в компаниях созданных под продукт, Масштаб S будет очень похожим. Но также будет доступ к менеджменту той же компании, который принимает решения о бюджете, объеме работ, и берет на себя управление рисками проекта. Владельцы и менеджмент компании будут выполнять роль «клиента» для менеджера масштаба S.

Масштабы M и L будут сильно отличаться от описанных в статье, поскольку даже очень большой и успешный продукт может развиваться и поддерживаться сравнительно небольшим IT-отделом. Фокус может постепенно смещаться из разработки продукта в поддержку пользователей и небольшие проекты по интеграции с партнерами. А проектная организация работы совмещаться с процессной деятельностью.

Если продукт ориентирован на массовый рынок, то у руководителя команды/отдела разработки масштаба M/L появятся новые «типы» клиентов в лице отделов Sales, Marketing, Customer Support, Accounting etc. А также несколько «коллективных» клиентов в лице разных групп пользователей.
Владельцы компании перестанут выступать в роли «клиента», и появится понятие «интересы компании», которое раньше было равно «интересам клиента». Менеджмент компании, в зависимости от условий контракта, может как выступать на 100% представителем владельцев, так и представлять еще один тип «внутреннего» клиента.
В то же время менеджмент компании будут выполнять роль ... менеджера масштабов M/L в вопросах контрактов, P&L и стратегического видения. А руководитель команды/отдела разработки будет заниматься бюджетом (своего отдела), рисками, приоритетами, ресурсами, развитием команды и ... контрактами и P&L меньшего масштаба. Также, могут сформироваться в отдельные команды/отделы IT/DevOps и Technical Support.

Если продукт ориентирован на внутренние потребности компании, то фокус и области ответственности руководителя IT-отдела будут еще сильнее отличаться от того, что описано в статье. С ростом IT-отдела и/или бизнеса все может как меняться каждые пол-года, так и не меняться много лет подряд. Разработку могут приостановить, отменить из-за замены на уже готовое внешнее решение, или передать в аутсорсинг другой компании. При подобных изменениях руководитель может встать перед выбором — покинуть компанию (развивая экспертизу руководителя проектов в IT), либо полностью изменить свой профиль и позицию (применяя и развивая экспертизу в конкретном виде бизнеса).

Масштаб XL в компаниях ориентированных на продукт (или к этому этапу — уже линейку продуктов и несколько видов бизнеса) обычно слабо связан с IT даже для позиций CIO/CTO. И полный переход на этот уровень в реалиях Украины — скорее исключение, чем типичный путь развития. Типичный путь — это сразу с позиции менеджера/владельца стартовать свой бизнес, или перейти в другую компанию на этапе стартапа или создания IT-отдела. А это уже совсем другая история :)

Как видим, отличия от описанной модели развития — значительные. И позиция Project Manager, в ее классическом понимании, также не на 100% отражает суть работы руководителя среднего и высшего звена в таких компаниях.
Так кого же ищут рекрутеры в Украине, открывая вакансии Project Manager? :)

Спасибо за отличный комментарий, Артур! Так как моя карьера развивалась именно в сервисном IT, то и мысли изложены в статье через эту призму. Я согласен, что в продуктовой компании или в IT отделе не-IT компании история будет развиваться по-другому.

На вопрос, кого ищут рекрутеры, открывая вакансии «Project Manager», думаю, лучше всего ответят рекрутеры. :) От себя могу добавить, что на моей практике рекрутеры сами ничего не открывают — они работают с теми вакансиями, которые открывают менеджеры. А вот менеджеры как раз и ориентируются по каким-то объективным и субъективным шкалам: в какой компании мы работаем (продуктовая, сервисная...)? на какой масштаб мы нанимаем менеджера (S, M, L, XL...)? какая специфика того проекта/продукта/клиента/отдела, в который мы нанимаем менеджера (больше упор на технологии, на клиента, на команду) — сейчас и на перспективу? И такие шкалы/срезы можно добавлять бесконечно — до необходимой детализации требований к вакансии и ожиданий от кандидата.

Когда вакансию Project Manager открывают в небольшой компании, или для нового отдела, обычно ищут первого IT-ориентированного руководителя. И делают это либо владельцы/руководители компании, либо HR/рекрутеры компании, либо рекрутеры из агентства.
Собственно вопрос теоретически может быть задан им (что я и делал на собеседованиях).

В моем ответе на DOU этот вопрос — скорее итог нашего с вами описания пути развития руководителя в IT компании.

Возможно DOU станет первым ресурсом, на котором эта тема станет причиной переименовать

Посада: Project manager

на что-то более точное.

И я смогу описывать свою специальность более точно, не отвечая на дополнительные вопросы, и попадая в результаты поиска :)

Отличная статья!
Немного дополню о том, что независит от размера проекта: баланс между интересами клиента, компании и команды надо всегда соблюдать. Клиент хочет заплатить меньше, компания заработать больше, а команда интересный и «удобный» проект. И всегда есть риски и надо, подобно канатоходцу, соблюдать баланс.
Если команда распределенная — то менеджеру в нагрузку добавляются дополнительные вопросы для решения и изменение коммуникации с командой. Хорошо, если все ребята легко идут на контакт, помогают друг другу и являются отзывчивыми. Но мы то знаем, что это не так ;)
Как по мне, сложнее всего балансировать в стартапах с распределенной не сработавшейся командой. Тут и ограниченные ресурсы, и разность культур, отсутствие полного (визуального) контакта, дополнительные риски (землетрясение — нет света, надо перекидывать работу на других членов команды или искать замену, на крайний случай — перевозить разработчика в более безпасное место), давление сроков и качества. Короче, полный букет :)

было интересно — без воды, популизма и самопиара. добавки!

Спасибо! :) Рад, что понравилось. Как соберусь с мыслями ещё на какую-нибудь стоящую тему, обязательно напишу ещё.

Спасибо, очень оптимистичная статья о росте management maturity, а вот о теме: от

И личная дистанция с командой (к сожалению!) начнёт понемногу расти.

до

Остается только клиент и компания, которую вы представляете.

говорить, как правило, не принято на столько открыто.

Интересно, в таком ходе вещей есть риски или альтернативы? И не противоречит ли эта линия утверждению, что

Одна из ключевых задач синьор менеджера — выращивать людей. И это не просто альтруизм или вклад в новые поколения, а конкретная бизнес-задача. Это помогает растить бизнес, за который вы отвечаете, и самому расти дальше, выше. Вперед и вверх!

?

Спасибо за отзыв! Постараюсь ответить на вопросы по-порядку.

Есть ли риски и альтернативы росту личной дистанции с командой?
Альтернатив нет. Все менеджеры по мере роста с этим сталкиваются. Рано или поздно. Есть, правда, те, кто этого не осознаёт, и тешет себя иллюзиями. Остальные осознают, и учитывают этот фактор в работе.
А вот риски есть. Основной риск — это как раз не отловить момент разрыва и/или не смочь вовремя аккуратно подменить личные связи профессиональными взаимоотношениями. Ведь поначалу личный контакт очень помогает выполнять менеджеру его работу — со многими можно полюбовно договориться — является одним из опорных столпов. Так вот не стоит допускать ситуации, когда этот столп из под вас выбьют (а рано или поздно это случится) неожиданно для вас, стоит готовить альтернативную опору заблаговременно: профессиональные взаимоотношения вместо личных, здоровый нетвёркинг вместо кумовства, источники авторитета через знания и навыки и т.п.

Как выращивать, развивать людей под собой, если личная дистанция растёт?
Во-первых, личная дистанция с инженерной командой растёт действительно быстро, а вот с менеджерский (джуниор и мидл менеджеры, которые подотчётны вам) — не так. Именно они в какой-то момент и становятся той самой командой, которую очень важно растить и развивать. Во-вторых, для того, чтобы еффективно выращивать команду в профессиональном плане, хорошие личные отношения не обязательны (не путать с хорошими рабочими отношениями): достаточно умело владеть такими инструментами, как обратная связь, коучинг, делегирование и 1-он-1 встречи.

Во-вторых, для того, чтобы еффективно выращивать команду в профессиональном плане, хорошие личные отношения не обязательны (не путать с хорошими рабочими отношениями): достаточно умело владеть такими инструментами, как обратная связь, коучинг, делегирование и 1-он-1 встречи.

Я предполагал, что SPM уже не занимается 1-он-1 встречами с разработчиками, для этого есть «рядовые» PMы. И Ваше утверждение

Когда команда переваливает за 100 человек, половину людей вы можете даже не знать по имени :(

вполне коррелирует с моим предположением.
Тогда что Вы вкладываете в идею выращивания команды, не применяя это к менеджерской команде? Я предполагал, что идея выращивания разработчиков также делегируется от SPM к PM. Я не прав?

Дмитрий, я имел в виду как раз выращивание менеджерской команды. И поэтому 1-оn-1 встречи, обратную связь, коучинг и делегирование я относил именно к менеджерской команды.

С другой стороны, если все вышеперечисленные инструменты использует старший менеджер, то эта практика так или иначе каскадируется ниже. Не стоит забывать и о skip-level 1-оn-1 встречах. Всё это хотя бы косвенно, но способствует росту разработчиков.

Но в первую очередь, опять же, я имел в виду менеджерскую команду.

Я понял. Спасибо за развёрнутый ответ!

Only sky is the limit! :)

Хорошо сказано!

Спасибо! Я рад, что вам понравилось :)

Порадьте матеріали для розвитку в цьому напрямку.

Читать книги : )
Джеф Сазерленд — Scrum
Том Демарко «Deadline. Роман об управлении проектами»
Эти маст рид :)

Джеф Сазерленд — Scrum

Сомнительной ценности книжка, как и методология.

Том Демарко «Deadline. Роман об управлении проектами»

Классика, но немного устарела.

Потрібно бути конструктивним : )
Що порадите Ви?

Что по вашему мнению проджект должен прочесть?)

Дедлайн для понимания, на то она и классика

Можу сміливо порадити такий ресурс: www.manager-tools.com/manager-tools-basics
На цьому порталі можна знайти корисні матеріали як для початківців, так і для досвідчених менеджерів.

Ицхак Адизес — «Идеальный руководитель. Почему им нельзя стать и что из этого следует»
Очень помогает общаться с другими менеджерами, что между прочим очень важная часть работы менеджера.

«Leading the Leaders» тоже интересная.

Підкажіть будь-ласка, а які поради по зміні профілю діяльності в напрямку проджект-менеджера? Які навички потрібні?

Добрый день Ольга, «в общем» такой список будет не релевантен. Всё зависит от Компании, Проекта, и т.д.
В нашей компании существует возможность роста, план которой составляется совместо с people partner-ом и текущим менеджером.
По моему личному убеждению, нельзя стать менеджером не имея соответствующего бекграунда или опыта, т.е. перейти из медицины в IT и стать менеджером.

А если из бэкграунда только 11 месяцев работы арт проджект менеджером в ооочень маленькой компании? Каковы шансы попасть хотя бы на джуниора в большую? К сожалению слышу на собеседованиях о том, что да Вы перспективны, но к сожалению нам нужны уже готовые люди, которых не надо учить, при этом сами говорят, что не берут меня из за отсутсвия опыта в крупных компаниях, а набраться опытаможно только поработав в крупной компании. Какой — то замкнутый круг получается.

Анастасия, менеджеры в IT — по определению, достаточно немногочисленная группа. Примерно каждый десятый. Возможно, даже реже. Поэтому спрос (количество открытых вакансий) относительно невысокий, часть вакансий многие компании закрывают изнутри, а если учесть некоторую кажущуюся статусность этих позиций, то конкуренция между соискателями достаточно серьёзная. В общем, удачно пройти собеседование часто сложно, достойных кандидатов хватает. С другой стороны, любой контекст общения работодатель-соискатель — это переговорный процесс, в котором важно свои слабые позиции компенсировать сильными. Вы слабую сторону своей позиции знаете — это уже по дела! «Да, мне не хватает опыта в крупной компании, но я настолько хочу к вам попасть, что... моя мотивация позволит мне работать с двойной отдачей; я готова на время испытательного срока получать 50% зарплаты, только дайте мне шанс; моя теоретическая подготовка компенсирует нехватку практического опыта — озадачьте меня, я найду выход из любой ситуации!» :)
В общем, не вешайте нос, не занимайте позицию жертвы, ищите вакансию мечты, а когда найдёте, хватайтесь за неё изо всех сил! Удачи!

Junior PM. К сожалению такой позиции не существует. А если таковое и присутствует, то скорее всего это завуалированный ТимЛид с некими задачами ПМа. И да, полностью поддержу Виктора, эффективнее вырастить внутри чем брать с рынка.
Мой совет прост — смотрите в сторону Продуктовых компаний и не больших. Там проще и опыта наберётесь, а может случится, что Вам и не понравится.
И напоследок, будте готовы к дауншифтингу...

Спасибо, учту! Джуниор идет как бы помощником, но во многих офисах его требования на уровне Проджекта.

В том-то и соль, что в тру ИТ простой координации мало. Работа с пресейлами это существенная часть работы ПМа и каждый раз дёргать уважаемых девелоперов будет крайне сложно, так что нужно быть готовым отвечать на вопросы хотябы верхнеуровнево и знать экспертизу.

Ольга, на це питання дійсно складно відповісти конкретно без детального спілкування з вами. Наприклад, корисно було б знати, який у вас профіль зараз, який попередній досвід, які сильні та слабкі навички?

Серед базових навичок я б зробив наголос на:
* Коммунікації (з командою, з клієнтом). У командних видах спорту є такий термін «vocal leader» — той, кого на майданчику добре чутно, хто голосніше усіх підказує, що кому робити. Без цього менеджеру буде важко (не неможливо, але важко). Навички публічних виступів я би також сюди відніс.
* Прийняття рішень (у будь-яких ситуаціях). Є безліч різноманітних підходів, як приймати вірні, зважені рішення в умовах великої (або навпаки, недостатньої) кількості інформації — хтось це робить через потужний аналітичний апарат, хтось — через призму багатого життєвого досвіду, хтось — через жіночу інтуїцію. Важливо зрозуміти ваш власний підхід, і розвивати його.

Дуже дякую за розвернуту відповідь. Цікавить можливість з менеджерським досвідом перейти саме в ІТ. Тобто наскільки менеджерські навички ІТ відрізняються від загальнопринйнятих. І якщо це можливо, що б ви порекомендували для початку?

Ольга, якщо ми говоримо про сильного досвідченого професійного менеджера, але з не-IT сфери, то перехід в IT, звичайно, можливий. Основна складність — підтягнути знання, розуміння, а краще навіть практичній досвід у питаннях власне розробки програмного забезпечення: технології, платформи та напрямки, процеси розробки, тестування, гнучкі та не дуже підходи, інструменти розробки та керування, конфігурація та деплоймент — перелічувати можна довго, все ж таки ціла професійна галузь сформувалась. Як вже писали вище, джерел теоретичних знань зараз дуже багато: оффлайн та онлайн курси, книги, статті та т.п. Але так чи інакше треба після теорії або паралельно з теорією набувати практичні навички, а для цього знадобиться багато наполегливості та трошки удачі: треба знайти таке місце, де допоможуть, підкажуть, і щось невеличке навіть довірять. Мені відомі такі випадки як у великих, так і в маленьких IT компаніях.

дуже вдячна ще раз за відповідь. Це саме те, що мене цікавило. Будемо пробувати!

це оте, що я запитувалась вище. В мене 12 річний досвід керування як від начальника відділу так до директора компанії (в підпорядкуванні до 30 ти людей). Але цього, нажаль замало навіть для найнижчого рівня РМ, наскільки я розумію. Саме собою, вражають перспективи ІТ галузі, і хочеться зібратися з думками і зробити крок вперед

Подписаться на комментарии