Автор: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе за рубежом
Последние 10 лет информационные технологии повсеместно проникают в нашу жизнь. За счет них клиенты получают более быстрые и персонализированные сервисы с фокусом на конкретные потребности. С увеличением конкуренции растет скорость изменений и вместе с этим борьба за клиентов. У компаний появилась потребность в создании гибких процессов и системе, которая бы позволила максимально оперативно подстраиваться под изменяющийся рынок, при этом делая потребности пользователя основным фокусом.
Скрам — один из таких фреймворков. Он позволяет бизнесу итеративно создавать небольшие кусочки продукта и тестировать их на рынке, что дает ему возможность быстро собирать обратную связь и минимизировать риск выпуска ненужного продукта и функциональности. С его помощью компания создает лучшие продукты и быстрее приходит к своим бизнес целям, быстрее отказывается от ненужных решений и не тратит на них время.
Скрам задает жесткие ограничения в процессе и структуре, которые должны обязательно выполняться.
Фундаментальный элемент — Скрам-команда — самоуправляемая команда людей, которая самостоятельно определяет цель и вектор движения к ней. Конечно, цель не может быть в отрыве от главной бизнес-цели компании и стратегии.
Состав скрам-команды
Скрам мастер — отвечает за эффективное внедрение фреймворка Скрам в процессы.
Владелец продукта — отвечает за максимизацию ценности того, что создает Скрам-команда. То есть он анализирует рынок, приоритезирует потребности, определяет, что сейчас является наиболее важным для пользователей, как максимизировать бизнес-ценность для компании.
Команда разработки (в новой версии Скрам их назвали «Разработчики») — это все компетенции, которые необходимо иметь внутри команды, чтобы создать продукт. Они отвечают за создание готового, качественного кусочка продукта в течение каждого спринта. В результате спринта не должно оставаться недоделанной работы.
Важно, что такие команды должны быть организованы непосредственно вокруг продукта. Продукт — это то, что решает задачу клиента и несет ценность компании. Подобные команды не стоит выстраивать вокруг компонент или функциональных отделов. Для этих целей Скрам не подойдет, так как фреймворк задумывался не для решения оперативных задач, а для того, чтобы достигать продуктовых и бизнесовых целей быстрее, сокращая риски.
Когда использовать Скрам
Скрам — это не про «сделать больше задач и успеть в срок». Здесь будет уместнее говорить про возможность создавать небольшими порциями продукт с целью получить обратную связь от пользователей, рынка, заинтересованных лиц, чтобы на основе новых знаний лучше понимать, куда двигаться дальше в процессе разработки. Скрам — это про работу в условиях неопределенности, когда результат плохо предсказуем.
Например, если вы создаете новый продукт и еще не знаете, каким он будет в итоге, вы можете достичь результата путем проведения небольших итераций и быстрых экспериментов, разработки на основе данных с рынка и от пользователей.
Или, скажем, у вас уже есть работающий продукт и вам нужно улучшить конверсию (то есть количество переходов) из корзины в оплату. Ответ не очевиден. Чаще всего, задача в лоб не решается, требуются эксперименты, поэтому процесс работы команды строится итерациями (в Скрам они называются Спринты).
В результате каждого спринта команда должна создать законченный кусочек продукта, который можно показать пользователям и другим стейкхолдерам, чтобы получить обратную связь. Команда заранее определяет критерии готовности продукта, чтобы одинаково понимать, что нужно сделать, чтобы продукт считать готовым. Условия выбора задач в спринт не должны быть слишком детальные, наличие излишнего анализа и документации также не приветствуются. В Спринте не должно остаться незаконченной работы!
Несмотря на гибкость фреймворка, не стоит забывать о таком важном этапе, как планирование. Планирование спринта проводится для определения объема работы на спринт и целей спринта. Внутри спринта команда использует следующие ритуалы:
ежедневные встречи (daily scrum или standup) — для синхронизации движения к цели спринта;
обзоры спринта (review или demo) — для обсуждения готового продукта со стейкхолдерами и пользователями;
ретроспективы (retro) — для обсуждения улучшения работы Скрам-команды.
Работа команды и ее взаимодействие со стейкхолдерами должна быть прозрачной. Для этого используется достаточно распространенный инструмент — доска, на которой визуализируются все процессы и работы. Так как Скрам отвергает разделение ответственности и ярко выраженные этапы (например, они могут идти параллельно), количество колонок зачастую минимально, их три: to do — взяли на спринт, in progress — в процессе, done — имеем результат.
Резюмируем
Фреймворк Скрам стоит применять в продуктовой разработке для того, чтобы чаще и быстрее тестировать новые версии продукта и корректировать вектор на основе обратной связи. Работает в условиях неопределенности. Чтобы начать работать по Скраму, нужно сначала создать кроссфункциональную команду и обеспечить ее необходимыми ролями — Владельцем продукта и Скрам мастером, а далее запустить спринты, в течение которых команда создает кусочек ценности, вы должны показать его заинтересованным лицам и протестировать на пользователях.
А чтобы узнать больше о ролевой модели в Скрам, приходите на бесплатный открытый урок в OTUS. На уроке обсудим, кто такие Скрам мастер, Владелец продукта и команда, и как меняется ролевая модель. Также разберем, в чем разница между проектным и продуктовым подходами, какие есть роли в этих командах и что изменяется, когда мы переходим в Скрам. Зарегистрироваться можно по ссылке ниже.
А если вам понравилась статья, жду в своем телеграмм-канале и на сайте.
