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

Звездная карта (рис. 3.12) – это простой инструмент, представляющий собой матрицу, в которой в пересечении «сотрудник – экспертиза» устанавливается звездочка, если сотрудник «звезда» в этой экспертизе, и точка, если может подменить «звездного» сотрудника, который по какой-то причине выпал. Звездная карта позволяет видеть провалы в экспертизах и риски возникновения бутылочного горлышка в случае незаменимости «звезды». Для минимизации риска «автобуса» можно поощрять сотрудников к развитию горизонтальных компетенций, например, оплачивая обучение. Если сотрудник хочет изучить что-то не по профилю, в ячейке ставится значок «книга».

Долгое время рынок труда в IT не поощрял многопрофильность. Это накладывало ограничение на желание разработчиков развиваться в смежных сферах. Например, фронтенд-разработчик не хотел развиваться в бэкенде, так как это не увеличивало его стоимость на рынке.

Сейчас, с развитием Agile, растет потребность в фулстек-разработчиках (от англ, full stack, полный стек[43]), и вакансий с каждым годом становится все больше.

3.2.2.2. Минимальная команда

Расширение команды увеличивает время на синхронизацию и ответственность каждого участника.

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

Чем больше команда, тем меньше ощущение личного вклада в результат, а следовательно, и ответственность становится все менее очевидной.

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

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

3.2.2.3. Долгое время вместе

Изменение состава команды нарушает внутренние равновесие и перезапускает процесс ее формирования.

Рис. 3.13. Стадии формирования групп по Брюсу Такману

Брюс Такман в 1961 году предложил модель групповой динамики, согласно которой команда проходит четыре стадии формирования (рис. 3.13):

➠ формирование (forming),

➠ шторм (storming),

➠ нормирование (norming),

➠ производительность (performing).

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

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

3.2.2.4. Владелец продукта

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

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

➠ разработку и детальное донесение цели продукта;

➠ разработку и ясное донесение элементов продуктового бэк-лога;

➠ приоритизацию элементов продуктового бэклога;