Вступление
Приветствую вас, дорогие читатели. Тружусь в IT сфере с 2016 года. Так вышло, что свое ремесло я нашел не сразу и пробовал себя в программировании, аналитике и теперь занимаю должность руководителя проекта. Простыми словами управляю командой в Ростелеком Информационные технологии. Меня зовут Радик. Приятно познакомиться
В этой статье хочу поделиться небольшим опытом транслирования изменений в рабочем процессе на свою команду.
Изменения являются неотъемлемой частью современного рабочего мира и касаются всех отраслей. Так уж повелось, что в ИТ изменения явление довольно частое (гибкость и все такое): они могут быть инициированы событиями планетарного масштаба или, например, связанными с изменением в руководстве.
Давайте рассмотрим два источника изменений:
Изменения, источником которых является сама команда
Изменения, источник которых пришел извне команды
Независимо от источника, важно знать, как эффективно преподнести изменения команде, чтобы обеспечить их принятие и поддержку.
Подробнее об изменениях
Внутренние изменения
Внутренние изменения возникают в результате предложений или идей членов команды. Самая распространенная для этого площадка: ретроспектива спринта. Команда сталкивается с проблемой, проблема фиксируется и подтверждается всеми, а дальше прорабатывается решение. Также довольно часто предложения об изменениях могут быть озвучены во встречах 1:1.
Обычно такие изменения принимаются легче, поскольку команда участвовала в их разработке:
Команда чувствует себя более вовлеченной и ответственной за изменения, поскольку они сами их придумали и проработали.
Команда склонна доверять внутренней информации и идеям.
Команда может заранее предвидеть потенциальные трудности и разработать стратегии их решения, поскольку изменения касаются ежедневных (здесь выберите сами периодичность) процессов.
Например
В пакет документов по доработке, которая идет на продуктивную среду, наша команда всегда прикладывает Руководство пользователя в формате *.docx. Команда поняла, что просто хранить документ в Jira недостаточно и решила на одном из Ретроспектив, что хранить базу знаний надо в отдельном открытом пространстве Confluence. Таким образом не надо знать номер задачи для поиска документов, всегда можно отправить заинтересованному лицу ссылку на пространство, любой из коллег, увидевший неточность мог внести правки или просто обновить руководство, если текущая доработка затрагивала механику пользовательской работы.
Круто! решили все и дружно реализовали
Нет гарантий, что все такие изменения будут внедряться так же легко. Но они все же отличаются от группы изменений ниже.
Внешние изменения
Внешние изменения, они другие. Навязываются команде сверху, от руководства или внешних факторов. В основном такие изменения встречают большее сопротивление.
Навязанные изменения принимаются командой неактивно из-за угрозы собственной безопасности/комфорта, утраты контроля и каких-то личных предубеждений.
При внедрении внешних изменений важно донести до команды достаточную информацию. «Почему эти изменения вдруг стали необходимы, ведь мы работали без них уже давно? Какая цель у этих изменений?»
Без подробного погружения вы рискуете помимо очевидного сопротивления получить так же недоверие и банальное отсутствие вовлеченности. «Да, там что-то говорили, но не очень понятно зачем. Пока буду работать как работал».
Примером такого изменения является необходимость ведения текущей нагрузки в Tempo, которую донесло руководство до команды. Из-за крайне малой информативности, вроде бы простой по механике процесс долго буксовал на старте: кто-то заполнял постфактум нагрузку, кто-то не давал информативного описания в строку. Этот инструмент нужен был в первую очередь для планирования ресурсов. Теперь процесс налаживается, но остается на подкорке «Занимаюсь непонятно чем», потому что момент упущен.
И те, и другие изменения в работе команды требуют усилий при внедрении. Где-то больше, где-то меньше. Для себя я сформировал некоторые обязательные пункты при трансляции изменений команде
Что нужно сделать для успешного внедрения изменений
И так, что нужно для успешного (или как минимум снизить сопротивление команды) внедрения изменений в команде:
Информирование
Соберитесь с командой. Расскажите какие изменения в скором времени произойдут. Объясните причины этих изменений, кем они были инициированы, донесите основные цели.
Попробуйте ввести изменения только потому что так надо и посмотрите на реакцию вашей команды =)
Регламент
Для того, чтобы не возвращаться каждый раз к рассказу об изменениях стоит написать страницу в конфлюенс с описанием, руководством (если требуется), а также с ответами на заданные вопросы. Эта страничка так же пригодится при погружении новых сотрудников в команду и процессы.
Тут все просто. Читаем мы внимательнее, чем слушаем. И быстрее. (Вы тоже «в восторге», когда вам присылают голосовые в ТГ?=) ) В регламент всегда можно посмотреть
В команде мы очень долго погружали новых сотрудников по наитию. Пока не оформили понятный гайд: кто должен показать новому сотруднику это, кто должен показать новому сотруднику то. Что должен новый сотрудник изучить самостоятельно, какие инструменты поставить на рабочую машину и т. д. Кадры в команде меняются у нас не так активно, поэтому роль куратора может подзабыться. Описанный регламент (у нас там схемы и таблички) быстро помогает восстановить все знания.
Ответы на вопросы
По мере информирования команды Вы обязательно столкнетесь с непониманием. Это непонимание искореняется достаточно просто: есть вопрос – есть ответ. Также спросите мнение самих сотрудников об изменениях. Активные участники команды могут задать вам вопросы сразу же после информирования. Другим может понадобиться личная встреча. Так же стоит дать время для размышления, не все вопросы могут возникнуть сразу.
Была отличная практика, когда я ввел некий регламент работы. В чате команды посыпались куча вопросов. Половина вопросов охватила рабочие моменты, которые не были четко прописаны, другая половина открывала мир в неизведанные сценарии. Дал положительную обратную связь ребятам за вопросы, постарался ответить на некоторые из них на горячую. Выхватил ушат вопросов на проработку и пошел обогащать регламент. И добавил раздел с FAQ.
Поддержите команду
Вы для сотрудников являетесь точкой входа и ретранслятором изменений. Необходимо активное участие пока команда будет адаптироваться
Когда вводили новый процесс в задаче Jira, разрабы и тестировщики очень часто втыкали и нужно было подсказывать. А иногда исправлять последствия.
Мониторинг
Отслеживайте, как изменения влияют на работу команды. Как команда выполняет необходимые новые действия. Если вы не будете обращать на это внимание на первых порах, то и команда может не принять эти изменения.
Была проблема, что разработчики отдавали неотлаженные задачи в тестирование. В связи с чем получали лишние хлопоты на этапе тестирования. Приняли решение внедрить небольшой чек-лист для разрабов перед тестированием (согласованный с ними, ага). Посмотри туда, тыкни то, проведи смоук-тест основного сценария. Я завтыкал и не контролировал исполнение этого чеклиста. Теперь в каждой задаче лежит этот артефакт как напоминание моего факапа
Итоги
В целом на этом у меня все. Конечно, каждая команда и каждые нововведения требуют своего подхода и нельзя использовать данные тезисы постоянно и повсеместно. Но надеюсь, что пункты с небольшими примерами облегчат вам жизнь хотя бы раз.
Спасибо за уделенное время. Пока!