Проникает ли водопад в ваш Agile? Распознайте 7 признаков!

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

Давайте проясним: в самом по себе подходе водопада нет ничего плохого. Он идеально подходит для определённых типов проектов (например, строительства здания). Но если вы стремитесь к Agile, а на деле у вас получается водопад, это уже совсем другая история. Так как же диагностировать скрытый синдром водопада и, что ещё важнее, как его излечить? Именно это мы и рассмотрим в этом посте.

Признак №1: Функциональная структура команды

Что это такое?

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

Почему это плохо?

Этот подход создаёт множество проблем. Координация становится сложной задачей, часто требующей использования диаграмм Ганта и проектных планов — типичных признаков водопада. Более того, каждая команда отвечает только за свою часть работы, и никто не берёт на себя ответственность за общий клиентский опыт. На создание каждой новой функции или продукта могут уйти месяцы, так как работа должна пройти через множество команд и не раз быть деприоритизированной.

Что делать?

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

Признак №2: Горизонтальное разделение работы

Что это такое?

Представьте свой конечный продукт как торт с несколькими слоями — дизайн, функциональность и тестирование. Даже если вы не можете сразу предложить весь торт клиентам, вы хотите предоставить им небольшой кусочек (с полным набором слоёв и глазурью), чтобы они могли попробовать его и дать обратную связь. Этот "кусочек" символизирует функцию — вертикальный срез через все слои, который приносит видимую ценность клиенту. Однако команды часто пытаются сэкономить время, разбивая работу горизонтально — сначала проектируют все функции, затем создают функционал и так далее.

Почему это плохо?

Хотя это может показаться стратегией экономии времени, на самом деле это ловушка. Представьте, что вы тратите недели на создание, как вам кажется, идеального шоколадного торта, а затем выясняется, что ваши клиенты ненавидят шоколад. Agile предлагает подход "один кусочек за раз", чтобы вы могли быстро протестировать предположения и адаптироваться — это ключевые принципы Agile.

Что делать?

Используйте пользовательские истории. Хотя они не единственный способ структурировать работу, они очень эффективны для вертикального деления задач. Убедитесь, что каждая задача чётко формулирует ценность для клиента. Например, "создать кнопку" не несёт очевидной ценности, тогда как "внедрить функцию отписки" — да. Вертикальное деление задач обеспечивает видимую ценность в каждом инкременте и поддерживает настоящую Agile-среду.

Признак №3: Фиксированные дорожные карты и планы

Что это такое?

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

Зависимости от других команд добавляют жёсткие временные рамки, оставляя мало пространства для гибкости.

Почему это плохо?

Одно из главных преимуществ Agile — это способность адаптироваться к изменениям, учиться у клиентов, совершенствоваться и, при необходимости, менять курс. Фиксированный объём работы лишает этой гибкости и ограничивает возможности для экспериментов и реакции на изменяющуюся среду.

Что делать?

Долгосрочное планирование (годовое, квартальное) необходимо, но оно должно служить ориентиром, а не неизменным указом. Каждая команда должна иметь возможность корректировать свои планы и управлять внешними зависимостями по ходу работы. На моём опыте OKR (цели и ключевые результаты) — отличный инструмент. Они переключают фокус с "что мы должны доставить" на "какой результат мы хотим достичь", что лучше соответствует Agile-принципам.

Признак №4: Крупные релизы и вехи

Что это такое?

Допустим, у вас есть гибкость в отношении функций, но вы установили жёсткие сроки для релизов и достижения вех. В этом случае высока вероятность, что вы неосознанно внедряете водопад в свой Agile-подход. Часто менеджеры вводят искусственные дедлайны, чтобы "держать команды в тонусе" или "ускорить запуск". На деле такой подход обычно даёт противоположный эффект.

Почему это плохо?

Дедлайны ставят команду перед треугольником управления проектами: объём, бюджет и график. Жёсткие сроки неизбежно влияют на объём (или бюджет, который редко можно легко скорректировать), переключая фокус команды с максимизации ценности для клиента на соблюдение временных рамок. Стресс, вызванный дедлайнами, негативно сказывается на здоровье команды и мотивации её членов. Кроме того, новые идеи часто встречают сопротивление, так как их воспринимают как отвлечение от цели "уложиться в сроки".

