Привет! Меня зовут Мария Белых, я занимаюсь управлением изменениями более 10 лет. Внедряла процесс управления выгодами для Газпромнефти, разработала методологию управления проектами для Правительств Ленинградской и Новосибирской областей, сформировала план управления проектом строительства завода по переработке целлюлозы. Параллельно погружалась в гибкие подходы к разработке продуктов, применяла их в своих проектах, прошла тренерскую аккредитацию в международном консорциуме ICAgile. 

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

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

Контекст: как работает продуктовый подход в SM Lab

Бизнес-процессы Спортмастера поддерживают более 200 информационных систем (ИС). Одна или несколько ИС представляют собой ИТ-продукт. Каждый ИТ-продукт развивает одна или несколько ИТ-команд. Работа с задачами в команде выстроена на принципах потокового производства, канбан-метода и практик бережливого производства. Входом в поток и рабочими процессами управляет Product Lead (PL). PL и команде помогают кураторы по компетенциям: аналитика, разработка, тестирование.  

В упрощенном виде это выглядит так:

Как было раньше: работа методологов с командами

В начале продуктовой трансформации (6-7 лет назад) командам требовалась комплексная помощь по внедрению новых правил работы, и поэтому методологи прикреплялись к командам и проводили с ними до полугода. Команда должна была пройти чек-лист запуска — выполнить набор базовых требований для старта работы. По итогам погружения в контекст методолог составлял дорожную карту развития команды. Мы настраивали WIP-лимиты, договаривались о критериях DoR и DoD, определяли правила работы с техническим долгом, учили команды прогнозировать сроки выполнения задач и управлять ожиданиями заказчиков, анализировать дефекты.

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

Завершение трансформации: смена фокуса

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

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

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

Как работает Консультационный центр

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

Лидер КЦ (ваш покорный слуга) получает, уточняет и маршрутизирует запрос: возможно, его лучше обработать методологу, который недавно работал с этой командой. Или, если поступил запрос на проведение очной встречи — передать методологу, который находится в нужном городе.

Далее назначенный исполнитель связывается с инициатором, планирует работу и выполняет запрос. Результаты работы (рекомендации, план действий, новые правила, сценарий и материалы очной встречи) исполнитель публикует в Confluence. После выполнения запроса инициатор оставляет обратную связь в опросе, и на этом работа считается завершенной.

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

Я горжусь автоматизациями, которые позволяют снизить количество механического ручного труда в этом процессе и не потерять ни один запрос, когда эти запросы приходят потоком:

• В ответ на получение письма создается задача в Jira и приходит уведомление на личную почту всем методологам, а также нашему руководителю;

• В ответ на создание задачи в Jira создается сообщение в отдельном канале корпоративного мессенджера. Под этим сообщением можно быстро скоординироваться, кто возьмет запрос;

• При переводе задачи в мониторинг/внедрение заказчику автоматически отправляется письмо со ссылкой на обратную связь.

Принципы работы КЦ

Кроме описания процесса важно договориться о принципах, на основе которых мы строим работу.

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

2. Простота. Мы даем понятные и практические рекомендации, нет цели нагородить сложных моделей и «поумничать».

3. Краткость взаимодействия инициатора и КЦ. Работа над запросом не должна занимать более 30 рабочих дней.

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

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

6. Преемственность задач. Исполнитель доводит задачу до завершения, за исключением случая явной передачи задачи другому исполнителю (с информированием всех заинтересованных сторон).

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

Кто и с какими запросами приходит в КЦ

Наши основные заказчики (инициаторы запросов) — это Product Lead’ы, кураторы и участники рабочих групп управления поездами. Среди частых запросов:

• диагностика текущего состояния команды, составление плана действий по решению выявленных проблем;

• помощь в подготовке ретроспективы команды или поезда;

• проведение ретроспективы;

• проведение очной бизнес-игры по канбан-методу;

• диагностика ролей в команде;

