Литмир - Электронная Библиотека
Содержание  
A
A

3.7. Демонстрация продукта. Завершение спринта

Говорят, в Царской России при испытании нового железнодорожного моста под него ставили всех строителей. А сверху пускали паровоз. Мосты век стояли. А разработчик – либо герой, либо – труп.

Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий - i_072.png

Нужно демонстрировать результат работы лично, ставить шкуру на кон! Это бодрит. Подстегивает ответственность и рост качества продукта. Боли, правда, будет больше. Но это полезная боль.

Согласуйте демонстрацию заранее. Если проект долгоиграющий – запланируйте стандартное время, в которое будете показывать спринты. Например, каждый вторник, 16:00. Времени резервируйте около часа. Нужна будет либо личная встреча, либо видеосвязь с демонстрацией экрана.

Со стороны бизнеса присутствует как минимум Product Owner. Пользователи и другие сочувствующие – допускаются. Со стороны разработки – вся команда. Понятно, что бывают исключения, но стремимся к этому.

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

Ради чего все это затевается: обратная связь в режиме реального времени. Пусть жесткая, но честная. По сути, обсуждается только первое впечатление, но оно не врет. WYSIWYG – What You See Is What You Get, или «если тебе кажется, что что-то не так, – скорее всего, тебе не кажется».

По опыту большая часть обратной связи будет конструктивной и позитивной. Особенно с англоговорящими заказчиками. Бояться демонстраций не надо. Надо готовиться. Продумайте чуть заранее:

▶ По каким путям проведете зрителей в продукте.

▶ Какие кейсы покажете.

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

▶ Какие вопросы скорее всего возникнут. И как на них отвечать.

Позднее Product Owner может потребоваться время помедитировать, поразглядывать продукт, поиграться с ним. Но это он будет делать в одиночестве, сублимируя в бэклог. Возникшие вопросы ему будет не с кем обсудить, и, наверное, он будет предполагать только худшее. Но с этой проблемой он должен справиться сам.

Мы же зафиксируем обратную связь и пойдем с ней на ретроспективу.

Аварийное завершение спринта

Редко, но гадко. Бывает, приходится останавливать спринт. Дело идет медленно и не туда. Команда упарывается, нужных доступов нет, кризис у клиента или еще какая-нибудь гадость. Дергаем стоп-кран, останавливаем спринт. Проводим ретроспективу, решаем проблемы. Делаем рескоупинг (перепланируем спринт). Едем дальше. Таких форс-мажоров допустимо не больше 5 %. Ибо нефиг.

3.8. Ретроспективы. Бородачи тоже плачут

Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий - i_073.png

Допустим, на демонстрации Product Owner разнес вашу работу в пух и прах. Справедливо, методично. Или просто очень эмоционально: он оказался злобным, неуязвимым говнюком. Команда сидит подавленная. Кто-то курит прямо в опенспейсе. Провал. Полный капут. «Что я тут делаю?» – читается в глазах бородатых программистов. Пятница, вечереет. Ваши действия?

Рохля разведет руками. Распустит команду по домам. Ага, щас! Мы пойдем в ближайший бар. И будем всякую фигню думать. Про процессы. Технологии. И ме-е-неджера. Рано его руководить поставили.

Люди будут смаковать неудачу, искать причины провала. На минуточку, не в себе, а в руководителе продукта, менеджере, проекте или процессах. Сами выберут такую позицию, когда они – Д’Артаньяны, а остальные – нет. И будут ныть. Пару-тройку раз повторятся такие ситуации, и дело разладится.

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

В скраме есть специальная активность, где мы с командой подводим и обсуждаем итоги спринта. Ретроспектива. Цель ретроспективы – не поныть (хотя иногда хочется), не выпить (хотя кому-то иногда необходимо), не байки потравить. А улучшить рабочие процессы.

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

Все не так. Им может не хватать ресурсов: времени, мотивации, энергии. В том числе квалификации, чтобы сделать на должном уровне. Вот с этим уже можно работать.

Итак, намеренно никто не гадит. На основе этой идеи вы должны гарантировать безопасность команде на ретроспективах. У людей должна быть уверенность, что:

▶ по итогам ретроспективы никого не накажут;

▶ на ретроспективе ни на кого не наорут, не затроллят и морально не опустят;

▶ за обсуждение проблем не посчитают слабаком (но только на ретроспективе – ежедневных нытиков отправим к мамочке);

▶ и так далее.

Придется стать сильным и тактичным, чтобы вскрывать проблемы команды, не вскрывая при этом людей.

3.8.1. Формат ретроспективы

1. Подготовка

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

На 2-х недельный спринт и команду в 3–4 человека планируем минут 40–60. На месячные спринты или большие команды может уйти часа полтора. Я бы не советовал делать ретроспективы еще длиннее – это контрпродуктивно.

Иногда уместна пицца: задушевные разговоры за едой сплачивают команду и снижают уровень агрессии.

Один человек будет ведущим. Как правило – скрам-мастер или менеджер, если он совмещает эти роли.

2. Настройка

Первые пару минут включаем команду в групповой транс работу.

Здороваемся, налаживаем контакт. Например, задайте простой вопрос, типа «Как дела?». И получите хоть какую-то реакцию. Кивок головы или угрюмое: «Расскажи, дружок мой, Вова, отчего мне так хреново», это окей.

Альтернативные техники, которые мне нравятся:

1. 10-пальцевый опрос. Попросите всех выбросить на пальцах, насколько довольны текущим спринтом.

2. Happiness radar. Чертим матрицу 3×3. По вертикали – смайлики настроения. По горизонтали – Технологии, Люди, Процесс. Каждый ставит палочку, насколько удовлетворен каждым из аспектов. Стикеры нужны для фиксации предложений по ходу.

Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий - i_074.png

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

Напоминаем цель ретроспективы. Если есть новые участники, не привыкшие к ретроспективам – рассказываем про формат и гарантируем безопасность. Рассказываем про «намеренно никто не гадит».

3. Накидывание на вентилятор

Далее просим по кругу рассказать о плюсах (хорошем) и минусах (плохом) на спринте. Начинайте не с новичков. Идеи приветствуются и фиксируются, но не критикуются.

22
{"b":"797231","o":1}