Все статьи
Почему процессы перестали работать (и это не вина Agile)
Дата: 31.08.2026
«Мы внедрили Scrum по книжке, но получили только современную бюрократию», — с этой болью сталкиваются десятки сильных команд. И дело здесь вовсе не в Agile.
Мир перестал быть предсказуемым. Сегодня за один спринт может измениться всё: от законов и стоимости трафика до возможностей ИИ. Проблема в том, что мы продолжаем строить процессы «на века», хотя главная ценность сейчас — скорость их адаптации. Менеджер больше не управляет стабильностью. Он управляет скоростью изменений.
В новой статье разбираем, как перестать бесконечно переписывать регламенты и начать извлекать выгоду из неопределенности. Внутри — три прикладных инструмента управления хаосом, а также реальные кейсы компаний, которые выросли в кризис благодаря гибкости систем.
На прошлой неделе руководитель одной студии поделился со мной:
— Мы внедрили тот самый Scrum. Обучили всех. Наняли Scrum-мастера. Написали регламенты и настроили workflow. Все по книжке. Знаешь, что изменилось?
— Что?
— Бюрократия. Ее стало больше, только теперь звучит современнее. А команда современнее — быстрее, гибче и адаптивнее — работать не стала.
А на днях я и вовсе наткнулась на очередную ссору в комментариях под статьей про продуктивность, где одни боготворят Agile, цитируя Сазерленда, а другие пытаются понять, в чем эффективность и проблема этой философии.
Забегая вперед, скажу: эффективность и проблема точно не в Agile.
До ковида процессы действительно работали
Не потому что мы были умнее, а после удаленки и с приходом ИИ отупели. Мир стал другим.
Раньше можно было:
- заранее расписать квартал с возможностью буферизации;
- составить четкий roadmap и не переделывать его каждый созвон;
- провести годовую стратегическую сессию и быть уверенным, что через полгода половина решений останется актуальной.
Сегодня это выглядит почти роскошью. Именно поэтому чаще звучат одинаковые выводы:
- Agile больше не работает.
- Scrum вообще умер.
- Процессы стали бюрократией.
Проблема чуть менее понятная на первый взгляд. Она в том, что большинство управленческих процессов проектировалось для совершенно другой среды. И эта среда больше не существует.
Давайте постараемся в этой статье это наконец принять и понять, как жить в новой среде.
Мы живем не быстрее, мы живем менее предсказуемо
Говорят, что мир ускорился, но это не совсем так.
Мы давно живем быстро, еще с появлением интернета. Изменилось другое: снизилось качество предсказуемости, а вместе с ним и возможность что-то долгосрочно планировать.
Раньше, пока команда делает один релиз, могли измениться фокусы компании, желания пользователей и бюджет на команду (и то — сократиться, а не вовсе исчезнуть). Сейчас, только за один спринт, может изменится:
- рынок (а вместе с ним и вся целевая аудитория);
- конкуренты (кто-то быстро ушел, кто-то быстро взлетел);
- стоимость привлечения пользователей (x2-x3);
- курс валют (особенно актуально для международных команд);
- законодательство (привет, блокировки сервисов);
- доступность рекламных каналов (Steam теперь не зарегистрируешь в РФ);
- политика платформ (YouTube отрубил монетизацию, App Store изменил комиссию);
- возможности ИИ (Claude за год из игрушки превратился в middle-специалиста)
— и, соответственно, приоритеты бизнеса.
Сам продукт или проект при этом может почти не измениться. Изменится контекст, в котором он существует.
Именно поэтому хороший процесс тоже начинает ломаться
Это важный момент.
Потому что когда после «идеально выстроенных процессов» компании все еще видят увеличение TTM (Time-To-Market) и засоренный бэклог, то начинают «лечить» процесс всем, чем можно и чем нельзя:
- меняют Scrum на Kanban, и обратно;
- меняют роли/позиции/обязанности, не меняя при этом их сути;
- добавляют новые встречи;
- покупают ЕЩЕ ОДИН таск-трекер;
- переписывают в сотый раз регламенты.
Короче говоря, ищут проблему совсем не там.
Можно иметь идеально настроенный процесс и все равно постоянно его перестраивать. Не потому что процесс плохой, а потому что изменились условия, под которые он проектировался.
Менеджер перестал управлять процессом
И это, мне кажется, влияет на нас, как на руководителей проектов, больше всего.
Раньше задача менеджера звучала примерно так: сделать процесс устойчивым. Сегодня она звучит иначе. сделать процесс гибким.
Это принципиально разные специализации менеджера. Первый менеджер строит систему, как в СССР строили дома: на века. Второй — постоянно адаптирует систему.
Если раньше ценностью была стабильность процессов, сегодня ценностью становится скорость их переосмысления.
Именно поэтому многие команды чувствуют постоянный хаос
Все вокруг боятся хаоса: и вы, и ваша команда, и даже ваш непосредственный руководитель.
В этом нельзя никого винить — это психология. Наш мозг стремится к покою и предсказуемости. Но менеджеры, пережившие уже ни один кризис, знают, что хаос — это не отсутствие процессов. Это материал, с помощью которого они настраивают процессы.
Представьте скульптора. Он не работает с готовой статуей. Он работает с глыбой мрамора. Неровной, непредсказуемой, с трещинами. Его задача не избавиться от глыбы, а научиться видеть в ней форму. Так же и с хаосом.
Ваша задача как менеджера не устранить неопределенность, это невозможно. Хотя руководство будет требовать от вас именно этого. Ваша задача превращать неопределенность в решения быстрее конкурентов.
Конкретный пример. Команда разработки финтех-приложения запланировала релиз. За неделю до запуска ЦБ (прим. ред. — Банк России или Центробанк) изменил требования к идентификации пользователей. Команда сначала запаниковала. а потом перестроилась. Они выкинули бонусную программу, переделали базу для идентификации и выпустили продукт в срок.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на MAX-канал ProAIgile.
И что теперь делать: отказываться от Agile?
Еще раз: проблема не в методологиях. Проблема в том, что мы боготворим их как религию, вместо того чтобы использовать как инструменты.
- Scrum все еще отличный инструмент;
- SAFe — мощная рамка для масштабирования;
- Kanban довольно удобен для потоковой работы.
Поэтому надо сосредоточиться на том какие практики из разных методологий помогут нам именно сейчас, с этой командой, в этих условиях.
Да-да, именно так, потому что завтра вам может предстоить выбрать уже другие практики. А значит проблема не в методологиях как в таковых, а в системе, которую мы выстраиваем с помощью них.
Как это выглядит на практике: пример.
Продуктовая команда в стартап-edtech (30 человек).
Что сработало:
- Взяли из Scrum спринты (но не 2 недели, а 1, так как среда меняется слишком быстро).
- Из Kanban взяли визуализацию потока (доска с WIP-лимитами).
Что не сработало:
- Ретроспективы раз в две недели (заменили на ретро после окончания проекта).
- Дейли созвоны (заменили на асинхронные стендапы в Slack).
Результат:
- TTM (Time to Market) сократился на 40%.
- Команда перестала чувствовать, что «процесс съедает время на работу».
Каких принципов придерживался менеджер:
- не бояться брать разное из разных методологий;
- не бояться выкидывать то, что не работает.
Ваш процесс должен помогать команде быстрее реагировать на изменения, а не защищать вас от изменений.
Какие навыки становятся важнее любого фреймворка
Ближайшие годы будут определяться не тем, кто лучше знает Scrum или SAFe. А тем, кто умеет работать в условиях постоянной неопределенности, а значит:
- Не ждать «всей информации» (её не будет), чтобы принять решение.
- Регулярно задавать вопрос: «Что изменилось в мире? Влияет ли это на нас?»
- Объяснять команде, почему вчерашние договоренности больше не работают (без ощущения провала).
То есть управлять не стабильностью, а скоростью адаптации.
А что делать с этим непрекращающимся хаосом и неопределенностью?
- Первое — перестать ждать, когда они закончатся.
- Второе — перестать воспринимать этот союз как врага.
- Третье — научиться извлекать из этого выгоду.
Звучит как мотивационная чушь? Понимаю, поэтому сейчас на конкретных инструментах и кейсах покажу как на практике не бороться с хаосом, а использовать его.
Инструмент 1: Ежемесячный «Радар изменений»
Ритуал, где команда отвечает на три вопроса:
- Что изменилось в мире вокруг нас за последнюю неделю? Законы, конкуренты, технологии, рынок, поведение пользователей.
- Какие из этих изменений влияют на наши текущие задачи? Не все изменения важны. Фильтруем шум.
- Нужно ли нам что-то изменить прямо сейчас? Да/нет. Если да — вносим в бэклог с приоритетом.
Кейс: команда SaaS-продукта для малого бизнеса на ежемесячном радаре заметили: конкурент запустил интеграцию с популярной CRM.
- Влияет ли это на них? Да. 30% их клиентов используют эту CRM.
- Менять что-то сейчас? Да. Поднимаем приоритет задачи «интеграция с CRM» в топ-3 на следующий спринт.
Результат: вместо того чтобы узнать об этом через три месяца (когда клиенты начнут уходить), команда среагировала заранее.
Инструмент 2: «Буфер на переосмысление»
20% времени каждого спринта/цикла резервируется не под задачи, а под адаптацию и гигиену. Звучит как роскошь? Возможно. Но на самом деле это страховка от пожаров.
Как использовать:
- Если за спринт ничего не изменилось (не добавились срочные задачи, например) — используйте это время на рефакторинг, техдолг, обучение.
- Если изменилось — у вас есть ресурс, чтобы перестроиться без сверхурочных.
Кейс: команда мобильного приложения планировала спринт на 100% загрузки. Каждое изменение требований приводило к кранчам, переработкам и логичным срывам дедлайнов. Изменили подход: планируют только на 80%.
Что в итоге получили:
- Когда Apple изменила гайдлайны App Store, они успели адаптироваться без срыва релиза.
- Когда ничего не менялось — использовали 20% на автотесты (что сократило баги на 30%).
Инструмент 3: «Сценарии вместо планов»
Вместо одного жесткого плана делаете три сценария:
- Оптимистичный (если все идет по плану).
- Реалистичный (если что-то изменится).
- Пессимистичный (если все пойдет не так).
Для каждого прописываете:
- Что делаем?
- Что отбрасываем?
- Какой минимальный результат считаем успехом?
Пример: запуск нового модуля в продукте.
- Оптимистичный сценарий: релиз через 6 недель, все фичи, полное тестирование.
- Реалистичный сценарий: релиз через 8 недель, 80% фич, сокращенное тестирование на критичных путях.
- Пессимистичный сценарий: релиз через 10 недель, только core-фичи, бета-версия для 10% пользователей.
Зачем это нужно? Когда через 4 недели пришло изменение требований, команда не впала в панику. Она просто переключилась на сценарий 2. Без стресса. Без ощущения провала.
Но давайте отойдем от абстрактных, кейсов и рассмотрим как реальные компании выросли во время кризисов.
Кейс Netflix (2011): от DVD к стримингу
В 2011 году Netflix решил резко разделить прокат DVD и развивающийся стриминг, подняв общую цену подписки сразу на 60%. Подписчики взбунтовались, компания потеряла 800 тысяч клиентов, а ее акции рухнули на 77%. Все говорили: «Компания умерла».
Но руководство не стало цепляться за старые процессы ради сиюминутного спасения. Они признали ошибку с ценами, но стратегический курс менять не стали, перестроив бизнес под новую реальность:
- Фокус на стриминге вместо DVD: прокат дисков приносил львиную долю выручки, но его развитие заморозили. Полностью от DVD отказались лишь в 2023 году, когда стриминг уже поглотил мир.
- Ставка на собственный контент: вместо бесконечной покупки дорогих чужих лицензий Netflix начал создавать свои сериалы. Первым суперхитом стал «Карточный домик» в 2013 году.
- Инфраструктура на опережение: компания годами планомерно переводила клиентов в онлайн (стриминг запустили еще в 2007 как бесплатное дополнение к дискам), создавая базу для будущего доминирования.
Сегодня Netflix — мировой лидер онлайн-проката с капитализацией около $300 млрд.
Кейс Авито (2020): пандемия и взрыв шеринг-экономики
Когда весной 2020 года начался жесткий локдаун, привычные личные встречи для передачи товаров на улицах стали невозможны. Казалось, формат классической доски объявлений должен замереть.
Но Авито не просто выстоял, а совершил мощный рывок. Компания выиграла этот кризис благодаря двум вещам:
- Инфраструктура, созданная на опережение: Авито запустил собственную «Доставку» и безопасную онлайн-оплату еще в 2018 году. Когда пришла пандемия, пользователям не пришлось привыкать к новым инструментам — готовое бесконтактное решение уже работало на платформе.
- Мгновенная адаптация под запросы: вместо создания новых разделов команда точечно доработала существующие. В «Авито Работе» моментально вывели в приоритет фильтры «удаленка» и «подработка», а в логистику добавили интеграцию с курьерскими службами для доставки «до двери» внутри городов.
Пандемия не убила бизнес, а ускорила его цифровую трансформацию, окончательно превратив Авито из простой доски объявлений в полноценный и безопасный маркетплейс.
Кризис не убил эти компании. Потому что они не защищали старые процессы. Они перестраивали систему быстрее, чем менялся мир.
Вместо вывода
Мне кажется, главный вопрос последних лет звучит совсем не так: «Какую методологию выбрать? Как построить идеальный процесс?»
Гораздо полезнее спросить себя: как построить гибкую и прозрачную систему управления, которая будет перестраиваться так же быстро, как и мир вокруг нее?
Потому что проблема давно перестала быть процессной. Она стала системной.
Мы больше не живем в эпоху «лучших практик». Мы живем в эпоху постоянной адаптации.
Раньше можно было внедрить процесс и пользоваться им годами. Теперь конкурентным преимуществом становится способность быстрее других отказаться от собственного процесса, когда он перестал работать.
Давайте начнем строить такую систему, которую можно безопасно адаптировать каждую неделю.
Делитесь в комментариях как вы строите сейчас именно такие.
