Внедрение изменений через диффузию инноваций #

Иногда нужно внедрять изменения в процессе работы в команде или компании. Процесс принятия этих изменений командой очень похож на процесс диффузии инноваций. В этой статье я рассмотрю личный опыт применения этой теории для изменения процессов разработке в команде.

Кривая диффузии инноваций #

В 1962 году социолог Эверетт Роджерс (Everett Rogers) опубликовал теорию диффузии инноваций.

Согласно этой теории, по мере проникновения в общество инновация или новая идея проходит последовательно через 5 когорт людей:

1. Инноваторы (2,5% людей) — готовы принимать риск и создают инновации
2. Ранние последователи (early adopters, 13,5%) — являются лидерами мнений и при этом более осторожны, чем инноваторы, используя разумный подход во внедрении инноваций
3. Ранее большинство (early majority, 34%) — принимают изменения через некоторое время после инноваторов и ранних последователей, реже являются лидерами мнений
4. Позднее большинство (late majority, 34%) — принимают инновации, когда большая часть общества уже приняла их
5. Отстающие (16%) — принимают инновации последними, имеют явное неприятие к сторонникам изменений

А причём тут внедрение изменений? #

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

1. Инноваторы — сами создают изменение
2. Ранние последователи — им нужно лишь объяснить, как это делать, и они без проблем начнут работать по-новому, а затем поделятся результатами с командой
   • скорее всего придётся «продать» им изменения, убедив попробовать
3. Раннее большинство — им уже нужно показать истории успеха
   • источником историй успеха будут инноваторы и ранние последователи
   • не торопитесь работать с ранним большинством, пока историй успеха ещё нет
4. Позднее большинство — с ними сложнее: они принимают инновации, когда большая часть общества уже приняла их
   • возникает очевидная проблема «курицы и яйца»: позднее большинство ждёт принятия большинством, прежде чем начать
   • эта проблема решается за счёт раннего большинства и пары хитростей (подробности ниже)
5. Отстающие — обычно они консервативны ради собственной безопасности
   • скорее всего негативный опыт изменений где-то в прошлом останавливает от принятия нового
   • этот опыт возник не на пустом месте
   • они примут новый процесс работы, когда посчитают, что это более безопасный выбор

Этапы внедрения изменения #

Шаг №1. Планирование инновации #

Допустим, вы решили внедрить в команде практику написания интеграционных (компонентных) тестов разработчиком.

• В команде 4 разработчика
• В начале ни один из них не пишет интеграционные тесты
• В смежной команде интеграционные тесты активно пишут 2 человека
• Один из смежников готов показать и рассказать, как это делать

Подумайте о разделении инновации на несколько отдельных изменений (уровней зрелости):

Например:

• 1-е изменение: писать интеграционные тесты для основной функциональности с целью защиты от регрессий
• 2-е изменение: писать интеграционные тесты для большей части новой функциональности
• 3-е изменение: составлять интеграционные тесты до начала проектирования и написания кода (ATDD)

Каждое изменение внедряется отдельно по всем этапам, описанным ниже.

Шаг №2. Работа с ранними последователями #

Ранним последователям надо лишь объяснить, как это делать, и они без проблем начнут работать по-новому

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

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

Например:

• разработчик начал делать новую фичу по интеграции с API смежной команды
• он затрял на этапе создания «каркаса» кода из-за попытки спроектировать всё наперёд
• к нему можно подойти и рассказать, что интеграционные приёмочные тесты позволили бы не проектировать всё наперёд, а работать по принципу YAGNI

Его новый способ разработки может выглядеть так:

1. Написать «в лоб» самый простой use case интеграции с API
2. Покрыть его приёмочным тестом
3. Написать второй use case интеграции
   • при этом происходит рефакторинг архитектуры
   • этот рефакторинг ничего не сломает благодаря приёмочным тестам
4. Покрыть второй use case приёмочным тестом
5. …и так далее до завершения разработки

Этот процесс даст успешный опыт:

• избавление от «паралича анализа» (analysis paralysis)
• сокращение этапа тестирования на тестовом стенде (QA, dev)

Шаг №3. Работа с ранним большинством #

