Привет, Хабр! Меня зовут Александр. Я ведущий инженер-технолог в авиационной литейке. И я нашёл один диагноз, который вскрывает все симптомы зомби-Agile – не десять объяснений, а одну единую структуру. И инструмент, чтобы поставить этот диагноз в вашей команде.

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

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

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

Вот Рон Джеффрис – один из авторов манифеста Agile – призывает отказаться от того, во что его превратили. Вот статья «Scrum должен умереть» – ритуалы создают ощущение контроля, но не создают ценность. Вот Agile-коуч из Ростелекома описывает «зомби-скрам»: фреймворк формально внедрён, но по нему никто не работает. Вот статья «Agile умер» – гибкость заменили ритуалами, здравый смысл – диаграммами.

И это не отдельные статьи недовольных авторов. Цифры говорят то же.

По данным 17-го State of Agile Report, удовлетворённость Agile упала с 72% до 59%. Внедряют больше, довольны меньше. И это не абстракция: почти половина респондентов называет главным барьером сопротивление изменениям, а 36% – то, что руководство не понимает Agile и ставит препятствия. Типичная картина: вложили деньги в трансформацию – коучи, тренинги, новые роли – а через год-два смотрят и не видят конкретного результата. Где скорость? Где деньги? Давление растёт, потому что деньги вложены, а ценности нет.

Можно было бы списать это на временный спад. Но с тех пор ничего не рассосалось. 18-й отчёт State of Agile (2025) фиксирует: только 13% респондентов считают, что Agile глубоко встроен в их организацию, а 42% описывают культуру как «лучше, чем ничего, но могло бы быть эффективнее». 63% компаний признают, что с трудом выпускают надёжное и качественное ПО – на 12 пунктов хуже, чем годом ранее. Руководители лишь в 15% организаций реально участвуют в формировании Agile-практик, а 74% компаний уже отошли от «чистых» фреймворков к гибридным и самодельным моделям. Инвестиции при этом выросли – но выросли и вопросы: 76% организаций столкнулись с требованием доказать отдачу от Agile. То есть проблема не «рассосалась» – она закрепилась. Деньги по-прежнему вкладывают, ценности по-прежнему не видно.

У нас в России – та же картина. ScrumTrek – крупнейшее российское исследование Agile – по данным за 2022 год показывает, что 22% компаний только пробуют Agile, 59% внедрили, но не дозрели, и лишь 19% работают по-настоящему гибко. Большинство застревает посередине. Команды переходят от экспериментов к рутине, а зрелых всё так же мало.

Эти цифры подтверждают то, что айтишники и так знают. Но они не объясняют, почему. Я читал это и чувствовал: что-то не сходится. Все пишут о разном, но как будто об одном и том же.

Все эти статьи рассматривают ситуацию одним углом: что-то не работает. Стендапы проводятся, но никто не слушает. Ретроспективы проходят, но ответы одни и те же. Метрики считаются, но ничего не значат. И каждый раз предлагают своё лекарство: сменить фреймворк, убрать ритуалы, нанять другого коуча или убрать коуча вообще. Всё это делают, а проблема годами всё остаётся и никуда не собирается уходить.

Тут меня осенило. Я это уже видел. На заводе.

У нас бывает так: техпроцесс прописан идеально – по ГОСТу, по регламенту. Но на литейном участке делают иначе. Не потому что не знают технологию – а потому что иначе быстрее, или удобнее, или «так исторически сложилось». И смысл? Смысл – не упасть в брак, не забраковать партию. Но между регламентом и реальной операцией – зазор. И в этом зазоре живёт то, что никто не описывает: практика, которая не совпадает ни с правилом, ни со смыслом.

Когда я читал про Agile-команды, где «стендапы есть, а смысла в них нет», я видел ровно то же расхождение. Только в литейке оно измеряется в забракованных отливках, а в IT – в выгорании и velocity, которое ничего не значит. Я уже знал, что это не просто параллель между заводом и IT, а одна и та же структура. И она универсальна. Но почему этот разрыв возникает – не в конкретной команде, а в принципе – я не понимал.

Вот как это выглядит на практике. Не в теории, а в командах, которые вы скорее всего узнаете.

Кейсы

Четыре ситуации. В каждой – знакомая картина: правило есть, практика другая, смысл потерян.

• Кейс 1. «Готово» – когда каждый понимает по-своему

