Для тех, кто не#nbsp;любит читать, есть видео доклада.
Привет! Меня зовут Михаил Мартынов, я#nbsp;деливери-менеджер Тинькофф Инвестиций. Мы#nbsp;с#nbsp;коллегами занимаемся тем, что улучшаем процессы. Они бывают самые разные:
В#nbsp;статье поделюсь текстовой версией доклада и#nbsp;видеозаписями всех выступлений коллег. В#nbsp;первую очередь текст будет полезен агентам изменений#nbsp;— тем, кто меняет процессы в#nbsp;фултайм-режиме. Но#nbsp;также он#nbsp;может пригодиться тимлидам и#nbsp;всем, кто влияет или строит новые процессы.
Что такое изменение процесса и зачем вообще что-то менять
Представим, что есть некий процесс, например покупки акции. На#nbsp;деле он, конечно, выглядит сложнее. Для#nbsp;простоты изобразим его так и#nbsp;представим, что это то, как процесс покупки акции работает сейчас.
Допустим, мы#nbsp;хотим поменять этот процесс: покупка акции должна проходить быстрее.
В#nbsp;нашем случае это и#nbsp;будет изменение. Процесс может быть любым#nbsp;— от#nbsp;оформления кредита до#nbsp;перехода на#nbsp;новую методологию в#nbsp;команде.
Но#nbsp;зачем вообще что-то менять, когда существует правило «если это работает#nbsp;— не#nbsp;трогай»? Вот основные факторы, которые помогают понять, что над процессом пора поработать:
1. Мы#nbsp;несем разного рода потери. Например, время от#nbsp;времени теряются данные пользователя#nbsp;— то#nbsp;они записываются в#nbsp;базу данных, то#nbsp;нет. Если к#nbsp;нам придет регулятор и#nbsp;попросит отчет, он#nbsp;будет неполный и#nbsp;у#nbsp;нас будут большие проблемы.
2. Не#nbsp;закрываем текущие или будущие запросы компании. Например, команда состоит из#nbsp;пяти человек, а#nbsp;по#nbsp;плану должна разрастись в#nbsp;отдел из#nbsp;десяти команд. С#nbsp;большой вероятностью то, что работало для#nbsp;пяти человек, не#nbsp;будет работать для#nbsp;ста. Инфраструктура или сложившийся процесс коммуникаций не#nbsp;вывезет новую нагрузку#nbsp;— его нужно менять.
3. Видим «узкое горлышко» в#nbsp;общем процессе. Что-то конкретное может мешать стабильной работе общей системы. Если коллеги часто ругают нашу команду и#nbsp;говорят, что мы#nbsp;тормозим работу, это тоже повод меняться.
4. Необходимость быть готовым ко#nbsp;всему. Даже если сейчас процесс как-то работает, это не#nbsp;значит, что он#nbsp;продолжит работать в#nbsp;будущем. Лучше иметь запасной план, а#nbsp;в#nbsp;идеале#nbsp;— два или три таких плана.
Когда мы#nbsp;пытаемся изменить процесс, оказывается, что реальность несколько сложнее плана в#nbsp;нашей голове. Иногда в#nbsp;ходе изменений мы#nbsp;понимаем, что нам больно, коллегам больно и#nbsp;вообще было#nbsp;бы лучше вернуться во#nbsp;времени и#nbsp;ничего не#nbsp;менять. Но#nbsp;уже поздно.
Чтобы вам и#nbsp;коллегам не#nbsp;было больно, предлагаю попробовать алгоритм#nbsp;— его я#nbsp;использую в#nbsp;90% изменений, которые провожу.
Алгоритм проведения изменений
Скорее всего, вы#nbsp;сейчас посмотрите на#nbsp;алгоритм и#nbsp;скажете: «Да#nbsp;это#nbsp;же обычный STATIK». Я#nbsp;бы#nbsp;так не#nbsp;сказал. Они похожи, но#nbsp;называя алгоритм STATIK, мы#nbsp;подразумеваем, что и#nbsp;проводить изменение нужно по#nbsp;всем канонам. А#nbsp;там еще и#nbsp;канбан-метод начинает выглядывать из-за угла. Давайте не#nbsp;будем вешать ярлыки и#nbsp;просто назовем это процессом работы здорового человека.
Сперва посмотрим на#nbsp;алгоритм целиком, а#nbsp;затем разберем его этапы.
По#nbsp;этому алгоритму мы, например, работали с#nbsp;командой сопровождения и#nbsp;внедряли процесс запуска продуктов и#nbsp;фич Инвестиций на#nbsp;клиентов. Это когда все новые продукты или фичи от#nbsp;шести бизнес-команд (100+ человек) запускаются через одно окно. В#nbsp;итоге при релизе на#nbsp;клиентов у#nbsp;продукта обязательно заполнен FAQ, первая линия имеет на#nbsp;руках скрипты для#nbsp;ответов на#nbsp;вопросы клиентов, отдел продаж знает, как предлагать и#nbsp;продавать продукт, а#nbsp;все процедуры для#nbsp;самостоятельного решения проблем через чат-бота в#nbsp;мобильном приложении и#nbsp;на#nbsp;сайте обновлены.
А#nbsp;теперь перейдем к#nbsp;этапам.
Снятие запроса
Этот этап помогает понять, чего хочет человек, который пришел к#nbsp;вам с#nbsp;запросом на#nbsp;изменения. Или чего хотите вы, если вы#nbsp;сами стали их#nbsp;инициатором.
В#nbsp;качестве инструмента здесь лучше всего подойдет интервью с#nbsp;заказчиком и#nbsp;командой, которая вовлечена в#nbsp;процесс. Наша задача#nbsp;— вытащить всю информацию, которая только есть в#nbsp;головах, и#nbsp;визуализировать ее, чтобы дальнейшее обсуждение строилось вокруг понятных всем артефактов.
Обычно уже на#nbsp;этом этапе видны нестыковки того, о#nbsp;чем вас попросили изначально, с#nbsp;тем, во#nbsp;что трансформировался запрос по#nbsp;итогу встречи. Например, попросили помощи в#nbsp;настройке процесса планирования, а#nbsp;оказалось, что нужно заниматься тимлидом и#nbsp;его навыками управления командой.
Определение предназначения
На#nbsp;этом этапе мы#nbsp;должны понять, с#nbsp;чем или кем собираемся работать. Здесь важно увидеть все: чем этот сервис живет и#nbsp;дышит, какие у#nbsp;него клиенты, какие услуги он#nbsp;выполняет и#nbsp;кому нужен. Если на#nbsp;этом этапе мы#nbsp;видим рассинхрон между людьми, возможно, с#nbsp;изменениями нужно повременить. Лучше остановиться и#nbsp;еще раз все обсудить: а#nbsp;точно#nbsp;ли мы#nbsp;понимаем, что вообще делаем, и#nbsp;делаем#nbsp;ли мы#nbsp;это правильно?
Инструменты, которые помогут на#nbsp;этом этапе,#nbsp;— это ваши корпоративные порталы, вики и#nbsp;документация. Благодаря им#nbsp;можно получить первое представление о#nbsp;том, из#nbsp;чего состоит сервис, как выглядит команда, увидеть состояние документации и#nbsp;прочие описания. И#nbsp;конечно#nbsp;же, используйте интервью. Ничто не#nbsp;заменит живого общения.
Формирование бэклога проблем и его приоритизация
Цель#nbsp;— визуализировать все проблемы и#nbsp;выбрать критичные. Те, с#nbsp;которых, скорее всего, мы#nbsp;начнем работу. Желательно кластеризовать их: например, разделить на#nbsp;проблемы клиента и#nbsp;проблемы команды. Можно еще добавить проблемы заказчиков и#nbsp;остальных команд, которым приходится общаться с#nbsp;вашим сервисом.
На#nbsp;выходе получается некий бэклог, с#nbsp;которым можно работать. Он#nbsp;помогает увидеть фактуру, с#nbsp;которой вам предстоит разобраться. Можно периодически к#nbsp;нему обращаться, актуализировать и#nbsp;расширять.
Главный инструмент на#nbsp;этом этапе#nbsp;— интервью с#nbsp;командой и#nbsp;теми, кто взаимодействует с#nbsp;командой. CustDev#nbsp;— это наше все. Когда вы#nbsp;поймете, что получаете одну и#nbsp;ту#nbsp;же информацию от#nbsp;разных людей, интервью можно заканчивать: это будет означать, что у#nbsp;вас появилось относительно реалистичное понимание источников неудовлетворенности.
Также в#nbsp;качестве инструментов можно использовать опросы и#nbsp;метрики из#nbsp;ваших CRM, Jira и#nbsp;прочих программулин.
Визуализация типов работ и их контекста
На#nbsp;этом этапе важно понять, какие типы работ есть в#nbsp;сервисе и#nbsp;откуда они приходят. Мы#nbsp;должны выяснить, какая работа может быть скрыта, и#nbsp;визуализировать#nbsp;ее. В#nbsp;примере ниже есть вопросительные знаки#nbsp;— когда мы#nbsp;не#nbsp;знаем, кому это нужно, зачем мы#nbsp;это делаем и#nbsp;так далее, но#nbsp;почему-то занимаемся этой работой. Возможно, так исторически сложилось. Если таких знаков вопроса очень много, лучше остановиться и#nbsp;попробовать понять, откуда они берутся, копнуть глубже в#nbsp;проблематику.
Например, почему мы#nbsp;прогоняем эти скрипты? Потому что кто-то когда-то прогнал один и#nbsp;теперь все к#nbsp;нам ходят? Почему это не#nbsp;может делать другая команда или какой-то робот с#nbsp;UI-интерфейсом?
В#nbsp;качестве инструментов используйте интервью с#nbsp;командой и#nbsp;теми, кто с#nbsp;ней взаимодействует, опросы и#nbsp;анализ систем работы с#nbsp;задачами. Так вы#nbsp;сможете увидеть негативные и#nbsp;позитивные паттерны. Кроме того, полезно будет проанализировать метрики доставки и#nbsp;поискать в#nbsp;них скрытые типы работ.
Визуализация процесса AS IS → TO BE
Отлично. Мы#nbsp;поняли, с#nbsp;чем работаем, выбрали проблему, которую хотим решить, определили, как выглядит работа и#nbsp;кто ее#nbsp;потребитель. Но#nbsp;теперь нам нужно визуализировать процесс в#nbsp;его нынешнем виде и#nbsp;найти места, которые требуют улучшения. Красные стикеры в#nbsp;примере#nbsp;— слабые, по#nbsp;мнению команды, места.
Создать визуализацию помогут следующие инструменты:
value stream mapping (VSM);
customer journey map (CJM);
event storming;
интервью с#nbsp;теми, кто взаимодействует с#nbsp;процессом;
анализ системы работы с#nbsp;задачами;
анализ метрик доставки.
Затем процесс#nbsp;AS IS#nbsp;нужно превратить в#nbsp;TO BE, то#nbsp;есть визуализировать желаемый результат.
Инструменты:
Мозговой штурм. Почелленджить идею, обсудить, точно#nbsp;ли нам нужно именно это.
Риск-менеджмент. Поработать с#nbsp;рисками, понять, не#nbsp;сломаются#nbsp;ли другие процессы.
Формирование опережающих метрик и#nbsp;метрик успеха. Как мы#nbsp;поймем, что процесс потихоньку решает нашу проблему, и#nbsp;как оценим изменение в#nbsp;конце?
Вопрос «Чем новый процесс лучше старого?». Если есть четкий и#nbsp;понятный ответ, можно начинать инвестировать в#nbsp;это свое время.
Стратегия и план проведения изменений
Если на#nbsp;предыдущем этапе мы#nbsp;поняли, что предполагаемый новый процесс отвечает на#nbsp;наши запросы и#nbsp;помогает решить проблему, можно переходить к#nbsp;стратегии. Здесь будем думать, как прийти к#nbsp;желаемому результату, и#nbsp;размазывать работу по#nbsp;его достижению по#nbsp;спринтам, месяцам или кварталам. Тут кому как удобно. Зависит от#nbsp;размера самого изменения. Чем лучше мы#nbsp;понимаем, что нужно делать, тем мельче декомпозируем задачи.
Инструменты:
OKR. Кстати, возможно, в#nbsp;компании уже есть какая-то цель, которая решает проблему вашего процесса, но#nbsp;вы#nbsp;просто о#nbsp;ней не#nbsp;знаете. Поэтому полезно будет узнать, что еще происходит вокруг.
SMART. Это план работы с#nbsp;проблемами. Там должны быть проблема, целевое решение, шаги и#nbsp;метрики успеха. Кроме того, нужно добавить зоны ответственности: мы#nbsp;не#nbsp;можем поменять процесс в#nbsp;одиночку. Важно понять, что будем делать мы#nbsp;и#nbsp;что будут делать другие люди. И#nbsp;конечно, важно попробовать предсказать риски: что может пойти не#nbsp;так и#nbsp;как мы#nbsp;будем с#nbsp;этим работать.
Инструменты:
риск-менеджмент;
мозговой штурм
Публичная презентация плана
Итак, у#nbsp;нас есть стратегия. Но#nbsp;мы#nbsp;не одни в#nbsp;этом процессе. Поэтому перед тем, как начинать вводить изменения, нужно показать коллегам, что мы#nbsp;хотим сделать, в#nbsp;какие сроки и#nbsp;как это повлияет их#nbsp;работу.
На#nbsp;мой взгляд, это один из#nbsp;самых сложных, неприятных и#nbsp;важных этапов в#nbsp;проведении изменения. Именно его часто пропускают, а#nbsp;потом удивляются, почему никто не#nbsp;понимает ценности изменения. Этот этап пугает, потому что мы#nbsp;уже инвестировали в#nbsp;проработку много сил и#nbsp;эмоций и#nbsp;очень страшно получить от#nbsp;коллег негативную обратную связь. Например, узнать, что им#nbsp;не#nbsp;нужно это изменение и#nbsp;вообще мы#nbsp;боремся с#nbsp;ветряными мельницами, так как они уже решили эту проблему в#nbsp;своих командах. Или решают, и#nbsp;нужно просто подождать пару месяцев.
Также люди могут быть перегружены, могут не#nbsp;видеть ценности в#nbsp;изменениях#nbsp;— по#nbsp;этим и#nbsp;другим причинам они могут без энтузиазма отнестись к#nbsp;идее что-то менять. Фишка публичного рассказа в#nbsp;том, чтобы коллеги, которым предстоит жить в#nbsp;новом процессе, отчелленджили ваши планы.
И#nbsp;конечно, важна корректировка. Сначала мы#nbsp;собираем фидбэк#nbsp;— возможно, не#nbsp;самый приятный, меняем план под новые вводные от#nbsp;коллег, а#nbsp;потом возвращаемся и#nbsp;презентуем план еще раз, но#nbsp;уже сделав работу над ошибками.
Заключение контракта
Только когда все посмотрели на#nbsp;план и#nbsp;одобрили его, мы#nbsp;заключаем контракт с#nbsp;заказчиком. Или с#nbsp;собой, если инициаторы#nbsp;мы. Потому что все, что мы#nbsp;делали до#nbsp;этого,#nbsp;— это процесс discovery. План действий лучше разместить в#nbsp;публичном пространстве, чтобы все участники процесса могли как максимум использовать его в#nbsp;работе и#nbsp;обращаться к#nbsp;нему, а#nbsp;как минимум#nbsp;— знали, где он#nbsp;лежит.
Исполнение
И#nbsp;только на#nbsp;этом этапе начинается delivery. Так как мы#nbsp;хорошо вложились в#nbsp;discovery, на#nbsp;этапе delivery нам остается только фигачить. Ведь у#nbsp;нас уже все для#nbsp;этого готово.
Но#nbsp;чтобы наш план не#nbsp;развалился и#nbsp;не#nbsp;протух в#nbsp;процессе работы, важно помнить о#nbsp;синхронизации. Определите точки, в#nbsp;которых вы#nbsp;будете собирать обратную связь от#nbsp;людей, задействованных в#nbsp;процессе. Каждые три недели, месяц, квартал? Эти промежутки времени придется нащупывать эмпирическим путем. Это важная часть проведения изменения, так как в#nbsp;командах, компании и#nbsp;мире постоянно что-то меняется#nbsp;— план должен учитывать новый контекст. И#nbsp;конечно, важно не#nbsp;забывать смотреть на#nbsp;метрики, которые мы#nbsp;сформулировали на#nbsp;этапе формирования плана.
Проведение изменений, особенно в#nbsp;большой компании,#nbsp;— это бесценный опыт. И#nbsp;я#nbsp;рекомендую складировать ваш опыт внедрения изменений в#nbsp;какую-то базу. Если получится настроить такой процесс на#nbsp;уровне команд, вы#nbsp;сможете быстрее обучаться сами и#nbsp;обучать коллег.
Только представьте, что, начиная новый проект, вы#nbsp;делаете себе чашку кофе, заходите в#nbsp;базу проектных ретроспектив и#nbsp;видите примеры, как делать не#nbsp;надо. Вам будет гораздо проще работать над проектом, понимая, с#nbsp;какими проблемами столкнулись коллеги и#nbsp;какие решения они предложили. В#nbsp;крайнем случае можно просто написать коллегам в#nbsp;личку и#nbsp;попросить поделиться опытом, если ваш проект похож на#nbsp;тот, что когда-то делали они.
Важно не#nbsp;только положить куда-то опыт, но#nbsp;и#nbsp;рассказать о#nbsp;нем. Поэтому здесь пригодятся презентации для#nbsp;коллег: было вот так, стало вот так, результаты такие, лежит вот здесь, пользуйтесь на#nbsp;здоровье. Также помогут информационные рассылки: если их#nbsp;нет, о#nbsp;вашем изменении никто не#nbsp;узнает. Поэтому постарайтесь организовать каналы коммуникаций для#nbsp;доставки знаний.
Заключение
На#nbsp;мой взгляд, любое изменение#nbsp;— это проект, и#nbsp;работать с#nbsp;ним нужно по#nbsp;всем канонам проектного менеджмента. Не#nbsp;бойтесь инвестировать в#nbsp;процесс discovery. Будет прекрасно, если именно на#nbsp;этом этапе вы#nbsp;поймете, что изменение обречено на#nbsp;провал и#nbsp;никому не#nbsp;нужно. Вы#nbsp;потратите только свое время, но#nbsp;не#nbsp;успеете задействовать коллег. Если вы#nbsp;начали что-то менять в#nbsp;командах или компании и#nbsp;плохо поработали над аналитикой и#nbsp;планом проведения, это может привести к#nbsp;денежным и#nbsp;эмоциональным потерям#nbsp;— и#nbsp;даже к#nbsp;потере коллег, которые могут уволиться.
При небольших изменениях и#nbsp;незабитых календарях по#nbsp;алгоритму можно пройтись за#nbsp;две-три недели, но#nbsp;чаще всего на#nbsp;глубокую аналитику крупного изменения уходит один-два месяца.
Помните, что процесс изменений не#nbsp;такой уж#nbsp;страшный, если подходить к#nbsp;нему с#nbsp;умом. Но, конечно, лучшее изменение#nbsp;— это то, которого удалось избежать.
🎃 Не#nbsp;всё чем я#nbsp;занимаюсь попадает на#nbsp;сайт. В#nbsp;моём telegram-канале «Доставка ценности» ты#nbsp;сможешь следить за#nbsp;публикацией новых статей, кейсов, видео, анонсов вебинаров, мастер-классов и#nbsp;мыслями на#nbsp;разные темы. Так#nbsp;же в#nbsp;комментариях можно поделиться своим опытом, спросить совета у#nbsp;коллег.