![](https://habrastorage.org/getpro/habr/upload_files/c15/3fc/4e3/c153fc4e337a6b4e8478112e4f27bfd1.png)
Привет! Меня зовут Михаил Мартынов, я деливери-менеджер Тинькофф Инвестиций. Мы с коллегами занимаемся тем, что улучшаем процессы. Они бывают самые разные:
— работа с проектами и задачами;
— разного рода планирование;
— процесс интеграционного тестирования;
— визуализация и сжигание технического долга;
— сокращение time-to-market;
— проработка бизнес-идей и многое другое.
В декабре прошел очередной IT's Tinkoff Process Improvement #2 — митап, посвященный управлению изменениями. Вместе с коллегами из других компаний мы обсуждали, как проводить изменения и какие инструменты применять. Римма Денисовец из and Change выступила с докладом «Пять этапов для успешных изменений ADKAR», а Денис Тучин из Agile Collage раскрыл тему «3 основных ошибки агента изменений». Я же подготовил доклад «Как не навредить себе и коллегам? Стратегия проведения изменений».
В статье поделюсь текстовой версией доклада и видеозаписями всех выступлений коллег. В первую очередь текст будет полезен агентам изменений — тем, кто меняет процессы в фултайм-режиме. Но также он может пригодиться тимлидам и всем, кто влияет или строит новые процессы.
Что такое изменение процесса и зачем вообще что-то менять
Представим, что есть некий процесс, например покупки акции. На деле он, конечно, выглядит сложнее. Для простоты изобразим его так и представим, что это то, как процесс покупки акции работает сейчас.
![](https://habrastorage.org/getpro/habr/upload_files/f1a/472/29f/f1a47229ffea6b0166a01ab65b021b0a.png)
Допустим, мы хотим поменять этот процесс: покупка акции должна проходить быстрее.
![](https://habrastorage.org/getpro/habr/upload_files/4dc/3af/049/4dc3af049b1386fd945718fefcfe5387.png)
В нашем случае это и будет изменение. Процесс может быть любым — от оформления кредита до перехода на новую методологию в команде.
Но зачем вообще что-то менять, когда существует правило «если это работает — не трогай»? Вот основные факторы, которые помогают понять, что над процессом пора поработать:
1. Мы несем разного рода потери. Например, время от времени теряются данные пользователя — то они записываются в базу данных, то нет. Если к нам придет регулятор и попросит отчет, он будет неполный и у нас будут большие проблемы.
2. Не закрываем текущие или будущие запросы компании. Например, команда состоит из пяти человек, а по плану должна разрастись в отдел из десяти команд. С большой вероятностью то, что работало для пяти человек, не будет работать для ста. Инфраструктура или сложившийся процесс коммуникаций не вывезет новую нагрузку — его нужно менять.
3. Видим «узкое горлышко» в общем процессе. Что-то конкретное может мешать стабильной работе общей системы. Если коллеги часто ругают нашу команду и говорят, что мы тормозим работу, это тоже повод меняться.
4. Необходимость быть готовым ко всему. Даже если сейчас процесс как-то работает, это не значит, что он продолжит работать в будущем. Лучше иметь запасной план, а в идеале — два или три таких плана.
Когда мы пытаемся изменить процесс, оказывается, что реальность несколько сложнее плана в нашей голове. Иногда в ходе изменений мы понимаем, что нам больно, коллегам больно и вообще было бы лучше вернуться во времени и ничего не менять. Но уже поздно.
![](https://habrastorage.org/getpro/habr/upload_files/561/415/ce4/561415ce4f5dbcddb27f80b6a57a2ecb.png)
Чтобы вам и коллегам не было больно, предлагаю попробовать алгоритм — его я использую в 90% изменений, которые провожу.
Алгоритм проведения изменений
Скорее всего, вы сейчас посмотрите на алгоритм и скажете: «Да это же обычный STATIK». Я бы так не сказал. Они похожи, но называя алгоритм STATIK, мы подразумеваем, что и проводить изменение нужно по всем канонам. А там еще и канбан-метод начинает выглядывать из-за угла. Давайте не будем вешать ярлыки и просто назовем это процессом работы здорового человека.
Сперва посмотрим на алгоритм целиком, а затем разберем его этапы.
![Простой и изящный алгоритм проведения изменений Простой и изящный алгоритм проведения изменений](https://habrastorage.org/getpro/habr/upload_files/451/d64/d85/451d64d85bac52bec6e28d1fd06b811f.png)
По этому алгоритму мы, например, работали с командой сопровождения и внедряли процесс запуска продуктов и фич Инвестиций на клиентов. Это когда все новые продукты или фичи от шести бизнес-команд (100+ человек) запускаются через одно окно. В итоге при релизе на клиентов у продукта обязательно заполнен FAQ, первая линия имеет на руках скрипты для ответов на вопросы клиентов, отдел продаж знает, как предлагать и продавать продукт, а все процедуры для самостоятельного решения проблем через чат-бота в мобильном приложении и на сайте обновлены.
А теперь перейдем к этапам.
Снятие запроса
Этот этап помогает понять, чего хочет человек, который пришел к вам с запросом на изменения. Или чего хотите вы, если вы сами стали их инициатором.
В качестве инструмента здесь лучше всего подойдет интервью с заказчиком и командой, которая вовлечена в процесс. Наша задача — вытащить всю информацию, которая только есть в головах, и визуализировать ее, чтобы дальнейшее обсуждение строилось вокруг понятных всем артефактов.
![Первый срез нужной информации Первый срез нужной информации](https://habrastorage.org/getpro/habr/upload_files/c2c/dae/1e1/c2cdae1e191665b1f130a89431e3c3be.png)
Обычно уже на этом этапе видны нестыковки того, о чем вас попросили изначально, с тем, во что трансформировался запрос по итогу встречи. Например, попросили помощи в настройке процесса планирования, а оказалось, что нужно заниматься тимлидом и его навыками управления командой.
Определение предназначения
На этом этапе мы должны понять, с чем или кем собираемся работать. Здесь важно увидеть все: чем этот сервис живет и дышит, какие у него клиенты, какие услуги он выполняет и кому нужен. Если на этом этапе мы видим рассинхрон между людьми, возможно, с изменениями нужно повременить. Лучше остановиться и еще раз все обсудить: а точно ли мы понимаем, что вообще делаем, и делаем ли мы это правильно?
![Пример борда по итогам второго этапа Пример борда по итогам второго этапа](https://habrastorage.org/getpro/habr/upload_files/9fa/ae1/48e/9faae148e1fd0ee63a44a527c6a28c49.png)
Инструменты, которые помогут на этом этапе, — это ваши корпоративные порталы, вики и документация. Благодаря им можно получить первое представление о том, из чего состоит сервис, как выглядит команда, увидеть состояние документации и прочие описания. И конечно же, используйте интервью. Ничто не заменит живого общения.
Формирование бэклога проблем и его приоритизация
Цель — визуализировать все проблемы и выбрать критичные. Те, с которых, скорее всего, мы начнем работу. Желательно кластеризовать их: например, разделить на проблемы клиента и проблемы команды. Можно еще добавить проблемы заказчиков и остальных команд, которым приходится общаться с вашим сервисом.
![](https://habrastorage.org/getpro/habr/upload_files/a35/dad/951/a35dad951603c56628243ec0db696188.png)
На выходе получается некий бэклог, с которым можно работать. Он помогает увидеть фактуру, с которой вам предстоит разобраться. Можно периодически к нему обращаться, актуализировать и расширять.
Главный инструмент на этом этапе — интервью с командой и теми, кто взаимодействует с командой. CustDev — это наше все. Когда вы поймете, что получаете одну и ту же информацию от разных людей, интервью можно заканчивать: это будет означать, что у вас появилось относительно реалистичное понимание источников неудовлетворенности.
Также в качестве инструментов можно использовать опросы и метрики из ваших CRM, Jira и прочих программулин.
Визуализация типов работ и их контекста
На этом этапе важно понять, какие типы работ есть в сервисе и откуда они приходят. Мы должны выяснить, какая работа может быть скрыта, и визуализировать ее. В примере ниже есть вопросительные знаки — когда мы не знаем, кому это нужно, зачем мы это делаем и так далее, но почему-то занимаемся этой работой. Возможно, так исторически сложилось. Если таких знаков вопроса очень много, лучше остановиться и попробовать понять, откуда они берутся, копнуть глубже в проблематику.
Например, почему мы прогоняем эти скрипты? Потому что кто-то когда-то прогнал один и теперь все к нам ходят? Почему это не может делать другая команда или какой-то робот с UI-интерфейсом?
![](https://habrastorage.org/getpro/habr/upload_files/6d2/8b7/dcb/6d28b7dcb0b7ae82eeb8f30dd9bdbba6.png)
В качестве инструментов используйте интервью с командой и теми, кто с ней взаимодействует, опросы и анализ систем работы с задачами. Так вы сможете увидеть негативные и позитивные паттерны. Кроме того, полезно будет проанализировать метрики доставки и поискать в них скрытые типы работ.
Визуализация процесса AS IS → TO BE
Отлично. Мы поняли, с чем работаем, выбрали проблему, которую хотим решить, определили, как выглядит работа и кто ее потребитель. Но теперь нам нужно визуализировать процесс в его нынешнем виде и найти места, которые требуют улучшения. Красные стикеры в примере — слабые, по мнению команды, места.
![](https://habrastorage.org/getpro/habr/upload_files/a34/cd5/897/a34cd5897b809c3dab83d19a74cc6fb8.png)
Создать визуализацию помогут следующие инструменты:
— value stream mapping (VSM);
— customer journey map (CJM);
— event storming;
— интервью с теми, кто взаимодействует с процессом;
— анализ системы работы с задачами;
— анализ метрик доставки.
Затем процесс AS IS нужно превратить в TO BE, то есть визуализировать желаемый результат.
![](https://habrastorage.org/getpro/habr/upload_files/400/0f9/0ee/4000f90eeb030edf83599e4cf1545f3f.png)
Инструменты:
— Мозговой штурм. Почелленджить идею, обсудить, точно ли нам нужно именно это.
— Риск-менеджмент. Поработать с рисками, понять, не сломаются ли другие процессы.
— Формирование опережающих метрик и метрик успеха. Как мы поймем, что процесс потихоньку решает нашу проблему, и как оценим изменение в конце?
— Вопрос «Чем новый процесс лучше старого?». Если есть четкий и понятный ответ, можно начинать инвестировать в это свое время.
Стратегия и план проведения изменений
Если на предыдущем этапе мы поняли, что предполагаемый новый процесс отвечает на наши запросы и помогает решить проблему, можно переходить к стратегии. Здесь будем думать, как прийти к желаемому результату, и размазывать работу по его достижению по спринтам, месяцам или кварталам. Тут кому как удобно. Зависит от размера самого изменения. Чем лучше мы понимаем, что нужно делать, тем мельче декомпозируем задачи.
![](https://habrastorage.org/getpro/habr/upload_files/5aa/00b/90d/5aa00b90dfe21e8ee9657f1e46743a51.png)
Инструменты:
— OKR. Кстати, возможно, в компании уже есть какая-то цель, которая решает проблему вашего процесса, но вы просто о ней не знаете. Поэтому полезно будет узнать, что еще происходит вокруг.
— SMART. Это план работы с проблемами. Там должны быть проблема, целевое решение, шаги и метрики успеха. Кроме того, нужно добавить зоны ответственности: мы не можем поменять процесс в одиночку. Важно понять, что будем делать мы и что будут делать другие люди. И конечно, важно попробовать предсказать риски: что может пойти не так и как мы будем с этим работать.
![](https://habrastorage.org/getpro/habr/upload_files/ae6/3e0/c8d/ae63e0c8d03840fc0c7204af8e5d7d95.png)
Инструменты:
— риск-менеджмент;
— мозговой штурм.
Публичная презентация плана
Итак, у нас есть стратегия. Но мы не одни в этом процессе. Поэтому перед тем, как начинать вводить изменения, нужно показать коллегам, что мы хотим сделать, в какие сроки и как это повлияет их работу.
На мой взгляд, это один из самых сложных, неприятных и важных этапов в проведении изменения. Именно его часто пропускают, а потом удивляются, почему никто не понимает ценности изменения. Этот этап пугает, потому что мы уже инвестировали в проработку много сил и эмоций и очень страшно получить от коллег негативную обратную связь. Например, узнать, что им не нужно это изменение и вообще мы боремся с ветряными мельницами, так как они уже решили эту проблему в своих командах. Или решают, и нужно просто подождать пару месяцев.
![](https://habrastorage.org/getpro/habr/upload_files/4bf/083/a63/4bf083a630d3685eff8eaddc0c7f5e33.png)
Также люди могут быть перегружены, могут не видеть ценности в изменениях — по этим и другим причинам они могут без энтузиазма отнестись к идее что-то менять. Фишка публичного рассказа в том, чтобы коллеги, которым предстоит жить в новом процессе, отчелленджили ваши планы.
И конечно, важна корректировка. Сначала мы собираем фидбэк — возможно, не самый приятный, меняем план под новые вводные от коллег, а потом возвращаемся и презентуем план еще раз, но уже сделав работу над ошибками.
Заключение контракта
Только когда все посмотрели на план и одобрили его, мы заключаем контракт с заказчиком. Или с собой, если инициаторы мы. Потому что все, что мы делали до этого, — это процесс discovery. План действий лучше разместить в публичном пространстве, чтобы все участники процесса могли как максимум использовать его в работе и обращаться к нему, а как минимум — знали, где он лежит.
Исполнение
И только на этом этапе начинается delivery. Так как мы хорошо вложились в discovery, на этапе delivery нам остается только фигачить. Ведь у нас уже все для этого готово.
Но чтобы наш план не развалился и не протух в процессе работы, важно помнить о синхронизации. Определите точки, в которых вы будете собирать обратную связь от людей, задействованных в процессе. Каждые три недели, месяц, квартал? Эти промежутки времени придется нащупывать эмпирическим путем. Это важная часть проведения изменения, так как в командах, компании и мире постоянно что-то меняется — план должен учитывать новый контекст. И конечно, важно не забывать смотреть на метрики, которые мы сформулировали на этапе формирования плана.
![Регулярный сбор обратной связи — страховка от никому не нужных действий Регулярный сбор обратной связи — страховка от никому не нужных действий](https://habrastorage.org/getpro/habr/upload_files/0a8/21e/026/0a821e026a481e225d4c535b14fa3923.png)
Регулярный сбор обратной связи — страховка от никому не нужных действий
Подведение итогов
Проведение изменений, особенно в большой компании, — это бесценный опыт. И я рекомендую складировать ваш опыт внедрения изменений в какую-то базу. Если получится настроить такой процесс на уровне команд, вы сможете быстрее обучаться сами и обучать коллег.
Только представьте, что, начиная новый проект, вы делаете себе чашку кофе, заходите в базу проектных ретроспектив и видите примеры, как делать не надо. Вам будет гораздо проще работать над проектом, понимая, с какими проблемами столкнулись коллеги и какие решения они предложили. В крайнем случае можно просто написать коллегам в личку и попросить поделиться опытом, если ваш проект похож на тот, что когда-то делали они.
Важно не только положить куда-то опыт, но и рассказать о нем. Поэтому здесь пригодятся презентации для коллег: было вот так, стало вот так, результаты такие, лежит вот здесь, пользуйтесь на здоровье. Также помогут информационные рассылки: если их нет, о вашем изменении никто не узнает. Поэтому постарайтесь организовать каналы коммуникаций для доставки знаний.
Заключение
На мой взгляд, любое изменение — это проект, и работать с ним нужно по всем канонам проектного менеджмента. Не бойтесь инвестировать в процесс discovery. Будет прекрасно, если именно на этом этапе вы поймете, что изменение обречено на провал и никому не нужно. Вы потратите только свое время, но не успеете задействовать коллег. Если вы начали что-то менять в командах или компании и плохо поработали над аналитикой и планом проведения, это может привести к денежным и эмоциональным потерям — и даже к потере коллег, которые могут уволиться.
При небольших изменениях и незабитых календарях по алгоритму можно пройтись за две-три недели, но чаще всего на глубокую аналитику крупного изменения уходит один-два месяца.
Помните, что процесс изменений не такой уж страшный, если подходить к нему с умом. Но, конечно, лучшее изменение — это то, которого удалось избежать.
Буду рад узнать ваш опыт и мнения по поводу такого подхода к работе. С удовольствием отвечу на вопросы в комментах.
Видео докладов
Если хотите посмотреть видео с других наших митапов или посетить один из них, приглашаю на страницу мероприятий.