В команде есть Definition of Done. Прописан, все согласились. Код-ревью минимум одним коллегой. Тесты. Документация обновлена.

На практике: в пятницу вечером, до конца спринта два часа. Если не закрыть задачу сейчас – она кочует в следующий спринт, и спринт-гол сорван. Ревьюер ставит одобрение за тридцать секунд – не потому что плохой разработчик, а потому что выбора нет. Тесты? «Напишу в следующем спринте». Документация? «Тут всё понятно». На демо показывают экран, который работает – на машине разработчика, с тестовыми данными. Задача уходит в «Done».

Правило: DoD прописан и согласован. Практика: соблюдается формально, но содержательно пуст – галочки стоят, качества нет. Смысл DoD – «это можно показать пользователю и не бояться» – теряется, потому что давление спринта сильнее. Когда выбор – «закрыть задачу или сорвать спринт-гол» – разработчик закрывает, и он прав по правилам игры, в которой живёт. За невыполненный план наказывают, за формальное соблюдение стандарта – нет. Стандарт не отменили – его обошли по форме: в системе, где план важнее качества, стандарт всегда проигрывает. Это не экзотика – формальное соблюдение DoD исследователи фиксируют как массовый паттерн: команда делает вид, что соблюдает стандарт, а стандарт делает вид, что работает.

Правило и практика разошлись. Сказано одно, сделано другое. Но почему?

• Кейс 2. Product Owner, который ничего не owns

Второй – про роль.

В компании внедрили Scrum. Назначили Product Owner'а. Он ведёт бэклог, расставляет приоритеты, проводит планирование. Формально – всё по гайду.

Но на практике: приоритеты спускаются сверху. Вице-президент приходит к PO и говорит: «Вот эти три фичи – к концу квартала, без вариантов». PO идёт к команде и ставит их в бэклог первым приоритетом. Команда знает, что эти три фичи – не от PO. Они от вице-президента. PO это тоже знает. Но по бэклогу – приоритеты «PO». По Jira – «PO расставил». По гайду – «PO управляет бэклогом».

Правило: PO управляет бэклогом и максимизирует ценность. Практика: PO записывает чужие решения в Jira. Смысл роли – «я отвечаю за то, что мы делаем и почему» – отсутствует. PO получил название, но не получил власть: это ловушка, в которой человек отвечает за результат, который не контролирует. Команда это видит и не приходит к PO с идеями – потому что знает: PO ничего не решит. Роль пустеет на глазах. Должность есть в Jira. Власти нет в жизни. PO получает зарплату, как PO. Отвечает – как секретарь. И это не частный случай – в Agile-сообществе такую роль так и называют: прокси-владелец. Человек, который выглядит как владелец продукта, но решения принимает кто-то другой.

Смысл и правило разошлись. Роль задумана для одного, встроена в другое. Но кто это видит?

• Кейс 3. Ретроспектива, где одни и те же проблемы живут годами

Третий – про встречу.

Команда проводит ретроспективу каждые две недели. Стикеры, «что хорошо – что плохо – что улучшить». Action items записывают. Вешают на доску. Назначают ответственного. Ставят срок.

Через две недели – следующая ретро. Action items с прошлой – не выполнены. «Не успели». «Был релиз». «Приоритеты сменились». Ответственный кивает. Все понимают. Записывают новые action items – часто те же самые. «Разобрать легаси в модуле авторизации». «Покрыть тестами ядро». «Настроить автоматическую проверку». Вешают на доску. Через две недели – снова не выполнены.

Сначала команда поднимала проблемы активно. Потом – по инерции. Потом – перестала. Ретроспектива жила, пока у неё был смысл: «мы говорим – нас слышат – что-то меняется». Когда стало ясно, что action items не выполняются не из-за лени, а потому что бюджет на рефакторинг не выделяют, приоритеты спускают сверху, а PO говорит «фичи важнее» – смысл умер. Практика осталась. Когда команда перестаёт поднимать реальные проблемы и начинает писать «улучшить коммуникацию» – это не лень. Это адаптация к системе, в которой искренность не приводит к изменениям, а только к разочарованию.

Практика и смысл разошлись. Ритуал остался, зачем – забыто. Но когда это началось?

• Кейс 4. Спринт, который ничего не поставил

Четвёртый – про весь цикл.

