Как проводить изменения в компании, чтобы не навредить себе и коллегам

Данная статья — полная копия моей статьи на Хабре в блоге Тинькофф. Решил, что хорошо бы её и себе на сайт перенести.

Для тех, кто не любит читать, есть видео доклада.

Привет! Меня зовут Михаил Мартынов, я деливери-менеджер Тинькофф Инвестиций. Мы с коллегами занимаемся тем, что улучшаем процессы. Они бывают самые разные:

В декабре прошел очередной IT’s Tinkoff Process Improvement #2 — митап, посвященный управлению изменениями. Вместе с коллегами из других компаний мы обсуждали, как проводить изменения и какие инструменты применять. Римма Денисовец из and Change выступила с докладом «Пять этапов для успешных изменений ADKAR», а Денис Тучин из Agile Collage раскрыл тему «3 основных ошибки агента изменений». Я же подготовил доклад «Как не навредить себе и коллегам? Стратегия проведения изменений».

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

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

Допустим, мы хотим поменять этот процесс: покупка акции должна проходить быстрее.

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

Но зачем вообще что-то менять, когда существует правило «если это работает — не трогай»? Вот основные факторы, которые помогают понять, что над процессом пора поработать:

1. Мы несем разного рода потери. Например, время от времени теряются данные пользователя — то они записываются в базу данных, то нет. Если к нам придет регулятор и попросит отчет, он будет неполный и у нас будут большие проблемы.

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

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

4. Необходимость быть готовым ко всему. Даже если сейчас процесс как-то работает, это не значит, что он продолжит работать в будущем. Лучше иметь запасной план, а в идеале — два или три таких плана.

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

Чтобы вам и коллегам не было больно, предлагаю попробовать алгоритм — его я использую в 90% изменений, которые провожу.

Скорее всего, вы сейчас посмотрите на алгоритм и скажете: «Да это же обычный STATIK». Я бы так не сказал. Они похожи, но называя алгоритм STATIK, мы подразумеваем, что и проводить изменение нужно по всем канонам. А там еще и канбан-метод начинает выглядывать из-за угла. Давайте не будем вешать ярлыки и просто назовем это процессом работы здорового человека.

Сперва посмотрим на алгоритм целиком, а затем разберем его этапы.

По этому алгоритму мы, например, работали с командой сопровождения и внедряли процесс запуска продуктов и фич Инвестиций на клиентов. Это когда все новые продукты или фичи от шести бизнес-команд (100+ человек) запускаются через одно окно. В итоге при релизе на клиентов у продукта обязательно заполнен FAQ, первая линия имеет на руках скрипты для ответов на вопросы клиентов, отдел продаж знает, как предлагать и продавать продукт, а все процедуры для самостоятельного решения проблем через чат-бота в мобильном приложении и на сайте обновлены.

А теперь перейдем к этапам.

Этот этап помогает понять, чего хочет человек, который пришел к вам с запросом на изменения. Или чего хотите вы, если вы сами стали их инициатором.

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

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

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

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

Цель — визуализировать все проблемы и выбрать критичные. Те, с которых, скорее всего, мы начнем работу. Желательно кластеризовать их: например, разделить на проблемы клиента и проблемы команды. Можно еще добавить проблемы заказчиков и остальных команд, которым приходится общаться с вашим сервисом.

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

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

Также в качестве инструментов можно использовать опросы и метрики из ваших CRM, Jira и прочих программулин.

На этом этапе важно понять, какие типы работ есть в сервисе и откуда они приходят. Мы должны выяснить, какая работа может быть скрыта, и визуализировать ее. В примере ниже есть вопросительные знаки — когда мы не знаем, кому это нужно, зачем мы это делаем и так далее, но почему-то занимаемся этой работой. Возможно, так исторически сложилось. Если таких знаков вопроса очень много, лучше остановиться и попробовать понять, откуда они берутся, копнуть глубже в проблематику.

Например, почему мы прогоняем эти скрипты? Потому что кто-то когда-то прогнал один и теперь все к нам ходят? Почему это не может делать другая команда или какой-то робот с UI-интерфейсом?

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

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

Создать визуализацию помогут следующие инструменты:

• value stream mapping (VSM);
• customer journey map (CJM);
• event storming;
• интервью с теми, кто взаимодействует с процессом;
• анализ системы работы с задачами;
• анализ метрик доставки.

Затем процесс AS IS нужно превратить в TO BE, то есть визуализировать желаемый результат.

Инструменты:

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

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

Инструменты:

• OKR. Кстати, возможно, в компании уже есть какая-то цель, которая решает проблему вашего процесса, но вы просто о ней не знаете. Поэтому полезно будет узнать, что еще происходит вокруг.
• SMART. Это план работы с проблемами. Там должны быть проблема, целевое решение, шаги и метрики успеха. Кроме того, нужно добавить зоны ответственности: мы не можем поменять процесс в одиночку. Важно понять, что будем делать мы и что будут делать другие люди. И конечно, важно попробовать предсказать риски: что может пойти не так и как мы будем с этим работать.

Инструменты:

• риск-менеджмент;
• мозговой штурм

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

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

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

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

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

И только на этом этапе начинается delivery. Так как мы хорошо вложились в discovery, на этапе delivery нам остается только фигачить. Ведь у нас уже все для этого готово.

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

Регулярный сбор обратной связи — страховка от никому не нужных действий.

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

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

Важно не только положить куда-то опыт, но и рассказать о нем. Поэтому здесь пригодятся презентации для коллег: было вот так, стало вот так, результаты такие, лежит вот здесь, пользуйтесь на здоровье. Также помогут информационные рассылки: если их нет, о вашем изменении никто не узнает. Поэтому постарайтесь организовать каналы коммуникаций для доставки знаний.

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

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

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

🎃 Не всё чем я занимаюсь попадает на сайт. В моём telegram-канале «Доставка ценности» ты сможешь следить за публикацией новых статей, кейсов, видео, анонсов вебинаров, мастер-классов и мыслями на разные темы. Так же в комментариях можно поделиться своим опытом, спросить совета у коллег.