Привет, Хабр. Меня зовут Виталий Колесников, я руководитель группы внедрения производственного процесса в МТС Диджитал. Мы формируем единый автоматизированный фреймворк управления производством, чтобы разработка продуктов была прозрачной для бизнеса и удобной для команд. Звучит сложно, поэтому поясню.

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

Еще одна проблема — это переключение сотрудников между проектами и перевод в другую команду. Всегда проще, когда знаешь, какие тебя ждут процессы, иначе придется тратить время на адаптацию. Например, недавно скилы нашего дизайнера понадобились в другой команде. Когда он «переехал» к новым ребятам, то уже знал, какие его ждут доски и статусы задач. И так с любым сотрудником: можно переходить из проекта в проект и обратно, не испытывая дискомфорта, при этом прогресс всегда можно отследить. Как раз в этом помог стандартный производственный процесс, который моя команда внедрила с нуля. Сегодня расскажу, как нам это удалось и с какими сложностями мы сталкивались. Путь был интересным, информации много, так что разобью пост на две части. Начнем с предпосылок к изменениям и первых подвигов.

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

Начнем с основ: а что это вообще такое — трансформация? Так называют внедрение подходов управления продуктами и разработкой, которые должны принести компании пользу — например, сократить сроки поставки бизнес-ценности и повысить качество релизов. Создание и внедрение производственного процесса (чем моя команда как раз и занималась в МТС) — один из этапов трансформации.

По моему опыту потребность в изменениях чаще всего возникает, когда в компании или команде увеличивается количество сотрудников. Инструменты, которые неплохо работали для 5 человек, могут не справиться там, где их 20. Вывод логичный: пора что-то менять. С ростом команды нужно увеличивать объем разрабатываемых фичей, обеспечивать качество тестирования. И важно делать это так, чтобы за всеми процессами можно было наблюдать — без этого не получится вовремя реагировать на сбои.

Итак, компания хочет расти и трансформироваться. Звучит просто, но в реальности на этом пути возникают проблемы — одна за другой. Когда моя команда создавала и внедряла производственный процесс в МТС, она тоже сталкивалась с препятствиями. Основных было пять. Дальше — подробнее о каждом.

Препятствие № 1. Сложная синхронизация продуктовых команд, участвующих в разработке фичи. Это когда каждая команда работает по-своему. Кто-то использует Agile-практики для управления продуктом и разработкой, а у кого-то — проектный подход. В итоге принципы формирования бэклогов и управления релизами у команд могут отличаться, а значит, свести их в одну систему будет сложно.

Препятствие № 2. Сильное влияние специфики и типизации продукта на скорость поставки ценности. Например, в МТС на момент начала трансформации были такие типы продукта:

• бизнес — то, что приносит компании выручку;

• внутренний — система, выступающая донором данных;

• технологический — ИТ-решения, которые обеспечивают производственные процессы, интеграционное взаимодействие, мониторинг, инфраструктуру, качество поставки и развертывания и многое другое;

• экосистемный, в котором бесшовно функционирует множество сервисов одного трайба, кластера или компании.

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

Препятствие № 3. Отсутствие стандарта, описывающего правила и практики производственного процесса. У команд может быть разный уровень технологической и продуктовой зрелости и инфраструктура. Количество команд внутри продуктов тоже отличается. Так что каждая в зависимости от условий формирует самый простой и упрощенный флоу. В тот момент для нее не стоит вопрос, как организовать процесс правильно и понятно для всех, она думает, как провернуть его с этими ресурсами и в этих условиях. Значит, не получится измерить все команды едиными технологическими метриками, поставить их на одну доску и понятно организовать процесс для всех разом.

Препятствие № 4. Непонимание производственного процесса. Тем, кто отвечает за трансформацию, важно понимать, как устроен производственный процесс программных продуктов. Без этого не получится интегрировать полезные практики Agile в производственный ЖЦ программных продуктов и объяснить командам разработки, чем они помогут и что конкретно для них улучшат. Это нужно учитывать, нанимая в штат Agile-коучей и скрам-мастеров. Иначе можно просто потратить ресурсы, но улучшений не получить.

Препятствие № 5. Отсутствие стратегии, которая на уровне компании в целом определяет основные цели и шаги в сторону изменений. Наличие стратегии уже само по себе сигнализирует, что руководство готово к трансформации и принимает риски. Можно сказать, она олицетворяет образ компании в будущем. Это хорошая мотивация для сотрудников: они понимают, зачем выполняют свои задачи и к чему стремится компания. Если стратегия транслируется сверху вниз на уровне целей и KPI, проводить изменения легче. Но если она просто лежит на полке или информационном ресурсе, никакого эффекта от нее не будет.

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

