Как оценить качество работы руководителя продуктовой команды?

Product Owner, Product manager, Project manager и иногда даже Team Lead — вот как в разных компаниях называют руководителей продуктовых команд. В учебниках даны точные различия между этими ролями, которые на практике соблюдаются лишь некоторыми крупными компаниями. В остальных случаях роли и обязанности будут перемешены.

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

В его задачи входит создание и развитие продукта, в его ответственность входит все, что связано с этим продуктом. Такая вот роль в коллективе.

А теперь представьте, что вы являетесь руководителем управления и у вас в лидировании находятся 15 руководителей продуктовых команд. Как сравнить их между собой? Кто лучше справляется с возложенными обязанностями, а кто хуже?

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

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

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

У руководителя продукта достаточно много власти, стоимость одного месяца ресурса команды часто составляет от 2 миллионов до 5 миллионов рублей. В год соответственно от 24 до 60 миллионов. И от того, насколько грамотно вы установите приоритеты разработки, зависит стоимость фич и их экономическая эффективность.

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

Переводя все задачи команд в Kanban доску можно увидеть следующую картину. В столбце в работе находится очень много задач, все усердно работают, я бы даже сказал зашиваются. И вот спринт подходит к концу и что мы видим? Задачи как были в статусе: «в работе», так там и остались.

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

Что же делать?

В первую очередь руководитель продукта должен следить на дейли за тем, чтобы на исполнителе не находилось больше двух задач одновременно. Это увеличит сфокусированность участника команды, а его труд будет легко контролировать руководителю. Поверьте, лучше 2 выполненные задачи за день, чем 5 невыполненных.

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

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

Еще важным аспектом является количество переделок. Особенно это характерно для работы дизайнеров. Руководитель продукта обязан максимально точно описывать свои пожелания к задачам, тратя на описание много времени, чтобы не допускать 5 или 6 итераций решения задач исполнителем. Никому не приятно, когда его результат работы постоянно просят переделать. Постарайтесь свести количество правок максимум к 1 или 2 итерациям. Если итераций больше — значит руководитель продукта плохо отработал.

Здесь все довольно просто. Многие руководители команд не знают, что стоимость подбора нового it специалиста часто превышает 400 тысяч рублей. Период адаптации обойдется компании в кругленькую сумму, потому что результативного нового специалиста крайне низка.

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

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

А как вы оцениваете труд руководителей продуктов? Как сравниваете их между собой?