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

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

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

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

В 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. Работа с ранними последователями #

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

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

У меня был случай, когда в декабре перед праздниками я убедил приехавшего на корпоратив удалёнщика попробовать разработать фичу через интеграционные тесты, с минимальным проектированием (принцип YAGNI или emerging architecture). Я ушёл на праздники с ощущением, что «продажа» не вполне удалась. А потом в январе разработчик пришёл с готовым решением: оказалось, он так поверил в подход, что не удержался и попробовал его применить прямо в праздники (хотя в компании не было принято овертаймить).

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

Например:

• разработчик начал делать новую фичу по интеграции с 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. Определите для себя способ контроля процесса — например, раз в месяц проверяйте соблюдение стандарта лично

Скорее всего после принятия нового процесса как стандарта отстающие начнут его соблюдать.

Исправление отклонений #

Если отстающие отклоняются от правильного выполнения нового процесса (например, пишут бессмысленные тесты), можно попробовать уделить им больше внимания:

1. Применить методику парного программирования
2. Поставить напарником человека, который проникся новым процессом (пишет полезные и лаконичные приёмочные тесты)

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

Попытка же уволить или изолировать человека из когорты отстающих наверняка создаст долгосрочные проблемы:

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

Впрочем, это мой ограниченный опыт и ситуации могут быть разными.

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

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

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

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

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

Также ценность многих изменений видна при выборе правильных метрик. Например, автоматизация тестирования позитивно влияет:

• на метрику Dev Cycle Time
• на впечатления QA о качестве новых фич
• на снижение задач, отправленных на доработку (метрика Rework)
• на готовность разработчиков к коллективному владению кодом

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

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

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

Пример из практики моего коллеги:

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

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

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

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