Всем привет! Мы — продуктовая команда Мой МТС, занимаемся разработкой основного мобильного приложения компании МТС (iOS/Android) и сайта mts.ru. Месячная аудитория активных пользователей (MAU) на всех платформах — свыше 23 млн. пользователей.
Данной статьей мы хотим начать цикл, посвященный трансформации нашей команды и вызванными ею изменениями. Первый пост полностью отведен под начальный этап перестройки, стартовавший с приходом внешних консультантов.
До трансформации
Погрузимся немного в исторический контекст. Изначально приложение Мой МТС разрабатывала команда внешнего поставщика. В 2016 году мы перевели продукт в In House разработку и начали планомерные работы по совершенствованию кодовой базы, команды и процессов.
На начало 2020 года команда продукта Мой МТС состояла из 63 человек, которые были организованы следующим образом:
Разработка велась по зачаточному Scrum'у с двухнедельными итерациями и основными командными ритуалами. Однако, как заметит внимательный читатель, на схеме отсутствуют scrum master'а – у нас это роль, которую выполнял и продолжает выполнять кто-то из членов feature team. Также была в наличии строгая изолированность Владельцев продукта и разработчиков. Мостиком между двумя мирами служили системные аналитики и технический лидер команды. Веб-разработкой полностью занимался подрядчик. Так совпало, что начало активной фазы избавления от внешних зависимостей началось одновременно с трансформацией.
Отдельного внимания заслуживает процесс планирования задач в спринтах и на более широких горизонтах. Здесь основой приоритизации была скоринговая модель. К сожалению, не всегда удавалось следовать полученным приоритетам, поскольку вертикальные связи были сильнее модели.
Как и говорилось ранее, до трансформации связи между командами разработки и бизнес направлениями не было, что давало следующие преимущества:
С технической точки зрения у нас имелись следующие вводные, которые хотелось бы обозначить в контексте трансформации:
Возможно, у кого-то из читателей похожий набор исходных данных, поэтому, как было модно в детстве, дадим несколько вредных советов трансформирующимся:
Цели трансформации
Говоря про цели трансформации, важно отметить, что далеко не вся наша команда разделяла даже необходимость этой самой трансформации и уж тем более не все понимали её цели. Слабая связность технической и продуктовой частей команды лишь добавляла сложностей. В конце концов было принято решение сверху, которое и запустило весь дальнейший процесс изменений.
Среди формальных целей руководством компании были обозначены два фактора, которые нужно было улучшить:
Достаточно быстро мы поняли, что для себя нам так же нужно определить и понять цели. То есть — сократить T2M, чтобы что? повысить прозрачность зачем? и другие подобные вопросы. Начали обсуждать это с CPO, Владельцами продуктов и к тому времени уже прошло несколько месяцев работы в новой парадигме. Так как получилось собрать достаточно много интересной фактуры, мы собрали всю большую команду Мой МТС и рассказали, как же на самом деле команда управления продуктом видит цели и ожидаемые результаты трансформации, какие небольшие победы уже можно отпраздновать, а так же где наоборот стало хуже и что потерялось из фокуса. Вот некоторые выводы, к которым мы пришли после первого такого подхода:
С точки зрения целей трансформации, для себя мы определили, что самое главное не цифры и T2M (на начальном этапе так точно), а изменение нашего подхода к работе, мышления, и, как сказал CPO, «раскачивание лодки, чтобы понимать, где она протекает». То есть сокращение Time2Market на этот период времени стало для нас не самоцелью, а процессом раскачивания устоявшейся системы с целью поиска узких мест и их разрешения. Звучит странно, но нам это помогло расставить все на свои места. Мы поняли, что:
Такое мероприятие оказалось хорошей практикой, мы до сих пор стараемся проводить его либо в онлайн-формате, либо в формате информирования раз в квартал с возможностью у всех сотрудников Мой МТС задать вопросы по дальнейшим целям, идеям и высказать свои пожелания.
Трансформация
Трансформация затронула многие аспекты рабочего процесса в компании, но подробно хотелось бы остановиться на двух вещах – планировании бэклога и формировании продуктовых команд.
Так как в МТС огромное количество продуктов, платформ, направлений и команд, в последнее время стала более очевидной необходимость стандартизировать их процессы. Например, в какой-то момент нашлись очень похожие по функционалу продукты, которые разрабатывались в разных местах и разными людьми. Чтобы избежать подобного, а также чтобы синхронизировать цели связанных продуктовых команд и повысить прозрачность постановки и достижения целей, был запущен новый процесс планирования бэклогов по кварталам.
Квартальное планирование — самая верхняя часть синхронизации планов. В конце каждого квартала мы отводим 4-6 недель на подготовку задач на следующий квартал и на согласование зависимостей. Конечно же, мы формируем бэклог задач наперед и в течение квартала, однако, именно в эти последние 4-6 недель у нас происходит итоговое формирование скоупа — кто-то пришел с новыми задачами, о которых никто не слышал, кто-то поменял приоритеты и т.д.
Все задачи следующего квартала предварительно обсуждаются, верхнеуровнево декомпозируются, а также оцениваются командами разработки. Одним из открытий наведения порядка в планировании для нас стало понимание, что в квартале 6 Спринтов, один из которых (±) уходит на тех. долг (сумма 20-ти % в Спринт), второй для тестировщиков команды — на релиз (сейчас релиз делается по всему приложению, «релизное знамя» переходит от команды к команде, но это временное явление, мы почти от этого избавились).
По итогам Квартального планирования мы получаем перечень задач, которые:
После окончания процесса Квартального планирования мы продолжаем регулярную синхронизацию по задачам на PO sync (еженедельная встреча Product Owner'ов и Chief Product Owner'а, технических лидеров, скрам-мастеров). Там же обсуждаем прогресс в достижении целей: если есть новые вводные или вскрылись не найденные ранее риски — у нас есть возможность узнать об этом и повлиять как можно раньше.
Помимо Квартального планирования и PO sync, у нас в Мой МТС прижилась традиция проведения ежедневных чек-инов команды трансформации. В эту команду входят: CPO, технические лидеры, скрам-мастера. Иногда туда приглашаем и других участников, если того требует задача. Как уже говорилось, мы встречаемся этим составом ежедневно в конце рабочего дня, на 15-45 минут, обсуждаем и решаем вопросы, связанные с кадровыми изменениями, отзывами пользователей, новыми инициативами (например, перезапуск Discovery процесса, но об этом в следующих статьях), инициативами от членов команды и т.д. Крайне редко на чек-инах рассматриваются проблемы какой-то конкретной фичи, так как это более низкоуровневая повестка.
В силу размера компании нам не удалось внедрить новый подход везде и сразу, что привело к рассинхронизации при запуске нового механизма планирования у разных направления – B2C, B2B и IT платформы.
Если говорить о структуре команды, то после трансформации продуктовая команда Мой МТС стала выглядеть следующим образом:
Разумеется, переход к новой структуре был поэтапным, нужно было нанять большое количество сотрудников и постепенно формировать новые команды. К сожалению, бурный рост не мог не сказаться на текучке кадров, и отток в 2020 году был самым большим за последние 4 года. Однако если рассмотреть последние месяцы 2020, когда найм по большей части был уже завершен, то ситуация заметно выправилась. Если говорить о цифрах, то в 2020 году текучка составила 30%, а в предыдущие годы (2018-2019) держалась на уровне 18%.
Переход на новую структуру, конечно же, — лишь малая часть всех изменений. В целом, можно выделить следующие важные шаги:
Трансформация — процесс постоянный, практически как ремонт в квартире, в данной статье мы по факту подводим итоги года, но это не значит, что изменения остановлены – всего лишь в очередной раз делаем срез, чтобы понять, куда двигаться дальше.
Результаты
Если формально подводить итоги трансформации, то поставленные цели были достигнуты:
1. Процесс стал прозрачным для всех
2. Time-to-market сокращен в 1,5 раза
Конечно же, существует множество нюансов, на основных из которых хотелось бы остановиться подробнее:
Новые проблемы
Скорее всего многим читателям знакомы молчаливые командные ритуалы, где из каждого присутствующего нужно клещами вытягивать каждое слово. Трансформация привела нас к осознанию одного очень важного факта – все участники должны быть крайне мотивированными и высококлассными специалистами, активно участвующими в командных процессах, иначе вся схема будет пытаться развалиться.
Также раньше мы очень большое внимание уделяли детальной проработке всех требований к фиче до старта разработки. Основные недостатки такого подхода – это сужение пропускной способности всей команды и слишком тепличные условия для разработчиков и тестировщиков. В юнитах уже на первых порах стало видно, что старый подход к ТЗ не работает и нужно что-то менять – аналитик не успевал готовить проработанные задачи. Для решения этой проблемы мы разделили ТЗ на две части — must have для старта разработки и всё остальное. Этот подход несколько снял напряжение, но не закрыл все вопросы, поэтому дальнейшие проверки различных гипотез – дело времени.
Помимо этого, Владельцы Продукта перестали работать как общая продуктовая команда, и разбежались по своим зонам ответственности. Сейчас этого уже практически нет, но в самом начале такая проблема возникла. Мы работаем над укрупнением направлений и объединением команд вокруг них.
Планы
Несмотря на глобальные изменения в 2020 году, мы хотим двигаться дальше, решать новые задачи и экспериментировать с процессами. На данный момент наметили несколько основных направлений работы:
Авторы — Артем Андреев, Наталья Егорова, Алексей Кретов
Данной статьей мы хотим начать цикл, посвященный трансформации нашей команды и вызванными ею изменениями. Первый пост полностью отведен под начальный этап перестройки, стартовавший с приходом внешних консультантов.
До трансформации
Погрузимся немного в исторический контекст. Изначально приложение Мой МТС разрабатывала команда внешнего поставщика. В 2016 году мы перевели продукт в In House разработку и начали планомерные работы по совершенствованию кодовой базы, команды и процессов.
На начало 2020 года команда продукта Мой МТС состояла из 63 человек, которые были организованы следующим образом:
Разработка велась по зачаточному Scrum'у с двухнедельными итерациями и основными командными ритуалами. Однако, как заметит внимательный читатель, на схеме отсутствуют scrum master'а – у нас это роль, которую выполнял и продолжает выполнять кто-то из членов feature team. Также была в наличии строгая изолированность Владельцев продукта и разработчиков. Мостиком между двумя мирами служили системные аналитики и технический лидер команды. Веб-разработкой полностью занимался подрядчик. Так совпало, что начало активной фазы избавления от внешних зависимостей началось одновременно с трансформацией.
Отдельного внимания заслуживает процесс планирования задач в спринтах и на более широких горизонтах. Здесь основой приоритизации была скоринговая модель. К сожалению, не всегда удавалось следовать полученным приоритетам, поскольку вертикальные связи были сильнее модели.
Как и говорилось ранее, до трансформации связи между командами разработки и бизнес направлениями не было, что давало следующие преимущества:
- В случае появления большой срочной задачи с погонами мы могли перераспределить всех людей на эту задачу и соблюсти сроки;
- Бэклог был единым и содержал совершенно разные задачи: с интеграционными проблемами, исключительно интерфейсные и технические, что позволяло разнопланово нагружать разработку;
- Вариативность задач в бэклоге и единая сквозная команда аналитики помогали равномерно нагружать разработчиков мобильных платформ.
С технической точки зрения у нас имелись следующие вводные, которые хотелось бы обозначить в контексте трансформации:
- Монолитные решения на всех платформах (iOS, Android, Web)
- Полное отсутствие UI тестирования
- Хаотичный процесс проверки pull request'ов без SLA
Возможно, у кого-то из читателей похожий набор исходных данных, поэтому, как было модно в детстве, дадим несколько вредных советов трансформирующимся:
- Переходите к гибким методологиям не глядя, просто примите как факт, что это верный выбор в любой компании и для любого продукта;
- Профессионализм вашей команды не играет роли, Scrum поможет кому угодно;
- Монолитные решения – отличный фундамент для экспериментов с процессами, технический долг начнет уменьшаться на глазах с каждым спринтом.
Цели трансформации
Говоря про цели трансформации, важно отметить, что далеко не вся наша команда разделяла даже необходимость этой самой трансформации и уж тем более не все понимали её цели. Слабая связность технической и продуктовой частей команды лишь добавляла сложностей. В конце концов было принято решение сверху, которое и запустило весь дальнейший процесс изменений.
Среди формальных целей руководством компании были обозначены два фактора, которые нужно было улучшить:
- Общая прозрачность работы команды на всех уровнях – понимание процессов и артефактов команды, в широком смысле этого слова, всеми сотрудниками, которым это может быть нужно, начиная с самих членов команды и заканчивая Советом директоров компании.
- Уменьшение показателя Time-to-Market путем поиска и устранения узких мест в рабочем процессе и изменения подхода к работе в целом.
Достаточно быстро мы поняли, что для себя нам так же нужно определить и понять цели. То есть — сократить T2M, чтобы что? повысить прозрачность зачем? и другие подобные вопросы. Начали обсуждать это с CPO, Владельцами продуктов и к тому времени уже прошло несколько месяцев работы в новой парадигме. Так как получилось собрать достаточно много интересной фактуры, мы собрали всю большую команду Мой МТС и рассказали, как же на самом деле команда управления продуктом видит цели и ожидаемые результаты трансформации, какие небольшие победы уже можно отпраздновать, а так же где наоборот стало хуже и что потерялось из фокуса. Вот некоторые выводы, к которым мы пришли после первого такого подхода:
- Появилась постоянная и ритмичная поставка по направлениям.
- Список выполняемых задач и их прогресс стал более явен как для CPO, так и для сотрудников вне команды Мой МТС.
- У CPO высвободилось достаточно много времени, которое теперь можно уделять стратегии, видению, исследованию рынка и анализу отзывов пользователей.
С точки зрения целей трансформации, для себя мы определили, что самое главное не цифры и T2M (на начальном этапе так точно), а изменение нашего подхода к работе, мышления, и, как сказал CPO, «раскачивание лодки, чтобы понимать, где она протекает». То есть сокращение Time2Market на этот период времени стало для нас не самоцелью, а процессом раскачивания устоявшейся системы с целью поиска узких мест и их разрешения. Звучит странно, но нам это помогло расставить все на свои места. Мы поняли, что:
- Важно учиться работать в эмпирическом подходе, по HADI-циклам, вместо привычного подхода исполнительного решения поставленных сверху задач.
- Важно до последнего искать и находить корневые причины и цели у заказчиков.
- Важно проверять гипотезы не только в продукте и фичах, но и в процессах и рабочих подходах. Нет единственного правильного подхода к работе, постоянно нужно искать слабые места.
Такое мероприятие оказалось хорошей практикой, мы до сих пор стараемся проводить его либо в онлайн-формате, либо в формате информирования раз в квартал с возможностью у всех сотрудников Мой МТС задать вопросы по дальнейшим целям, идеям и высказать свои пожелания.
Трансформация
Трансформация затронула многие аспекты рабочего процесса в компании, но подробно хотелось бы остановиться на двух вещах – планировании бэклога и формировании продуктовых команд.
Так как в МТС огромное количество продуктов, платформ, направлений и команд, в последнее время стала более очевидной необходимость стандартизировать их процессы. Например, в какой-то момент нашлись очень похожие по функционалу продукты, которые разрабатывались в разных местах и разными людьми. Чтобы избежать подобного, а также чтобы синхронизировать цели связанных продуктовых команд и повысить прозрачность постановки и достижения целей, был запущен новый процесс планирования бэклогов по кварталам.
Квартальное планирование — самая верхняя часть синхронизации планов. В конце каждого квартала мы отводим 4-6 недель на подготовку задач на следующий квартал и на согласование зависимостей. Конечно же, мы формируем бэклог задач наперед и в течение квартала, однако, именно в эти последние 4-6 недель у нас происходит итоговое формирование скоупа — кто-то пришел с новыми задачами, о которых никто не слышал, кто-то поменял приоритеты и т.д.
Все задачи следующего квартала предварительно обсуждаются, верхнеуровнево декомпозируются, а также оцениваются командами разработки. Одним из открытий наведения порядка в планировании для нас стало понимание, что в квартале 6 Спринтов, один из которых (±) уходит на тех. долг (сумма 20-ти % в Спринт), второй для тестировщиков команды — на релиз (сейчас релиз делается по всему приложению, «релизное знамя» переходит от команды к команде, но это временное явление, мы почти от этого избавились).
По итогам Квартального планирования мы получаем перечень задач, которые:
- Обсуждены и согласованы со всеми участниками вне наших команд, например, с другими продуктами, по которым есть зависимости в реализации фичей
- Обсуждены и предварительно проработаны командой разработки
- Распределены по Спринтам внутри квартала
- Презентованы всем заинтересованным лицам. В конце квартального планирования мы рассказываем о своих планах, зависимостях и рисках на встрече, где помимо остальных продуктов и команд присутствуют топ-менеджеры. Синхронизация очень масштабная — в последний раз только на B2C направление было 44 продукта/платформы.
После окончания процесса Квартального планирования мы продолжаем регулярную синхронизацию по задачам на PO sync (еженедельная встреча Product Owner'ов и Chief Product Owner'а, технических лидеров, скрам-мастеров). Там же обсуждаем прогресс в достижении целей: если есть новые вводные или вскрылись не найденные ранее риски — у нас есть возможность узнать об этом и повлиять как можно раньше.
Помимо Квартального планирования и PO sync, у нас в Мой МТС прижилась традиция проведения ежедневных чек-инов команды трансформации. В эту команду входят: CPO, технические лидеры, скрам-мастера. Иногда туда приглашаем и других участников, если того требует задача. Как уже говорилось, мы встречаемся этим составом ежедневно в конце рабочего дня, на 15-45 минут, обсуждаем и решаем вопросы, связанные с кадровыми изменениями, отзывами пользователей, новыми инициативами (например, перезапуск Discovery процесса, но об этом в следующих статьях), инициативами от членов команды и т.д. Крайне редко на чек-инах рассматриваются проблемы какой-то конкретной фичи, так как это более низкоуровневая повестка.
В силу размера компании нам не удалось внедрить новый подход везде и сразу, что привело к рассинхронизации при запуске нового механизма планирования у разных направления – B2C, B2B и IT платформы.
Если говорить о структуре команды, то после трансформации продуктовая команда Мой МТС стала выглядеть следующим образом:
Разумеется, переход к новой структуре был поэтапным, нужно было нанять большое количество сотрудников и постепенно формировать новые команды. К сожалению, бурный рост не мог не сказаться на текучке кадров, и отток в 2020 году был самым большим за последние 4 года. Однако если рассмотреть последние месяцы 2020, когда найм по большей части был уже завершен, то ситуация заметно выправилась. Если говорить о цифрах, то в 2020 году текучка составила 30%, а в предыдущие годы (2018-2019) держалась на уровне 18%.
Переход на новую структуру, конечно же, — лишь малая часть всех изменений. В целом, можно выделить следующие важные шаги:
- Основным изменением стал переход на юниты – обособленные scrum команды, состоящие из технических специалистов, дизайнера и владельца продукта.
Юниты собираются вокруг направлений бизнеса (например, фиксированная связь, финтех и так далее). В теории, подобная трансформация должна была привести к большей вовлеченности всех участников команды в специфику своих направлений и более качественной проработке продуктовых гипотез. - В команде продукта появились выделенные scrum-мастера. Они выполняют важные функции:
- коррекция процесса трансформации
- консультирование по вопросам Agile
- связующую функцию с корпоративным центром продуктовой культуры.
- Выделенная команда автоматизации UI тестирования.
Значительный рост количества команд привел быстрому развитию приложения, вместе с которым также стремительно увеличивается количество тест-кейсов в регрессе. На данный момент автоматизировано 25% основных сценариев. - Мы начали активно работать в направлении перехода на In House разработку WEB.
Процесс оказался значительно сложнее, чем в случае с мобильным приложением, в силу исторического и юридического наследия. Также ожидания бизнеса не позволили замедлить или остановить разработку нового функционала. - В 2021 году планируем провести эксперимент по созданию гибридных команд app+web.
Трансформация — процесс постоянный, практически как ремонт в квартире, в данной статье мы по факту подводим итоги года, но это не значит, что изменения остановлены – всего лишь в очередной раз делаем срез, чтобы понять, куда двигаться дальше.
Результаты
Если формально подводить итоги трансформации, то поставленные цели были достигнуты:
1. Процесс стал прозрачным для всех
2. Time-to-market сокращен в 1,5 раза
Конечно же, существует множество нюансов, на основных из которых хотелось бы остановиться подробнее:
- Излишняя прозрачность может быть вредной
Применимо в случае, например, когда у стейкхолдеров есть некий технический бэкграунд (или они так думают) и они пытаются, экстраполируя свой старый опыт, активно влиять на рабочие процессы команды.Стоит отметить, что прозрачность планирования в полной мере не была достигнута. Квартальное планирование сейчас запущено параллельно на различных срезах (B2C, B2B, платформы), хотя остро стоит потребность в синхронизации. - Абсолютные значения показателей в вакууме
Нам, конечно, удалось уменьшить time-to-market, но параллельно с трансформацией активно улучшались и подходы к работе владельцев продукта. Это привело к уменьшению среднего размера задачи и ускорило скорость доставки инкремента до пользователя. Даже не смотря на оговорки, подобный результат для нас очень ценен: отказ от больших и толстых задач, которые становятся неактуальными за время доставки до пользователей, является огромным плюсом. Также за прошедший год был сделан очень мощный рывок в работе с техническим долгом. Изолированные команды требуют по возможности изолированных «песочниц» в коде, поэтому модульность приложения стала основным техническим вектором для нас наравне с автоматизацией тестирования.
Новые проблемы
Скорее всего многим читателям знакомы молчаливые командные ритуалы, где из каждого присутствующего нужно клещами вытягивать каждое слово. Трансформация привела нас к осознанию одного очень важного факта – все участники должны быть крайне мотивированными и высококлассными специалистами, активно участвующими в командных процессах, иначе вся схема будет пытаться развалиться.
Также раньше мы очень большое внимание уделяли детальной проработке всех требований к фиче до старта разработки. Основные недостатки такого подхода – это сужение пропускной способности всей команды и слишком тепличные условия для разработчиков и тестировщиков. В юнитах уже на первых порах стало видно, что старый подход к ТЗ не работает и нужно что-то менять – аналитик не успевал готовить проработанные задачи. Для решения этой проблемы мы разделили ТЗ на две части — must have для старта разработки и всё остальное. Этот подход несколько снял напряжение, но не закрыл все вопросы, поэтому дальнейшие проверки различных гипотез – дело времени.
Помимо этого, Владельцы Продукта перестали работать как общая продуктовая команда, и разбежались по своим зонам ответственности. Сейчас этого уже практически нет, но в самом начале такая проблема возникла. Мы работаем над укрупнением направлений и объединением команд вокруг них.
Планы
Несмотря на глобальные изменения в 2020 году, мы хотим двигаться дальше, решать новые задачи и экспериментировать с процессами. На данный момент наметили несколько основных направлений работы:
- Вся разработка должна быть In House. На наш взгляд, это аксиома, аутсорсинг — всегда непрозрачно и почти всегда неуправляемо.
- Техническое развитие продукта
- автоматические UI тесты для снятия лишней нагрузки с unit'ов при подготовке релизов
- единый интеграционный backend для снижения затрат на подключения к другим системам ландшафта компании
- дальнейшее развитие модульности приложения для упрощения работы структуры в целом. Для ускорения и стабилизации этого процесса мы планируем создать выделенную команду развития платформ.
- Автоматизация сбора различных метрик работы unit'ов и продуктовой команды целиком.
- Создание кросс-команды, в которую будет входить полный спектр специалистов для реализации функционала в app и web части нашего продукта.
Авторы — Артем Андреев, Наталья Егорова, Алексей Кретов
