Менеджмент цифрового продукта. От идеи до идеала

Scrum-команда достаточно маленькая, чтобы сохранять проворство, и достаточно большая, чтобы завершать значимую часть работы каждый спринт. Многочисленные исследования показывают, что чем меньше команда, тем она продуктивнее. Следовательно, как только Scrum-команда становится слишком большой (более 15 человек), рекомендуется разделить ее на несколько.

Scrum-команда полностью самостоятельна и наделена полной властью для достижения целей спринта, а следовательно, самостоятельно несет ответственность за взаимодействие со стейкхолдерами, сопровождение, операционную деятельность, исследования, R&D и все остальное, что может понадобиться в процессе.

ST наделена всеми полномочиями на управление собственной структурой и процессами.

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

3.2.1.2. Лучшие практики организации Scrum-команд

Самостоятельность

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

➠ Ждем, пока юристы согласуют формулировку.

➠ Ждем, пока другая команда развернет обновление API.

➠ Ждем, пока Scrum-мастер перенесет истории из продуктового бэклога в бэклог спринта и т. д.

Несколько практик по работе с внешними зависимостями:

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

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

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

➠ Выявление и регулярное устранение внешних зависимостей. На определенном масштабе, когда команд становится много, требуется настроить процесс работы с зависимостями. Создается доска зависимостей (dependency board), команды назначают друг другу задачи по устранению зависимостей, и зависимости устраняются, часто с повышенным приоритетом.

Вертикальная интеграция

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

➠ Бизнес-блок. Компания подразделяется на несколько бизнес-блоков. Каждый из них автономен с точки зрения внутренней экономики, имеет обособленный P&L, за который отвечает руководитель блока.

➠ Трайб (tribe, иногда племя) – совокупность отрядов, сфокусированных вокруг одного продукта или портфеля родственных продуктов. Руководитель трайба отвечает за финансовый эффект продуктов портфеля трайба.

➠ Отряд – минимальная автономная команда (например, Scrum-команда), разрабатывающая продукт или компонент. Владелец продукта отвечает за возврат инвестиций в разработку продукта.

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

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

Хороший подход, когда продуктовая команда самостоятельно отвечает за качество на уровне определения завершенности (Definition of Done, DoD).