IAMPM
ул. Успенская, 44 65000 Одесса, Украина
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club

От I-shaped до X-shaped: как рынок заставляет PM-ов эволюционировать

9 июня 2020

  • Автор: Виктория Бобро

  • Сложность: норм

  • Время: 6 мин

Если РМ хочет качественно руководить проектом, недостаточно развивать только «вертикаль» управленческих навыков, оставаясь I-shaped. Чтобы профессионально расти и быть востребованным на рынке вакансий, РМ-у нужно изучать смежные «горизонтальные» области: в первую очередь, процесс разработки, то есть, становиться T-shape. 

Дальше менеджер проекта может эволюционировать в настоящего профессионала — X-shaped управленца, эксперта в двух и больше областях, который знает, как обеспечить нужное качество продукта в рамках бюджета и дедлайнов. 

X-shaped — это не очередной «модный» термин, а конкретное требование рынка к кандидатам выше junior project manager. В статье рассказали как пройти путь от I-shaped до X-shaped специалиста. 

I-shaped — управленческие навыки

От I-shaped до X-shaped: как рынок заставляет PM-ов эволюционировать 1

Буква «I» в слове I-shaped означает глубокую экспертизу в управлении проектом. I-shaped менеджер умеет мотивировать людей, знает как построить взаимодействие в команде, отследить эффективность работы и поддержать каждого в профессиональном развитии. 

Фундаментальные требования к тому, чтобы прокачивать I-shaped вертикаль — это лидерские качества, развитые навыки коммуникации, а также способность к анализу, планированию и оценке:

  1. Лидерство. Способность мотивировать людей и руководить командой, а не просто контролировать ход проекта. Лидер думает о долгосрочной перспективе и концентрируется на стратегических целях, стремится управлять так, чтобы команда вдохновлялась самостоятельно делать правильные вещи.
  2. Коммуникация. Одна из главных целей общения — убедиться, что стейкхолдеры и проектные команды точно понимают происходящее, знают об ожидаемых результатах или ключевых требованиях. 
  3. Ведение переговоров и разрешение конфликтов. Умение договариваться помогает согласовывать сроки и результаты со стейкхолдерами, привлекать дополнительные ресурсы, мотивировать команду работать усерднее. Лица, заинтересованные в проекте, часто хотят противоположных вещей, поэтому так ценится способность РМ-а находить компромисс. 
  4. Планирование и контроль. Умение анализировать, оценивать, составлять план и контролировать выполнение, помогают РМ-у отслеживать цели и ход проекта, от начала до завершения. План показывает — что делать, а контроль — насколько хорошо команда это делает и что изменить, чтобы сделать еще лучше. 

РМ с развитыми менеджерскими навыками умеет управлять:

  • документацией: договора, деловая переписка, отчетность по проекту;
  • ресурсами: людьми, финансами, временем;
  • управляет коммуникацией: с клиентами и с командой;
  • ходом проекта: от инициации до завершения;
  • рисками и зависимостями;
  • развитием и мотивацией людей в команде;
  • конфликтами и переговорами. 

Мало кто из РМ-ов приходит в первый проект с готовым набором навыков, обычно нужные скилы приобретаются постепенно, через опыт других и собственные шишки. Можно прокачивать I-shaped экспертизу быстрее, и учиться более системно при участии ментора на проекте или на курсах с практическими заданиями

Менеджеру в IT недостаточно только управленческой составляющей, ведь без понимания процессов разработки, трудно общаться с командой, и ставить задачи технарям. Поэтому для каждого I-shaped менеджера в IT наступает время «подтягивать матчасть» и становиться T-shaped. 

T-shaped — T means Tech 

От I-shaped до X-shaped: как рынок заставляет PM-ов эволюционировать 2

У Т-shape менеджера уже не один, а два вектора развития: Вертикальный — это экспертиза и компетенция в управленческой сфере. Горизонтальный — знания и навыки в других областях. Чем более развиты оба вектора, тем выше ценность РМ-а на рынке.

Как приобретаются T-shape skills? Помимо выполнения основных рабочих обязанностей, РМ-у нужно интересоваться смежными сферами, чтобы, как минимум, быть на уровне при общении со специалистами. 

Например, менеджер не из IT-сферы, придя в IT, по-прежнему хорошо владеет навыками управления и построения команды. Но каждый раз, когда I-shape РМ сталкивается с необходимостью понять, что происходит у ребят, найти общий язык с разработчиками, у него возникают сложности в общении.

Если РМ не вникает в технические детали, он может даже не осознавать, что проблема существует. Например, заказчик выбрал неподходящие технологии, и команда пытается обсудить это с менеджером, но для РМ-а слово «заказчик» звучит как синоним слова «закон», с которым ничего нельзя поделать. 

Чтобы доказать свою точку зрения, разработчику придется потратить много времени, долго спорить и приводить аргументы, а это приносит дополнительный стресс команде и не добавляет хорошего отношения к РМ-у. 

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

Сигналы, что пора прокачивать техническую экспертизу: 

  • На все вопросы заказчика у PM-а один ответ: «Сейчас уточню у команды». Хорошо, если на проекте все общаются в чате, и можно спросить быстро, а не «делать умное лицо» и говорить: «Интересный вопрос, я чуть позже на него отвечу, мы, кажется, что-то подобное делали».
  • Трудно объяснить клиенту, чем одно решение выгоднее другого или что делают разработчики для решения задач заказчика. 
  • РМ часто ошибается, адресуя задачу не тому специалисту, потому что слабо понимает, кто за что отвечает в команде. 
  • Для принятия решений постоянно нужны чужие знания. Если у РМ-а нет экспертизы в разработке, может помочь привлечение тимлида на общение с заказчиком или на собеседование. Но что, если тимлид занят или заболел? Тогда РМ-у придется краснеть на встрече, потому что он не может ответить на технические вопросы. 
  • РМ неправильно эстимейтит: сложную техническую задачу обещает решить быстро — и срывает сроки, а на простую — отводит лишнее время, потому что не понимает, как работают технологии на проекте. 