Спринт за спринтом. Планирование, дейли, демо, ретро – всё по календарю. Задачи берутся, закрываются, переносятся. Но если спросить: «Что мы доставили пользователю за последние три спринта?» – ответ: «Ну... мы работали. Много чего сделали. Почти готово».

«Почти готово» – не просто частая фраза, а сжатый диагноз. Эту фразу слышал каждый, кто работал в Agile-команде: правило требует результата, практика производит незакрытые задачи, а смысл подменён отработанными двумя неделями. Задачи кочуют из спринта в спринт. На демо показывают «почти работающую» фичу – ещё немного багфиксов, ещё немного тестов, ещё одна неделя – и будет готово. Но «ещё немного» каждый раз превращается в следующий спринт. Того, что можно показать пользователю и сказать «вот, это работает, пользуйтесь» – нет.

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

Все три уровня разошлись. Но как?

Четыре кейса. Четыре проявления одного диагноза. В каждом форма воспроизводится, а функция умирает. И это не только Agile-патология. Это паттерн, который повторяется везде, где есть три уровня: правила, практики и смыслы – от цеха до министерства, от команды до корпорации.

Это не метафора. Возьмите университет. Правило – образовательный стандарт и учебный план. Практика – преподаватели ставят «тройки за посещаемость», закрывают глаза на списывание, потому что отчислить студента – это отчётность, комиссия, объяснения. Смысл – «подготовить специалиста» – расходится и с правилом, и с практикой: стандарт писан для специалиста, а не для отчёта, а тройка за посещаемость специалиста не готовит. Та же триада. Те же три оси. Тот же зомби – система воспроизводится, но не выполняет свою функцию.

Я заметил: во всех кейсах проблема не в уровнях, а в связях между ними. Но почему эти связи рвутся? Я искал ответ в социологии. Вечерами после смен я читал Вебера, Дюркгейма, Бурдье, Гидденса. И видел знакомую картину. Вебер смотрел на смысл (за действием стоит то, что оно значит для человека). Дюркгейм – на правило (оно держит группу). Бурдье – на практику (она воспроизводится как привычка). Гидденс пытался их соединить, но у него всё свелось к одной оси: структура против действия.

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

Постепенно у меня появилась простая идея. Любая система – завод, команда, организация – держится на трёх вещах. Правило – что прописано. Практика – что реально делают. Смысл – зачем это нужно. В литейке это технология, реальная операция и годность детали. Если все три совпадают – правило работает, практика ему следует, смысл объясняет зачем – система здорова. Если хоть один расходится – начинается брак, имитация, выгорание.

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

И когда я применил этот объём к тому, что читал про Agile, всё встало на свои места. В Agile: правило – Scrum Guide, фреймворк, регламент команды. Практика – то, что реально происходит на стендапах и ретроспективах. Смысл – зачем команда это делает, видит ли она ценность того, что делает.

Стало понятно: «зомби-Agile» – это не просто плохой Scrum Master и не неправильный фреймворк. Это рассогласование трёх уровней, при котором оболочка остаётся, а суть исчезает.

Три уровня – это три точки. Между ними – три линии. Каждая пара может расходиться независимо: практика не совпадает с правилом – соблюдаем форму, но нарушаем стандарт. Практика не совпадает со смыслом – делаем без понимания зачем. Смысл не совпадает с правилом – правило организации перекрывает смысл. И за каждым разрывом стоит конкретная сила. Это не бинарные совпадения. Правило и практика могут совпадать в одном и расходиться в другом – а смысл жить по своей логике в третьем. Оси – это градиенты, а не равенства.

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

Ось «Правило – Практика»

Закон Гудхарта: «когда метрика становится целью, она перестаёт быть хорошей метрикой». Velocity была задумана как инструмент планирования – «сколько команда реально тянет за спринт?». Но в тот момент, когда менеджмент говорит «увеличьте velocity на 20% в этом квартале», метрика становится целью. И практика расходится с правилом: задача, которая была на 3 поинта, становится на 5. Velocity растёт на бумаге – реальная скорость не меняется. Правило бизнеса (KPI) перекрывает правило гайда – и команда рационально имитирует оба: цифры растут, планирование формально проводится, а по сути не делается ни того, ни другого. Это не «плохая команда», это единственно рациональное поведение в системе, где честность наказывается, а имитация поощряется. Это то, что мы видели в кейсе про DoD.

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

Но это только одна ось. Есть вторая.

