Привет! Меня зовут Сергей Господчиков, и в IT я, страшно подумать, с 1992 года. Именно тогда я начал работать программистом и писать свой первый код, за который мне платили деньги. Примерно в 2001 году я стал руководить людьми и прошел путь от главного инженера до генерального директора, попутно попробовав себя в ролях CIO, CTO, CEO и даже преподавая проектный менеджмент. И все эти годы я постоянно проводил различные изменения.

Сейчас я работаю с командами разработки в качестве методолога продуктового подхода и практикую Канбан-метод. В этой статье поделюсь с вами своим опытом проведения изменений. А именно — практическими инструментами, которые сам использую почти ежедневно.

Жизнь вокруг нас меняется очень динамично, и не все изменения нам нравятся. Точнее, давайте так — не каждое изменение мы принимаем. Так что эта статья для большинства из нас. Для тех, кто восемь часов в день, как минимум, проводит на своей (конечно же, любимой) работе. Инструменты, которые я опишу, также подходят для планирования и проведения изменений в семейном кругу. Однако в этом случае нужно быть очень аккуратным, чтобы не навредить вашим отношениям. Кстати, я в браке уже 28 лет. Ребята, оно реально работает. Но, как говорится, это уже совсем другая история.

Так вот, про изменения. Задумывались ли вы когда-нибудь почему предложенные вами изменения не вызывают восторг у окружающих и остаются лишь мечтами, несмотря на то, что с вашей точки зрения они очень полезны? Но остальные, к вашему удивлению, почему-то так не думают и не спешат делать то, что вы задумали. Бывало? 

Изменение — это что вообще?

Самый простой способ ответить на этот вопрос —  вбить «управление изменениями» в любимый поисковик. Мне сходу откликнулось вот такое определение из википедии.   

Управление изменениями (англ. change management) — это структурный подход к переводу индивидов, команд и организаций из текущего состояния в желаемое будущее состояние. Целью этого организационного процесса является расширение прав и возможностей сотрудников принять и поддержать изменения в их текущем бизнес-окружении.

В этой формулировке важно отметить то, что когда мы проводим какое-то изменение, у нас есть два состояния — текущее и желаемое. И мы четко понимаем из какого состояния в какое мы хотим перейти.

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

Формулирование проблемы

Почему это важно? Помните, как в сказках формулировалось «Пойди туда — не знаю куда, принеси то — не знаю что»?

Представьте, вы работаете разработчиком, и ваша проблема сформулирована как «У нас очень неудобный и медленный трекер задач». Проблема? Проблема. Давайте ее решать! Но она содержит только понимание текущей ситуации и ничего нам не говорит про желаемое состояние. Поэтому это изменение неосуществимо, ибо мы пытаемся решить какую-то ничем не ограниченную проблему.

Если у вас похожая ситуация, то есть очень простой способ помочь с формулировкой. В ответ на сформулированную в негативном ключе проблему задайте себе вопрос — «Что мы хотим вместо этого?». Дальше задайте себе еще один вопрос — «Когда мы этого хотим?». После этого формулировка может поменяться, например, на такую. «Ввиду неудобства текущего трекера мы хотим его поменять на другой трекер, который будет соответствовать следующим критериям … Сделать это мы хотим к такой-то дате».

Звучит уже как решение проблемы именно в «терминах разрыва». Отлично! Мы описали текущее состояние и желаемое состояния.

Казалось бы, все очевидно. Нужно действовать! Но коллеги говорят — «Нам и так норм». Начальник ворчит насчёт дороговизны, а внутренний голос уже уговаривает послать всех подальше и написать заявление об уходе … Но не стоит торопиться.

Сейчас нам пригодится второй инструмент, который позволяет прикинуть - а пойдет ли это изменение? Реально ли его провести? Для того, чтобы это понять мы должны оценить вероятность успешного проведения изменения. Для это существует формула изменений (формула перемен). Она не строго математическая, скорее эмпирическая.

Звучит она так:

Формула изменений (перемен)

Если

A = уровень неудовлетворенности отдельного человека или группы тем, как «идут дела»;

B = разделяемое видение отдельного человека или группы о лучшем будущем;

C = существование приемлемого, безопасного первого шага с возможностью отката назад

D = затраты отдельного человека или группы,

то успех изменения наиболее вероятен, если А + B + C > D

Есть и более экстремальное изложение этой формулы. Это когда вместо знака "+" ставят "*", получая в итоге произведение. Если вес любого множителя стремится к нулю, значит, у вас нет шансов. Но я обычно использую "+".

Давайте посмотрим на первое слагаемое.

Под отдельным человеком имеем в виду кого-то, имеющего вес. Например, генерального директора. Или это какой-то иной руководитель, имеющий полномочия и возможности что-то изменить. Ну или неформальный лидер, например, вашей команды.

Что касается группы, то это может быть значительное количество людей, например, та же команда. Или сотрудники одного отдела, если изменение касается отдела. Если мы имеем недовольство текущей ситуацией в этом слагаемом такого весомого человека или группы, то считаем, что это слагаемое имеет вес. Так, в примере с трекером недовольным можете быть вы один. И тогда мы считаем вес слагаемого небольшим. Наоборот, если трекером недовольна вся организация, то вес будет огромным. Стоит также оценить уровень недовольства. Бывает, что тот же трекер неудобен, но все привыкли и ситуация терпимая.

