В 2019 году мы почувствовали необходимость сфокусировать силы разработки на реализации наиболее ценных бизнес-проектов, а не всего подряд. Внедрили сквозное планирование от стратегии компании до продуктовых роадмапов и задач на команды разработки на квартал. Но на коммуникации при самом планировании и реализации фичей уходило слишком много времени.
Тогда мы запустили первые agile-поезда. Эксперимент оказался успешным: сократилось время выдачи полезной функциональности, увеличился фокус команд, была хорошая обратная связь от бизнеса. Поэтому сейчас все инженерные команды и сотрудники функциональных команд Quadcode работают в том или ином поезде. В статье подробнее расскажем, почему понадобилось переходить на новую модель, где мы на пути к продуктовому подходу и верхнеуровнево пройдёмся по процессам.
Что такое поезд
Поезд — это набор agile-команд, которые работают над конкретным бизнес-направлением компании. Мы запускаем поезда под длительные роадмапы, когда уверены, что выполнение задач приведёт к развитию бизнеса и росту бизнес-метрик. В состав поезда входят все специалисты, которые нужны для реализации проектов и фичей в определённой продуктовой или инфраструктурной области, например:
Разработчики.
QA-инженеры.
Тимлиды.
Аналитики.
Продакт-менеджеры.
Дизайнеры.
Технические писатели.
HR BP.
Предпосылки запуска поездов
Главная задача, которую нам предстояло решить, — это фокусировка сил разработки, чтобы ускорить реализацию наиболее ценных фичей.
В прошлом у нас случались ситуации, когда топ-менеджмент думал, что приоритеты одни, продакт-менеджер — что приоритеты другие, а команды разработки делали что-то третье. Это замедляло прогресс и усложняло коммуникацию.
Представьте полтора десятка команд, к которым приходит около десятка фича-оунеров (FO). Каждый общается с каждым. Десять FO приходят в команду, а FO необходимо обойти десять команд. Для планирования одной фичи может потребоваться цепочка команд, а если кто-то не может взять фичу, то пасьянс придётся раскладывать заново. Затем приходит заказчик и предлагает изменить приоритеты фичей, и опять всё по новой.
Плюс к этому, по необходимости к фичам добавляли сотрудников функциональных команд: аналитиков, дизайнеров, инфраструктурных инженеров. Если их подключали с опозданием, появлялись бутылочные горлышки, что ещё больше увеличивало сроки реализации. Всё это переусложняло систему, а сотрудники распылялись на разные задачи.
Мы поняли, что важно объединить команды вокруг бизнес-направлений и выстраивать продуктовый подход со сквозной постановкой задач от бизнес-целей к разработке. Модель управления поездами подразумевает, что есть решения, которые централизованно принимает руководство компании. Дальше они идут на уровень поездов и команд, а уже сами команды предлагают технические решения.
Для компании цель истории с поездами заключается в личной эффективности каждого бизнес-направления. Сотрудникам же это позволяет сфокусировано работать в своей области компетенций и наращивать экспертность. Такие условия могут не подойти тем, кто хочет полной свободы в выборе задач, но при этом хороши потому, что выполненная работа не пойдёт «в стол» — про это поговорим подробнее в следующем разделе.
Эксперимент с реорганизацией структуры мы начинали в 2020 году с двумя поездами. На них смотрели, какие «детские» проблемы возникают, и дорабатывали модель. На текущий момент все команды разработки относятся к одному из поездов.
Развитие продуктового подхода в поездах
Первый год после запуска поездов ушёл на то, чтобы выстроить порядок. Чтобы продакт-менеджеры могли хорошо описывать задачи, планировать нагрузку и согласовывать планы с бизнесом. А бизнес, в свою очередь, знал метрики поездов и команд, а также мог самостоятельно использовать аналитику. Так мы пришли к точке, в которой отлично умеем планироваться.
Но тот факт, что фичу или задачу взяли в планирование сам по себе не означает, что она этого достойна. Поэтому сейчас мы находимся на этапе, где стараемся проверять гипотезы до того, как отправляем их в разработку. Делаем MVP и запускаем эксперименты, а из результатов передаём в работу только то, что показало эффективность. Если тест не показал статистически значимых улучшений — отказываемся от фичи.
Командам разработки комфортнее работать, когда есть доказательство полезности задачи. В прежней модели «завода» с запросами от разных фича-оунеров мы далеко не всегда понимали, сработает ли то или иное решение. Сейчас переходим на гораздо более прозрачную работу с гипотезами, метриками, роадмапами и продуктовым целеполаганием.
Бизнес говорит, что и почему нужно сделать, команды отвечают за реализацию. При этом сотрудники тоже могут предлагать свои идеи по улучшению продукта. Мы стараемся сделать так, чтобы все в цепочке коммуникаций были исполнительным: бизнес проверял идеи, а инженеры предлагали лучшие технические решения по внедрению. Сейчас у продакт-менеджеров есть возможность заблокировать задачу на своём уровне, если гипотеза не проверена до передачи в разработку. Они своего рода щит для команд, который защищает от микроменеджмента и хаотичных процессов.
Процессы в поезде
Верхнеуровнево процессы в поезде устроены следующим образом:
В конце каждого квартала проходит ретроспектива.
После ретроспективы начинается квартальное планирование, где формируется план на следующие три месяца. В ходе планирования мы приоритезируем крупные задачи, декомпозируем их на user story и распределяем по спринтам. На этот процесс выделяем неделю.
Дальше стартуют спринты. Каждый спринт длится две недели. Старты спринтов в поездах синхронизированы между собой.
По завершению спринта проходит демо поезда.
Внутри команд — стандартные SCRUM-процессы: стендапы, планирование, product backlog refinement, ретроспективы.
Иногда в поездах появляются отдельные команды, нацеленные на проверку гипотез и эксперименты. Они обычно движутся вперёд быстрее остальных, потому что не готовят полновесные решения. Они могут сами делать переприоритезацию в рамках спринта.
Как оцениваем результаты поезда
Продакт-менеджер каждого поезда формирует два основных типа метрик:
Продуктовые или метрики бизнес-ценности.
Процессные.
От их роста зависит бонусная система сотрудников поезда.
По продуктовым метрикам мы смотрим:
Насколько активности поезда повлияли на ключевые метрики по продуктам или бизнес-направлению.
Как это в целом повлияло на успешность и гибкость бизнеса.
Какой профит от развития данного направления.
Поскольку продукты разные, набор продуктовых метрик у каждого поезда свой. Пара примеров: конверсия в реальную сделку или демо-сделку, размер депозита конечного клиента.
С помощью процессных метрик мы оцениваем, насколько эффективны процессы внутри поезда в целом и внутри отдельных команд, что и почему необходимо улучшать. Вот примеры:
Lead time — время от появления идеи до её проверки.
Cycle time — процент задач, завершённых за спринт.
Количество задач, завершённых за спринт. В отчёте также видно, сколько процентов закрытых задач — из плана, а сколько — внутренние доработки или фикс багов.
Product index — процент времени, затраченного на реализацию продуктовых фичей.
WIP (work in progress) — количество задач в работе, которые ещё не завершены. Отчёт показывает период между заведением фичи или бага и текущим моментом. Здесь мы следим, чтобы в работе не было слишком большого количества задач, а их возраст не уходил в космос.
Минусы и плюсы поездов
С внедрения поездов прошло достаточно времени, чтобы мы могли ретроспективно посмотреть на их минусы и плюсы.
Минусы:
Не каждому понравится, что задачи приходят от продакт-менеджера и нет полной свободы действий. Это важно учитывать при найме в компанию, чтобы сотрудники не выгорали.
Для качественной реализации истории с поездами нужны опытные разработчики и продакт-менеджеры. Они должны отлично понимать, как работает система в целом, чтобы иметь возможность подкручивать винтики в отдельных частях.
Плюсы:
В поезде есть все необходимые специалисты для реализации любой фичи — это значит, что продакт-менеджеру не нужно «вставать в очередь» к внешним командам. Благодаря этому мы сокращаем количество взаимосвязей, время на реализацию фичей и улучшаем коммуникации.
Команда понимает, что делать сегодня, через квартал и через год: есть согласованное видение, роадмап и чёткие приоритеты.
Ребята из поезда хорошо знают свои продукты и полностью сфокусированы на них. Благодаря этому они могут предлагать лучшие технические решения и через них влиять на развитие бизнеса.
За счёт сокращения времени на планирование и встречи команды могут уделять больше времени непосредственно разработке и тестированию. Поэтому сотрудники поезда стабильно наращивают экспертность в своей предметной области.