Что делать?

Как ни парадоксально, попробуйте отказаться от дедлайнов и предоставьте каждой команде возможность самостоятельно устанавливать график работы. Здесь снова на помощь приходят OKR. Сосредоточив внимание на достижении конкретных результатов, команды сохраняют ответственность за свою продуктивность, но при этом получают свободу определять, над чем работать и в каком порядке.

Признак №5: Метрики и результаты исследований не влияют на планы

Что это такое?

Возможно, вы используете Agile-фреймворк и сохраняете гибкость в рамках объёма работы, но корректируете ли вы свою работу в соответствии с полученными данными? Нередко команды проводят исследования клиентов, собирают результаты тестирования, но затем продолжают двигаться по первоначальной траектории, игнорируя эти новые знания.

Явный признак скрытого водопада — неспособность адаптироваться к изменяющимся обстоятельствам.

Почему это плохо?

Игнорируя новые данные, вы рискуете упустить значительные возможности или потратить время на инициативы, которые никому не нужны. Жёсткое следование изначальному плану, несмотря на доказательства, указывающие на необходимость изменения курса, подавляет инновации и снижает удовлетворённость клиентов.

Что делать?

Каждая новая информация должна влиять на процесс планирования, будь то возможность воспользоваться неожиданным шансом или необходимость отказаться от функций, которые не нравятся клиентам. Чем быстрее вы сможете внести эти корректировки, тем лучше. Начинайте каждую встречу по планированию с анализа последних данных и убедитесь, что приоритеты продукта соответствуют запросам клиентов и рыночным условиям. Иными словами, пусть данные управляют вашим Agile-подходом.

Признак №6: Ориентация на объём работы, а не на результаты

Что это такое?

Если команда сосредоточена больше на «выполнении задач», чем на «достижении результатов», это тревожный сигнал. Например, в Японии, где я живу, это очень распространённая проблема. Вы можете предложить инновационное решение, которое сэкономит компании много времени и денег, но повышение может получить ваш коллега, который каждый день проводит в офисе несколько лишних часов (хотя и не всегда эффективно). Это происходит потому, что его воспринимают как "усердно работающего".

В Agile, однако, ценится не то, сколько вы делаете, а каков результат вашей работы.

Почему это плохо?

Фокус на объёме работы вместо результата создаёт неверные стимулы и подталкивает к предпочтению количества над качеством. Это мешает командам искать творческие подходы: зачем предлагать инновационные способы создания ценности для клиента, если можно просто завалить его большим количеством нестыкующихся функций?

Что делать?

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

Признак №7: Отсутствие психологической безопасности

Что это такое?

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

Почему это плохо?

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

Что делать?

Развитие психологической безопасности должно начинаться с лидеров: подавайте пример, демонстрируйте уязвимость и чётко показывайте, что ошибки — это нормально. Награждайте за эксперименты, а не только за их успех или неудачу. Создайте среду, где ошибки открыто обсуждаются и воспринимаются как возможность для обучения, а не как нечто, чего следует избегать.

В завершение хочу ещё раз подчеркнуть, что в самом по себе подходе водопада нет ничего плохого, если он сознательно выбран для подходящего контекста. Однако если водопад проникает в ваш Agile незаметно, это может стать серьёзным препятствием. Надеюсь, этот пост помог вам выявить способы, которыми скрытый водопад может негативно влиять на вашу команду, и предоставил инструменты для борьбы с этим явлением.

Помните, Agile — это не конечная цель, а путь. Это всего лишь способ работы, который помогает вам достигать ваших целей и приносить больше ценности. Вместо того чтобы стремиться к идее стать "на 100% Agile", пользуйтесь здравым смыслом и постоянно спрашивайте себя: "Максимизирую ли я эффективность своей работы и работы моей команды в данный момент?" Успехов вам на вашем Agile-пути!