Есть ли среди читателей те, чьи команды проводят демо каждый спринт? Не просто раз в квартал или по большим вехам. Таких команд обычно немного — и это понятно. Демо каждый спринт — это как регулярные публичные выступления, а такое испытание не каждому по душе, особенно если ты разработчик-интроверт.
У нас в банке регулярные демо появились не сразу. Но сейчас я замечаю, как постепенно все больше команд включают их в свой ритм работы. И даже самые закоренелые интроверты втягиваются. Хочу рассказать, как мы к этому пришли, почему два раза чуть не забросили эту затею и что в итоге сработало.
Попытка первая
В 2022 году у нас в банке были сформированы кросс-функциональные команды. И в календаре каждой из них, согласно ритуалам, появилось демо спринта. Мероприятие было внутрикомандным, требовало подготовки, участия и вовлеченности всех сотрудников.
Как обычно, первыми в игру вступили энтузиасты. В каждой команде нашлось по одному-два человека, которые действительно включились в процесс, — обычно самые активные инженеры и продакт-оунеры. А вот остальные смотрели на все это со скепсисом.
Что происходит, когда большая часть команды не верит в полезность ритуала? Сначала демо начали пропускать just for this sprint. Потом переносить «потому что». А через пару месяцев события и вовсе стали тихо исчезать из календарей, причем часто в самый последний момент. В итоге демо практически не проводились. Вместе с аджайл-коучем мы решили реанимировать этот ритуал, но хотелось сделать это так, чтобы вовлечь всех участников команд.
Попытка вторая
Заручившись поддержкой нашего VSO, мы решили попробовать другой подход, который заключался в ежемесячных демонстрациях достижений всех команд стрима с открытым списком участников. В календарях мы зарезервировали время на двух-трехчасовые встречи с интервалом 1 раз в месяц, плюс несколько подготовительных сессий для согласования материалов.
Надо сказать, что материалы получались действительно интересными — наши PO прошли обучение по созданию презентаций и научились делать красивые слайды. На демо приглашали всех: сотрудников сети, коллег из отдела продаж, технических лидов и других представителей банка, в том числе топов.
В этот формат мы вложили кучу сил и времени. Презентовали пользователям передовые фичи, рассказывали о планах на ближайшее будущее. Несколько месяцев все шло неплохо, но потом вернулись прежние проблемы: переносы, отмены…
Снова стали разбираться, почему так, и пришли к трем главным выводам. Во-первых, подготовка стала съедать слишком много времени и сил. Во-вторых, демо превратились в (бизнес-ориентированные) презентации. А в-третьих, и это оказалось главным, — большая часть инженеров осталась в стороне. Пока PO и технические директора показывали красивые слайды, разработчики просто сидели и занимались своими делами.
На этом наша вторая попытка «демонизации» закончилась, и все с облегчением выдохнули — больше не нужно было тратить силы на то, в чем команды не видели ценности.
Проблема, которая осталась
После двух неудачных попыток можно было бы махнуть рукой — ну, не приживаются у нас демо, и ладно. В конце концов, процесс идет, задачи закрываются, пользователи не жалуются.
Но тут важно понимать специфику. Банк — не стартап, где все сидят в одной комнате и знают друг про друга все. У нас десятки команд, сотни людей, огромное количество взаимосвязанных процессов. И в этом масштабе отсутствие синхронизации становится реальной проблемой.
В стриме, как и в любой крупной структуре, сохранялся запрос на прозрачность работы команд. Нам нужно было понимать, как идет реализация ключевых эпиков, какие есть риски и достижения у команд. И самое главное — требовалось получать достоверную информацию о том, как реализована та или иная новая фича, над которой команды так старательно работали.
Еще одна сложность — никто толком не знал, что происходит у соседей, с какими они вызовами сталкиваются. Часто в одной команде находили решение какой-то проблемы, но об этом больше никто не знал. В итоге остальные, сталкиваясь с такой же проблемой, тратили время, чтобы разобраться с нуля.
В общем, нужно было разработать формат, который решал бы главную задачу: обеспечивал прозрачность для руководства и давал командам возможность учиться друг у друга (не скатываясь при этом в «проходные презентации» и не отнимая кучу времени на подготовку), а также позволял бы командам авторизовать свои результаты спринта.
Новое решение
Мы долго думали, как найти баланс между формальными требованиями и реальной пользой для команд и продукта. И в итоге пришли к совершенно новому для стрима формату. Идея была простой: убрать все лишнее и оставить только то, что действительно важно — живой показ результатов работы. Формат, который не только обеспечит прозрачность работы, но и увеличит вовлеченность инженеров, а также создаст площадку для обмена опытом и сбора обратной связи по каждой новой фиче.
Теперь у нас все работает так. Каждый спринт проходит полуторачасовая встреча, которую ведет наш аджайл-коуч. Расписание стабильное, никаких переносов — в конце спринта обязательно собираемся. Приглашены все участники команд стрима, каждой команде дается 10–12 минут: примерно 8 минут на демонстрацию и 4 минуты на вопросы и обсуждение.
PO коротко рассказывает о ключевой цели спринта, а потом инженеры показывают, как реализована фича. Не слайды, не красивые презентации — живая демонстрация прямо на локальной машине или тестовом полигоне. Получается динамичное мероприятие, где каждый может тут же задать вопрос или предложить улучшение. Главное — сделать продукт максимально удобным для клиентов, как внутренних, так и внешних.
А чтобы сделать встречи более интересными, мы решили, что порядок выступления команд определяет рандомайзер. Накануне демо наш коуч запускает «рулетку» и присылает запись — все честно, как в «Спортлото». Таким образом, любая команда может стать открывающей или завершающей.
Главное отличие от прежних форматов — никакой специальной подготовки и полировки слайдов. Команды просто показывают то, что реально сделали за спринт: вот код, вот работающая фича, вот реальный итог работы команды.
Результаты
Мероприятие получилось не затратным для команд, но при этом полезным. В нем появился легкий дух соревнования — команды видят работу друг друга и хотят в следующий раз показать что-то еще более крутое. Главное, что все начали по-настоящему вовлекаться в процесс.
Команды теперь не просто знают, что происходит у соседей, но и обмениваются опытом. Увидел интересное техническое решение на демо — можно спросить коллег о деталях. Заметил похожую проблему — поделился решением. Также это хорошая возможность для участников команды развивать навыки презентации и публичного выступления, а также авторизовывать свои достижения.
От этого выигрывают и клиенты. Когда разработчики видят, как их коллеги выполняют похожие задачи, появляются новые идеи по улучшению собственных решений. Фичи становятся лучше, удобнее в использовании, а проблемы решаются быстрее.
На этом, пожалуй, все. Если вы до сих пор сомневаетесь, стоит ли внедрять такие ритуалы в работу своих команд, — просто попробуйте. Главное — не превращать демо в формальность, и тогда оно станет не обязаловкой, а реально полезным инструментом для всей команды.
Читать первым в Telegram-канале «Код Дурова»
