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

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

Что такое поезд

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

• Разработчики.

• QA-инженеры.

• Тимлиды.

• Аналитики.

• Продакт-менеджеры.

• Дизайнеры.

• Технические писатели. 

• HR BP. 

Предпосылки запуска поездов

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

В прошлом у нас случались ситуации, когда топ-менеджмент думал, что приоритеты одни, продакт-менеджер — что приоритеты другие, а команды разработки делали что-то третье. Это замедляло прогресс и усложняло коммуникацию. 

Представьте полтора десятка команд, к которым приходит около десятка фича-оунеров (FO). Каждый общается с каждым. Десять FO приходят в команду, а FO необходимо обойти десять команд. Для планирования одной фичи может потребоваться цепочка команд, а если кто-то не может взять фичу, то пасьянс придётся раскладывать заново. Затем приходит заказчик и предлагает изменить приоритеты фичей, и опять всё по новой. 

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

Мы поняли, что важно объединить команды вокруг бизнес-направлений и выстраивать продуктовый подход со сквозной постановкой задач от бизнес-целей к разработке. Модель управления поездами подразумевает, что есть решения, которые централизованно принимает руководство компании. Дальше они идут на уровень поездов и команд, а уже сами команды предлагают технические решения. 

Для компании цель истории с поездами заключается в личной эффективности каждого бизнес-направления. Сотрудникам же это позволяет сфокусировано работать в своей области компетенций и наращивать экспертность. Такие условия могут не подойти тем, кто хочет полной свободы в выборе задач, но при этом хороши потому, что выполненная работа не пойдёт «в стол» — про это поговорим подробнее в следующем разделе. 

Эксперимент с реорганизацией структуры мы начинали в 2020 году с двумя поездами. На них смотрели, какие «детские» проблемы возникают, и дорабатывали модель. На текущий момент все команды разработки относятся к одному из поездов. 

Развитие продуктового подхода в поездах

Первый год после запуска поездов ушёл на то, чтобы выстроить порядок. Чтобы продакт-менеджеры могли хорошо описывать задачи, планировать нагрузку и согласовывать планы с бизнесом. А бизнес, в свою очередь, знал метрики поездов и команд, а также мог самостоятельно использовать аналитику. Так мы пришли к точке, в которой отлично умеем планироваться.   

Но тот факт, что фичу или задачу взяли в планирование сам по себе не означает, что она этого достойна. Поэтому сейчас мы находимся на этапе, где стараемся проверять гипотезы до того, как отправляем их в разработку. Делаем MVP и запускаем эксперименты, а из результатов передаём в работу только то, что показало эффективность. Если тест не показал статистически значимых улучшений — отказываемся от фичи. 

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

Бизнес говорит, что и почему нужно сделать, команды отвечают за реализацию. При этом сотрудники тоже могут предлагать свои идеи по улучшению продукта. Мы стараемся сделать так, чтобы все в цепочке коммуникаций были исполнительным: бизнес проверял идеи, а инженеры предлагали лучшие технические решения по внедрению. Сейчас у продакт-менеджеров есть возможность заблокировать задачу на своём уровне, если гипотеза не проверена до передачи в разработку. Они своего рода щит для команд, который защищает от микроменеджмента и хаотичных процессов. 

Процессы в поезде 

Верхнеуровнево процессы в поезде устроены следующим образом:

1. В конце каждого квартала проходит ретроспектива.

2. После ретроспективы начинается квартальное планирование, где формируется план на следующие три месяца. В ходе планирования мы приоритезируем крупные задачи, декомпозируем их на user story и распределяем по спринтам. На этот процесс выделяем неделю.

3. Дальше стартуют спринты. Каждый спринт длится две недели. Старты спринтов в поездах синхронизированы между собой. 

4. По завершению спринта проходит демо поезда. 

5. Внутри команд — стандартные SCRUM-процессы: стендапы, планирование, product backlog refinement, ретроспективы.

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

Как оцениваем результаты поезда

Продакт-менеджер каждого поезда формирует два основных типа метрик: 

1. Продуктовые или метрики бизнес-ценности.

2. Процессные. 

От их роста зависит бонусная система сотрудников поезда. 

По продуктовым метрикам мы смотрим:

• Насколько активности поезда повлияли на ключевые метрики по продуктам или бизнес-направлению.

• Как это в целом повлияло на успешность и гибкость бизнеса. 

• Какой профит от развития данного направления.

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

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

• Lead time — время от появления идеи до её проверки.

• Cycle time — процент задач, завершённых за спринт. 

• Количество задач, завершённых за спринт. В отчёте также видно, сколько процентов закрытых задач — из плана, а сколько — внутренние доработки или фикс багов. 

• Product index — процент времени, затраченного на реализацию продуктовых фичей. 

• WIP (work in progress) — количество задач в работе, которые ещё не завершены. Отчёт показывает период между заведением фичи или бага и текущим моментом. Здесь мы следим, чтобы в работе не было слишком большого количества задач, а их возраст не уходил в космос.  

Минусы и плюсы поездов

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

Минусы:

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

2. Для качественной реализации истории с поездами нужны опытные разработчики и продакт-менеджеры. Они должны отлично понимать, как работает система в целом, чтобы иметь возможность подкручивать винтики в отдельных частях. 

Плюсы:

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

2. Команда понимает, что делать сегодня, через квартал и через год: есть согласованное видение, роадмап и чёткие приоритеты. 

3. Ребята из поезда хорошо знают свои продукты и полностью сфокусированы на них. Благодаря этому они могут предлагать лучшие технические решения и через них влиять на развитие бизнеса. 

4. За счёт сокращения времени на планирование и встречи команды могут уделять больше времени непосредственно разработке и тестированию. Поэтому сотрудники поезда стабильно наращивают экспертность в своей предметной области.