В большой ИТ-компании существует множество процессов работы. Часто бывает так, что тем органам управления, которые занимаются их построением, сложно понимать какие отрабатывают хорошо, а что устарело или требует преобразований.
Столкнулась с этим и наша Команда изменений в SM Lab. Процессов было много, но не всегда понятно, действительно ли то, что мы предлагали ИТ-производству в качестве улучшений, шло на пользу большинству.
Это влекло за собой всем известную проблему. К руководителям команд, тимлидам, приходили новости о нововведениях, и никто не понимал откуда они и почему приняты. Мало тех, кто лояльно воспринимал изменения, большинство коллег относились к ним со скепсисом или вовсе игнорировали.
Сначала коротко расскажу о том, как у нас все устроено. Затем перейду к тому, как мы выстроили систему, помогающую эффективно решать актуальные проблемы ИТ и внедрять полезные глобальные изменения, избегая безмолвного саботажа.
Как все устроено
В компании работаем по методологии, при которой команды объединены в так называемые поезда, у нас их сейчас больше 10. Они функционируют в рамках определенного временного отрезка (PI/ Program Increment/ Planning Interval) по общему для всех графику.
Для того чтобы такая огромная структура работала без перебоев и вовремя поставляла ценность бизнесу, у нас создана Команда изменений. Вернее, это общее название группы команд:
Уровень системы управления (CoreTeam).
-
Уровень производства PI:
Операционная команда (OperTeam);
Команда Менеджеров и Методологов.
Их основная задача - делать более эффективной совместную работу бизнеса и ИТ.
В чем проблемы
Поездов с командами становилось все больше, управлять ими становилось все сложнее. Стало очевидно, что не было:
системы регулярного получения информации от поездов: удовлетворены ли процессами PI, какие области требуют улучшений;
актуальных бэклогов у Команды изменений;
понимания о самых приоритетных «болях». По обрывочной информации, которая поступала, мы понимали, что они были, но не совсем понятно что нужно корректировать в первую очередь.
Я, находясь в OperTeam, поняла, что информацию от поездов и их отзывы нужно регулярно собирать, изучать и приоритизировать перед тем, как брать в работу.
С чего начала
Посмотрела из каких источников приходила информация для бэклогов Команды изменений. Оказалось, это происходило стихийно: кто-то написал в чате, кто-то провел ретро, что-то было в e-mail переписках, некоторые сложности мы видели сами и т. д.
Выявила недостающие источники информации и заполнила «белые пятна».
Построила целостную систему для сбора и обработки информации от поездов о процессах PI.
Модель обратной связи
Полученную систему назвала Моделью сбора обратной связи. Не той, которую аккумулируют HR-специалисты, а исключительно касающуюся процессов и процедур в PI. Система не собирает данные о том, как чувствует себя сотрудник в компании, ей интересно какие процессы на уровне команд и поездов нужно оптимизировать, чтобы вся система работала продуктивнее.
Цель Модели – не просто собрать данные от поездов, но и распределить их по командам изменений для дальнейшей проработки. Это иерархическая последовательность событий, которая помогает собирать, обрабатывать и адресно передавать информацию о текущем положении системы управления поездами и инкрементами. Важно то, все события внутри Модели связаны между собой.
Как это работает
Слева указаны уровни, на которых обратная связь аккумулируется и обрабатывается - сейчас их 4.
Вверху этапы, на которых ОС собирается — Реализация и Оценка результатов PI. Цветные блоки - это события внутри каждого уровня. Они все между собой связаны, что схематично показано стрелками. То есть результаты собранной информации на одном уровне являются входными данными для инициативы другого уровня. Получается лестница событий.
Все это большая система, но самое главное, что в ней удалось выстроить – это цепочку проведения ретро с хронологический последовательностью передачи информации от уровня к уровню.
Пример цепочки ретро
PI длится 3 месяца и заканчивается этапом под названием «Оценка результатов».
В это время команды проводят встречи (ретро). На Модели они отображены напротив Уровня команд. Здесь фиксируются не только успехи, но и проблемы, помешавшие завершить задачи, которые были запланированы на эти 3 месяца.
Результаты Ретро команд рассматриваются на Ретро поездов. На схеме это цветной блок на Уровне поезда. Сортируется что может быть решено оперативно и к чему не нужно привлекать допсилы, а что нужно подсветить выше, привлечь работу Менеджеров, Методологов, OperTeam.
-
Далее проводится Ретро Менеджеров поездов, и результаты транспортируются на Ретро OperTeam. Это важная встреча, на которой обсуждаются те вопросы, которые не могли быть решены на других уровнях и требуют глубокой проработки и анализа. Плюс то, что было собрано от поездов через Опрос PI. На схеме стрелка от него протянута к Ретро OperTeam. OperTeam уже непосредственно работает над изменением и внедряет его, раскатывая решение на все поезда-участники PI.
Пожелания и проблемы, прежде чем попасть в бэклог команд Менеджеров, Методологов и OperTeam, приоритизируются. Учитывается, например, частотность упоминаний: сколько раз указали на одну и ту же проблему. Важна и массовость: принятое в итоге изменение затронет сразу все поезда или будет актуально только для одного.
Помимо выстроенной вертикали движения информации от Ретро команд к Ретро OperTeam проводятся и другие мероприятия. Например, регулярные синки, выпуск ежемесячного Дайджеста со статистикой по поездам и так далее. Однако это темы следующих публикаций.
Наглядно видно, что изменения процессов, процедур не происходят интуитивно, стихийно – им предшествует большая работа на каждом уровне. Внедренные изменения являются в итоге не статпогрешностью, а вдумчивые, подкрепленные анализом.
Очень важно, насколько поездам комфортно работается в PI, поэтому при любой возможности призываем коллег принимать активное участие в Ретро команд, Ретро поездов, давать подробные ответы в Опросе, не игнорировать опросники.
Более того, построенная Модель является замкнутой. Это значит, что цепочка от Сбора предложений, проработки, внедрения всегда заканчивается информированием инициаторов предложений. ВСЕГДА. У нас это опубликование в специальном чате, который читают участники поездов.
Тайминги
На первый взгляд, процедура от инициации проблемы на уровне команды до Ретро OperTeam (период поднятия информации) выглядит долгим. На деле, занимает не более 3 недель.
Сложности
Я создала систему, и благодаря вовлеченности коллег мы внедрили ее относительно быстро – от питчинга до включения в График PI прошло 5 месяцев (апрель-август 2024). Однако были и сложности:
Аналогичной системы не нашлась в доступных источниках, поэтому была придумана своя.
Большое количество заинтересованных лиц, поэтому много согласований и обсуждений. Если планируете построить что-то подобное, то сразу будьте готовы к тому, что придется провести большую работу с возражениями. Это нормально.
Итоги
Дали возможность говорить о проблемах и влиять на процессы всем.
Получаем в разы меньше хейта (считаем по скорости внедрения, а также вопросам, сообщениям, комментариям во время оргвстреч и в основном канале коммуникации).
Благодаря Модели удалось сделать значимые улучшения на уровне всей системы PI:
разработали подробные, понятные чек-листы работы в PI для каждой участвующей в нем роли;
запустили удобную систему создания заявок на ряд изменений;
разработали несколько обучающих курсов, которые помогают коллегам разбираться с самыми сложными кейсами в их работе;
починили некоторые сложности в системе приоритизации задач поездов и продолжаем работу над ними;
и еще много чего.
И напоследок
Если хотите построить работающую систему внедрения изменений в своей компании или отделе, придерживайтесь двух правил:
Держите с коллегами регулярную информационную связь. Интересуйтесь их видением, задавайте вопросы.
Придерживайтесь принципа прозрачности во всем. Провели опрос – поделитесь результатами. Починили процесс – расскажите об этом. Коллеги оценят такую честность, а сопротивления нововведениям со временем станет меньше.