База про внедрение изменений.
Вот в посте писал про важность процессного подхода и с чего начать его применение. Умолчал про "внедрение". Разберемся на примере из начала моего пути в айтишке.
Есть небольшая команда, где все люди ранее работали в trello. Команду все устраивало: тикеты есть, задачи фиксировать можно, смотреть на статусы удобно. Что еще надо? Но менеджмент был неугомонным. Появился новый инструмент в компании - jira, а функциональности там сильно больше, чем в trello. Инициатива с внедрением jira была для сбора метрик с команд. Менеджмент понимал, зачем это и какие тут есть плюсы.
Но вот Васе, Пете, Тане и Наташе это было не интересно. У каждого инженера есть свои инструменты для работы, которые нужно знать, а еще в индустрии всякое новое постоянно появляется. Не до вас, короче.
Тут у меня появилась дилемма: а как внедрить новый инструмент так, чтобы им начали пользоваться. Еще в будущем будет расширение команды. Надо будет распространять знание на новых ребят.
Залез в интернет, почитал, какие есть модели внедрения изменений. Оказывается, что их много: Маккинзи, IBM, ADKAR и т.д. Есть из чего выбрать и каждая решает задачи разного масштаба.
Если смотреть глубже, чем на основное описание этих моделей, то там много общего. Я постарался для себя найти наиболее подходяющую и вот что понял.
1) Нужно осознать потребность в изменении и превратить её в мотивацию для сотрудников.
Прикинул, что полезного получат мои ребята, если вместо trello будут использовать jira, а некоторые процессы будут делать по дргоуму? Начал с поиска проблем в текущем процессе трекинга задач. Оказалось, он не до конца отображал реальный цикл разработки, из-за чего некоторые люди путались в статусах и делали какие-то действия интутивно. Также выявилась проблема "тушения пожаров". Ребята не всегда говорили корректные сроки бизнесу, а бизнес не всегда понимал "сколько осталось". В итоге заваленные коммиты перед бизнесом заливались переработками.
Получилось 2 основных полезности для команды: все будут понимать, что и от кого ждать, потому что флоу работы будет более четким, и мы перестанем заливать переработками некорректные оценки задач перед заказчиком.
2) Нужно описать само изменение. Это будет опорой для сотрудников в период привыкания к новым процессам.
Пытаясь понять, какие запросы могут быть у руководства, заказчиков, меня и у команды, я сделал некий набор метрик. Нарисовал новый флоу работы. Показал ребятам, собрал обратную связь. После нескольких итераций выложил в общий доступ в confluence. Каждый мог зайти и вспомнить, что и на каком этапе делать, а у новеньких дополнялся план адаптации.
3) Дать ошибаться и собирать обратную связь. Формулировка моя, но смысл очень похожий.
У вас не получится с первого раза классно внедрить изменение, а у людей не получится сходу работать правильно - это нормально. На этом этапе главное отличать сопротивление от непонимания и работать с этим.
На тот момент у меня сопротивления практически не было. В течение 2-ух недель я брал каждый тикет и выписывал себе замечания: что человек сделал не по процессу и на что это повлияло. Далее в индивидуальном порядке обсуждал проблемы и вносил корректировки.
Все эти 3 пункта - это про здравый смысл того, как научить людей работать по другому. Но, блин, сколько раз я видел ситуации, когда пропускался пункт 2 и сразу шел пункт 3. Или игнорировался пункт 1 и сразу делался пункт 2, а на пункте 3 вообще не отслеживали ошибки людей, не доносились их последствия, не собиралась обратная связь.
На протяжении нескольких лет я внедрил много изменений в разные команды, но вот эти 3 пункта всегда работали🫡
#кейс@lead_latvenas
