Данная статья — полная копия моей статьи на Хабре в блоге Тинькофф. Решил, что хорошо бы её и себе на сайт перенести.
Для тех, кто не любит читать, есть видео доклада.
Привет! Меня зовут Михаил Мартынов, я деливери-менеджер Тинькофф Инвестиций. Мы с коллегами занимаемся тем, что улучшаем процессы. Они бывают самые разные:
- работа с проектами и задачами;
- разного рода планирование;
- процесс интеграционного тестирования;
- визуализация и сжигание технического долга;
- сокращение time-to-market;
- проработка бизнес-идей и многое другое.
В декабре прошел очередной IT’s Tinkoff Process Improvement #2 — митап, посвященный управлению изменениями. Вместе с коллегами из других компаний мы обсуждали, как проводить изменения и какие инструменты применять. Римма Денисовец из and Change выступила с докладом «Пять этапов для успешных изменений ADKAR», а Денис Тучин из Agile Collage раскрыл тему «3 основных ошибки агента изменений». Я же подготовил доклад «Как не навредить себе и коллегам? Стратегия проведения изменений».
В статье поделюсь текстовой версией доклада и видеозаписями всех выступлений коллег. В первую очередь текст будет полезен агентам изменений — тем, кто меняет процессы в фултайм-режиме. Но также он может пригодиться тимлидам и всем, кто влияет или строит новые процессы.
Что такое изменение процесса и зачем вообще что-то менять
Представим, что есть некий процесс, например покупки акции. На деле он, конечно, выглядит сложнее. Для простоты изобразим его так и представим, что это то, как процесс покупки акции работает сейчас.
![](https://static.tildacdn.com/tild3133-3836-4539-a430-316264303162/f1a47229ffea6b0166a0.png)
Допустим, мы хотим поменять этот процесс: покупка акции должна проходить быстрее.
![](https://static.tildacdn.com/tild3463-3663-4265-b436-656535313738/4dc3af049b1386fd9457.png)
В нашем случае это и будет изменение. Процесс может быть любым — от оформления кредита до перехода на новую методологию в команде.
Но зачем вообще что-то менять, когда существует правило «если это работает — не трогай»? Вот основные факторы, которые помогают понять, что над процессом пора поработать:
1. Мы несем разного рода потери. Например, время от времени теряются данные пользователя — то они записываются в базу данных, то нет. Если к нам придет регулятор и попросит отчет, он будет неполный и у нас будут большие проблемы.
2. Не закрываем текущие или будущие запросы компании. Например, команда состоит из пяти человек, а по плану должна разрастись в отдел из десяти команд. С большой вероятностью то, что работало для пяти человек, не будет работать для ста. Инфраструктура или сложившийся процесс коммуникаций не вывезет новую нагрузку — его нужно менять.
3. Видим «узкое горлышко» в общем процессе. Что-то конкретное может мешать стабильной работе общей системы. Если коллеги часто ругают нашу команду и говорят, что мы тормозим работу, это тоже повод меняться.
4. Необходимость быть готовым ко всему. Даже если сейчас процесс как-то работает, это не значит, что он продолжит работать в будущем. Лучше иметь запасной план, а в идеале — два или три таких плана.
Когда мы пытаемся изменить процесс, оказывается, что реальность несколько сложнее плана в нашей голове. Иногда в ходе изменений мы понимаем, что нам больно, коллегам больно и вообще было бы лучше вернуться во времени и ничего не менять. Но уже поздно.
Но зачем вообще что-то менять, когда существует правило «если это работает — не трогай»? Вот основные факторы, которые помогают понять, что над процессом пора поработать:
1. Мы несем разного рода потери. Например, время от времени теряются данные пользователя — то они записываются в базу данных, то нет. Если к нам придет регулятор и попросит отчет, он будет неполный и у нас будут большие проблемы.
2. Не закрываем текущие или будущие запросы компании. Например, команда состоит из пяти человек, а по плану должна разрастись в отдел из десяти команд. С большой вероятностью то, что работало для пяти человек, не будет работать для ста. Инфраструктура или сложившийся процесс коммуникаций не вывезет новую нагрузку — его нужно менять.
3. Видим «узкое горлышко» в общем процессе. Что-то конкретное может мешать стабильной работе общей системы. Если коллеги часто ругают нашу команду и говорят, что мы тормозим работу, это тоже повод меняться.
4. Необходимость быть готовым ко всему. Даже если сейчас процесс как-то работает, это не значит, что он продолжит работать в будущем. Лучше иметь запасной план, а в идеале — два или три таких плана.
Когда мы пытаемся изменить процесс, оказывается, что реальность несколько сложнее плана в нашей голове. Иногда в ходе изменений мы понимаем, что нам больно, коллегам больно и вообще было бы лучше вернуться во времени и ничего не менять. Но уже поздно.
![](https://static.tildacdn.com/tild3365-3339-4934-b537-326231396238/561415ce4f5dbcddb27f.png)
Чтобы вам и коллегам не было больно, предлагаю попробовать алгоритм — его я использую в 90% изменений, которые провожу.
Алгоритм проведения изменений
Скорее всего, вы сейчас посмотрите на алгоритм и скажете: «Да это же обычный STATIK». Я бы так не сказал. Они похожи, но называя алгоритм STATIK, мы подразумеваем, что и проводить изменение нужно по всем канонам. А там еще и канбан-метод начинает выглядывать из-за угла. Давайте не будем вешать ярлыки и просто назовем это процессом работы здорового человека.
Сперва посмотрим на алгоритм целиком, а затем разберем его этапы.
![Простой и изящный алгоритм проведения изменений](https://static.tildacdn.com/tild6438-3936-4130-b666-393261306161/451d64d85bac52bec6e2.png)
По этому алгоритму мы, например, работали с командой сопровождения и внедряли процесс запуска продуктов и фич Инвестиций на клиентов. Это когда все новые продукты или фичи от шести бизнес-команд (100+ человек) запускаются через одно окно. В итоге при релизе на клиентов у продукта обязательно заполнен FAQ, первая линия имеет на руках скрипты для ответов на вопросы клиентов, отдел продаж знает, как предлагать и продавать продукт, а все процедуры для самостоятельного решения проблем через чат-бота в мобильном приложении и на сайте обновлены.
А теперь перейдем к этапам.
А теперь перейдем к этапам.
Снятие запроса
Этот этап помогает понять, чего хочет человек, который пришел к вам с запросом на изменения. Или чего хотите вы, если вы сами стали их инициатором.
В качестве инструмента здесь лучше всего подойдет интервью с заказчиком и командой, которая вовлечена в процесс. Наша задача — вытащить всю информацию, которая только есть в головах, и визуализировать ее, чтобы дальнейшее обсуждение строилось вокруг понятных всем артефактов.
![Первый срез нужной информации](https://static.tildacdn.com/tild6137-3139-4532-b665-396334663361/c2cdae1e191665b1f130.png)
Обычно уже на этом этапе видны нестыковки того, о чем вас попросили изначально, с тем, во что трансформировался запрос по итогу встречи. Например, попросили помощи в настройке процесса планирования, а оказалось, что нужно заниматься тимлидом и его навыками управления командой.
Определение предназначения
На этом этапе мы должны понять, с чем или кем собираемся работать. Здесь важно увидеть все: чем этот сервис живет и дышит, какие у него клиенты, какие услуги он выполняет и кому нужен. Если на этом этапе мы видим рассинхрон между людьми, возможно, с изменениями нужно повременить. Лучше остановиться и еще раз все обсудить: а точно ли мы понимаем, что вообще делаем, и делаем ли мы это правильно?
![Пример борда по итогам второго этапа](https://static.tildacdn.com/tild6438-3732-4332-b235-636136613833/9faae148e1fd0ee63a44.png)
Инструменты, которые помогут на этом этапе, — это ваши корпоративные порталы, вики и документация. Благодаря им можно получить первое представление о том, из чего состоит сервис, как выглядит команда, увидеть состояние документации и прочие описания. И конечно же, используйте интервью. Ничто не заменит живого общения.
Формирование бэклога проблем и его приоритизация
Цель — визуализировать все проблемы и выбрать критичные. Те, с которых, скорее всего, мы начнем работу. Желательно кластеризовать их: например, разделить на проблемы клиента и проблемы команды. Можно еще добавить проблемы заказчиков и остальных команд, которым приходится общаться с вашим сервисом.
![](https://static.tildacdn.com/tild3738-3465-4362-b634-313966313937/a35dad951603c5662824.png)
На выходе получается некий бэклог, с которым можно работать. Он помогает увидеть фактуру, с которой вам предстоит разобраться. Можно периодически к нему обращаться, актуализировать и расширять.
Главный инструмент на этом этапе — интервью с командой и теми, кто взаимодействует с командой. CustDev — это наше все. Когда вы поймете, что получаете одну и ту же информацию от разных людей, интервью можно заканчивать: это будет означать, что у вас появилось относительно реалистичное понимание источников неудовлетворенности.
Также в качестве инструментов можно использовать опросы и метрики из ваших CRM, Jira и прочих программулин.
Главный инструмент на этом этапе — интервью с командой и теми, кто взаимодействует с командой. CustDev — это наше все. Когда вы поймете, что получаете одну и ту же информацию от разных людей, интервью можно заканчивать: это будет означать, что у вас появилось относительно реалистичное понимание источников неудовлетворенности.
Также в качестве инструментов можно использовать опросы и метрики из ваших CRM, Jira и прочих программулин.
Визуализация типов работ и их контекста
На этом этапе важно понять, какие типы работ есть в сервисе и откуда они приходят. Мы должны выяснить, какая работа может быть скрыта, и визуализировать ее. В примере ниже есть вопросительные знаки — когда мы не знаем, кому это нужно, зачем мы это делаем и так далее, но почему-то занимаемся этой работой. Возможно, так исторически сложилось. Если таких знаков вопроса очень много, лучше остановиться и попробовать понять, откуда они берутся, копнуть глубже в проблематику.
Например, почему мы прогоняем эти скрипты? Потому что кто-то когда-то прогнал один и теперь все к нам ходят? Почему это не может делать другая команда или какой-то робот с UI-интерфейсом?
![](https://static.tildacdn.com/tild3464-3031-4338-b330-383333376464/6d28b7dcb0b7ae82eeb8.png)
В качестве инструментов используйте интервью с командой и теми, кто с ней взаимодействует, опросы и анализ систем работы с задачами. Так вы сможете увидеть негативные и позитивные паттерны. Кроме того, полезно будет проанализировать метрики доставки и поискать в них скрытые типы работ.
Визуализация процесса AS IS → TO BE
Отлично. Мы поняли, с чем работаем, выбрали проблему, которую хотим решить, определили, как выглядит работа и кто ее потребитель. Но теперь нам нужно визуализировать процесс в его нынешнем виде и найти места, которые требуют улучшения. Красные стикеры в примере — слабые, по мнению команды, места.
![](https://static.tildacdn.com/tild3939-6335-4061-b736-393731376366/a34cd5897b809c3dab83.png)
Создать визуализацию помогут следующие инструменты:
Затем процесс AS IS нужно превратить в TO BE, то есть визуализировать желаемый результат.
- value stream mapping (VSM);
- customer journey map (CJM);
- event storming;
- интервью с теми, кто взаимодействует с процессом;
- анализ системы работы с задачами;
- анализ метрик доставки.
Затем процесс AS IS нужно превратить в TO BE, то есть визуализировать желаемый результат.
![](https://static.tildacdn.com/tild3966-3937-4563-a438-613665656163/4000f90eeb030edf8359.png)
Инструменты:
- Мозговой штурм. Почелленджить идею, обсудить, точно ли нам нужно именно это.
- Риск-менеджмент. Поработать с рисками, понять, не сломаются ли другие процессы.
- Формирование опережающих метрик и метрик успеха. Как мы поймем, что процесс потихоньку решает нашу проблему, и как оценим изменение в конце?
- Вопрос «Чем новый процесс лучше старого?». Если есть четкий и понятный ответ, можно начинать инвестировать в это свое время.
Стратегия и план проведения изменений
Если на предыдущем этапе мы поняли, что предполагаемый новый процесс отвечает на наши запросы и помогает решить проблему, можно переходить к стратегии. Здесь будем думать, как прийти к желаемому результату, и размазывать работу по его достижению по спринтам, месяцам или кварталам. Тут кому как удобно. Зависит от размера самого изменения. Чем лучше мы понимаем, что нужно делать, тем мельче декомпозируем задачи.
![](https://static.tildacdn.com/tild3737-3431-4938-a434-663330396130/5aa00b90dfe21e8ee965.png)
Инструменты:
- OKR. Кстати, возможно, в компании уже есть какая-то цель, которая решает проблему вашего процесса, но вы просто о ней не знаете. Поэтому полезно будет узнать, что еще происходит вокруг.
- SMART. Это план работы с проблемами. Там должны быть проблема, целевое решение, шаги и метрики успеха. Кроме того, нужно добавить зоны ответственности: мы не можем поменять процесс в одиночку. Важно понять, что будем делать мы и что будут делать другие люди. И конечно, важно попробовать предсказать риски: что может пойти не так и как мы будем с этим работать.
![](https://static.tildacdn.com/tild3233-3230-4461-b864-316563633164/ae63e0c8d03840fc0c72.png)
Инструменты:
- риск-менеджмент;
- мозговой штурм
Публичная презентация плана
Итак, у нас есть стратегия. Но мы не одни в этом процессе. Поэтому перед тем, как начинать вводить изменения, нужно показать коллегам, что мы хотим сделать, в какие сроки и как это повлияет их работу.
На мой взгляд, это один из самых сложных, неприятных и важных этапов в проведении изменения. Именно его часто пропускают, а потом удивляются, почему никто не понимает ценности изменения. Этот этап пугает, потому что мы уже инвестировали в проработку много сил и эмоций и очень страшно получить от коллег негативную обратную связь. Например, узнать, что им не нужно это изменение и вообще мы боремся с ветряными мельницами, так как они уже решили эту проблему в своих командах. Или решают, и нужно просто подождать пару месяцев.
![](https://static.tildacdn.com/tild6366-3331-4034-a136-303239663266/4bf083a630d3685eff8e.png)
Также люди могут быть перегружены, могут не видеть ценности в изменениях — по этим и другим причинам они могут без энтузиазма отнестись к идее что-то менять. Фишка публичного рассказа в том, чтобы коллеги, которым предстоит жить в новом процессе, отчелленджили ваши планы.
И конечно, важна корректировка. Сначала мы собираем фидбэк — возможно, не самый приятный, меняем план под новые вводные от коллег, а потом возвращаемся и презентуем план еще раз, но уже сделав работу над ошибками.
Заключение контракта
Только когда все посмотрели на план и одобрили его, мы заключаем контракт с заказчиком. Или с собой, если инициаторы мы. Потому что все, что мы делали до этого, — это процесс discovery. План действий лучше разместить в публичном пространстве, чтобы все участники процесса могли как максимум использовать его в работе и обращаться к нему, а как минимум — знали, где он лежит.
Исполнение
И только на этом этапе начинается delivery. Так как мы хорошо вложились в discovery, на этапе delivery нам остается только фигачить. Ведь у нас уже все для этого готово.
Но чтобы наш план не развалился и не протух в процессе работы, важно помнить о синхронизации. Определите точки, в которых вы будете собирать обратную связь от людей, задействованных в процессе. Каждые три недели, месяц, квартал? Эти промежутки времени придется нащупывать эмпирическим путем. Это важная часть проведения изменения, так как в командах, компании и мире постоянно что-то меняется — план должен учитывать новый контекст. И конечно, важно не забывать смотреть на метрики, которые мы сформулировали на этапе формирования плана.
![Регулярный сбор обратной связи — страховка от никому не нужных действий](https://static.tildacdn.com/tild6539-3337-4134-a135-643132316436/0a821e026a481e225d4c.png)
Регулярный сбор обратной связи — страховка от никому не нужных действий.
Подведение итогов
Проведение изменений, особенно в большой компании, — это бесценный опыт. И я рекомендую складировать ваш опыт внедрения изменений в какую-то базу. Если получится настроить такой процесс на уровне команд, вы сможете быстрее обучаться сами и обучать коллег.
Только представьте, что, начиная новый проект, вы делаете себе чашку кофе, заходите в базу проектных ретроспектив и видите примеры, как делать не надо. Вам будет гораздо проще работать над проектом, понимая, с какими проблемами столкнулись коллеги и какие решения они предложили. В крайнем случае можно просто написать коллегам в личку и попросить поделиться опытом, если ваш проект похож на тот, что когда-то делали они.
Важно не только положить куда-то опыт, но и рассказать о нем. Поэтому здесь пригодятся презентации для коллег: было вот так, стало вот так, результаты такие, лежит вот здесь, пользуйтесь на здоровье. Также помогут информационные рассылки: если их нет, о вашем изменении никто не узнает. Поэтому постарайтесь организовать каналы коммуникаций для доставки знаний.
Заключение
На мой взгляд, любое изменение — это проект, и работать с ним нужно по всем канонам проектного менеджмента. Не бойтесь инвестировать в процесс discovery. Будет прекрасно, если именно на этом этапе вы поймете, что изменение обречено на провал и никому не нужно. Вы потратите только свое время, но не успеете задействовать коллег. Если вы начали что-то менять в командах или компании и плохо поработали над аналитикой и планом проведения, это может привести к денежным и эмоциональным потерям — и даже к потере коллег, которые могут уволиться.
При небольших изменениях и незабитых календарях по алгоритму можно пройтись за две-три недели, но чаще всего на глубокую аналитику крупного изменения уходит один-два месяца.
Помните, что процесс изменений не такой уж страшный, если подходить к нему с умом. Но, конечно, лучшее изменение — это то, которого удалось избежать.
🎃 Не всё чем я занимаюсь попадает на сайт. В моём telegram-канале «Доставка ценности» ты сможешь следить за публикацией новых статей, кейсов, видео, анонсов вебинаров, мастер-классов и мыслями на разные темы. Так же в комментариях можно поделиться своим опытом, спросить совета у коллег.