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

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

Помимо таких достаточно простых примеров, есть менее очевидные, например команда, образованная вокруг систем, заново используемых другими продуктами, таких как единая точка входа (single sign-on, SSO), рекомендательная система или система мониторинга.

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

Коллективное владение системой

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

Практика коллективного владения системой основана на практике коллективного владения кодом из экстремального программирования (extreme programming, ХР).

Роль делегата может возникать как дополнительная роль у уже существующего участника команды; при увеличении нагрузки может быть выделен отдельный человек или даже несколько.

Рис. 3.10. Виртуальная команда

Доработки системы инициируются владельцами продукта, делегаты осуществляют доработку системы, а развертывание начинается с проверки кода несколькими делегатами.

С примерами реализации практики коллективного владения системой можно ознакомиться в табл. 3.3.

Табл. 3.3. Сравнение коллективного и централизованного владения системами

* Дашборд (англ, dashboard) – это интерактивная панель, на которой отображаются все метрики из гипотез жизнеспособности продукта в режиме реального времени.

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

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

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

3.2.1.2. Команда разработки

Команда разработки (development team, DT), или разработчики – это часть Scrum-команды, которая берет на себя обязательство поставлять полезный инкремент каждый спринт. Команда обладает всеми необходимыми навыками в операционном домене[41] и отвечает за:

➠ формирование бэклога спринта и плана достижения целей спринта;

➠ развитие качества путем соблюдения и дополнения определения завершенности (DoD);

➠ ежедневную адаптацию плана для достижения цели спринта;

➠ профессионализм друг перед другом.

3.2.2. Лучшие практики

3.2.2.1. Т-образные специалисты

Т-образные (англ. T-shaped, в форме буквы «Т») специалисты названы так по способу формирования компетенций и представляют собой комбинацию специалистов широкого профиля (dash-shape, или тиреобразные) и узких специалистов глубокого профиля (I-shape, или 1-образные). Т-образные специалисты глубоко разбираются в одной экспертизе, но при этом на базовом уровне разбираются в смежных (рис. 3.11).

Рис. 3.11. Способы формирования компетенций. Т-, I- и «-»-образные специалисты

Наличие таких специалистов в команде позволяет убрать бутылочные горлышки и снизить так называемый фактор автобуса[42].

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

Некоторые компании, в которых мне доводилось работать, поощряли развитие разработчиков в сторону Т-образности. Известная практика – создание звездной карты.

Рис. 3.12. Звездная карта