Псевдо-Agile и календарно-сетевой Agile: хаос против гибкости

На собеседовании кандидат спрашивает: «Как у вас устроены процессы?» Ему отвечают с гордостью: «У нас Agile». Через месяц он понимает, что за этим словом нет ни спринтов, ни ретроспектив, ни приоритизированного бэклога. Есть дедлайн, названный директором на планёрке, диаграмма Ганта в Excel (в лучшем случае) и чат, где задачи прилетают в 23:40. Это гибрид худшего из двух миров: от классического проектного управления взяли жёсткие сроки (которые диктует кто угодно), а от Agile — право ничего не планировать на долго и пренебрегать документацией с убеждённостью, что это у нас такая корпоративная культура.

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

Почему так происходит? Чаще всего псевдо-Agile — это симптом роста. Компания растёт быстрее, чем успевает осознать, что в ней происходит: приходят новые люди, клиенты, направления, а процессы остаются на уровне команды из пяти человек, где всё решалось в одном чате.

Время на стабилизацию не выделяется, потому что всегда есть что-то срочнее. Договорённости не записываются, роли не закрепляются, планирование не пересобирается под новый масштаб. Хаос накапливается, и слово «Agile» становится удобным объяснением, почему всё устроено именно так.

Эту тему я уже затрагивала в статье «Что вам нужно: отпуск или COO?»: рост и стабилизация — разные циклы, и их нельзя смешивать. Псевдо-Agile возникает там, где фазу стабилизации просто пропускают.

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

Это две разные философии, и у каждой своя дисциплина:

	Календарно-сетевое планирование	Agile	Календарно-сетевой Agile	Псевдо-Agile
Сроки	Расчётные, из плана работ	Фиксирован ритм, гибок объём	Ключевые вехи по критическому пути, внутри них — циклы	Назначены сверху, без расчёта
Объём	Зафиксирован в ТЗ	Пересматри-вается каждую итерацию	Каркас зафиксирован, детали — в бэклоге	Растёт без ограничений
Изменения	Через формальный запрос	Через бэклог и приоритеты	Через бэклог, в пределах цикла	В любой момент, в любом канале
Обратная связь	На этапах приёмки	В конце каждой итерации	В конце спринта и на каждом цикле	Когда что-то сломалось
Ответст-венность	У руководителя проекта	У команды и владельца продукта	Циклы — у общего собрания руководителей, спринты — у команд	Ни у кого конкретно

Календарно-сетевой Agile соединяет сильные стороны обоих подходов: сетевой график задаёт циклы и зависимости, а спринты дают гибкость внутри них. Псевдо-Agile берёт от обоих подходов только терминалогию и отбрасывает дисциплину.

Ключевая ошибка — в прочтении Agile-манифеста. Фраза «реагировать на изменения важнее, чем следовать плану» превращается в «план не нужен». Хотя в манифесте прямо сказано: правое тоже ценно, просто левое ценнее.

Пример: Управление лизинговой компанией

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

А что же между? Именно здесь живут процессы, и устроены они по-разному в зависимости от управленческой парадигмы. Разберём это на следующих схемах.

Внутри ящика у лизинговой компании одни и те же шаги. Разница в том, как каждый из них организован.