Забегая вперед, скажу, что этим слагаемым, как и последующими, можно управлять и усиливать. Например сделать опрос по степени удовлетворенности трекером, сосчитать временные потери на ожидание отклика в масштабе отдела и довести это до руководителя, который возможно не придает этой проблеме внимания. Тогда степень недовольства этого человека может возрасти и вес слагаемого увеличится. 

Итак, мы определили вес первого слагаемого (ну хотя бы по простейшей шкале — большой, средний, маленький).

Можно приступить к оценке следующего слагаемого.

Тут мы по-прежнему оперируем отдельным человеком или группой. Но в этом случае речь идет о разделяемом видении будущего. Это о том, что все одинаково понимают то самое желаемое состояние, т.е. то, куда мы придем и что получим после проведения этого изменения. И тут не всегда все очевидно, что приводит нас к ошибкам. Люди часто не принимают изменения, просто не понимая, что они получат в результате.

И это, кстати, одна из возможных причин сопротивления изменениям (но об этом чуть дальше). Подумайте, какой вес имеет эта составляющая, и если он небольшой — слагаемое не сработает.  В случае с нашим примером о трекере — не все могут понимать "Что нам даст переход на новый трекер"? Какой это будет трекер? Насколько он будет удобнее и вообще.

Третье слагаемое про то, что у вас есть возможность (и о ней все знают) попробовать двинуться в сторону желаемого состояния, но иметь возможность отката назад. В случае с трекером мы можем попробовать запустить альтернативный трекер, перенеся туда текущие задачи. Сделать песочницу. Главное — не ломать старое, иметь возможность безболезненно вернуться назад. Это может быть предложение попробовать некое правило работы в команде на ближайшие пару недель, с последующим обсуждением итогов в группе.

Четвертый компонент формулы — затраты. Здесь имеются в виду затраты любого вида. Время, деньги, нервы и пр, Если затраты на изменение небольшие, то вес этой части маленький. Обычно люди легко идут на такие изменения. Руководство не сопротивляется, если нет денежных затрат. Людям импонирует, что им не нужно тратить на это время. В случае с трекером инициативная группа может взять на себя настройку и внедрение нового трекера, при этом сделав это на “субботнике”, который не будет оплачен, но от организации в подарок будет пицца. Ну или две, хотя …

По итогу, внимательно изучив составляющие формулы и наложив ее на текущее состояние вы можете примерно понять — получится или нет. И даже получив отрицательный результат не стоит останавливаться. Слагаемые можно усиливать, работая над ними. Двигаться дальше вам поможет следующий инструмент.

У любого изменения есть заинтересованные стороны и их интересы, затрагиваемые планируемым изменением. Те самые люди из формулы изменений. Для понимания того, кто и какой вес имеет в текущей ситуации и куда нужно приложить усилия для сдвига состояния равновесия и реализации изменения (читай - увеличить вес слагаемых), существует такой инструмент как Анализ поля сил.

Анализ поля сил

Он помогает визуализировать текущее состояние и понять, куда стоит приложить усилия, чтобы текущая ситуация сдвинулась и мы начали переходить в желаемое состояние. Толщина стрелок показывает величину влияния заинтересованной стороны или фактора (за которым, как правило, стоит заинтересованная сторона).

Наша задача — понять, как нам усилить движущие силы и как ослабить сдерживающие. В том числе, оценить свои силы в предстоящем изменении. В нашем примере с трекером в этом списке могут оказаться, например, руководители, которые могут быть движущей силой, ну  или влиятельный сеньор разработчик, которого устраивает текущее состояние. Инструмент вспомогательный, можно обойтись без него, но он позволяет увидеть картину целиком.

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

"O" показывает исходное состояние по отношению к изменениям. "Х" конечное. Стрелками — направление перехода. После этого мы можем приступить к составлению планов по проведению изменения.  Но для начала нам нужно понять — насколько быстро нам нужно провести планируемое изменение.

И тут нам помогут пять базовых стратегий проведения изменений.

1. Директивная — прямое использование полномочий для принуждения совершения нужных действий. Приказы, указания, регламенты и пр. Когда я был CEO, я иногда этим пользовался. Лайфхак — не очень приятные решения лучше сообщать в конце дня, лучше в пятницу. Иначе весь рабочий будет потерян.

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

3. Переговорная — общаемся с людьми и пробуем найти компромиссы. Ты мне я Тебе. Уступаем, предлагаем, угрожаем, но не принуждаем. Как пример — разделение команды на две новых. Было у меня такое, когда приходилось готовить лидера новой команды. Переговоры с обещанием развития и изменением заработной платы.

4. Образовательная — рассказываем, что нас ждет в результате изменения. Обучаем людей внутри компании, отправляем их на внешнее обучение. Все это приводит к устранению неопределенности. В таком я участвовал, когда несколько сотен человек заходили в LeSS (Large Scale Scrum). Проходило обучение и последующий переход на работу по правилам этого фреймворка.