Как мы создавали один общий производственный процесс на всю компанию

На начальных этапах трансформации была скорректирована структура внутри подразделений, сделаны шаги по внедрению методологии продуктового управления, появились технические и продуктовые руководители: CTO, CPO, PO. В 2021 году начался второй этап. Он предполагал внедрение внутри компании полноценных практик Agile и приземление их на технологические практики по DevOps, QA и другим направлениям.

На старте трансформации (напомню, создание производственного процесса — это ее часть) моя команда прошла повышение квалификации по Agile. Agile, разработка и управление продуктом — связанные вещи. Нам предстояло создать производственный процесс, который не будет противоречить принципам Agile, то есть предлагаемый нами флоу должен был это учитывать. Внедряя стандартный флоу производства, по сути мы сразу внедряли продуктовую модель Agile. Мои основные компетенции были связаны с разработкой ПО, так что после повышения квалификации у меня получился хороший багаж знаний. Это позволило посмотреть на процесс создания унифицированного жизненного цикла разработки и учесть практики гибких методологий, которые должны были положительно повлиять на метрику Lead Time, формирование бэклога, спринтов и графика цикличности поставки.

Идей было много. Осталось создать процесс, чтобы их проверить. Тогда в компании было больше 400 продуктов, и все они уже работали по настроенным процессам. Так что перед нами встало первое препятствие: микропроцессов много, у каждой команды свой настроенный флоу. Плюс в компании развернуто несколько экземпляров Jira, и все они поддерживались разными командами — так сложилось исторически. Структура сущностей, схем процессов, экранов в каждом экземпляре была своя. Права доступа для администрирования и кастомизации схем проектов были практически у каждой продуктовой команды, а значит, настройки могли меняться постоянно. Как думаете, можно ли просто так взять и «загнать» всех в одну централизованную стандартную Jira МТС? Разумеется, просто это не будет.

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

Получается, тогда нам нужно было решить две задачи:

• создать унифицированный флоу, который как минимум не ухудшит текущий производственный процесс;

• придумать, как провести миграцию проектов продуктовых команд с их процессами из разных таск-трекеров в единую Jira МТС.

Приступили к разработке

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

Автоматизации мы вынесли за скобки. Повторить или унифицировать их в исходном виде мы бы не смогли: для этого были бы нужны сложные доработки, плюс мы не могли внедрять непроверенные инструменты. К тому же переход на стандартный производственный процесс уже предусматривал автоматизацию ключевых этапов ЖЦ создания продукта. Это важно, чтобы команды не игнорировали аналитику, PBR (уточнение сути задачи), тестирование, дизайн-ревью и так далее.

Дальше для каждого объекта (Epic, Story, Task) объединили все схожие по этапу ЖЦ статусы в один. В результате получили полный набор сущностей и статусов, которые учитывали потребности всех команд. 

Полученные флоу оказались неповоротливыми и длинными: на доске в Jira было больше 15 статусов. Конечно, мы стремились не к этому.

После формирования объединенного флоу мы скорректировали процесс с учетом предложений Agile: удалили избыточные статусы, добавили новые. Потом соотнесли получившиеся флоу с ЖЦ производства: проектированием, аналитикой, разработкой, тестированием, развертыванием. И вуаля — получили первый драфт базового Workflow, который можно начинать внедрять в команды.

Пилотирование

Изначально нашей целью было стандартизировать процессы и обеспечить наблюдаемость за ними со стороны бизнеса. Мы стремились создать единый фреймворк управления производством и сделать прозрачными такие процессы, как:

• управление бэклогами;

• визуализация этапов ЖЦ производства;

• автоматическое подключение всех продуктов к дашборду метрик (базовый набор метрик — Lead Time, Deployment Frequency, Change Failure Rate).

То есть сначала мы решали задачу бизнеса, но не пытались сделать систему удобной для команд. И это было нашей болью на протяжении всего пути создания MVP-версии стандартного процесса. Интегрировать изменения без участия реальных продуктовых команд, которые потом будут с ними работать, — невозможно. Поэтому мы старались найти золотую середину. Нам было важно выстроить диалог с командами, чтобы продвинуться хотя бы на шаг в сторону пилота. Это было не всегда просто: они не видели проблем и не были готовы к изменениям.

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

Как поняли, что сработало