Ось «Практика – Смысл»

Команда продолжает проводить стендапы и ретроспективы не потому, что понимает зачем – а потому что «так принято». Это не глупость. Организации копируют практики не ради эффективности, а ради легитимности – «мы тоже делаем Agile, как все нормальные компании». В социологии это называют институциональным изоморфизмом. Эту закономерность описали ещё в восьмидесятых, и с тех пор она только подтвердилась. Например: компания внедряет Scrum, потому что «все уже внедрили». При этом CEO требует еженедельные отчёты по каждому проекту, а решения принимаются на совещании наверху. Стендапы проводятся. Ретроспективы – тоже. Но если спросить команду «зачем?» – ответ: «потому что так надо». Здесь «так принято» становится негласным правилом компании. И это правило оказывается сильнее смысла: команда воспроизводит практику, чтобы соответствовать ожиданиям системы, даже если не видит в этом ценности. Практика воспроизводится без смысла, потому что смысл – единственный уровень, который невозможно имитировать. Можно провести стендап по всем правилам. Можно заполнить Jira. Но «зачем мы это делаем?» – этот вопрос либо имеет ответ, либо нет. И если ответа нет, практика становится пустым ритуалом.

Это сила, которая разводит практику и смысл: легитимность вместо эффективности. И это то, что мы видели в кейсе про ретроспективу.

Ось «Смысл – Правило»

Scrum Guide предполагает самоорганизующуюся команду, которая сама решает, как ей работать. Но в большинстве компаний решения принимаются наверху, бюджеты выделяются под проекты, а KPI завязаны на утилизацию, а не на ценность. Здесь сталкиваются два правила: правило Agile (самоорганизация команды) и правило бизнеса (централизованное планирование и контроль). И правило бизнеса оказывается сильнее. Самоорганизация и утилизация – две системы координат. Косметически их не совместить, но компании пытаются: назначают Scrum Master, проводят стендапы, а решения всё равно идут сверху, через план, через KPI. Scrum есть. Agile нет. Правило написано для одной системы координат, а внедряется в другую. Смысл Agile («быстрая реакция на изменения») вступает в противоречие с правилом организации: «план на год, KPI по плану, отклонение – провал».

И то же самое на уровне кошелька: структура бонусов привязана к индивидуальным показателям, а Agile требует командной ответственности. Разработчик, которому платят за личный результат, не будет тратить время на помощь коллегам: это невыгодно. Это не «Agile неправильно внедрили». Это конфликт, который не чинится ни коучем, ни фреймворком, ни новым Scrum Master, потому что проблема не в команде, а в системе координат, в которую команду поместили. И это та сила, которая разводит смысл и правило: две системы координат, которые нельзя совместить. Это именно то, что мы видели в кейсе про PO.

Три оси. Три силы. Каждая разводит свои уровни и держит их в напряжении. Система не может расслабиться, потому что ни одна сила не исчезает сама.

Почему правило бизнеса побеждает

Но тут возникает вопрос, который проще задать, чем обойти. Если правило бизнеса сильнее правила Agile – почему? Почему команда не может просто сказать: «Мы работаем по Scrum Guide, оставьте нас в покое»?

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

Когда два правила сталкиваются, система выбирает то, которое защищает её от гибели. Поэтому KPI и план всегда будут сильнее Scrum Guide. Это не «плохой менеджмент» – это логика любой устойчивой системы: сначала выживание, потом оптимизация.

Но ответ глубже. Команда не может сказать «оставьте нас в покое» – не потому что бизнес сильнее, а потому что команда не отдельная система. Она живёт внутри другой. У неё – своя тройка: гайд, ретроспектива, «ценность для пользователя». Вокруг – другая: план, отчёт наверх, «выполнить задачу». Внешняя не спорит с внутренней – она её переписывает. План становится правилом. Отчёт – практикой. Срок – смыслом. Гайд остаётся на полке. Вот почему в зомби-Agile ломаются не оси по очереди – вся триада разом: одну конфигурацию заменила другая.

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

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

А теперь – что делают с этим чаще всего на практике и почему популярные лекарства не работают.

Почему привычные лекарства не работают

Вот самые популярные рецепты – из статей, комментариев, конференций.

