Продуктовые фреймворки и зачем они нужны

Что это – продуктовый фреймворк? Если говорить простым языком, это шаблон организации процессов, которая нужна для создания продукта. Шаблон описывает, по какому принципу будут работать сотрудники, как менеджер будет управлять деятельностью людей, в какой последовательности выполнятся действия.

Из фреймворков, адаптированных под условия конкретной задачи, складывается цикл работы над проектом. С использованием этих шаблонов легче организовать работу так, чтобы продукт был готов вовремя, сотрудники выполняли обязанности эффективно, а роли были распределены грамотно.

Scrum как основа современных фреймворков

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

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

LeSS

Фреймворк «Лесс» – это что? Грубо говоря, это скрам, адаптированный под большие масштабы проекта. Даже само название LeSS расшифровывается как Large-Scale Scrum. Идея шаблона в том, чтобы применить принципы скрама на больших проектах настолько просто, насколько это в принципе возможно – потому что излишнее усложнение только создает проблемы.

Особенность фреймворка LeSS в том, что он применяется к большому числу команд, которые работают вместе над одним и тем же большим end-to-end продуктом, ориентированным на клиента.

Принципы использования.

Из сказанного вытекают следующие принципы:

• LeSS – это фреймворк Scrum. Не «улучшенная версия», не другая модель – просто скрам, отмасштабированный под большие проекты;
• больше результатов с помощью меньшего. Не нужно вводить новые роли, новую документацию – лучше повышать ответственность существующих ролей и значимость работы;
• фокус на продукте. Целиком, а не по отдельности. Это важно;
• ориентирование на клиента. Думать следует о нуждах потребителя и о его реальных проблемах;
• прозрачность. Важны реальные и осязаемые результаты, а также командная работа;
• непрерывное совершенствование. Процессы выполняются постоянно, без пауз и лишних затрат, и конечная цель – улучшать и модернизировать продукт;
• lean-мышление – мышление менеджеров в ключе снижения потерь, постоянного улучшения продукта и уважения к исполнителям;
• эмпирический контроль. Продумывайте развитие в соответствии с контекстом, а не по заданным шаблонам;
• теория массового обслуживания. Ее можно применить для работы с крупным проектом.

Spotify

Вы правы: модель имеет отношение к одноименному музыкальному сервису. Именно его создатели впервые использовали ее в ходе организационного эксперимента – и вполне успешно. Фреймворк Spotify тоже следует гибкой методолологии, но не основан на уже имеющихся моделях:

• вместо стандартных скрам-команд используются отряды, работающие над определенными задачами – они могут сами видоизменять методологию внутри себя. Основные требования к этим группам – высокая мотивация, автономность и соответствие идеям и миссии компании;
• отряды со схожими принципами объединяются в племена, которые периодически совещаются друг с другом. Так устраняются зависимости, а команды убеждаются, что следуют единой миссии;
• существуют также отделы и гильдии – группы людей из разных команд, объединенные схожей сферой деятельности. Например, отдел бэкенд-разработчиков. Гильдия отличается тем, что в нее входят не только представители одного направления, но и те, кто интересуется этой сферой.

Nexus

Название фреймворка Nexus расшифровывается как «связь». По сути он, как и LeSS, является масштабируемой версией Scrum. Модель описывает дополнения к скраму, которые призваны гибко масштабировать процессы для многочисленных команд. Именно работа нескольких команд – то, на чем фокусируется этот фреймворк.

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

SAFe

SAFe – Agile-фреймворк, цель которого – получить возможность использовать гибкие методологии в больших командах. Название расшифровывается как Scaled Agile Framework и само по себе говорит о масштабируемости. Модель ориентирована на экономику предприятия, очень популярна и активно используется в крупных коммерческих проектах. Фреймворк SAFe:

• унифицирует подход к выполняемым задачам, делает его более предсказуемым и упорядоченным. На оригинальный Scrum накладывается новый процессный слой, который детализирует работу;
• разделяет организацию на три уровня: командный, программный и портфолио. Уровни взаимодействуют между собой, команды разделяются на группы по 8–10 человек и создают так называемые поезда релизов – проекты, привязанные к одной программе. Каждая программа – отдельная статья бюджета;
• привязывает организацию разработки к экономике предприятия, обеспечивает четкий и понятный подход, поэтому крайне популярна в больших компаниях.

Цель фреймворка SAFe – распространить Agile-подход на крупные команды до 50, 100 и более человек.

Scrum of Scrums

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

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