Чего разработчики ждут от PM-а, а PM - от разработчиков

  • 25 мая, 09:15
  • 3953
  • 0

Что входит в обязанности Project  Manager-а и Teach Lead-а, а так же как наладить взаимосвязь внутри команды рассказывают спикеры  IAMPM Project/Product Manager Денис Шамантажи и Tech Lead Леонид Неугодников.

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

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

Чем на проекте занимается PM

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

  1. Бюджет: какое количество денег нужно потратить, чтобы разработать итерацию релиза, какую-то фичу.
  2. Сроки: насколько быстро РМ может получить нужную функциональность. В одних проектах сроки ни к чему не привязаны: можно сделать «не к среде, а к пятнице» — и ничего страшного не произойдет. В других — отношение к срокам очень серьезное, потому что даты «завязаны» на маркетинге или PR-процессах заказчика.
  3. Функциональность поставки: РМ-у нужно быстро принимать решение по функциональности, когда кто-то из владельцев или инвесторов говорит: «Делайте что угодно, но к среде мы должны уйти в продакшн».
  4. Ожидания: проектному менеджеру приходится иметь дело не только с ожиданиями заказчика, но еще и начальства и команды.
  5. Внутрикомандное взаимодействие: обеспечить эффективность и слаженность работы всех участников команды — это тоже задача РМ-а.
  6. Ресурсы: понимание, какое количество людей нужно РМ-у в каждый конкретный момент и обеспечение проекта этими ресурсами.
  7. Планирование задач: все, что касается классического Scrum-а: планирование, поставка, демо, ретроспективы. Определение ближайшего скоупа, донесение его до команды, фасилитация и минимизация рисков.
  8. Отчетность по проекту: управление документацией.

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

Что точно должен делать Teach Lead

Для лида спектр повседневных задач в команде будет намного шире, чем у разработчика. Кроме написания кода, он ответственен за:

  1. Командное code review: позволяет избежать понятия «code owner», потому что все, вовлеченные в разработку, видят код и понимают, что происходит. Если кто-то заболеет, будет проще найти замену. Именно лид отвечает за качество кода, поэтому он детально подходит к code review и решает, сколько нужно аппрувов, чтобы код ревью мог попасть в продакшн.
  2. Поддержка качества кода: с помощью code review, автоматических инструментов, которые проверяют качество кода по заданным метрикам.
  3. Планирование задач/сроков, то есть эстимейты в классическом понимании. Лиду или разработчику нужно участвовать в планировании задачи вместе с РМ-ом, потому что даже у самой простой технической задачи могут возникнуть неожиданные последствия. Лид может предвидеть потенциальные проблемы до того, как они возникнут, а без его участия на планировании может получиться решение, как в конструкторе, когда в круглое отверстие пытаются запихнуть треугольник.
  4. Выбор технологий/архитектуры: из чего будет состоять приложение, как будут взаимодействовать его компоненты.
  5. Согласование технического взаимодействия: Tech Lead решает, когда фича считается готовой к тестированию, что именно должны проверять QA, какие компоненты кода обязательно покрывать юнит-тестами.
  6. Менеджмент технического долга: Техдолг — это решение, которое сначала работало хорошо, но сейчас его нужно править, потому что оно не подходит к текущему состоянию проекта. Технический долг появится в любом случае, это просто этап развития, следствие того, что код пишут люди. Поэтому, одна из задач лида — это менеджмент техдолга на проекте.
  7. Распределение задач: кроме того, что нельзя сваливать серьезные задачи на джуна, есть еще понятие экспертизы: лид знает, кто в команде лучше работает с платежными системами, кто больше понимает в обработке картинок, кто лучше разбирается с техдолгом — и соответственно распределяет задачи.
  8. Поддержка климата в команде: наряду с РМ-ом, лид взаимодействует с участниками команды разработки и следит, чтобы всем было комфортно работать, никто не остался без внимания.
  9. Интервью потенциальных сотрудников: каким бы опытным не был рекрутер компании, именно лид — тот человек, который задаст нужные технические вопросы соискателю и примет окончательное решение — насколько новый сотрудник впишется в команду.

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

Чисто технические вещи РМ не заберет, но зато может: взаимодействовать с командой, распределять задачи внутри технических команд, поддерживать внутренний климат, взять на себя часть активности по подбору кандидатов на вакансию.

Как РМ-у ставить задачи разработчикам

Чтобы разработчики правильно поняли задачу и выполнили ее хорошо, важно не просто «как-то описывать» требования, а учитывать несколько условий. Так проще работать всем, и процесс создания продукта движется быстрее.