С критерием успешности проекта все было просто. До пилота команды работали с разными флоу процессов: атрибуты, статусы и переходы в них отличались. Это усложняло управление, настройку досок и онбординг — особенно при разработке фичей с зависимостями от других продуктовых команд. Но после пилота все стали вести свои задачи по целевому Workflow Jira и собирать метрики на витрине PowerBI — наконец в работе появилась прозрачность. При совместных проектах участники команд могли легко ориентироваться на производственных досках друг друга. Этого мы и добивались. 

У пропилотированного процесса еще не было хитрых автоматизаций — например, автоназначений задач на исполнителей, движения родительских задач по статусам в зависимости от состояния дочерних, проверок и валидаторов при переводе в определенные статусы или закрытии задач и так далее. Над всем этим нам еще предстояло работать. Зато сейчас на 15 командах мы наладили процессы проектирования и декомпозиции фичей (Epic), организации разработки с использованием Story и работы с дефектами.

Первый старт мы прошли, пилоты завершили. Следующий шаг — начать внедрение стандартного производственного Workflow. Я специально не называю его стандартным производственным процессом, ведь на этом этапе цельного производственного стандарта у нас еще не было.

На старте внедрения мы частично столкнулись с проблемой отсутствия стратегии — это пятое препятствие, которое я описывал выше. Встречаясь с командами, мы натыкались на сильное сопротивление. У CTO продуктов не было соответствующих целей и KPI: они не понимали, почему мы приходим с изменениями именно к ним, и не хотели тратить на это время. Нам нужно было без каких-либо оснований сверху начать заходить напрямую в продуктовые команды кластеров и внедрять пропилотированный Workflow. И мы нашли решение: полностью поменяли позиционирование и стали предлагать свой Workflow как сервис. Что это значит?

На производственный Workflow была положительная обратная связь, команды стали на него переходить. Получается, задачу компании мы в какой-то степени решили. Теперь можно было сосредоточиться на удобстве и развитии нашего процесса. Мы перестали заходить в команды с позицией «это требование техностратегии». Вместо этого предлагали: «Посмотрите, что у нас есть с точки зрения функциональности, как это облегчит для вас работу, с чем поможет». То есть превратились в сервис для производства и стали развиваться, используя продуктовые подходы.

Процесс производства как сервис для команд

Предоставляя сервис, мы проводили комплексный анализ внутренних процессов продуктовой команды. Начиная от структуры и принципов формирования бэклога до планирования и организации разработки и выпуска релиза. Погружали сотрудников в новый производственный Workflow, максимально бесшовно адаптировали процессы под него, помогали с настройкой в Jira. Учили формировать бэклог в привязке к ценностям, декомпозиции на фичи и атомарные истории. Тут мы столкнулись с тем, что не все владельцы продуктов понимали, как декомпозировать ключевые фичи, чтобы в рамках коротких итераций выводить изменения. В результате частота поставки релизов могла колебаться от двух недель до трех месяцев. Внедрение стандартного Workflow в таких командах могло даже привести к пересмотру архитектуры решения.

За полгода работы нашего сервиса к середине 2022-го на стандартный производственный Workflow было переведено 80 продуктов. Мы поняли, что созданный процесс вкупе с нашим сервисом можно использовать в качестве инструмента для трансформации: он полностью соответствовал принципам Agile и учитывал все стадии ЖЦ создания продуктов.

Чтобы этот инструмент начал работать максимально автономно и гарантировал соблюдение командами установленного процесса, нам нужно было подумать, как реализовать автоматизации в Jira. С одной стороны, они могли бы сократить трудозатраты при работе с нашим Workflow. С другой — минимизировать риски, связанные с отклонениями команд от стандартного процесса.

Автоматизации — это не только облегчение жизни для команд, но и включение рычагов контроля. Не каждому нравятся новые требования, которые теперь придется соблюдать, а тем более, если для этого нужно перестроить свою работу. Так что мы должны были еще раз пройти через сопротивление. Чтобы внести изменения как минимум для 80 продуктовых команд, уже использующих стандартный Workflow, нужно было придумать, как их заинтересовать и сформировать у них доверие к нам.

Мы понимали, что не смогли бы идти со стандартным Workflow в другие продуктовые команды, не учитывая их проблемы. Поэтому развивать производственный Workflow дальше продолжили, используя все продуктовые принципы: Discovery, пользовательские исследования, открытые демо и бэклог. Логичный вопрос: почему нельзя было сделать так сразу? Вспомните, что в самом начале мы столкнулись с полной неопределенностью, огромным количеством разнородных процессов и разным уровнем зрелости команд. Тогда это превратилось бы в бесконечность.

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