• обучение анализу метрик;

• прояснение смысла и правил проведения регулярных встреч в команде;

• определение и установка WIP-лимитов;

• запуск различных регулярных встреч — ретроспектив, встреч по анализу метрик, собраний по пополнению.  

С какими препятствиями мы столкнулись и как их преодолевали

В ходе внедрения нового процесса и работы над запросами мы столкнулись с несколькими проблемами.

• Мало сотрудников знают о существовании КЦ. Чтобы повысить узнаваемость, пиарим сервис всеми доступными способами: рассказываем о КЦ в рамках ведения тренингов в корпоративном университете, запускаем рассылки, собираем и публикуем фото- и видеоотзывы от инициаторов запросов на внутреннем видеоресурсе.

• Сотрудники не знают, с какой проблемой можно прийти в КЦ. Чтобы облегчить старт обсуждения запроса для инициатора, мы составили Каталог сервисов — список задач, с которыми могут помочь методологи. Он разделен на 11 тематических блоков, для каждой активности указан формат (очно/онлайн) и длительность (более 4 часов/менее 4 часов).

• Крупные запросы. Бывают случаи, когда для решения запроса требуется длительная работа с командой, «как раньше». Правило «работа над запросом занимает не более 30 рабочих дней» не выполняется. В таких ситуациях мы переводим задачу в стандартный эпик и берем в работу по мере появления емкости.

• Запросы вне зоны компетенций и/или ответственности методологов. Инициатор не всегда знает, к кому обратиться со своей проблемой, и иногда к нам поступают запросы по ИТ-архитектуре и работе с крупными стратегическими бизнес-инициативами. Мы можем дать короткую консультацию в рамках своих знаний, а далее помогаем найти, куда правильнее обратиться.

• Инициаторы не оставляют обратную связь. Решается только настойчивостью методолога, который хочет получить обратную связь о своей работе :) Напоминаем, пишем в личку, присылаем ссылку на опрос.

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

• Конфликты с другими задачами. Кроме запросов в КЦ у методологов есть и другие задачи, и периодически возникают конфликты приоритетов. Это некритичная проблема, так как запросы обычно не занимают много времени, и, выполнив запрос, мы можем быстро вернуться к другим задачам. Если работа над запросом занимает больше времени, чем планировалось, всегда можно попросить помощи у другого методолога — передать задачу целиком или поделиться частью работы.

Обратная связь и метрики сервиса

Как любой сервис, мы улучшаем свою работу на основе обратной связи от инициаторов и объективных данных о нашем процессе.

Обратную связь от инициаторов мы собираем по 5 параметрам:

• Удовлетворенность итоговым решением;

• Скорость решения;

• Детальность проработки решения;

• Качество коммуникации в процессе решения;

• Готовность рекомендовать КЦ коллегам.

Один раз в квартал я формирую отчет по работе КЦ, в котором можно посмотреть:

• количество новых, завершенных и находящихся в работе запросов;

• источники новых запросов (из каких бизнес-областей к нам обращались);

• темы новых запросов, сгруппированные по категориям;

• ссылки на результаты работ;

• обратную связь по выполненным запросам.

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

Бонус: лайфхаки, которые повышают качество сервиса

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

Для запросов на очные встречи это:

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

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

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

Для любых запросов это:

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

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

Резюме: как запустить сервис внутреннего консультирования

Если вас заинтересовала эта статья и вы хотели бы запустить подобный сервис, вот что нужно сделать.

• Выбрать лидера сервиса и команду исполнителей

• Описать правила работы

• Определить шаблон для описания запроса

• Установить единое окно для входящих запросов (отдельный почтовый ящик)

• Визуализировать работу над запросами

• Популяризировать сервис

• Собирать обратную связь, метрики и непрерывно улучшать процесс

Если у вас в компании есть подобный сервис, то было бы здорово обменяться опытом в комментариях. Пишите!