Что должно быть в задаче, чтобы разработчик делал работу с энтузиазмом и пониманием:

  1. Тело задачи — это самый важный пункт. Когда РМ говорит, что задача — «Поменять цвет кнопки на экране», то разработчику непонятно: «На какой цвет поменять, на каком экране, какой кнопки?» Тело задачи должно быть исчерпывающим, включать definition of done или сценарии, которые отличают выполненную задачу от невыполненной. Четкие критерии позволят понять, что задача выполнена, причем, выполнена правильно.
  2. Сроки — на когда должна быть сделана задача.
  3. Приоритеты — понимание того, в каком порядке разработчику нужно делать ежедневные задачи.
  4. Взаимодействие с остальными участниками команды — бэкенду важно понимать кто будет разрабатывать фронтенд на этой фиче, чтобы обсудить и понять, как склеивать работу в целом.
  5. Понимание смысла задачи. И лид, и разработчик способны понять потенциальные проблемы и риски фичи, которых не видит бизнес. Поэтому всегда нужно доносить до разработчиков смысл задачи: какую потребность бизнеса или проблему пользователя решает продукт. Иначе можно получить пару багов, которых можно было бы избежать с самого начала при должной коммуникации.
  6. Буфер времени на баги/инфраструктуру. Люди ошибаются просто потому, что они — люди, поэтому баги появятся в любом случае — это неизбежный процесс разработки. РМ-у нужно предусматривать запас времени на устранение багов.
  7. Прозрачность процесса. Одна из самых важных вещей. Если представить стандартную доску в Jira, в которой тикеты двигаются слева-направо, то процесс абсолютно прозрачный. А если процесс не очень красиво настроен, тогда в rework могут прилетать тикеты трехмесячной давности без какого-либо описания. Такой процесс —непрозрачный, и разработчику непонятно, как адекватно работать с задачами.

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

У опытного РМ-а есть два статуса: обычный и важный (задача вне очереди). Когда все задачи в high-приоритете, то происходит обесценивание, потому что не верится, что все сразу может быть срочным.

Что РМ-у и разработчикам нужно понимать из области знаний друг друга

Какие знания разработчиков важно понимать РМ-у

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

На первом проекте никто не будет требовать от менеджера досконального знания разработки. А вот дальше, чтобы управлять результативно, РМ-у все-равно придется разобраться в том, что ведомо разработчикам.

Что обязательно знать:

  1. Технологии — то, с чем непосредственно работает команда: например, Android или IOS-разработка.

Если менеджер понимает базовые нюансы, предметно разбирается в происходящем, то ему не надо объяснять почему, например, в push-уведомления нельзя поместить какую-то возможность или почему нельзя сделать торрент-трекеры на IOS.

  1. Риски и ограничения технологий: какое решение можно выполнить, а какое — нельзя.

Когда РМ понимает технологии — это приносит несколько преимуществ:

  • понимание, правильно ли разработчик дает эстимейт;
  • минимизация рисков, потому что РМ способен оценить какие-то технические нюансы уже на этапе согласования;
  • способность РМ-а самостоятельно обсуждать с заказчикам будущие фичи снимает лишнюю нагрузку с разработчиков.
  1. Версионность и как все устроено под капотом: РМ-у не нужно глубокое знание на техническом уровне, а просто на концептуальном. Понимание для чего использовать разные версии или как приложение взаимодействует с сервером, помогает РМ вникать в суть работы и звучать убедительно в разговоре с девелоперами.
  2. Общая инфраструктура: что такое «клиент-серверы». Почти все в современной разработке — это «клиент-серверы». РМ-у нужно знать, что «клиент» — это все, что видят пользователи, например, мобильное приложение, браузер или гаджет с программным обеспечением, а сервер — это какое-то удаленное место, где происходит большая часть логики, взаимодействия с пользователем и направления пользователя внутри приложения.
  3. Зоны ответственности каждого участника: если РМ разберется, кто что умеет и где чья ответственность заканчивается в технической команде, это поможет снизить число конфликтов: РМ будет понимать, например, стоит ли приходить к разработчику с проблемами пользовательской логики и другими вопросами.

Что обязательно знать разработчику из того, что знает РМ

  1. Как работает процесс: какие шаги проходит фича от инициирования до попадания к пользователю.
  2. Как менеджер оценивает работу: помогает понять, как быть эффективным и по каким метрикам РМ считает разработчика клевым и полезным.
  3. Для чего нужны митинги: какие проблемы РМ пытается решить текущими митингами (то есть, понимать цель).
  4. Какие проблемы решает продукт или конкретная фича: вообще для кого она делается.

Три совета РМ-у как подружиться с командой разработки

Менеджмент стресса

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

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

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

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

Решение конфликтов

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

Важно, чтобы разработчики всегда понимали, что можно сказать: «Я устал — помоги мне», или «Я хочу в отпуск», а не полагались на то, что РМ читает мысли и сам догадается о проблеме.

Понимание ценности задачи

Любой участник команды будет негодовать, если видит, что пишет «в стол», неважно: интерфейс, код или что-то еще. Понимание, какую выгоду приносит твоя конкретная задача, очень повышает продуктивность.

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

Краткие итоги:

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

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


Теги: project manager pm
0 комментариев
Сортировка:
Добавить комментарий