1. «Нанять другого Scrum Master'а». «Ваш Scrum Master просто проводит встречи и ведёт Jira. Нужен настоящий лидер, который меняет организацию». Новый человек приходит полным энтузиазма, проводит ретроспективы по-новому, делает демо с реальными стейкхолдерами. Но через полгода – те же симптомы. Хороший Scrum Master может сделать лучше – но он не может изменить систему координат, в которую встроен. Новый Scrum Master не контролирует KPI организации, не распоряжается бюджетом, не меняет структуру бонусов. Он работает с практикой – но не может изменить правило.

2. «Обучить команду». «Команда не понимает Agile. Объясните ценности – и всё пройдёт». Команда проходит тренинг. Знает, что стендап нужен для синхронизации, а не для отчёта. Но если менеджер требует отчёт на стендапе – стендап станет отчётом, независимо от знаний. Знание – не смысл. Команда знает, как должно быть. Но делает, как выгодно – стимулы сильнее понимания. И это может сделать только хуже. Когда люди знают, как правильно, но система не даёт так делать, появляется цинизм. Обученная команда выгорает быстрее – она слишком хорошо видит абсурд происходящего.

3. «Убрать пустые ритуалы». «Стендапы бесполезны? Отмените. Ретроспективы не работают? Не проводите». Убрали стендап – менеджер нашёл другой способ контроля: ежедневный отчёт в чате, еженедельную встречу, таблицу в Excel. Практика заменилась, рассогласование осталось. Система породила новый ритуал с тем же смыслом – контролем.

4. «Сменить фреймворк или заменить человека». «Scrum не работает? Попробуйте Kanban. Kanban не работает? Возможно, вам нужен SAFe». Но новый фреймворк ложится поверх тех же KPI и бонусов – правило меняется, ось «правило – практика» остаётся, потому что практика подчинена системе стимулов, а не фреймворку.

5. «Нужен сильный Product Owner» – но через некоторое время новый PO становится тем же «секретарём бэклога», потому что вице-президент всё равно спускает приоритеты. Сильный человек в слабой позиции не делает позицию сильной.

6. «Делать Agile правильно» или «Нужны правильные метрики». Но почему не получается? Пока правило организации требует спринт-гол любой ценой, практика будет обходить DoD. Ось «правило – практика» не чинится волевым усилием. А закон Гудхарта не делает исключений для Agile-метрик. Новая метрика в старой системе координат станет новой целью – и поедет по новым рельсам, но в ту же сторону.

Уровни vs оси

Уровни – это правила, практики или смыслы. Ось – связь между ними. Рассогласование живёт не в уровне самом по себе, а в разрыве. Поэтому, когда чинишь один уровень – два других остаются рассогласованными и тянут систему обратно. Вы поменяли фреймворк – три месяца всё по-новому. Потом KPI не изменился, бонусы не изменились, вице-президент не изменился. Практика подтягивается обратно – к старой конфигурации. Вы наняли нового Scrum Master'а – он полгода тянул команду к смыслу. Потом устал, потому что за спринт-гол отвечает не он, за KPI – не он. Смысл, который он привнёс, начал размываться.

Эти три оси существуют одновременно, и выравнивание одной не устраняет напряжение по двум другим. Система возвращается в исходное состояние – как сжатая пружина. Не потому, что лекарство плохое. А потому что две другие оси никуда не делись – их силы продолжают тянуть уровни в разные стороны. Каждый раз кажется, что лекарство было неправильное – а на самом деле лекарство было не от той болезни.

Потому что все эти лекарства – про команду. А задаёт тон – не команда.

Полный диагноз

Теперь вернёмся к нашим кейсам. Когда мы их разбирали, мы видели расхождение уровней. Теперь – полный диагноз: сколько осей рассогласовано в каждом.

Все четыре кейса – три рассогласованные оси. На уровне организации это стагнация: система ещё держится – имитация работает, зарплаты платятся из выручки, люди ходят на работу. Но это не здоровье. Пока хватает инерции, найма и рыночного спроса – она держится. Но технический долг копится, доверие иссякает, люди выгорают и уходят. И в какой-то момент пружина срывается. Три рассогласованные оси – это зомби. Зомби – это стагнация, доведённая до предела: система воспроизводится, но не развивается.

