За последние десятилетия у компаний появился внушительный набор управленческих инструментов. Waterfall, Scrum, Kanban, SAFe — каждый описан, стандартизирован, проверен на тысячах внедрений.

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

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

Методология держится на предположениях о вашей компании

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

У управленческой среды свои закономерности как в России, так и в других странах. Их подтвердили десятилетия социологических исследований, в первую очередь, работы нидерландского социального психолога Герта Хофстеде.

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

Сегодня на Хофстеде ссылаются, когда объясняют, почему практика управления приживается в одной стране и проваливается в соседней. Только средние значения по стране мало что говорят о вашей конкретной команде. Смотреть нужно на то, как эти параметры проявляются у вас.

Два измерения, которые ломают фреймворк

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

Отношение к неопределенности видно по поведению, а не по декларациям. Допускают ли эксперименты? Наказывают ли за ошибку? Как встречают изменение требований посреди работы?

Эти два параметра определяют, заработает ли выбранная методология. Что происходит с популярными фреймворками, когда среда не совпадает с их допущениями?

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

• Waterfall держится на стабильных требованиях, то есть на низкой неопределенности. Если требования меняются по ходу, к моменту сдачи вы получаете устаревшее решение.

• Kanban раскрывается там, где поток задач непредсказуем: поддержка, DevOps, разбор инцидентов. Стоит команде потерять дисциплину — лимиты WIP начинают игнорироваться, а доска превращается в отчётность для галочки.

• SAFe собирали под масштабирование Agile в крупных компаниях с десятками команд. Он требует вложений в обучение и зрелой культуры. Без этого SAFe оборачивается «водопадом с демо»: бюрократическая надстройка создаёт видимость Agile, а скорость падает.

Корень один: инструмент применяют так, будто среда вокруг ничего не значит.

Кейс: Scrum «по книжке», который не дал результата

Крупная компания запускала переход на Agile в ИТ-разработке. Выбрали Scrum, собрали команды, ввели спринты, демо, ретроспективы.

Через несколько месяцев картина выглядела образцово: процессы соблюдались, отчётность была в порядке. Только бизнес-метрики никуда не сдвинулись.

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

Руководство попробовало «дожать» Scrum — усилить контроль, добавить отчётности. Стало хуже. Сработал контринтуитивный ход: внедрение пересобрали заново вместо усиления.

Сначала провели диагностику и нашли три ограничения:

• требования действительно нестабильны, значит нужен итеративный подход;

• делегирование решений низкое, значит полноценный Scrum невозможен;

• команда не готова к быстрым экспериментам, резкая ломка вызывает сопротивление.

Scrum оставили, но перестали внедрять «в чистом виде». Сохранили итерации, прозрачный бэклог, регулярные демо. Часть решений закрепили за руководством открыто, а не по умолчанию. Зону ответственности команд сузили, зато сделали её настоящей. Полномочия расширяли постепенно.

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

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

Три вопроса, которые задают до выбора метода

Как «разобраться с контекстом» на практике? Через проверяемые вопросы, а не интуицию. Перед тем как выбрать или докрутить фреймворк, ответьте на три из них.

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

В каком «мире» живёт задача. Здесь помогает модель Cynefin. Задача предсказуема — берите классику: планирование, документация, контроль. Ясности нет — переходите к экспериментам и гипотезам. Среда непредсказуема и события опережают анализ — сначала действие, потом разбор. Метод следует из типа задачи, а не из того, что Scrum сейчас в моде.

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

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

Если хочется готовый каркас

Диагностику можно держать в голове, а можно опереться на готовый каркас. Один из них — РИМ-III, разработанный Павлом Алфёровым, профессором бизнес-практики Школы управления «СКОЛКОВО». Каркас собирает три вопроса в один инструмент: проверку логики проекта (Пентабазис), определение типа задачи (через Cynefin) и поправку на национальные и организационные особенности.

Ценность тут в порядке шагов, а сами рамки вторичны. Сначала Пентабазис проверяет, есть ли у проекта смысл и ответственный за результат. Затем Cynefin отвечает, в каком режиме работать: где-то достаточно плана и контроля, где-то спасут только короткие итерации. И только в конце каркас спрашивает про среду — иерархию, уровень доверия, отношение к ошибкам — и подсказывает, что в выбранном методе придётся ослабить или усилить под местные правила. Из этой последовательности рождается решение в формате «возьмём итерации, но половину решений оставим за руководством, потому что делегирование тут низкое», вместо рефлекторного «берём Scrum, потому что у всех Scrum».

В отличие от Scrum или SAFe, каркас стоит уровнем выше — помогает выбрать инструмент и понять, как им пользоваться. Если фреймворки сравнить с молотком, отвёрткой и гаечным ключом, диагностический каркас подсказывает, что из этого вообще брать в руки под конкретную задачу. Решение он не диктует. Вместо готового ответа он заставляет проговорить, куда вы идёте и что вам нужно помимо строчки в учебнике.

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

Адаптация вместо копирования

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

Главный вывод

Эффективность методологии держится на том, насколько точно она встроена в вашу реальность, а «правильность» по учебнику тут вторична.

Можно внедрить Scrum и не дождаться Agile. Можно идти по Waterfall и не получить предсказуемости. А можно отступить от канона и управлять результатом вместо процесса. Разницу определяет понимание, куда и зачем вы ставите фреймворк, а сам выбор фреймворка тут второстепенен.

А у вас Agile превратился в инструмент или в ритуал? Расскажите в комментариях, где методология «по книжке» сработала, а где осталась декорацией.