Time to market: не теряйте время, это слишком дорого

В современном бизнесе есть понятие time to market — это время, которое компания тратит на реализацию и выпуск бизнес-идеи своим клиентам. Чем ниже time to market, то есть чем быстрее фича отправляется в продакшн, тем быстрее зарабатываются деньги для бизнеса. Подробнее — в статье руководителя отдела производства продукта для магазинов Леонида Савченкова.

В Яндекс.Маркете мы внедрили несколько изменений, которые помогли нам сократить время разработки новой фичи с 64 до 46 дней. Их можно применить в любой команде, которая разрабатывает софт.

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

Теперь давайте посмотрим, как можно ускорить каждый из этапов.

Если код-ревью для вас — обязательный этап, максимально оптимизируйте его. Отдайте линтеру все стилистические требования, чтобы живой человек на них не отвлекался. Договоритесь в команде о правиле, что на код-ревью отводится 24 часа. Внедрите инструмент, который автоматически раздаёт задачи на код-ревью — с учётом справедливости, опыта членов команды и календаря отсутствия.

Вот так у нас получилось ускорить этот этап (на графике изображён 80-й персентиль времени, за которое коммит проходит код-ревью):

Ручная проверка готового релиза QA-инженерами может занимать много времени. Как правило, она проходит в два этапа: тестирование новой функциональности, ради которой и затевался релиз, и регрессионное тестирование, чтобы убедиться, что мы ничего не сломали. Ускорить процесс поможет уменьшение размера релизов и автоматизация тестирования.

Если релизы будут небольшими и простыми в развёртывании (см. следующий пункт про CI и CD), их легко будет тестировать. Стоит целиться в один релиз в день.

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

После такого подхода к автоматизации профессия тестировщика бэкенда в Яндекс.Маркете исчезла как класс. Существующие QA-инженеры остались для фронтенда.

Вручную они теперь проверяют только новый функционал, а для регрессионного тестирования пишут автотесты.

Вот так мы избавились от ручного регресса для личного кабинета партнёров Маркета в 2019 году:

Внедрение CI & CD позволило свести к нулю ручной труд разработчиков при выполнении рутинных операций: сборки и выкладки новых версий кода на стенды. Теперь это делается по кнопке, с помощью специальных инструментов, функционально похожих на TeamCity и Jenkins.

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

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

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

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

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

Поэтому при разработке проектов в Яндекс.Маркете было принято правило:

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

Несмотря на то, что bus factor звучит как средство для управления рисками, он также значительно влияет на time to market. Когда над фичей работает не один человек, а несколько (в идеале — вся команда), она будет готова быстрее.

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

Вот пара примеров:

1) Есть три фичи, каждая из которых оценивается в 12 недель разработки и приносит 10 000 рублей в неделю. Для команды из трёх разработчиков после 24 недель получаем разницу в 60 000 рублей (450 000 против 390 000) — больше 15%. И это при оверхеде на параллельную разработку в 25%:

2) Для больших фичей (55 человеко-недель, каждая фича приносит 50 000 рублей в неделю), больших команд (5 человек) и при большом оверхеде на параллельную разработку (75%) запускаться раньше всё ещё имеет экономический смысл. Спустя 110 недель мы получаем 10,8 млн рублей против 8,4 млн рублей — разница в 28%!

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

Сложность такой совместной работы в том, что команда должна обладать экспертизой по всему продукту. И экспертизу приходится распространять. Поначалу нам нужно было преодолевать сопротивление в командах, особенно в маленьких. «О, у тебя по этой области вопрос. Тогда тебе к Пете, больше никто проконсультировать не сможет». Также часто использовались аргументы «мне проще сделать самому, новичку я дольше объяснять буду». Но позже, когда экспертиза распространилась, все почувствовали облегчение.

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

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

Есть важные и срочные проекты, которые все делают прямо сейчас. А есть проекты, которые «нельзя не сделать», которые «хорошо бы сделать», или которые уже кому-то пообещали. Про них команды часто говорят, что «делают их в фоне» или «в свободное от работы время» (ха-ха).

Time to market таких проектов катастрофически велик — иногда в 10 раз больше, чем у обычных. Как правило, это бесконечная прокрастинация до момента, когда дальше оттягивать уже неприлично.

Секрет в том, чтобы честно признаться: проект заморожен, работы по нему не ведутся. И озвучить это. Если проект действительно важен, найдутся неравнодушные спонсоры из бизнеса или откуда-то ещё, способные обозначить для него правильное место в бэклоге. Если таких людей нет, значит, проект никому не нужен. Тогда зачем его делать?

Проект в IT часто сложен не из-за решения или архитектуры IT-системы, а потому, что участникам нужно договориться между собой. Скорость коммуникации сильно влияет на time to market. Разработчик продолжает программировать текущую задачу, если быстро получает ответы на свои вопросы. Иначе он просто переключается на понятную ему задачу и теряет контекст первой. В итоге, когда ответ подоспеет, разработчик вернётся к первой задаче не сразу, а лишь когда закончит вторую задачу или почему-то от неё отвлечётся.

Мы измерили скорость, с которой наши разработчики, аналитики, менеджеры и тестировщики отвечают на вопросы в таск-трекере. Результаты нас вполне устроили. На 73% вопросов отвечают в течение дня, на 86% — в течение трёх дней, и только на 6% — больше 10 дней.

Уметь измерять скорость коммуникации полезно, как и иметь частью культуры способность быстро отвечать на вопросы.

По результатам работы, время (80-й персентиль) от коммита кода в VCS до появления этого кода в продакшне сократилось с 310 календарных часов до 115. Медиана плавающего среднего time to market в наших проектах снизилась с 64 до 46 дней. 90-й персентиль снизился со 170 дней до 144 дней. Это означает, что каждый второй проект за последние 90 дней мы сделали быстрее, чем за 47 календарных дней. Лишь один проект из десяти делался дольше 144 дней.

Таким образом, чтобы быстрее получать отдачу от вашей IT-разработки, инвестируйте в сокращение time to market. Начните с инженерных практик — большинству разработчиков они придутся по душе. Затем переходите к процессным изменениям — здесь рассчитывайте на управленческое звено. Ресурсы, которые вы потратите на внедрение и совершенствование time to market, быстро окупятся.