Как вы внедряли изменение процесса, которому команда сначала сопротивлялась?

Внедрение изменения процесса вопреки сопротивлению

Кейс: я пришёл в команду, которая не делала code review — PR мержились автором. Я хотел ввести обязательный review. Команда сопротивлялась: «мы доверяем друг другу», «это замедлит разработку», «у нас нет времени».

Шаг 1 — понять природу сопротивления. Провёл 1:1 с каждым членом команды и задал один вопрос: «Что тебя больше всего беспокоит в этом изменении?» Ответы разделились:

• 2 человека: «боюсь, что мой код будут критиковать» (психологическая безопасность).
• 2 человека: «это реально замедлит нас» (практическое опасение).
• 1 человек: «не понимаю, зачем это нужно» (отсутствие контекста).

Это разные проблемы, и они требуют разных ответов.

Шаг 2 — дать контекст, а не команду. На командной встрече я поделился данными: за последние 3 месяца 4 из 7 production инцидентов были связаны с изменениями, которые не видел второй глаз. Стоимость этих инцидентов × время восстановления. Это не про доверие — это про систему, у которой есть слепые пятна.

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

• Review не обязателен для hotfix под инцидентом (но требует ретроспективного review).
• Reviewer отвечает в течение 4 часов в рабочее время (убирает страх блокировки).
• Review — это не одобрение, а второй взгляд. Автор принимает финальное решение.

Шаг 4 — ограниченный эксперимент. Предложил попробовать 4 недели, собрать данные и честно оценить: стало ли медленнее? Нашли ли проблемы, которые иначе попали бы на прод? По итогам 4 недель: cycle time вырос на 8% (меньше ожидаемого), команда сама нашла 3 серьёзных бага в review. Они решили продолжать.

Принципы изменения процесса:

• Distinguish between position and interest: «не хочу review» — позиция; «не хочу критики кода» — интерес. Работать нужно с интересом.
• Start with why: люди сопротивляются не изменению, а непонятому изменению.
• Co-design: если команда участвовала в создании правил, она чувствует ответственность за их соблюдение.
• Time-boxed experiment: «попробуем 4 недели» значительно меньшее обязательство, чем «меняем навсегда».

Подводные камни

• Обойти сопротивление через авторитет — «я сказал, делайте» работает краткосрочно, но убивает trust и вовлечённость.
• Не различать типы сопротивления — технические опасения требуют данных, эмоциональные — разговора, информационные — контекста.
• Навязать детали процесса — если команда не участвовала в дизайне, она найдёт способы обходить правила.
• Нет явного механизма пересмотра — «мы попробуем, и если не работает, изменим» снижает сопротивление. «Это навсегда» — увеличивает.
• Изменять процесс без измерения результата — как будет оценено, успешно ли изменение? Без метрики нет основания для продолжения или отмены.
• Внедрять слишком много изменений одновременно — команда теряет ощущение стабильности, что усиливает сопротивление каждому следующему изменению.
• Игнорировать loudest voice — один человек, активно сопротивляющийся, может блокировать всю команду. Нужно работать с ним отдельно, не замалчивать.

• Продавить изменение через должность.
• Игнорировать реальные причины сопротивления.
• Не отменить или не адаптировать изменение, если оно не сработало.

• Умеет работать с adoption.
• Использует эксперименты вместо больших указов.
• Сохраняет доверие команды при изменениях.