что такое продуктовая команда
Продуктовая команда
Сегодня постараюсь рассказать, что такое продуктовая команда. Ее состав и роли, на примере большой организации.
ПРОДУКТ — Предмет, являющийся результатом человеческого труда (книжн.).
В IT — продукт это программное обеспечение решающее какие-то задачи или потребности.
Отличие продуктовой команды от сервисной
Сервисная разработка заканчивается после запуска проекта.
В продуктовой разработке после запуска происходит анализ обратной связи, генерация новых идей. За тем цикл повторяется вновь, и длится это бесконечно.
Состав команды
В зависимости от специфики продукта состав команды может меняться. Чаще всего в команду входят Владелиц продукта, Аналитик, Разработчики, Дизайнер, Тестировщик.
Давайте рассмотрим каждого из них и поймем чем они занимаются.
Задача Владельца продукта вести разработку в нужном направлении. Формулировать потребности пользователя, изучать обратную связь и формулировать задачи для команды, расставлять приоритеты и помогать команде выполнять свою работу в максимально комфортных условиях.
Составляет Бэклог Продукта.
В некоторых случаях владелиц проводит командные ритуалы, такие как дейли, ретроспективу и планирование.
Продуктовый аналитик — должен уметь работать с данными. Чем больше данных, тем выше вероятность принять правильное решение. Для этого необходимо изучать метрики, строить воронки, следить, к каким результатам приводят малейшие изменения.
У дизайнера в команде бывает несколько задач. Проектирование взаимодействия пользователя с системой и отрисовка ui компонентов. На этапе проектирование, он плотно взаимодействует с аналитиком, создает UX карты, вайрфремы сценариев. За тем они превращается в полноценные макеты и связываются в прототипы. После тестирования и доработки, макеты передаются разработчикам
Разработчики это те люди которые превращают идеи и картинки в рабочее приложение с которым в последствии взаимодействует пользователь. Обычно разработка разделяется на серверную и фронтальную часть.
Серверные разработчики пишут программно-аппаратную часть сервиса. Работа с базой данных, API.
Frontend разработчик отвечает за визуальную часть сервиса, с которым взаимодействует пользователь.
В продуктах для мобильных платформ это часто бывает один и тот же человек.
Тестировщики люди которые отвечают за то, чтобы новый код работал корректно и решение соответствовало поставленной задаче, чтобы не было пропущено ни одного запланированного сценария и чтобы после внедрения новых частей кода, старые оставались в рабочем состоянии.
Ритуалы
В зависимости от принятых в компании метод управления проектами в продуктовых командах проводят свои ритуалы. В нашем случае это дейли, ретроспектива и планирование.
Дейли — проводится каждый день, на нем каждый член команды рассказывает что было сделано вчера и что планируется к исполнению сегодня. Цель мероприятия не контроль исполнителя, а своевременное выявление осложнений и выработка решений.
Ретроспектива — встреча команды в конце каждого спринта для улучшения совместной работы. На ней участники обсуждают, хорошо ли они взаимодействовали между собой. К концу встречи участники составляют план улучшения работы для внедрения в следующем спринте.
Планирование — это встреча для определения цели и объёма работы в будущем спринте. На ней обсуждают, в каком направлении развивать продукт и сколько задач взять в спринт, чтобы к этому прийти. Благодаря встрече они чётко представляют, что и как улучшить в продукте.
Chapter
Когда в компании несколько продуктовых команд, одинаковые роли из разных команд образуют чаптер.
Из этих сотрудников выбирается чаптер лидер, который несет ответственность за консистентность и за то, как именно будут решаться те или иные задачи в командах. Так же чаптер лидер устанавливает иерархию и ответственен за развитие членов чаптера.
Вся нагрузка ложится на него в дополнение к той которую несет на себе каждый участник чаптера.
Tribe
Когда в компании много команд и подразделений коммуникация между ними может стать проблемой. Здесь и возникают Трайбы.
Трайб — это совокупность команд объединенных одной миссией.
Трайбы координируются Лидером трайба, который выступает гарантом того, что знания и понимание является общим, управляет приоритетами и распределяет бюджет. Лидер так же обеспечивает взаимодействие с другими трайбами компании.
Сервисные команды
Иногда для эффективного выполнения работы команде не нужна на постоянной основе какая-то роль. Например один дизайнер, в состоянии обслуживает 4–5 команд, но в этом случае не может полноценно участвовать в жизни команды. Такие роли исключают из продуктовой команды и образуют из них сервисную структуру, которая берет заказы от продуктовых команд. Часто бывает что такими командами являются аутсорсовые ресурсы.
Работа с продуктовой командой
Продолжаем серию статей для быстрого погружения в продакт-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь — первая часть третьей лекции в формате для чтения. Педагог — Андрей Попов, директор по информационным технологиям в 12 STOREEZ.
Кто нужен в продуктовой команде помимо продакта
Количество человек в продуктовой команде зависит от размера компании и сложности продукта, который она разрабатывает. Рассмотрим, какие специалисты входят в неё практически всегда.
Проджект-менеджер. Контролирует работу команды, следит, чтобы задачи выполнялись вовремя. Не генерирует гипотезы.
Back-end разработчик. Создаёт всё, что не видит и напрямую не трогает пользователь: связку полей формы регистрации и корзины, интеграцию с платёжным шлюзом, автоматические письма, подгрузку и обновление контента.
Front-end разработчик. Разрабатывает пользовательский интерфейс (вывод результатов поиска, форму ввода данных, корзину и т. д.). Делает так, чтобы сайты и приложения выглядели одинаково на различных устройствах.
Аналитик. Собирает у пользователей продукта информацию о фичах, которые нужно разработать, и оформляет в техническое задание для программистов. Сокращает неопределённость для команды.
Тестировщик. Всесторонне тестирует продукт. Помогает убедиться, что система ведёт себя корректно на всех этапах пользовательского пути.
Дополнительно в команду можно пригласить продакт-оунера, scrum-мастера и бизнеса-аналитика. Продакт-owner (владелец продукта) управляет созданием продукта и отвечает за то, что получится в результате. Scrum-мастер анализирует, как устроены процессы в команде, делит большие задачи на более мелкие и улучшает рабочие процессы. Бизнес-аналитик определяет слабые места бизнеса, помогает выстроить и развернуть инфраструктуру продукта.
Стоит отметить, что во многом судьба проекта и его команды зависит от основателя. Представьте: у человека компания с оборотом в полмиллиарда рублей в год. Если завтра здание, в котором он арендует офис, сгорит вместе с серверами и бумагами, а сотрудники уволятся и уедут жить на Гаити — он воссоздаст свой бизнес. Снова соберёт команду, разовьёт идею, накидает бизнес-гипотезы и помчит. Каждый основатель должен быть именно таким или стремиться к подобному уровню.
Виды продуктовых команд
Продуктовые команды бывают двух видов: Growth Hacking и Core.
Growth Team — это команда роста, которая отвечает за тестирование гипотез и развитие продукта. В неё обязательно входит front-end разработчик и дизайнер, а управляется она напрямую продакт-менеджером.
Основные задачи команды Core — поддерживать продукт в стабильном рабочем состоянии и внедрять в продакшен уже протестированные гипотезы. В Core Team входят все специалисты, которых мы перечислили выше, а управляет ей руководитель разработки (Engineering Lead).
Работа продакта с командами
Чтобы продакт мог эффективно работать в команде Core, ему важно зарекомендовать себя как профессионала и научиться продавать свою идею. Причём сначала продать её себе, затем команде и после — всем остальным. Если продакт не умеет этого делать, команда не будет его слушать: он будет ставить задачу, специалисты — как-то её выполнять, но эффективность будет низкой. И это может длиться годами.
Чтобы команда слушала продакта, он должен доказать ценность доработок и показать на метриках, как внедрение той или иной фичи улучшит продукт или его конверсию. Постепенно, видя результаты, Core Team будет все больше проникаться доверием к продакту и прислушиваться к тому, что он говорит.
Что касается работы с командой Growth, то продакт обсуждает с ней фичи: они все вместе накидывают гипотезы, определяют объём работ, временные рамки и берутся за дело.
Как собрать команду мечты
Со временем к вам начнут «прилипать» хорошие люди. Для этого нужно создавать комфортные условия, в которых они будут понимать, чем занимаются, как могут расти и какая для них ценность в продукте. Делайте это системно, планомерно и терпеливо. Тогда в среднем вы будете нанимать одного очень хорошего специалиста раз в три месяца.
Не ждите, что команда мечты появится у вас уже завтра. Так не бывает. Если вам кто-то скажет, что завтра придёт и наймёт супер-огонь-команду, не верьте. Во-первых, крутые специалисты не пойдут к вам сразу, потому что им может быть не интересен продукт. А во-вторых, у вас может не быть на это ресурсов.
Чтобы собрать команду мечты, ищите единомышленников, подключайте к работе над продуктом знакомых, перетаскивайте специалистов команды Core в команду Growth, рассказывайте о проекте в социальных сетях.
Как реагировать на изменения в команде
Кто-то приходит, а кто-то уходит — это нормально. Удерживать людей нужно, но не стоит делать это силой. Часто человек работает в компании, пока видит для себя ценность в продукте и развитии, которое может получить.
Ситуации бывают разные. Например, специалиста нанимали под одни задачи. За несколько лет проект вырос, а человек — нет. Тогда его нужно либо прокачивать и учить решать более сложные задачи, либо ранжировать — находить более сильного специалиста на его место. Бывает иначе: человек нашёл новый проект и неожиданно покинул текущий. Основатель всегда должен быть к этому готов, думать на несколько шагов вперёд.
Как обосновать расширение команды
Если продукт развивается, команду нужно увеличивать. Рассмотрим, как продакту обосновать её расширение для основателя.
Рассчитать текущую ёмкость команды. Допустим, команда работает по гибким методологиям и двигается в рамках спринта. Внутри спринта продакт планирует задачи, формирует список на неделю. Если в команде пять программистов, которые работают по 40 часов в неделю, их общая ёмкость — 200 часов. Но часть этого времени уходит на устранение багов, так что на разработку остаётся только 100 часов. Продакт ставит задачи, и программисты оценивают, сколько времени потребуется на их решение. Продакт продолжает ставить задачи, пока 100 часов не закончатся. Если он считает, что команду необходимо расширить, то может привести основателю компании такой аргумент: «Проект будет выполнен за 90 дней. А если привлечь ещё двух человек, то за 30».
Указать на отсутствие нужного эксперта в команде. Например, вы приходите к основателю проекта и говорите, что нужно нанять специалиста по Google Analytics. Чтобы обосновать это решение, следует рассказать, какие задачи он решает, как поможет развивать продукт, какую зарплату будет получать.
Где искать специалистов
Если вам нужно найти email-маркетолога, идите на Facebook, YouTube, Хабр, vc.ru, в LinkedIn. Ищите там специализированные группы, каналы — и напрямую пишите специалистам, которые вас заинтересовали.
Если планируете нанять front-end разработчика, изучите Upwork.com и другие биржи фриланса, HH.ru, а также загляните в систему вопросов и ответов о программировании Stack Overflow (это часть глобальной Stack Exchange Network).
Если ищете дизайнера, просмотрите рейтинги Tagline, напишите в дизайн-студии и digital-агентства и не забудьте посетить биржи фриланса.
Если хотите подобрать тестировщика, вам на помощь придут специализированные telegram-каналы, поиск в Яндексе и Google и, разумеется, сарафанное радио: поспрашивайте у друзей и знакомых, не знают ли они хорошего специалиста, который ищет работу.
В следующих статьях мы продолжим конспектировать лекции по быстрому погружению в продакт-менеджмент. Весь курс сразу, бесплатно и в видеоформате, уже доступен на GeekBrains.
Продолжаем серию статей для быстрого погружения в продакт-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь — первая часть третьей лекции в формате для чтения. Педагог — Андрей Попов, директор по информационным технологиям в 12 STOREEZ.
Кто нужен в продуктовой команде помимо продакта
Количество человек в продуктовой команде зависит от размера компании и сложности продукта, который она разрабатывает. Рассмотрим, какие специалисты входят в неё практически всегда.
Проджект-менеджер. Контролирует работу команды, следит, чтобы задачи выполнялись вовремя. Не генерирует гипотезы.
Back-end разработчик. Создаёт всё, что не видит и напрямую не трогает пользователь: связку полей формы регистрации и корзины, интеграцию с платёжным шлюзом, автоматические письма, подгрузку и обновление контента.
Front-end разработчик. Разрабатывает пользовательский интерфейс (вывод результатов поиска, форму ввода данных, корзину и т. д.). Делает так, чтобы сайты и приложения выглядели одинаково на различных устройствах.
Аналитик. Собирает у пользователей продукта информацию о фичах, которые нужно разработать, и оформляет в техническое задание для программистов. Сокращает неопределённость для команды.
Тестировщик. Всесторонне тестирует продукт. Помогает убедиться, что система ведёт себя корректно на всех этапах пользовательского пути.
Дополнительно в команду можно пригласить продакт-оунера, scrum-мастера и бизнеса-аналитика. Продакт-owner (владелец продукта) управляет созданием продукта и отвечает за то, что получится в результате. Scrum-мастер анализирует, как устроены процессы в команде, делит большие задачи на более мелкие и улучшает рабочие процессы. Бизнес-аналитик определяет слабые места бизнеса, помогает выстроить и развернуть инфраструктуру продукта.
Стоит отметить, что во многом судьба проекта и его команды зависит от основателя. Представьте: у человека компания с оборотом в полмиллиарда рублей в год. Если завтра здание, в котором он арендует офис, сгорит вместе с серверами и бумагами, а сотрудники уволятся и уедут жить на Гаити — он воссоздаст свой бизнес. Снова соберёт команду, разовьёт идею, накидает бизнес-гипотезы и помчит. Каждый основатель должен быть именно таким или стремиться к подобному уровню.
Виды продуктовых команд
Продуктовые команды бывают двух видов: Growth Hacking и Core.
Growth Team — это команда роста, которая отвечает за тестирование гипотез и развитие продукта. В неё обязательно входит front-end разработчик и дизайнер, а управляется она напрямую продакт-менеджером.
Основные задачи команды Core — поддерживать продукт в стабильном рабочем состоянии и внедрять в продакшен уже протестированные гипотезы. В Core Team входят все специалисты, которых мы перечислили выше, а управляет ей руководитель разработки (Engineering Lead).
Работа продакта с командами
Чтобы продакт мог эффективно работать в команде Core, ему важно зарекомендовать себя как профессионала и научиться продавать свою идею. Причём сначала продать её себе, затем команде и после — всем остальным. Если продакт не умеет этого делать, команда не будет его слушать: он будет ставить задачу, специалисты — как-то её выполнять, но эффективность будет низкой. И это может длиться годами.
Чтобы команда слушала продакта, он должен доказать ценность доработок и показать на метриках, как внедрение той или иной фичи улучшит продукт или его конверсию. Постепенно, видя результаты, Core Team будет все больше проникаться доверием к продакту и прислушиваться к тому, что он говорит.
Что касается работы с командой Growth, то продакт обсуждает с ней фичи: они все вместе накидывают гипотезы, определяют объём работ, временные рамки и берутся за дело.
Как собрать команду мечты
Со временем к вам начнут «прилипать» хорошие люди. Для этого нужно создавать комфортные условия, в которых они будут понимать, чем занимаются, как могут расти и какая для них ценность в продукте. Делайте это системно, планомерно и терпеливо. Тогда в среднем вы будете нанимать одного очень хорошего специалиста раз в три месяца.
Не ждите, что команда мечты появится у вас уже завтра. Так не бывает. Если вам кто-то скажет, что завтра придёт и наймёт супер-огонь-команду, не верьте. Во-первых, крутые специалисты не пойдут к вам сразу, потому что им может быть не интересен продукт. А во-вторых, у вас может не быть на это ресурсов.
Чтобы собрать команду мечты, ищите единомышленников, подключайте к работе над продуктом знакомых, перетаскивайте специалистов команды Core в команду Growth, рассказывайте о проекте в социальных сетях.
Как реагировать на изменения в команде
Кто-то приходит, а кто-то уходит — это нормально. Удерживать людей нужно, но не стоит делать это силой. Часто человек работает в компании, пока видит для себя ценность в продукте и развитии, которое может получить.
Ситуации бывают разные. Например, специалиста нанимали под одни задачи. За несколько лет проект вырос, а человек — нет. Тогда его нужно либо прокачивать и учить решать более сложные задачи, либо ранжировать — находить более сильного специалиста на его место. Бывает иначе: человек нашёл новый проект и неожиданно покинул текущий. Основатель всегда должен быть к этому готов, думать на несколько шагов вперёд.
Как обосновать расширение команды
Если продукт развивается, команду нужно увеличивать. Рассмотрим, как продакту обосновать её расширение для основателя.
Рассчитать текущую ёмкость команды. Допустим, команда работает по гибким методологиям и двигается в рамках спринта. Внутри спринта продакт планирует задачи, формирует список на неделю. Если в команде пять программистов, которые работают по 40 часов в неделю, их общая ёмкость — 200 часов. Но часть этого времени уходит на устранение багов, так что на разработку остаётся только 100 часов. Продакт ставит задачи, и программисты оценивают, сколько времени потребуется на их решение. Продакт продолжает ставить задачи, пока 100 часов не закончатся. Если он считает, что команду необходимо расширить, то может привести основателю компании такой аргумент: «Проект будет выполнен за 90 дней. А если привлечь ещё двух человек, то за 30».
Указать на отсутствие нужного эксперта в команде. Например, вы приходите к основателю проекта и говорите, что нужно нанять специалиста по Google Analytics. Чтобы обосновать это решение, следует рассказать, какие задачи он решает, как поможет развивать продукт, какую зарплату будет получать.
Где искать специалистов
Если вам нужно найти email-маркетолога, идите на Facebook, YouTube, Хабр, vc.ru, в LinkedIn. Ищите там специализированные группы, каналы — и напрямую пишите специалистам, которые вас заинтересовали.
Если планируете нанять front-end разработчика, изучите Upwork.com и другие биржи фриланса, HH.ru, а также загляните в систему вопросов и ответов о программировании Stack Overflow (это часть глобальной Stack Exchange Network).
Если ищете дизайнера, просмотрите рейтинги Tagline, напишите в дизайн-студии и digital-агентства и не забудьте посетить биржи фриланса.
Если хотите подобрать тестировщика, вам на помощь придут специализированные telegram-каналы, поиск в Яндексе и Google и, разумеется, сарафанное радио: поспрашивайте у друзей и знакомых, не знают ли они хорошего специалиста, который ищет работу.
В следующих статьях мы продолжим конспектировать лекции по быстрому погружению в продакт-менеджмент. Весь курс сразу, бесплатно и в видеоформате, уже доступен на GeekBrains.
8 ключевых ролей в продуктовой команде
И почему некоторые из них недооценивают (а зря).
Состав продуктовой команды зависит от продукта, его сложности, целей и темпов роста. Но есть «стандартный набор», которого зачастую достаточно для создания продукта, его вывода на рынок и привлечения первых пользователей.
Нам Александр рассказал о ключевых ролях в продуктовых командах — в чем их ценность, когда они необходимы, а когда ими можно пожертвовать.
#1. Product Manager / Product Owner
PM отвечает за создание и развитие продукта (определяет его стратегию, User Flow, наполняет бэклог), управляет бюджетом, коммуникациями с клиентами и внутри команды (планирует, приоритизирует и контролирует выполнение задач). Зачастую РМ отвечает и за успешный вывод продукта на рынок, его масштабирование, а также за монетизацию. На ранних стадиях развития стартапов роль РМ’а может выполнять фаундер.
В Agile-фреймворке Scrum есть позиция Product Owner (владелец продукта). Она близка к РМ’у, но больше сфокусирована на разработке и развитии: РО создает концепцию, руководит реализацией на всех этапах жизненного цикла, зачастую глубже погружен в техническую часть. Его ответственность — получить продукт, который отвечает ожиданиям клиентов (через анализ обратной связи пользователей, коммуникации с коллегами и создание для них комфортных условий).
Также в Agile-командах, работающих по фреймворку Scrum, часто есть отдельная роль Scrum Master. В таких коллективах РМ/PО отвечают за продукт, а SM — за соблюдение Scrum-артефактов (стендапы, daily-митинги, ретроспективы, фасилитации и т. д.).
По моему опыту, выделять эту роль необходимо не всегда, даже если команда работает по фреймворку (по крайней мере, full-time). Например, в компании MacPaw есть Scrum Masters, которые «шерятся» между командами. Также эта роль не всегда обязательна на ранних стадиях развития проекта, когда критично оптимизировать косты. Не все команды четко следуют артефактам фреймворка, многие настраивают его под себя — и это тоже работает. Ведь главное — не теоретические выкладки, а результат (успешный продукт).
#2. Разработчик
Это обязательная роль в продуктовой команде, но количество и потребность в экспертизе девелоперов зависят от:
Например, простой продукт может разработать и один «универсальный» девелопер на кроссплатформенных фреймворках типа Flutter или React Native.
#3. Дизайнер
Дизайнер в продуктовой команде отвечает не только за визуальную часть (например, разработку макетов) — он должен знать потребности бизнеса, как продукт будет решать проблемы пользователей и зарабатывать деньги.
Если команда не просто разрабатывает продукт, но еще и выводит его на рынок или масштабирует, часто выделяют две разные роли:
#4. QA (тестировщик)
Этот специалист проверяет продукт на наличие багов, тестирует пользовательские сценарии. Помогает обеспечивать нужное качество, соответствие техзаданию и корректность работы продукта на девайсах, которые будут использовать юзеры.
QA-специалисты могут поспорить, но мое личное мнение — чем выше seniority команды, тем меньше потребность в этой роли. Зачастую опытные разработчики допускают мало багов, могут сами написать и провести тесты.
Хотите получать дайджест статей?
#5. Копирайтер
Необходимость в этой роли зависит от объемов копи (текстов). Часто копирайтер вовлечен в работу продуктовой команды на part-time — или же привлекается подрядчик. Он пишет UX-копи (тексты для интерфейса) и маркетинговые материалы — например, для продвижения в соцсетях. Также стратегия развития продукта может включать органические охваты (например, блог с SEO-контентом).
#6. Product Marketing Manager
Создает маркетинговую стратегию и план, ищет эффективные каналы привлечения пользователей и масштабирования, а также устанавливает метрики, по которым будет оцениваться успешность продукта. Это важная роль, но не во всех командах ее выполняет отдельный специалист.
Например, создание приложения Gemini Photos в MacPaw началось именно с того, что мы с Product Marketing Manager провели
User Research и обнаружили запрос на продукт. А в medtech-компании Bioniq моей экспертизы на позиции Chief Product Officer было достаточно.
#7. UA Manager / PPC Manager
User Acquisition Manager — это специалист по привлечению пользователей, PPC Manager — по контекстной рекламе. Они планируют кампании для разных каналов, отслеживают их эффективность, работают с копирайтерами и маркетинг-дизайнерами над созданием перформящих креативов.
Я считаю эту роль важной, но недооцененной. Необходимо грамотно работать с paid-трафиком (платными каналами привлечения пользователей), прежде всего — это Google, Facebook, Instagram и TikTok. Иначе невозможен быстрый и предсказуемый рост продукта.
Александр Емельянов,
Chief Product Officer at Kama.co
Волк Ірина,
General Manager у Dell Technology Group, Ukraine and West CI
#8. Аналитик
Роль может называться по-разному: Data Analyst, Product Analyst, Business Analyst. Этот специалист помогает команде принимать data-driven решения о развитии продукта. Аналитик собирает и исследует данные, изучает продуктовые метрики (в привлечении, удержании, вовлеченности пользователей и т. д.), отслеживает влияние изменений в продукте на поведение юзеров. Мониторит конверсию и находит инсайты, направляющие команду.
Специфика данных, с которыми работают аналитики, зависит от продукта. Например, в medtech-компании Bioniq такие специалисты занимались процессингом (обработкой) и созданием баз медицинских данных.
Не существует единого, оптимального состава продуктовой команды — и эти рамки не нужны. Сначала формируются цели — например, надо создать MVP, — а затем определяются необходимые компетенции и состав команды.
В одном коллективе с задачей справятся два девелопера, в другой — понадобится еще Machine Learning Engineer или 3D-художник. Продуктовая команда собирается в определенном бизнес-контексте.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!