Модели Коттера и ADKAR, работа со скептиками, постепенное vs радикальное изменение, измерение принятия
Время освоения: ~45 минут Цель: Научиться проводить изменения в инженерных командах так, чтобы они приживались, а не саботировались
Изменения в командах проваливаются не потому, что идея плохая. Они проваливаются потому, что люди, которым с этим жить, не были готовы. Задача лидера — не продавить изменение, а создать условия, в которых оно станет нормой.
Быстрый справочник
- Люди сопротивляются не изменению, а потере — компетентности, статуса, предсказуемости
- Модель Коттера: 8 шагов, самые частые провалы на шагах 1 и 8
- ADKAR диагностирует, где именно застряло изменение: знание, желание, умение или закрепление
- Скептики бывают трёх типов — каждый требует отдельной стратегии
- Early adopters — ваш главный ресурс: используйте их как агентов изменений
- Gradualism работает для культуры и инструментов; Big Bang — для безопасности и compliance
- Измеряйте adoption: активное использование, error rates, обращения в поддержку
Сопротивление изменениям — не слабость характера и не злой умысел. Это нормальная нейробиологическая реакция.
Нобелевский лауреат Даниэль Канеман описал феномен: потеря ощущается примерно в два раза сильнее, чем эквивалентная выгода. Вы говорите разработчику: «Переходим на новый фреймворк — будет быстрее». Он слышит: «Твой накопленный опыт, твои горячие клавиши, твои любимые паттерны — всё это теряет ценность». Интеллектуально он понимает, что выгода есть. Эмоционально — ощущает угрозу.
У инженера с пятилетним опытом в определённом стеке есть статус — его уважают за экспертизу, к нему приходят с вопросами, его решения принимаются. Если команда переходит на новую технологию, этот статус обнуляется: завтра Junior, который уже изучил новый инструмент, будет знать больше него. Переход на новый процесс также несёт скрытый вопрос: «Значит, то, как мы делали раньше, было неправильно? Значит, я делал неправильно?»
Лидеры часто недооценивают этот момент. Правильный фрейм: «Мы делали правильно для тех условий. Условия изменились — меняемся и мы».
Мозг воспринимает неопределённость как угрозу по умолчанию. Когда людям говорят «скоро будут изменения, детали расскажем позже», они автоматически заполняют пробел худшими сценариями. Молчание лидера интерпретируется не как «всё хорошо», а как «скрывают что-то плохое».
Разработчики по природе своей профессии скептичны и data-driven. «Покажи мне данные, что это лучше» — не саботаж, а профессиональная позиция. Попытка продавить изменение авторитетом («я решил, делаем так») без аргументов вызывает особо сильное сопротивление именно в инженерных командах.
Что работает с инженерами:
Джон Коттер, профессор Harvard Business School, изучил сотни программ изменений и вывел 8 шагов, пропуск любого из которых резко снижает шансы на успех.
Изменение не начнётся, пока достаточное количество людей не почувствует, что статус-кво опасен или неприемлем.
Частая ошибка: Лидер чувствует срочность сам, но не создаёт её у команды. Объявляет решение («переходим на CI/CD»), не объяснив, почему сейчас это критично.
Для инженерных команд: Используйте конкретные данные. «За последний квартал 30% релизов потребовали хотфиксов в первые 24 часа. Три из них — критические. CI/CD снизит этот показатель» — это срочность. «Надо бы автоматизировать деплой» — это нет.
Одного тимлида недостаточно. Нужна группа людей с авторитетом и влиянием, которые поддерживают изменение.
Для внедрения code review: Найдите 2-3 Senior Engineers, которые видят ценность. Они будут отвечать на скептические вопросы коллег убедительнее, чем менеджер — потому что говорят с той же позиции.
Видение должно быть достаточно простым, чтобы его можно было объяснить за 5 минут. Если не можете — оно ещё не готово.
Для внедрения новых процессов: «Через полгода каждый PR проходит ревью минимум одного Senior, у нас есть автоматический прогон тестов, и время от коммита до деплоя в стейджинг — менее 15 минут» — это видение.
Коттер подчёркивает: большинство лидеров недооценивают, сколько коммуникации нужно. В десять раз больше, чем кажется достаточным.
Ключевой принцип: действия говорят громче слов. Если вы объявляете, что code review — приоритет, а сами мёрджите без ревью «потому что горит» — команда берёт сигнал от действия, не от слова.
Люди хотят измениться, но что-то мешает. Это может быть: нет времени (все заняты feature-задачами), нет инструментов, нет знаний, нет полномочий.
Задача лидера на этом шаге: активно искать и устранять барьеры, а не ждать, что люди преодолеют их сами. «У нас нет времени на ревью» — это сигнал, что нужно переоценить WIP, а не призывать стараться больше.
Долгосрочные изменения теряют импульс без промежуточных результатов. Людям нужны доказательства, что изменение работает.
Пример: Внедряете code review — через месяц покажите: «Ревью поймало 12 потенциальных проблем до мерджа, включая одну, которая бы привела к потере данных». Это топливо для продолжения.
Преждевременное объявление победы — один из самых частых провалов. Изменение не завершено, когда все начали делать по-новому. Оно завершено, когда никто не помнит, как делали по-старому.
Изменение должно войти в ДНК команды: в найм («мы ищем людей, которые ценят code review»), в онбординг, в ретроспективы, в описание процессов.
Частый провал: Процесс работает, пока лидер рядом. Когда лидер уходит или отвлекается — команда возвращается к старому. Это значит, изменение не укоренилось в культуре, а держалось на личном авторитете.
ADKAR (Prosci) — прагматичная модель для диагностики изменений. Она описывает 5 состояний, через которые должен пройти каждый человек, чтобы изменение состоялось.
Знает ли человек, зачем нужно изменение?
Не «слышал об этом», а понимает причины и контекст. Если Awareness отсутствует, человек не чувствует потребности меняться.
Диагностика: Спросите разработчика: «Как ты понимаешь, зачем мы вводим обязательный code review?» Если ответ размытый или неточный — Awareness не сформирован.
Хочет ли человек участвовать в изменении?
Awareness есть, но человек говорит: «Да, понимаю зачем, но мне это не нужно / я не согласен». Это Desire-проблема.
Важно: Desire нельзя создать приказом. Его создают через вовлечение в принятие решений, через демонстрацию личной выгоды, через устранение страхов.
Знает ли человек, как делать по-новому?
Многие лидеры переходят сразу от Awareness к требованиям, пропуская Knowledge. «Внедряем TDD» — хорошо. А кто-то объяснил команде, как это делается на практике в вашем конкретном стеке?
Может ли человек применить знание на практике?
Знание и способность — разные вещи. Разработчик посетил воркшоп по code review (Knowledge). Но первые реальные ревью даются с трудом: непонятно, как давать обратную связь конструктивно, сколько времени тратить, что комментировать. Это Ability-проблема. Решается практикой с поддержкой, не лекциями.
Поддерживается ли изменение системой?
Если новое поведение не поощряется и не требуется — люди постепенно возвращаются к старому. Reinforcement создаётся через: признание («отличное ревью, поймал важный баг»), встроенность в процессы (нельзя смёрджить без ревью технически), регулярное обсуждение на ретроспективах.
Если изменение «не идёт», пройдите по каждому компоненту последовательно. ADKAR — каскадная модель: нельзя прыгнуть через этап. Если проблема в Desire, добавление Knowledge ничего не исправит.
| Симптом | Вероятная проблема в ADKAR |
|---|---|
| «Зачем вообще это нужно?» | Awareness |
| «Понимаю зачем, но не хочу» | Desire |
| «Хочу, но не знаю как» | Knowledge |
| «Знаю как, но на практике не получается» | Ability |
| «Делали, но постепенно забросили» | Reinforcement |
Скептики — не враги изменений. Они — бесплатная обратная связь. Проблема не в скептицизме, а в том, что лидеры либо игнорируют скептиков, либо давят на них. Оба подхода проигрышные.
Тип 1: «Не верю, что нужно»
Сигналы: «У нас и так всё работает», «Это решает проблему, которой нет», «Мы уже пробовали что-то похожее — не взлетело».
Стратегия: Работайте с Awareness. Покажите данные, которые создают неудобство со статус-кво. Признайте, что предыдущий опыт был неудачным — и объясните, чем этот раз отличается. Не спорьте; задавайте вопросы: «Что убедило бы тебя, что проблема реальна?»
Тип 2: «Не верю, что получится»
Сигналы: «Хорошая идея, но у нас это не сработает», «Команда к этому не готова», «Слишком сложно, не хватит ресурсов».
Стратегия: Это Desire или Knowledge-проблема, замаскированная под скептицизм. Спросите: «Что конкретно, по-твоему, пойдёт не так?» Разберите каждое опасение. Предложите пилот на ограниченном объёме: «Давай попробуем с одной командой на один спринт».
Тип 3: «Боюсь потерять»
Сигналы: Не говорит явно, но саботирует; технические возражения кажутся надуманными; ведёт себя иначе при начальстве, чем с командой.
Стратегия: Это самый сложный тип — страх потери редко признаётся вслух. Создайте условия для честного разговора: «Слушай, я хочу понять, что тебя беспокоит по-настоящему. Мне важно, чтобы переход был нормальным для всех, включая тебя».
Не каждый человек одинаково легко принимает новое. Диффузия инноваций (Everett Rogers) описывает кривую: сначала инноваторы и ранние последователи (early adopters), затем большинство, затем консерваторы.
Тактика: Не пытайтесь убедить всех одновременно. Найдите 1-2 early adopters — людей с авторитетом в команде, которые видят ценность изменения. Поддержите их, дайте ресурсы, сделайте их успех видимым. Остальные будут наблюдать за тем, что происходит с первыми.
Early adopter в инженерной команде убеждает коллег принять изменение в несколько раз эффективнее, чем менеджер, — потому что не воспринимается как «у него нет выбора, он должен продвигать это».
Есть разница между здоровым скептицизмом и токсичным. Токсичный скептик:
Разговор с токсичным скептиком должен быть прямым: «Я слышу твои возражения и отношусь к ним серьёзно. Мы их обсуждали. Решение принято. Что мне нужно от тебя — либо следовать договорённостям, либо открытый разговор о том, что ты не согласен. Тихий саботаж — не вариант».
Не все изменения вводятся одинаково. Выбор между постепенным и резким внедрением — стратегическое решение.
Культурные изменения: Психологическая безопасность, открытость к обратной связи, культура code review — это меняется месяцами и годами. Попытка «запустить культуру» за один спринт не работает.
Новые инструменты разработки: Внедрение нового IDE, фреймворка, инструмента мониторинга — людям нужно время на освоение. Резкий переход создаёт продуктивность-яму: короткое время команда работает медленнее, пока не наработает навык.
Ситуации, где риск высок: Если изменение затрагивает production, постепенность снижает риск. Мигрировать 5% трафика на новую архитектуру и наблюдать — лучше, чем переключить всё разом.
Security incidents и compliance: «Начиная с понедельника все секреты хранятся только в Vault, никаких переменных в коде» — это не обсуждается постепенно. Здесь Big Bang оправдан.
Критические архитектурные решения: Когда поддержка двух путей дороже боли перехода. Если вы мигрируете с одной БД на другую — период двойной записи должен быть коротким, не бесконечным.
Когда разделение создаёт больше проблем: «Некоторые используют новый процесс, некоторые — старый» — худший вариант. Если изменение требует консистентности всей команды (например, branching strategy), тогда Big Bang.
Техника, которая объединяет плюсы обоих подходов: изменение в коде есть (Big Bang для разработчиков), но для пользователей включается постепенно (Gradualism для adoption).
Для внутренних инструментов: Dark launch — новый инструмент работает параллельно со старым, данные пишутся в оба места. Команда сравнивает результаты. Только после подтверждения — переключение.
Пилот снижает риск и создаёт данные для аргументации перед остальными.
Как выбрать пилотную команду:
Что делать с результатами:
Изменение, которое не измеряется, не управляется. «Кажется, приживается» — не метрика.
Показывают, движетесь ли вы в правильном направлении, раньше чем финальный результат станет виден.
Примеры для внедрения code review:
Финальный результат, который изменение должно было произвести.
Примеры:
| Метрика | Что измеряет | Как собрать |
|---|---|---|
| Active users | Кто реально использует | Логи инструмента |
| Error rates | Проблемы при использовании | Мониторинг |
| Support requests | Сложность освоения | Тикеты, вопросы в чате |
| Time-to-complete | Эффективность нового процесса | Логи, ручные замеры |
| Regression rate | Возврат к старому | Регулярный аудит |
Люди редко говорят «это не работает» открыто, если боятся, что их услышит автор идеи.
Что работает:
Красный флаг: Если все говорят «всё отлично», но метрики плохие — честная обратная связь не поступает. Ищите причину.
Контекст: Команда из 8 разработчиков. До этого каждый мёрджил сам. Несколько серьёзных инцидентов в production за год. Новый тимлид решает внедрить обязательное ревью.
Первая реакция (сопротивление):
Что пошло не так в первой попытке: Тимлид объявил: «С этого спринта все PR должны иметь ревью». Никакого объяснения почему, никаких договорённостей о процессе. Результат — PR висели по 3 дня без ревьюеров, разработчики злились, тимлид злился. Через три недели негласно вернулись к старому.
Что сработало во второй попытке:
Создание срочности через данные: Тимлид собрал данные за год: 7 production-инцидентов, 3 напрямую связаны с отсутствием второй пары глаз. Показал команде. Не как обвинение — как контекст.
Вовлечение команды в дизайн процесса: «Я хочу внедрить code review. Мне важно, чтобы процесс был рабочим. Давайте вместе решим: как это будет устроено, чтобы не стало болью». Команда сама выработала правила: ревью в течение 24 часов, максимум 2 ревьюера, что обязательно проверять, а что — по желанию.
Early adopter: Один из Senior Engineers (не тот, который возражал публично) видел ценность. Тимлид поговорил с ним заранее, сделал его первым ревьюером. Он показывал, как давать конструктивную обратную связь.
Pilot sprint: Первые 2 недели — добровольно. Те, кто хотел, пробовали. Результаты обсуждались публично.
Quick win: На третьей неделе ревью поймало потенциальную уязвимость в коде авторизации. Тимлид обратил на это внимание всей команды: «Вот что ревью даёт».
Работа с главным скептиком: После успешного пилота тимлид поговорил с Senior Engineer, который возражал. Не чтобы переубедить — чтобы услышать. Оказалось, его главный страх был: «мой код будут судить публично». Договорились: первые его ревью видит только один конкретный человек, не вся команда.
Метрики через три месяца:
Ключевой вывод: Первая попытка провалилась, потому что тимлид пропустил шаги 1-4 по Коттеру и компоненты A и D в ADKAR. Вторая сработала, потому что изменение началось с вовлечения, а не с приказа.
| Ошибка | Почему плохо | Как правильно |
|---|---|---|
| Объявить изменение и забыть | Без постоянной поддержки люди возвращаются к привычному — сила привычки сильнее разовых объявлений | Создать систему Reinforcement: напоминания, ретроспективы, метрики — изменение должно жить в процессах |
| Игнорировать скептиков | Скептики не молчат — они вербуют команду против изменения, пока лидер делает вид, что не замечает | Работать со скептиками активно: выяснить тип, ответить на реальный страх, а не на декларируемое возражение |
| Двигаться слишком быстро | Люди не успевают адаптироваться → нарастает тревога → пассивный саботаж → изменение проваливается | Ориентироваться на скорость команды, а не на идеальный план; пилоты дают темп |
| Нет quick wins | Через 2-3 месяца без видимых результатов люди теряют веру и мотивацию продолжать | Намеренно искать и визуализировать ранние победы, даже небольшие; «ревью поймало баг» — win |
| Менять слишком много одновременно | Когнитивная нагрузка — люди не знают, на что фокусироваться; изменения конкурируют за внимание | Максимум 1-2 значимых изменения параллельно; приоритизировать и секвенировать |
| Не измерять принятие | Без данных не знаете, работает ли изменение или вам только кажется, что работает | Определить leading и lagging indicators до старта; проверять еженедельно в первые месяцы |
Возьмите любое изменение, которое сейчас идёт в вашей команде или буксует. Для каждого члена команды оцените по шкале 1-5, насколько сформирован каждый компонент ADKAR.
Цель: Превратить «изменение не идёт» в «у конкретных людей проблема в конкретном компоненте — вот что делать».
Нарисуйте схему: кто в команде поддерживает изменение, кто нейтрален, кто сопротивляется.
Цель: Работать стратегически — не пытаться убедить всех сразу, а выстраивать коалицию от наиболее влиятельных к остальным.
Вспомните изменение, которое не взлетело (у вас или в командах, о которых вы знаете).
Цель: Отделить «плохая идея» от «хорошая идея, плохо реализованная» — и не повторять ошибок реализации с хорошими идеями.
Управление изменениями — навык, который разделяет тимлидов, которые «объявляют» изменения, от тех, у кого изменения действительно происходят.
Ключевые выводы:
Следующий шаг: Выберите одно изменение, которое вы хотите провести в команде. Напишите одно предложение-видение (шаг 3 Коттера). Определите трёх людей, от которых зависит успех. Для каждого пройдите ADKAR и запланируйте конкретный разговор на этой неделе.
Время освоения: 45 минут Уровень: Средний — Продвинутый Для кого: Тимлиды, менеджеры, senior-разработчики, tech leads
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.