5. Стратегия участия — вовлекаем людей в изменение. Делаем так, чтобы они получали интересный опыт в процессе его реализации. Можно комбинировать с переговорной и образовательной стратегией. Часто это реализуют с помощью энтузиастов. Ищем, кому интересен определенный опыт, и подключаем к изменению.

Дальше нам нужно выбрать необходимую стратегию для каждой из заинтересованных сторон из матрицы приверженности. Всего таких стратегий пять. Но это не мешает вам придумать шестую, седьмую, восьмую ... но, скорее всего, хватит этих пяти.

Чтобы понять, каким образом мы будем нашу стратегию воплощать в жизнь и составить конкретный план для каждой строки матрицы приверженности, нам необходимо осознать причины возможного сопротивления тех самых заинтересованных сторон. И здесь нам очень поможет анализ причин сопротивления изменениям. Его можно также применить для каждой из заинтересованных сторон.

Всего причин 10. В моей практике мне их всегда хватает.

Причины сопротивления

Например, в случае с заменой трекера, лидер команды и синьор разработчик (да, да, вот так вот без тире), которые не очень готовы к внедрению нового трекера, сопротивляются по причине "Утрата компетентности" (ведь они не знают про выбранный трекер ничего, а в старом они были главными экспертами и все к ним ходили за советами).

В этом случае мы можем использовать образовательную стратегию и отправить их бесплатно обучаться премудростям нового трекера. Это, кстати, также снимает головную боль руководителя отдела, который сопротивляется по причине "больше работы", ибо к сеньору разработчику (ох простите, снова пропустил тире) можно дополнительно применить "стратегию участия" и поручить ему внедрение.

При этом руководитель отдела переходит с состояние "Допускает", а разработчик в состояние "Делает". Ну а лидер переходит в состояние "Помогает" и тем самым становится экспертом в новом трекере. В общем, это способ, как можно погнаться за несколькими зайцами, всех догнать и сделать так, чтобы они при этом были довольны.

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

Такой инструмент как Ромб Левита как раз напоминает нам об этом. Недостаточно просто поменять Задачи. Нужно обучить Людей, которые эти задачи будут реализовывать. Если меняется структура, то необходимо подумать и о том, какие люди эту структуру наполнят и что необходимо предусмотреть, чтобы люди начали работать в новой реальности. Ну и если небожители в вашей компании захотели поменять систему мотивации — задумайтесь о том, как это воспримут люди, и не придется ли вам менять этих людей, ну или самому менять ... компанию. У меня, кстати, такое было. Как-нибудь обязательно расскажу.

Ромб Левита

Все готово, чтобы изменения реализовывать. Наша матрица из примера с трекером теперь может выглядеть так.

Тут можно вспомнить модель модель Коттера. Если посмотреть на все описанное, то большую часть пути в этих восьми шагов мы как раз и прошли.

Модель Коттера содержит в себе восемь шагов:

1. Создаем необходимость. Все участники изменения должны понимать, что изменения необходимы. Это слагаемое А из нашей формулы изменений.

2. Создаем поддерживающую группу. Без группы людей, которая сможет это изменение поддержать нам не обойтись. Тут мы вспоминаем описанный нами анализ поля сил и матрицу приверженности.

3. Разделяемое видение будущего. Мы должны понимать куда мы идем и что нам всем принесет изменение. А это про слагаемое B из формулы изменений. Также здесь необходимо формирование стратегии изменения. И тут нам поможет континуум изменений и описанные нами варианты стратегий.

4. Доносим видение. Мы должны не просто сформировать видение будущего, но и всем его донести до каждого. Это также работа со вторым слагаемым формул. Помните, что если вес его будет небольшим - изменение не пойдет.

5. Устраняем препятствия. По ходу движения нам необходимо устранять препятствия. Это в том числе то самое сопротивление ,причины которого мы закладывали в план приверженности. Чтобы с этим работать как раз и нужна поддерживающая группа из шага 2.

6. Быстрые победы. Важно их подсвечивать. Первые успешные шаги, например. Помните слагаемое С из формулы изменений? Вот тут-то оно нам и пригодится.

7. Закрепляем изменения. Достигнув первых побед, мы движемся дальше. План приверженности нам в этом поможет.

8. Углубляем изменения. Как только у нас все получится, мы станем примером и сможем масштабировать свой опыт, меняя организационную культуру. Но не забываем про Ромб Левита. Поменять что-то одно не получится. Нужно действовать комплексно.

Из моего более чем двадцатилетнего опыта проведения изменений следует вот что —  эти инструменты достаточно просто применимы на практике. Они работают. Это многократно проверено.

Хотите попрактиковаться? Попробуйте наложить их на ваши уже реализованные изменения. Можно взять удачные или неудачные или достаточно "тяжело" прошедшие. Обычно даже формулы изменений бывает достаточно, чтобы увидеть причины провала. Пробуйте, и все у вас получится!

Буду рад обсудить ваш опыт изменений в комментариях.