Что это стоит самому бизнесу? Формальное DoD ведёт к росту дефектов в проде – и каждый такой дефект дороже, чем вовремя написанный тест, потому что ловить его приходится не в код-ревью, а на живом продукте. PO без власти – к задержке решений: пока приоритеты согласуются наверху, рынок уходит, а команда простаивает. Ретро без результата – к росту текучести: люди уходят не потому, что устали, а потому, что перестали верить, что что-то изменится – и уходят часто лучшие, потому что у них есть выбор. Спринт без поставки – к техническому долгу, который копится, пока скорость не начинает падать. А когда скорость падает, давление растёт. А давление – это новые KPI, новые отчёты, новый контроль. Что усиливает рассогласование. Это порочный круг.

Каждое такое рассогласование имеет свою цену. Ось «правило – практика» бьёт по качеству и скорости. Ось «практика – смысл» – по людям и доверию. Ось «смысл – правило» – по решениям и гибкости. Ни одна не исчезает сама. Ни одна не чинится ритуалом. Зомби-Agile – это не проблема культуры команд. Это проблема денег, просто компания об этом ещё не знает. Не потому что не считает – а потому что не там смотрит. Она смотрит на уровни. А считать надо оси.

Можно ли разжать пружину?

Да. Но не рывком и не одним лекарством. С точки зрения триадного анализа, точка входа – это ось, где рассогласование сильнее всего и где у вас есть рычаг. Здесь важно не путать диагноз и лечение. Диагностируем мы всегда ось (ищем, где порвана связь), но воздействуем – через уровень: меняем правило, вводим новую практику или объясняем смысл. Нельзя «починить связь» в вакууме – можно только сдвинуть один из уровней так, чтобы связь восстановилась. Диагноз показывает, где точка приложения усилия; как именно – в следующей статье.

И главное: сам Agile – не порок. Есть компании, где он работает – не потому, что им повезло с людьми, а потому, что уровни согласованы. Один и тот же Scrum в одной организации даёт результат, в другой – зомби. Разница – не в фреймворке, а в связях между его элементами. Это и подтверждает рамку: проблема – в конфигурации.

Один диагноз вместо десяти объяснений

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

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

Кому-то может показаться, что я описываю очевидные вещи. DoD соблюдается формально? Известно. PO без полномочий? Известно. Ретроспектива не работает? Тоже известно. Закон Гудхарта? Классика. Институциональный изоморфизм? Расписан за десятилетия до меня. Всё это – да, известно. Но только по отдельности.

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

И вот что происходит, когда вы читаете всё это по отдельности. Про Гудхарта – «надо исправить метрики». Про изоморфизм – «надо объяснить команде смысл». Про конфликт координат – «надо дать PO власть». Каждое решение верное. Но каждое лечит одну ось. И через три месяца система возвращается – потому что две другие не тронуты. А болезнь – в связи.

Вебер, Дюркгейм, Бурдье, Гидденс – каждый описывал одну грань. Триадный анализ показывает: все они – не три теории, поставленные рядом, а три грани одного тела. Только увидев все три – видно объём. Теперь у вас есть язык, чтобы описать то, что вы и так чувствовали. Не «всё плохо», а «вот здесь порвана связь».

Начните с одного: спросите команду, что она доставила пользователю за последние три спринта. Если ответ «почти готово» – вы уже знаете, где искать.

Посчитайте, сколько осей порвано. Одна – система адаптируется: она шатается, ищет обходные пути, но остается живой. Две – стагнирует: люди еще работают, но уже не верят в процесс, имитация становится нормой, а ресурсы тратятся на поддержание фасада. Три – зомби. Это состояние, когда связь потеряна везде: правило – фикция, практика – пустой ритуал, смысл – забыт. Система держится только на инерции и ресурсах. И когда ресурс заканчивается – она распадается. Зомби – это не «очень плохо». Это когда система воспроизводится, но уже не живет. Это и есть ваш диагноз.

Как найти точку входа, не сломать систему и почему иногда лучше ничего не трогать – читайте в следующей статье.

P.S. Для тех, кто любит докопаться до сути: полная теория и строгая методология триадного анализа опубликованы как научный препринт. Там я подробно разбираю, откуда берутся эти три уровня, почему их именно три и как модель соотносится с классической социологией.

Ссылка на препринт: Соколов А. А. «Дуальность мотивационных паттернов и триадный анализ: к социетальной методологии исследования. Статья 1. Теоретико-методологические основания» (DOI: 10.24108/preprints-3114863).
На данный момент журнальная версия статьи проходит процедуру рецензирования.

Мой профиль исследователя в ORCID: 0009-0003-4656-8048.