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

➠ обеспечение доступности, прозрачности и понятности продуктового бэклога.

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

Плохо, когда владелец продукта:

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

➠ Перегружен работой: будет терять контекст.

➠ Совмещает: не будет нести ответственность в трудной ситуации.

➠ Работает удаленно: будет недоступен в срочной ситуации и часто неправильно понят.

➠ Прокси: будет задерживать и искажать сигнал от реального РО.

➠ Скрытный: команде будет трудно понять, как сделать, если непонятно, зачем.

➠ Комитет: решения будут затягиваться.

➠ Не заинтересован: команда будет демотивирована бесполезным трудом.

➠ Боится: страх парализует и заставляет имитировать работу.

3.2.2.5. Scrum-мастер

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

➠ развивает команду в сторону самоорганизации и кросс-функциональности;

➠ помогает увеличивать производительность – поставлять как можно больше максимально ценных элементов продуктового инкремента каждый спринт;

➠ убирает препятствия в прогрессе команды;

➠ фасилитирует события Scrum для регулярного увеличения их эффективности.

Scrum-мастер помогает владельцу продукта ⁄ Scrum-команде:

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

➠ эффективно действовать в комплексном мире (см. п. З.1.З.);

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

➠ организовать взаимодействие со стейкхолдерами, фасилитировать встречи.

На уровне организации Scrum-мастер:

➠ возглавляет и активно участвует во внедрении Scrum;

➠ участвует в планировании мероприятий по внедрению;

➠ помогает стейкхолдерам осознать и внедрить эмпирический процесс для комплексного мира;

➠ убирает препятствия между стейкхолдерами и Scrum-командой.

Важно добавить, что Scrum-мастер создает эффективную здоровую среду взаимного профессионального уважения и самостоятельности. Он выступает в роли третейского судьи для команды разработки и владельца продукта. Это позволяет добиться состояния справедливости, когда владелец продукта не «продавливает» команду, а команда не «продавливает» ПО.

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

Плохо, если Scrum-мастер:

➠ Проджект-менеджер: это противоречие на уровне операционных окружений по модели «Киневин», рассмотренной в п. 3.1.3.

➠ Прокси: чью бы волю ни выполнял – РО, СТО, SH[45], – в команде образуется несправедливый перекос;

➠ Частичный: SM, который работает на две и более команды, по-настоящему не болеет ни за одну из них;

➠ Нянька: потакая капризам команды, убивает в них самостоятельность;

➠ Трусливый: боится настоять на правильном процессе, из-за чего Scrum превратиться в Scream.

3.2.3. События Scrum

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

Табл. 3.4. Краткое описание событий и процессов Scrum

Создатели Scrum выявили все обязательные типы событий, необходимых для разработки, и определили рекомендованную нормативную длительность (табл. 3.4).

Помимо официальных названий, есть устоявшиеся неофициальные: обзор спринта – демо. Далее для краткости будем использовать как официальные, так и неофициальные обозначения.

3.2.3.1. Краткое описание событий Scrum

Для начала давайте рассмотрим «скелет» событий Scrum (рис. 3.14).

➠ На планировании спринта собирается Scrum-команда. Участники идут сверху вниз по бэклогу, прошедшему приоритизацию, и разработчики набирают в него элементы.