Шаг процесса	Календарно-сетевое планирование	Agile	Календарно-сетевой Agile	Псевдо-Agile
Заявка	Единая анкета по регламенту	Форма заявки дорабатывается каждую итерацию по отзывам клиентов	Запуск онлайн-заявки — веха плана, удобство формы улучшается в итерациях	Заявки приходят в мессенджеры, на почту и звонком, единого входа нет
Проверка и скоринг	Фиксированные правила риск-отдела, меняются раз в год	Модель скоринга проверяется и уточняется короткими циклами	Требования регулятора и риск-политика — неизменный каркас, модель улучшается внутри него	Менеджер оценивает «на глаз», правила знает один риск-аналитик
Одобрение	Многоуровневая матрица полномочий: долго, но предсказуемо	Кросс-функциональная команда решает в пределах лимитов	Лимиты заданы заранее, внутри них решает команда, сверх них — по регламенту	Всё согласует директор, когда освободится
Подбор автомобиля и договор с дилером	Только аккредитованные дилеры по рамочным договорам	Пул партнёров и условия пересматриваются по данным спроса	Поставка встроена в критический путь сделки, пул дилеров расширяется итерациями	Каждый менеджер договаривается со «своими» дилерами
Договор лизинга	Типовой шаблон, любые изменения через юристов	Шаблон упрощается по отзывам клиентов, юрист работает в команде	Юридическая основа зафиксирована, формат подписания развивается итерациями	Версии договора лежат у разных менеджеров, актуальную знают не все
Первый платёж и график	График по стандартной формуле в учётной системе	Варианты графиков тестируются как продуктовые гипотезы	Расчёт по утверждённой методике, способы оплаты и напоминания улучшаются итерациями	График считают вручную в Excel, ошибки находит клиент
Передача и регистрация	Чек-лист выдачи, сроки по регламенту	Процесс выдачи улучшается по итогам ретроспектив	Дата выдачи — финальная веха, все шаги планируются от неё назад	Дату выдачи обещает продавец, не спросив остальных
Ежемесячные лизинговые платежи и их просрочка	Платежи по графику, просрочка — строго по регламенту: уведомление, пени, передача в отдел взыскания	Напоминания и способы оплаты тестируются, сценарии работы с просрочкой улучшаются по данным	Этапы работы с просрочкой привязаны к срокам (напоминание, претензия, изъятие), каналы и тексты общения с клиентом улучшаются итерациями	О просрочке узнают, когда клиент уже не отвечает, а кто звонит должнику, решают каждый раз заново
Бизнес-документация и оргструктура	Подробные регламенты и должностные инструкции, функциональные отделы: продажи, риски, юристы, взыскание. Документы обновляются редко и отстают от практики	Минимум документации, кросс-функциональные команды вокруг продукта. Знания живут в команде и уходят вместе с людьми	Описаны сквозной процесс и владельцы ключевых вех и рисков. Документы живые и обновляются по итогам итераций, внутри вех работают кросс-функциональные команды	Документации нет или она устарела. Оргструктура на бумаге не совпадает с реальной, и кто за что отвечает, знает только собственник
Управление рисками	Риски описаны заранее и закрыты регламентами. Кредитный и операционный риск под контролем, но новые риски, например падение спроса или рост ставок, замечают поздно	Новые риски видны быстро благодаря коротким циклам. Но в регулируемой сфере частые изменения скоринга и договоров сами создают риск ошибок и претензий регулятора	Неизменный каркас защищает от регуляторных и кредитных рисков, итерации позволяют быстро реагировать на новые. Риски пересматриваются на каждой вехе	Риски никто не ведёт. Кредитный риск зависит от интуиции менеджера, операционный — от того, кто сегодня на работе. Проблемы обнаруживаются уже как просрочка
Удовлетворённость клиента	Сервис предсказуемый, но долгий. Любой нестандартный запрос упирается в регламент	Сервис быстро становится удобнее, но точную дату выдачи автомобиля клиенту назвать сложно	Клиент заранее знает дату получения машины и видит, что сервис со временем улучшается	Опыт зависит от конкретного менеджера: одному клиенту повезло, другой получил неверный график и сорванную дату выдачи
Итог для клиента	Предсказуемо, но медленно	Сервис быстро улучшается, но срок сложно назвать	Понятная дата и процесс, который становится лучше	Каждая сделка — уникальное приключение
Итог для собственника компании	Контроль и предсказуемость, но рост ограничен скоростью регламентов, и более быстрые конкуренты уводят клиентов	Продукт быстро развивается, но денежный поток сложно планировать и сложно отчитываться перед банками и регулятором	Предсказуемые сроки и денежный поток плюс постоянное улучшение: бизнес можно масштабировать и привлекать под него финансирование	Собственник сам становится узким местом: решения идут через него, портфель рисков непрозрачен, бизнес нельзя ни масштабировать, ни продать

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

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

Главный признак псевдо-Agile — у компании нет схемы главного производственного цикла. Никто не может нарисовать путь от «клиента без…» к «клиенту с…», как в примере с лизинговой компанией.

Остальные симптомы — следствия этого:

1. Дата есть, плана нет. Срок релиза объявлен до того, как кто-то оценил объём работ. Команда узнаёт о дедлайне из презентации для инвестора.

2. Спринт, который не защищён. Двухнедельная итерация существует в Jira, но в середине спринта приходит «срочная задача от CEO», и она важнее всего запланированного.

3. Стендап как отчёт начальнику. Ежедневная встреча длится 40 минут, каждый докладывает руководителю, а не синхронизируется с коллегами.

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

5. Бэклог — свалка. В нём 600 задач без приоритета, и никто не может сказать, какая из них самая важная.

6. Нет владельца продукта. Приоритеты одновременно задают продажи, CEO и самый громкий клиент.

7. Документации нет, потому что «у нас же Agile». Знания живут в головах и чатах, а уход одного человека парализует направление.

8. Гибкость в одну сторону. Команда должна принимать любые изменения, но сроки при этом не двигаются.

   
   

Почему компании называют хаос Agile

Почти никто не делает это из злого умысла. Подмена складывается из нескольких понятных причин.