Если появляются подобные сигналы, значит пора приобретать новые знания. Три первых шага для наращивания экспертизы:

  • Начинайте с терминологии. Изучайте технический словарь. Когда программистам не приходится отдельно «переводить» что-то РМ-у, коммуникации ускоряются, а отношение команды меняется в лучшую сторону. Понимание технического глоссария, базовой терминологии нужно не только для общения с командой. РМ — тот человек, который закрывает коммуникационный разрыв между бизнесом и разработкой, может объяснить технические детали заказчику на простых примерах: «на яблочках» или «на котиках». А для этого, нужно самому знать глоссарий.
  • Разберитесь, как выглядят термины на практике. Изучение словаря — это начало, а дальше надо понять суть терминологии. T-shaped PM знает не только названия методов, но и сколько времени понадобится, чтобы имплементировать определенную методологию в проект. 

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

Для этого есть методология — test-driven development — разработка через тестирование. Это способ, когда девелоперы сначала пишут тесты, а только потом — код, который этими тестами будет проверяться. Процесс кажется запутанным, зато с точки зрения менеджмента, такой способ дает уверенность, что тесты будут написаны обязательно. 

  • Приходите на технические собрания. РМ на встрече — не просто пассивный слушатель — он инвестирует время в команду: записывает, задает уточняющие вопросы, и старается понять, как все происходящее повлияет на проект. Во время общения девелоперы часто поднимают вопросы, которые позже менеджеру нужно обсудить с заказчиком. Если РМ будет улавливать суть проблемы, просто слушая диалог разработчиков на собрании, то команда будет очень благодарна, что не нужно вторично объяснять вопрос менеджеру. 

О базовой технической экспертизе для РМ-ов понятно и с примерами рассказал Tech Lead Леонид Неугодников на dou.ua.

X-shaped — качество в любых обстоятельствах

От I-shaped до X-shaped: как рынок заставляет PM-ов эволюционировать 3

Когда менеджер прокачал I и T-shaped скилы, появляется возможность расти дальше — развивать экспертизу в двух и больше смежных областях. Конечно, понимание процессов разработки увеличивает шансы найти хорошую работу, но техническая экспертиза — это уже must have для менеджеров в IT. 

Заказчикам и компаниям нужнее X-shaped специалисты — те, кто умеют анализировать рынок, работать с требованиям и поставлять качественный продукт

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

Конечно, выявлять требования — это задача бизнес-аналитика, только часто бывает так, что вакансия ВА на проекте не открыта, и эту роль выполняет РМ. И в этой ситуации, чтобы правильно понимать стейкхолдеров, приоритизировать клиентские запросы и проектировать под них решения, X-shaped менеджеру не обойтись без практических знаний бизнес-анализа. 

РМ с пониманием бизнес-анализа:

  • умеет не только выяснить, но и правильно зафиксировать требования заказчика с помощью техник документирования, таких как user story и use cases. 
  • знает, как создавать наглядные модели решений, использует базовые инструменты для прототипирования. 
  • понимает, как работать с требованиями разных уровней детализации: от самых общих пожеланий заказчика до конкретных запросов к воплощению решения в продукте. 
  • владеет разными техниками по сбору требований (например, интервью, наблюдение, workshop, мозговой штурм). 

Знание и бизнес-анализа, и разработки помогают РМ-у быть связующим звеном между клиентом и командой: С одной стороны, РМ может превратить слишком общие требования заказчика в конкретные задачи для девелоперов. С другой — сумеет на понятном языке объяснить клиенту, чем заняты технические специалисты. 

При налаженной работе с требованиями повышается и качество продукта. И если для управления командой РМ-у нужны развитые управленческие навыки, то для оценки качества понадобится еще и понимание процессов тестирования. Потому что, даже в успешном растущем проекте качество может сильно снизится, если у РМ-а недостаточно развиты X-shaped скилы.

Заказчики относятся к вопросам качества достаточно требовательно,  и частый запрос от компаний — это менеджер с пониманием QA, способный наладить контроль и поставить нужное качество продукта. 

X-shaped PM не пишет тесты, зато умеет:

  • построить работу с качеством, даже если в проекте нет тестировщика;
  • знает как собеседовать QA и собрать команду под конкретную задачу;
  • понимает, как управлять качеством через метрики; 
  • поддерживает нужный уровень качества, даже если проект быстро растет. 

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

Вместо вывода

Способность управлять проектами включает разные навыки: экспертность в домене, лидерство, планирование, разрешение конфликтов, управление людьми, знание смежных областей. 

X-shaped РМ — это человек, который всегда будет востребован, потому что научился сочетать управленческую экспертную часть с техническими и аналитическими навыками. 

Новичок в менеджменте проектов сможет пройти путь до X-shaped, если реально оценит собственные компетенции, запланирует, какие скилы нужно развивать — и начнет работать над ними уже сегодня.

 

 

 

Виктория Бобро

Виктория Бобро

Копирайтер IAMPM. Пишет тексты, боится разговаривать с незнакомыми людьми и предпочитает судить о качестве материалов по статистике в Google Analytics.