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

Меня зовут Ирина Васильева, и я старший Agile-коуч в МТС Live. В этой статье я расскажу, как мы провели Agile-трансформацию билетного оператора Ticketland. В процессе реорганизации мы навели порядок в задачах, сохранили команду и обеспечили сервису дальнейшее развитие в экосистеме МТС. На нашем примере я покажу, что любые изменения возможны, если декомпозировать основную задачу, наладить общение между командами и придерживаться выбранного роадмэпа. «Глаза боятся, а руки делают» — об этом я и расскажу под катом.

Предпосылки трансформации

В 2018 году МТС приобрела один из ведущих российских сервисов на рынке культурно-развлекательных мероприятий — Ticketland. Это послужило основой для старта нового бренда в билетном бизнесе — МТС Live. Какое-то время эти сервисы и бренды болтались в параллельных вселенных, лишь изредка пересекаясь друг с другом. Технологические связи, напротив, были весьма тесными: через Live люди бронировали и покупали билеты, а транзакции и возвраты шли через Ticketland. При этом каждая из команд искренне не понимала, зачем нужна другая.

Мое появление не было случайностью. CPO и CTO Live специально искали Agile-коуча для помощи в трансформации МТС Live. В то время команда Live делилась по приложениям, что создавало большой разрыв в UX и в функциональности web-, Android- и iOS-версий продукта. Чтобы обеспечить управляемость разработки, мы решили разбить команду на кросс-функциональные подкоманды со своими зонами бизнес-ответственности.

Подобная реорганизация не так проста, как может показаться на первый взгляд. Нужно было разделить зоны ответственности так, чтобы каждый продакт получил возможность применить свои компетенции. Команды необходимо нарезать так, чтобы каждой хватило ресурса для ее задач (попробуйте-ка разделить 4 тестировщика на 3 команды, чтобы никто не обиделся). А еще нужно выделить chapter-лидов разработки, перевести всех на единый процесс в Jira, настроить рабочий процесс для DevOps-инженеров, расписать взаимодействие между командами, провести обучение и многое другое. Добавьте к этому сжатые сроки — и вся эта работа вообще превращается в задачку со звездочкой. О том, как развивался продукт и команда Live, можно почитать в нашей прошлой статье.

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

Все это время Ticketland существовал сам по себе, но к весне 2023 года мы пришли к тому, что его пора встраивать в процессы МТС. Важно было сохранить людей и тот положительный опыт, который существовал до слияния, приумножить клиентскую базу. Любые изменения должны в итоге улучшать продукт, хотя в первое время регресс неизбежен.

Зачем нужно что-то менять?

Очевидно, что предпосылками для трансформации Ticketland были не процессы и стандарты МТС сами по себе. У «МТС Энтертеймент», куда входит и Ticketland, есть амбициозная цель — стать лидером на рынке развлечений, что невозможно без эффективной организации бизнеса. Надо помнить, что Ticketland — это очень старая билетная система с кучей legacy, багов и костылей, про которые зачастую никто уже не вспомнит, зачем они были добавлены и как работают.

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

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

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

С чего начать

В такой ситуации было непонятно, за что хвататься. Разобраться в этом помогли инструменты системного мышления. Например, диаграмма причинно-следственных связей. Они позволяют выявить ключевые проблемы и зависимости. Можно использовать разные подходы — например, «Дерево текущей реальности» из Теории ограничений Э. Голдратта.

Составив диаграмму, я сформулировала основные задачи трансформации:

• Перестроить процессы: перейти на Scrum и SAFe, применить тот же шаблон рабочего процесса, что используется в Live. Унификация процессов в первую очередь даст синхронизацию с Live, что позволит улучшить предсказуемость поставки в обеих командах. Дополнительно люди поймут свои и чужие роли — это уберет часть проблем в коммуникациях. И наконец, процесс станет прозрачным, что позволит найти в нем узкие места и обрадует стейкхолдеров, которые всегда любят быть в курсе происходящего.

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

• Перейти на общие рабочие инструменты, в первую очередь Jira и Confluence. Из очевидных моментов: ведение документации в едином пространстве и по одинаковым шаблонам упрощает работу, можно организовать сквозную приоритизацию, сделать связи между задачами и использовать одни и те же инструменты сбора метрик. Менее очевидно, что изменения проще отследить в одном инструменте, а не в нескольких.

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

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

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

Подготовка к пилоту

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

Такое решение позволяет избежать проблем, которые проявятся при масштабировании на весь продукт:

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

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

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

• Если мы берем контур всего продукта, то мы не можем перестроить работу только продуктовых команд. Изменится и подход в службе поддержки, будут затронуты DevOps-инженеры, команды маркетинга и PR.

В качестве первопроходцев была выбрана команда, наиболее вовлеченная в b2c-сферу. В отличие от более консервативного b2b-сегмента, b2c чувствителен к плохому пользовательскому опыту, поэтому его трансформация должна была быстрее показать бизнес-эффект. Кроме того, эта команда имела тесные связи и непосредственно влияла на работу МТС Live.

Был составлен roadmap проекта — и понеслось!

Реализация пилота

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

Также мы используем внутренний документ нашего кластера, разработанный командой Agile-коуча и Scrum-мастера, чек-лист зрелости команды, с которым сверяемся по прошествии

После этого, наконец, началась работа с командой:

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

• заполнили профиль команды;

• договорились о каденциях и длине спринта;