Agile звучит современно. Для кандидатов, инвесторов и клиентов это маркер «мы прогрессивная компания». Слово работает как бейдж, и его вешают, не меняя процессов.

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

Ловушка "свобода без обязательств". Когда нет зафиксированного плана, можно менять приоритеты каждый день и не отвечать за последствия и этим начинают пользоваться все. Хаос перестаёт быть проблемой и становится «псевдо-гибкостью».

Нет человека, который отвечает за процесс. В небольших компаниях роль Scrum-мастера или PM экономят. Основатель тянет всё сам, а процессы не строятся, потому что на них просто не хватает внимания.

Внедрение ограничилось инструментом. Купили Jira или Notion, завели доску с колонками — и решили, что Agile внедрён. Инструмент без договорённостей между людьми остаётся красивой таблицей.

Язык зрелой модели без её практик. Фредерик Лалу в книге «Открывая организации будущего» описывает бирюзовые организации, которые работают без жёсткой иерархии, на самоуправлении. Но их свобода держится на очень чётких договорённостях: например, на процессе совета, когда любой может принять решение, только предварительно выслушав всех, кого оно затронет. Псевдо-Agile устроен как «бирюза на словах»: компания перенимает язык самоорганизации, проактивности и гибкости, но не перенимает дисциплину, на которой они держатся.

Хаос под чужим именем обходится дороже, чем честно признанный хаос. Признанную проблему хотя бы пытаются решить.

• Выгорание команды. Постоянное переключение между «срочными» задачами съедает время и силы. Люди работают много, но ощущения результата нет.

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

• Непредсказуемость для бизнеса. Компании трудно оперировать цифрами, сроками и обязательствами.

• Технический и организационный долг. Решения принимаются «на сейчас», без документации и без пересмотра.

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

Тест: у вас Agile или хаос

Ответьте честно на десять вопросов. Каждое «да» — один балл.

• Каждый член команды может назвать три главных приоритета на эту итерацию.

• Есть один человек, который принимает финальное решение о приоритетах продукта.

• Задачи, добавленные посреди итерации, — исключение, а не норма.

• Сроки называются после оценки командой, а не до неё.

• Если требования растут, обсуждается, что убрать или какой срок сдвинуть.

• Выводы последней ретроспективы привели хотя бы к одному реальному изменению.

• Заказчик или пользователь видит результат минимум раз в месяц.

• Новый сотрудник может разобраться в процессе по документам, а не только по чатам.

• Стендап занимает не больше 15 минут.

• Вы можете назвать метрику, по которой видно, что команда работает лучше, чем полгода назад.

8–10 баллов: у вас работающий Agile, его можно совершенствовать. 4–7 баллов: элементы есть, но система держится на отдельных людях. 0–3 балла: у вас псевдо-Agile. Слово есть, процесса нет.

Что делать руководителю?

Первый шаг — перестать называть происходящее Agile. Честное название проблемы уже меняет разговор в команде.

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

Если вы уже руководите компанией и осознали, что у вас псевдо-Agile. Начните с описания сквозного крупного процесса, не вдаваясь в детали каждого блока: от «клиента без…» к «клиенту с…», как в примере с лизинговой компанией.

Дальше помогут общие шаги:

1. Признайте текущее состояние. Скажите команде прямо: «Сейчас у нас нет устойчивого процесса, и мы будем его строить». Это снимает напряжение между словами и реальностью.

2. Выберите подход осознанно. Не каждой команде нужен Scrum. Если объём работ известен заранее, честный каскадный план лучше имитации спринтов. Если поток задач непредсказуем, подойдёт Kanban с лимитами на незавершённую работу.

3. Назначьте владельца приоритетов. Один человек решает, что важнее. Все остальные приходят с запросами к нему, а не напрямую к исполнителям.

4. Защитите итерацию. Договоритесь, что новая задача попадает в текущий цикл только в обмен на другую. Исключения фиксируются и разбираются на ретроспективе.

5. Связывайте сроки с объёмом. Если дата фиксирована, гибким должен быть объём. Если объём фиксирован, гибкой должна быть дата. Зафиксировать и то и другое без запаса — это не план, а надежда.

6. Измеряйте. Минимальный набор: сколько задач команда закрывает за цикл и сколько времени проходит от идеи до результата. Без цифр любое улучшение остаётся ощущением.

7. Документируйте договорённости. Одна страница с правилами процесса в Confluence или Notion работает лучше, чем десять устных обсуждений.

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

Когда компания говорит «у нас Agile», полезно задать один уточняющий вопрос: «А что изменилось после последней ретроспективы?» Ответ на него расскажет о процессах больше, чем любая презентация.

Хаос можно победить. Но сначала его нужно назвать своим именем.