Управление проектами по Agile: как отличить настоящую гибкость от имитации
Разбираемся в принципах полноценного Agile-менеджмента вместе с первым сертифицированным Scrum- и LeSS-тренером в России
Хотите понять, как работает Agile-управление проектами за пределами модных слов и красивых презентаций — нужно разобраться в принципах, которые стоят за этим подходом.
Мы поговорили с Ильей Павличенко, первым сертифицированным Scrum- и LeSS-тренером в России, сооснователем компании Scrum.ru и консультантом по организационному дизайну. Илья рассказал, почему большинство команд только играют в гибкость, а не работают гибко.
Что такое управление проектами по Agile
Agile project management или управлением проектами по Agile — это способ разработки продуктов в условиях комплексности, когда меняются требования, технологии и внешняя среда. В такой ситуации длинные планы не работают: команда идет короткими итерациями, проверяет гипотезы и корректирует курс по ходу.
При этом сама формулировка «управление проектами» для Agile не совсем верная. Ее используют в статьях, на курсах, в корпоративных регламентах. Но если спросить практиков, вы услышите любопытную вещь — в настоящем Agile проектов нет:
Чтобы увидеть, чем Agile отличается от привычного управления проектами, достаточно посмотреть на оба подхода рядом:
→ В классическом проектном управлении команда фиксирует объем, сроки и бюджет на старте и дальше идет по плану. Успех = выполнить план.
→ В Agile логика другая: главная ценность — не только следовать плану, но и быстро менять курс, если этого требует рынок, заказчик или новые данные. Успех = бизнес-ценность. А качество, объем работ, сроки и бюджет — это ограничения, внутри которых команда эту ценность создает.
Для управления проектами по Agile используют разные фреймворки и методологии: Scrum, LeSS, SAFe. Но сама суть Agile — не в конкретном фреймворке, а в гибкости бизнеса. Сейчас расскажем, что это значит.
Что такое гибкость на самом деле
Настоящая гибкость — способность компании разворачиваться: быстро менять приоритеты, структуру и способ работы в ответ на изменения рынка. И разворачиваться должен бизнес целиком, а не отдельная команда внутри него.
Илья утверждает, что именно этот момент большинство компаний упускают, когда пытаются внедрить Agile:
Несмотря на простоту этой идеи, на практике ее реализуют единицы компаний. Разберемся, почему так происходит.
Почему настоящий Agile — это редкость
Причина в том, что серьезная Agile-трансформация требует менять не только процессы, но и структуру власти, систему KPI, принципы найма и премирования. А это болезненно: на кону должности руководителей, бонусы сотрудников, устоявшиеся зоны ответственности.
Поэтому компании предпочитают сохранить статус-кво и ограничиться косметическими изменениями: повесить доску с колонками, назвать менеджера Scrum-мастером, ввести ретроспективы. А когда через год проходит «ретроспектива Agile-трансформации», бизнес делает вывод, что Agile не работает. Илья же говорит, что работает — просто никто его не внедрил.
«Настоящий Agile — это удел очень немногих. Все остальное — театральные постановки.
Это как с музыкой: у популярных эстрадных исполнителей десятки миллионов подписчиков, а у Чайковского слушателей в разы меньше. Но никому не придет в голову сказать, что эстрадный хит глубже симфонии — просто это разные вещи.
С Agile то же самое: массовые имитации популярнее настоящего подхода, но путать их нельзя», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Если компания все-таки хочет внедрить полноценный Agile, один из шагов — выбрать подход под свои задачи.
Как выбирать Agile-подход под задачи бизнеса: 3 сценария
Одна из главных ошибок компаний — слепая привязка к конкретному фреймворку или методологии. Например, перешли на Scrum, потому что модно. Или на SAFe, потому что консультанты посоветовали. А контекст бизнеса может требовать совсем другого.
Перед тем как выбирать подход, руководителю стоит ответить на 3 вопроса:
- Какие организационные способности нужны бизнесу прямо сейчас? Например, быстрая проверка гипотез, стабильность поставок, способность масштабировать разработку на десяток команд — вариантов много. Подход, который вы выберете, должен развивать именно те способности, которые нужны вашему бизнесу.
- Сколько команд работает над одним продуктом — одна или несколько?
- Готова ли компания к тому, что ради гибкости и адаптивности люди будут не всегда полностью загружены, вынуждены учиться новому и помогать коллегам за рамками своих специализаций?
Ответы подскажут, в какую сторону смотреть. Разберем 3 сценария.
Если важна скорость проверки гипотез
Это типичная история продукто-центричных компаний, которые ищут прорывные фичи или борются за долю рынка и для которых важен кратчайший Time to Market (срок вывода продукта или функции на рынок). Приоритеты — короткий срок вывода продукта, быстрая проверка идей, готовность разворачиваться по итогам каждого спринта. Под такие задачи подходит Scrum.
Важный момент: Scrum работает только целиком. Если использовать отдельные его элементы вроде ретроспектив без остального — эмпирическая петля обратной связи ломается, и команда теряет способность корректировать курс на основе реальных данных.
Если продукт большой и над ним работают много команд
Здесь появляется отдельная задача — как организовать работу 8–10 команд над одним продуктом. Для этого есть фреймворки масштабирования, и они по-разному отвечают на один и тот же вопрос: как распределить работу между командами.
- Например, LeSS построен на идее взаимозаменяемых feature-команд: в идеале любая команда может взять любую задачу из продуктового бэклога, потому что владеет всем набором компетенций. Это ориентир, к которому команды двигаются, развивая мультифункциональность.
- А SAFe допускает гибридную модель — часть команд работают как кросс-функциональные, часть закрепляются за конкретными компонентами продукта.
Выбор здесь зависит от амбиций компании. Готова ли она к глубокой перестройке ради кратного роста скорости — или ей достаточно умеренного улучшения существующих процессов. Оба варианта имеют право на жизнь.
Если важна предсказуемость
Это история про компании, которым не нужно подстраиваться под рынок: монополисты с госконтрактами, регулируемые отрасли, стабильные сервисные бизнесы. Главная задача — не сорвать сроки и не налететь на штрафные санкции. Под такую стратегию подходит канбан с ограничением потока. Команда стабилизирует поставку, видит узкие места и плавно выравнивает темп.
При этом важно помнить: сам по себе канбан не относится к Agile и развивался параллельно этой философии. В то же время, если полноценно работать по этому методу, то он станет максимально близок к гибким подходам:
«Канбан популярен вне Agile как раз потому, что не требует глубокой перестройки процессов. Но правильно выстроенный канбан работает иначе — за счет ограничения потока на уровне всей системы люди вынуждены помогать друг другу, брать задачи за пределами своих ролей и вместе разгребать узкие места. Так из группы специалистов постепенно вырастает настоящая команда», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Теперь рассмотрим тонкости, которые часто опускают при переходе на Agile-подход.
Что будет, если взять от Agile только отдельные практики
Выбор подхода — это только половина вопроса. Вторая — насколько глубоко компания готова его внедрять. И здесь большинство совершают типичные ошибки. Например, у компаний часто возникает соблазн взять из Scrum «самое удобное» — ретроспективы и планирование спринта — а остальное оставить на потом.
Работает ли это? Да, но с важными оговорками:
«Здесь все как у спортсменов. Я могу ходить в зал, но при этом неправильно питаться, иногда пропускать тренировки и не следить за режимом. Поможет ли мне это стать лучше? Конечно, поможет. Но если все делать в комплексе, я стану еще лучше. По итогу кто-то будет третьим разрядником, кто-то — мастером спорта, кто-то — олимпийским чемпионом. Это вопрос амбиций», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Поэтому если цель — немного улучшить процессы и сделать работу команды чуть более организованной, частичное применение Scrum даст такой результат. Добавили ретроспективы — команда начала обсуждать ошибки. Ввели планирование спринта — работа стала прозрачнее. Но нужно понимать: это не Scrum, а отдельные его элементы, поэтому эффект будет ровно на глубину внедренных элементов.
А если цель — получить от Scrum весь заявленный эффект: быструю проверку гипотез, способность разворачиваться по итогам спринта, полноценный эмпирический контроль — полумеры не сработают. В таком случае нужно внедрять все элементы сразу: роли, события, артефакты. И в первую очередь — отвечать на вопрос не «какие инструменты Scrum нам пригодятся», а «насколько глубоко мы готовы поменять работу команды».
Что будет, если отдать роль владельца продукта прокси, а не представителю бизнеса
Часто эту роль отдают человеку без реальных полномочий — без собственного бюджета и ответственности за P&L продукта (отчет о прибылях и убытках). В Scrum-сообществе такую фигуру называют прокси: он передает требования от настоящего бизнеса команде, но не принимает сам.
Если такая компания при этом работает по Scrum, то это неправильный подход:
«Настоящий владелец продукта — это всегда человек с реальной властью: он распоряжается бюджетом, определяет стратегию, решает, какие фичи пойдут в разработку, а какие нет. Это не тот, кто пишет пользовательские истории и уточняет требования для разработчиков.
Когда эту роль отдают прокси, у него просто нет полномочий принимать такие решения, поэтому он может только передавать запросы от настоящего бизнеса дальше. А любая передача через посредника — это испорченный телефон: смысл задачи и приоритеты искажаются, пока доходят до разработчиков», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
В то же время если владелец продукта — это топ-менеджер, у него физически не хватит времени писать детальные требования и разбирать каждую задачу. Что делать с этим? Решение — поднять уровень самой команды. Схема при этом выглядит так:
- Владелец продукта задает направление и ставит бизнес-цель: например, «в этом квартале увеличиваем конверсию на третьем этапе воронки с 70 до 90%, есть три гипотезы, как это сделать».
- Команда сама разбирается в деталях: общается с пользователями, проверяет гипотезы, уточняет требования, выбирает техническое решение.
То есть фактически команда становится продуктовой, а не просто исполнительской. Для этого внутри нее должна быть экспертиза продуктового менеджмента, а не только разработки.
Как гибкость бизнеса реализуется на уровне команды
Мы уже говорили, что настоящая гибкость — это свойство всего бизнеса. Но реализуется она через команды, и если команда устроена неправильно, гибкости не будет даже в самой продвинутой компании.
Гибкость команды проще всего проверить на том, как она справляется с меняющейся нагрузкой. Работа в продукте редко идет ровным потоком: в одном спринте пожар у бизнес-аналитика, через пару недель — завал у разработчиков серверной части, а еще через месяц внезапно понадобился дизайнер.
Классическая команда с жестким разделением ролей не готова к таким колебаниям. Когда нагрузка смещается в одну область, часть людей остается без работы, а перегруженные специалисты быстро упираются в предел своей пропускной способности. В результате задачи начинают копиться, сроки растягиваются, а часть команды работает на износ.
Гибкая команда отличается мультифункциональным развитием сотрудников. Это не значит, что дизайнер завтра должен писать код, а разработчик — рисовать макеты. Речь про другое: сотрудники осваивают одну-две смежные специализации, которые им интересны и близки по характеру работы. Например:
- разработчик серверной части учится помогать с интерфейсом;
- аналитик подхватывает часть задач менеджера продукта;
- тестировщик разбирается в архитектуре настолько, чтобы закрывать простые задачи разработки.
За счет такого запаса компетенций команда лучше переваривает пиковые нагрузки. Это и есть гибкость на уровне команды.
Как должны взаимодействовать Agile-команды
Принцип мультифункциональности работает и на уровне между командами. В гибкой продуктовой компании, где над одним продуктом работает 8–10 команд, в идеале любая команда может подхватить работу любой другой. Это крайняя точка максимальной адаптивности, к которой стремятся при построении такой системы.
Но на практике компании часто идут в противоположную сторону. Вместо того чтобы развивать взаимозаменяемость, команды специализируют: например, первая отвечает за мобильное приложение, вторая — за веб-версию, третья — за платежный модуль. Выглядит логично: у каждой команды своя экспертиза, свой участок ответственности. Но именно в этот момент вся система теряет гибкость.
«Завтра залетит слишком много работы, которую могут сделать 2–3 команды. А чем будут заниматься остальные 6? Наверняка менее важной работой, раз более приоритетная им не по профилю», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
И вот здесь проявляется главный подвох. Все команды чем-то заняты, никто не сидит без дела — со стороны кажется, что компания работает эффективно. На деле приоритетное направление движется со скоростью 2–3 команд, которые в нем разбираются, а остальные 6 просто закрывают второстепенные задачи. Компания платит зарплаты за полезную с виду работу, пока ключевые задачи выполняют с ограниченной скоростью.
У специализации есть и второе следствие — очереди зависимостей. Если задача задевает сразу несколько частей продукта, ее нельзя сделать одной командой: нужно дождаться, пока освободится вторая, потом согласовать работу с третьей. Из-за этого срок поставки неизбежно растет, и бизнес теряет скорость.
Могут ли Agile-команды ужиться с остальными
Редкая компания меняется целиком и сразу. Обычно внутри организации параллельно сосуществуют несколько миров: один отдел живет по классическому управлению проектами с жестким планированием, другой пробует Scrum, третий вообще ни о чем таком не слышал. Получится ли в таких условиях создать настоящую Agile-команду, если вся остальная организация играет по своим правилам?
Ответ зависит от автономии руководителя. Гибкая команда требует пересборки множества вещей одновременно: процессов, ролей, метрик, систем мотивации. И чем больше у руководителя полномочий менять это все самому, не согласовывая с половиной компании, тем выше шансы построить внутри гибкую команду.
Обратная ситуация — компания с жесткой вертикалью, где всеми разработчиками управляет IT-директор. В этом случае даже владелец продукта не может просто щелкнуть пальцами и изменить правила работы команды. Каждое изменение превращается в серию согласований со смежными руководителями, и большинство инициатив просто застревают на этом этапе.
«У меня был проект, где руководитель с нуля делал новый продукт. В его подчинении было 40 разработчиков, но полуавтономным он не был. И у нас было очень много проблем: каждый раз, когда требовалось что-то серьезное — например, обучение разработчиков — приходилось идти за согласованием к CTO. Это очень сильно ограничивало», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Поэтому в централизованной организации гибкость возможна только при поддержке сверху: если идею поддерживают CEO и все его прямые подчиненные, команды могут работать по Agile. Без такой поддержки локальная инициатива упрется в смежные отделы на каждом шагу.
А в компаниях с автономными бизнес-юнитами гибкие команды спокойно уживаются с консервативными — руководитель такого юнита сам распоряжается процессами и не зависит от общекорпоративных правил.
3 организационных механизма для сборки Agile-команды
Допустим, автономии у руководителя достаточно и условия для гибкой команды есть. Что делать дальше? Мало объявить людей командой — нужны организационные механизмы, которые делают командную работу возможной.
Реализовать такие условия помогут следующие изменения в процессах:
1. Общая цель и общая награда. Не может быть ситуации, когда один молодец и его хвалят, а остальная команда провалилась. Как бы плохо это ни звучало, нужно фактически ввести круговую поруку: общие KPI, общие бонусы, общая судьба.
2. HR-политики, которые стимулируют помощь коллегам. Например, доплата за мультифункциональное развитие. На практике люди осваивают смежные роли и без этого — из интереса, из желания расти, из вовлеченности в общую цель команды. Но денежный стимул работает как дополнительный стимул и показывает, что компания ценит такое поведение и готова за него платить.
3. Короткие циклы обратной связи. В командах всегда есть трения и дисфункциональное поведение. Кто-то плохо коммуницирует, кто-то срывает договоренности. Но люди стремятся избегать конфликтов и молчать, поэтому нужно встроить в процесс прозрачный диалог и сделать его обязательным.
«Обратная связь должна быть устной, чтобы на нее можно было отреагировать. Проводить встречу можно в простом формате: раз в 2 недели вся команда садится в Zoom на 30–60 минут и обсуждает паттерны поведения друг друга. Обязательно нужен фасилитатор — Scrum-мастер или другой человек, который сделает разговор безопасным», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Еще один элемент — рабочие договоренности на старте. Прежде чем давать обратную связь, команда должна зафиксировать, какие паттерны поведения считает «зелеными», а какие «красными». Это делают при запуске команды или когда ее перезапускают.
Кому не подходит работа в Agile-команде
Работа в настоящей команде требует большого количества коммуникаций и системного мышления. Система зависит от того, как элементы взаимодействуют между собой, а не от того, как они работают по отдельности.
Людям, которые хотят молча сидеть целый день и чтобы их не беспокоили, такой формат не подходит. Им комфортнее в специализированных группах или на платформенных командах, где меньше коллаборации.
В продуктовых командах нагрузка еще выше. Разработчики должны напрямую общаться с пользователями и клиентами, чтобы проверять гипотезы и уточнять требования. Это большой выход за комфортную зону для людей, которые привыкли получать таски из Jira и отдавать результат в вакуум.
«Кому-то, в принципе, не подходят командные виды спорта. Кто-то любит индивидуальные. Это абсолютно нормально», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
По какому принципу выбирать инструменты для команды
Универсального списка инструментов не существует — все зависит от контекста. Но есть принцип, по которому их стоит выбирать:
«Нужны инструменты, которые поощряют высокую степень коллаборации внутри команды. Кайтен, Miro, онлайн-борды, где вы можете совместно работать в один момент времени. Даже Google Docs может быть необходимым и достаточным, если у вас команда редакторов — они одновременно меняют текст, и этого хватает», — Илья Павличенко, консультант по организационному дизайну и сооснователь Scrum.ru.
Ключевой критерий выбора — возможность совместной работы в реальном времени. Инструмент, где один человек что-то пишет, а остальные смотрят результат через день, гибкую команду не поддержит. Инструмент, где 8 человек одновременно двигают карточки, комментируют, связывают задачи и видят изменения коллег, — поддержит.
Как проверить, что у вас настоящий Agile-менеджмент, а не декорация
Для этого ответьте на эти 5 вопросов:
- Владелец продукта распоряжается бюджетом и решает, какие фичи пойдут в разработку? Или он пишет пользовательские истории и передает требования от настоящего заказчика?
- Когда нагрузка смещается с одной роли на другую, команда перераспределяет работу? Или перегруженные специалисты тонут, а остальные ждут своих задач?
- У команды общие KPI и общие награды? Или каждого премируют отдельно за его участок?
- Если над продуктом работает несколько команд, любая из них может взять задачу из приоритетного направления? Или команды закреплены за разными частями продукта?
Чем больше «нет» — тем дальше компания от настоящего Agile-менеджмента. И тем важнее решить: вкладываться в полноценную трансформацию или честно признать, что вам достаточно отдельных практик вроде ретроспектив и планирования спринта.