• построили процесс работы с зависимостями от МТС Live и наоборот;

• провели обучение основам Agile и Scrum;

• начали считать емкость спринта в относительных оценках (в том числе выбрали эталоны);

• определили DoR и DoD;

• проработали на ретрозоны роста и нарисовали Value Stream Map.

По завершении пилота был проведен повторный замер уровня зрелости команды по чек-листу, который показал, что этап трансформации успешно пройден.

Но бизнес, конечно, интересует не уровень команды, а процессные метрики. Здесь замеры также выявили улучшение:

• время на выполнение (Lead time) сократилось на 20%;

• переезд задач в следующий спринт (spillover) уменьшился с 70% до 40%.

В итоге мы достигли цели пилота, и он был признан успешным. Дело оставалось за малым — раскатить его на остальные команды.

Масштабирование

Несмотря на всю проделанную в рамках пилота работу, полноценная интеграция Ticketland в структуру МТС замедлилась. Проводились только разовые мероприятия по запросу команд и небольшая часть обучений: сказывались отсутствие CPO и нехватка моих ресурсов как Agile-коуча. В это же время я помогала МТС Live с процессами и работала параллельно в двух продуктах. Летом 2023 года стало понятно, что дальше так продолжаться не может, и было принято решение активнее искать CPO и выделить своего Agile-коуча для Ticketland.

Выявился ряд моментов, которые не казались столь значимыми на этапе пилота:

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

• Технические сложности, связанные с долгим получением доступов (welcome в большую организацию), а также переносом архива задач и комментариев из Youtrack в Jira. С последним, к сожалению, справиться так и не удалось. Спойлер: оставили Youtrack как архив, а Jira начали вести фактически с нуля.

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

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

В августе 2023 года в продукт вышел новый CPO, работа снова пошла в активную фазу. При этом мы помним, что у Ticketland пока еще не было выделенного Agile-коуча. Мы сели вместе с СТО, СPO и директором по продукту и определили первостепенные области приложения усилий (которые возможно сделать в рамках того, что я не могу двигать полноценно все активности). Построили роадмэп на 3 месяца.

Мы приступили к работе в масштабе всего Ticketland:

• Провели обучение Agile/Scrum/SAFe и стандартам МТС. Команде нужно не зубрить манифест, а разобраться, как формируется ценность для клиента, какие этапы есть на пути формирования ценности, какие препятствия и задержки могут возникать.

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

• Определили и настроили все события Scrum:
  

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

  • Ежедневные встречи (Daily scrum). Превратили их из пересказа вчерашних дел в обсуждение целей спринта, решений препятствий и корректировок плана.

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

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

• Запустили Agile Release Train и провели квартальное планирование совместно с МТС Live. Это позволило нам координировать работу и обеспечивать ее согласованность даже в условиях нарушений сроков зависимостей. Вместе с квартальным планированием мы также начали проводить и I&A. В результате показатель предсказуемости программы стабильно растет: стартовали с 80%, а сейчас добились 91%.

• Сформулировали и встроили в процесс DoR и DoD. Эти простые инструменты уменьшают число простоев и задержек задач, а также повышают качество продукта. Как бы странно ни звучало, DoR и DoD можно определять не только для задач, но и для релиза. В Jira мы их реализовали как чек-листы в задаче, без отметки которых нельзя продвинуться в следующий статус.

• Перевели оценку задач на story points. Так же, как и ретроспектива, это сильно недооцененный инструмент. Если к нему не относиться формально, он позволяет эффективно планировать задачи с учетом их трудоемкости, сложности и рисков даже при отсутствии детального технического задания. Для формирования набора эталонов применялась авторская методика, доказавшая свою эффективность уже не в первом продукте.

• Мигрировали в корпоративные Jira и Confluence. Параллельно с этим запустился процесс подготовки недостающей документации legacy-кода Ticketland. Манифест Agile подсказывает нам, что работающий продукт важнее исчерпывающей документации, но без документации легко попасть в ситуацию, когда разработка встала из-за того, что непонятно, как же этот работающий продукт работает.

• Обучили продактов и аналитиков азам продуктового подхода. Продуктовый подход — это в первую очередь образ мышления, который направлен на формирование значимой ценности для пользователя и улучшение пользовательского опыта. Не забываем при этом про цели и миссию компании. В рамках продуктового подхода внедрили приоритезацию эпиков по скоринговой модели ICE, идет работа по переходу на принятие решений на основе цифр, а не интуиции.

• Запустили наем продуктовых дизайнеров. Казалось бы, дизайнер просто рисует интерфейс, но на самом деле дизайнер должен решать продуктовые задачи: сделать фичу заметной и понятной, выделить предложение среди конкурентов, предоставить информацию так, чтобы она зацепила пользователя. Это выходит далеко за рамки просто «нарисовать дизайн в корпоративном брендбуке».

Процесс все еще идет. В ноябре 2023 года в Ticketland вышел долгожданный Agile-коуч. Многое из того, что перечислено выше, сделала уже Инна, а без нее все двигалось бы гораздо медленнее. Кроме основных задач, Agile-коуч последовательно работает с командами. Всего у нас 6 команд, и Инна совместно с СТО каждый квартал выбирает, какой команде нужно наиболее пристальное внимание.

Итоги

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

Проект встал на ноги и активно развивается, а мы получили:

• слаженную команду;

• улучшение процессных и продуктовых метрик;

• довольных стейкхолдеров;

• много, очень много опыта.

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