Получив успешный опыт, вы можете попросить ранних последователей провести демонстрацию в команде. Это будет началом второго этапа.

• Раннее большинство требует истории успеха и доказательства ценности изменений.
• Источником историй успеха будут инноваторы и ранние последователи
• Не торопитесь работать с ранним большинством, пока историй успеха ещё нет

Новички в команде #

На этапе работы с ранним большинством обратите внимание на новеньких.

Почти все новички попадают либо в ранее, либо в позднее большинство

• открытый к новому и уверенный в себе новичок легче примет новый подход — он попадёт в ранее большинство
• осторожный новичок попадает в позднее большинство — вы не убедите его писать тесты на даном этапе

Обратите внимание, в какую именно когорту попадает новичок относительно ваших текущих изменений. Договоритесь с его наставником, чтобы тот попросил его работать по-новому (даже если сам наставник ещё не пробовал это делать).

Шаг №4. Работа с поздним большинством #

Позднее большинство сложнее убедить:

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

Проблема неидеального распределения #

Проблема этой вероятностной модели в том, что в команде мало людей и их распределение по когортам наверняка будет неравномерным.

Например, таким:

В этой команде имеются:

1. Инноватор Серёга, который не относится напрямую к команде
2. Ранний последователь Вася, который уже работает по-новому
3. Ноль людей в раннем большинстве
4. Два человека в позднем большинстве
5. Один человек в отстающих, изначально наиболее критичный к изменению

В этом случае никто из позднего большинства не примет изменения, потому что они ждут принятия большинством, а в предыдущих когортах есть лишь 1 из 4 разработчиков.

Есть несколько приёмов, позволяющих решить проблему:

1. Добавить в команду новичков путём найма или ротации — при этом важно следить, чтобы новички оказались в раннем большинстве. Для этого нанимайте или просите в команду открытых к новому и уверенных в себе людей, возможно, с прошлым опытом работы по целевому для вас процессу.
2. Долго работать с конкретным человеком, чтобы убедить его попробовать работу по-новому вопреки скепсису

Есть и слегка манипулятивный приём: изменить структуру команды в умах людей. Например объявить, что инноватор Серёга, а также разработчики Коля и Толя из смежной команды, где уже работают по-новому, теперь будут ходить на daily meeting и демонстрации команды:

Это изменит ситуацию в головах позднего большинства: теперь 4 из 7 разработчиков уже приняли изменения, и позднее большинство теперь можно убедить сделать это.

Шаг №5. Закрепление стандарта #

Этот шаг направлен как на когорту отстающих, так и на защиту от регрессии к старому процессу в будущем:

1. Задокументируйте новый процесс как новый стандарт (регламент)
2. Объявите в команде, что новый процесс стал правилом, которому надо следовать
3. Определите для себя способ контроля процесса — например, раз в месяц проверяйте соблюдение стандарта лично

Шаг №6. Контроль и защита нового процесса #

Где-то в обозримом будущем в команде могут прорасти подобные мысли:

А зачем мы пишем тесты к каждой фиче? Можно сэкономить и писать только для 50% фич, вроде и так тестов много.

Чтобы не допустить такого, вам нужно:

1. При документировании нового процесса описать причины его внедрения, прошлый негативный опыт и преимущества нового подхода
2. Системно следовать выбранному способу контроля процесса — или придумать новый, если старый уже не работает

Шаг №7. Замена процесса новым #

Где-то в далёком будущем в команде захотят внедрить ещё более новый, инновационный процесс вместо внедрённого вами.

1. Важно не допустить ошибки, когда более новый процесс оказывается на деле откатом к прошлым плохим процессам
2. В этот момент поможет документация, описывающая причины и опыт внедрения текущего процесса
3. Более новый процесс пройдёт с нуля через все перечисленные этапы внедрения

Масштабирование внедрения изменений на компанию #

Эта техника прекрасно работает как в масштабе команды, так и в компаниях среднего размера (50-200 разработчиков). В компании её можно применять на двух уровнях раздельно:

• в компании изменения длятся дольше, а работа ведётся с командами как с целостными единицами
• в команде изменения происходят быстрее, а работа ведётся с отдельными людьми