Новости

За время работы в банке мне удалось успешно собрать пять Scrum-команд и руководить одновременно тремя из них. В процессе управления командами разработки у меня получилось настроить процессы так, чтобы значительно повысить их эффективность в рамках работы над одним продуктом.

Инструмент для планирования и управления

Чтобы повысить эффективность работы команды над продуктом, нужна стратегия развития. Хороший инструмент для ее разработки — GIST. Он позволяет планировать работу команды исходя из целей компании.

• G — Goals. Цели описывают, куда компания стремится и чего хочет достичь. Цели отвечают также на вопрос «зачем мы это делаем?». Это самый первый и важный этап, без которого невозможно построить реальную стратегию развития продукта. Определение целей компании обычно происходит на три-пять лет вперед.
• I—Ideas. Идеи предполагают, каким образом компания может достичь своих целей. В менеджменте продуктов идеи обычно называются гипотезами. Менеджер выдвигает их на основании исследований рынка и пользователей. Идеи по достижению целей собирают и приоритизируют беспрерывно.
• S — Step projects. На этом этапе отобранные гипотезы попадают в бэклог команды в виде проектов. Проекты разделяют на milestones (промежуточные этапы разработки), это ключевые точки в работе над всем проектом. Обычно это сначала MVP (минимально жизнеспособный продукт), потом первая стадия реализации, вторая стадия и т.д. В первую очередь реализуют более приоритетные и критически важные составляющие проекта, без которых он не может существовать. Проекты определяются в рамках годового и квартального планирования.
• T — Tasks. Проекты разбивают на конкретные задачи, которые команда разработки берет в работу в рамках своих спринтов.

Проекты и задачи вносят в «дорожную карту» продукта, их выполнение отслеживают в процессе оперативного управления.

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

Инструменты для отслеживания разработки

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

• мессенджеры для эффективного общения,
• сервисы видеоконференций,
• виртуальные доски,
• сервисы для ведения документации.

В качестве рабочих мессенджеров часто используют корпоративные (Slack) или общедоступные (Telegram). Не так важно, какой именно, — главное, чтобы он соответствовал нескольким требованиям:

• был удобен в использовании и стабильно работал;
• был защищен;
• предоставлял доступ к коллегам и был эффективен для коммуникации.

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

Однажды, в рамках управления тремя командами разработки, мне понадобилось наладить коммуникацию не только внутри команд, но и между ними, а также с внешними коллегами, для которых также была важно напрямую контактировать с некоторыми членами команд. Для этого был создан telegram-чат с темами по нужным направлениям:

• общение с поддержкой,
• с маркетингом,
• смежными командами,
• неформальное общение и т.д.

Что касается рабочей почты, то удобнее всего использовать ее для фиксации разного рода договоренностей: пересылки бизнес-требований, технических заданий, фиксации сроков, итогов встреч и т.п.

В эпоху удаленной работы для общих встреч в видеоформате также нужны различные сервисы для онлайн-конференций. Это может быть Zoom, Google Meet, Microsoft Teams, «Яндекс.Телемост» и т.д.

Любой современный сервис для видеозвонков позволяет вести эффективную работу. Основные требования к нему такие:

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

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

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

Miro позволяет мне эффективно решать следующие задачи:

• строить USM, CJM, Metrics Tree,
• наглядно объяснять User Flow будущей функциональности на встрече со стейкхолдерами.

В связке с Miro используется Confluence как единый источник знаний в рамках продуктовой документации.

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

Теперь в Confluence есть единый шаблон для описания каждой функции, соответствующей ей гипотезы и эксперимента.Там же находятся ссылка на Miro, в котором лежит User Story Map, и ссылка на Figma, где в соответствующем задаче разделе можно найти дизайн. То есть командам в любое время доступна качественная продуктовая документация. Это экономит время большому количеству коллег.

Правила поддержания эффективности

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

Во-первых, существует стабильное расписание командных встреч. Какие-то из них могут быть перенесены, но это происходит редко, а сообщают об этом заранее.

Каждая встреча происходит по четко описанной структуре. Например, Daily Scrum Meeting длится не более 15 минут. На нем команда дает статусы по своим задачам, прогноз по выполнению цели спринта, а также сигнализирует о возможных препятствиях в работе. Если требуется обсудить, как эти препятствия преодолеть, то для этого собирается отдельная встреча. Последний принцип касается и остальных Scrum-встреч. Среди них такие:

• Sprint Planning Meeting — менеджер продукта объясняет приоритеты на спринт, пополняет бэклог спринта и ставит цель спринта.
• PBR (Product Backlog Refinement) — обсуждаются способы реализации поставленных задач, оцениваются задачи из бэклога, разбираются баги.
• Sprint Review — команда подводит итоги спринта, фиксирует, была ли достигнута цель спринта, делится успехами со стейкхолдерами.
• Sprint Retrospective — команда обсуждает прошедший спринт: какие успехи были достигнуты, с какими проблемами столкнулись и как в будущем их избежать.

Во-вторых, на Sprint Review менеджер продукта совместно с командой анализирует метрики производительности команды.

Ключевая метрика, которую мы наблюдаем, — это Velocity (непосредственно метрика производительности команды, которая обычно исчисляется в Story Points).

В рамках Sprint Review мы анализируем Velocity Chart, который показывает нам запланированный объем, реализованный объем и средний Velocity команды за квартал. Этот чарт позволяет отслеживать, придерживается ли команда рекомендованного темпа работы. Если он демонстрирует снижение Velocity, это сразу становится темой для обсуждения на ретроспективе, где команда будет искать причину и решение проблемы, которая повлекла за собой снижение показателей.

Важно не путать Velocity (производительность) и Capacity (вместимость). В отличие от Capacity, Velocity может расти, благодаря тому, что команда накапливает опыт и увеличивает экспертность в рамках своего продукта. Именно поэтому команда способна постоянно увеличивать запланированный объем работы на спринт.