Ответ
В моей практике сопротивление изменениям обычно возникает из-за комбинации факторов, связанных с человеческой психологией и рабочим контекстом.
Основные причины, с которыми я сталкивался:
- Нарушение устоявшегося workflow: Когда процесс, который "отточен до автоматизма", меняется, это требует когнитивных усилий на перестройку. В краткосрочной перспективе это всегда приводит к временному снижению продуктивности, что может вызывать раздражение.
- Отсутствие понимания "зачем": Если изменения спускаются директивно без четкого объяснения бизнес-цели или технических преимуществ, они воспринимаются как бессмысленная бюрократия. Например, внедрение обязательного code review без объяснения, что это снижает количество багов в продакшене на 15%.
- Страх некомпетентности: Особенно у опытных разработчиков. Новый инструмент (например, переход с Jenkins на GitLab CI) может означать, что их экспертиза в старом стеке обесценивается, и они снова становятся "новичками".
- Реальные тактические недостатки: Часто сопротивление обоснованно. Новая Jira-доска может оказаться менее гибкой, а обязательное TDD для всех задач — избыточным для прототипирования.
Что я видел в успешных случаях внедрения:
- Пилотирование: Сначала изменения опробовала одна заинтересованная команда, показала результаты, и только потом процесс масштабировали.
- Прозрачность: Руководство честно говорило: "Да, первые две недели скорость будет ниже на 20%, но через месяц мы ожидаем рост за счет X".
- Участие команды: Разработчиков привлекали к выбору нового инструмента или адаптации процесса под наши нужды, а не просто ставили перед фактом.
В итоге, сопротивление — это чаще не лень, а рациональная реакция на потенциальные риски и издержки, которые не были учтены инициаторами изменений.