Яндекс.Маркет
890

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

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

В закладки

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

Инженерные практики

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

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

1) Ускорьте код-ревью

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

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

2) Автоматизируйте тестирование

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

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

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

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

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

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

3) Внедряйте Continuous Integration & Deployment

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

4) Культивируйте внутренний open source

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

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

Изменения процессов

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

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

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

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

5) Сначала заканчивай начатое

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

6) Bus factor в проекте >1

Несмотря на то, что 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%!

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

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

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

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

7) Перестаньте делать неважное

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

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

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

8) Договаривайтесь быстро

Проект в 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, быстро окупятся.

Группа компаний Яндекс.Маркета — это экосистема сервисов электронной коммерции: площадка для сравнения цен, выбора и покупки товаров «Яндекс.Маркет», сервис для бизнеса Яндекс.Маркет Аналитика и многое другое.
{ "author_name": "Яндекс.Маркет", "author_type": "editor", "tags": [], "comments": 5, "likes": 13, "favorites": 10, "is_advertisement": false, "subsite_label": "yandexmarketgroup", "id": 161459, "is_wide": true, "is_ugc": false, "date": "Tue, 29 Sep 2020 17:25:08 +0300", "is_special": false }
Объявление на vc.ru
0
5 комментариев
Популярные
По порядку
5

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

Ответить
0

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

Ответить
0

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

Ответить
0

Интересная статья, особенно подкрепление тезисов намерянной статистикой. Спасибо!

Ответы на вопросы в таск-трекере, хмм. Как это устроено? И что за таск трекер используется?
Автоназначение код ревью - какой инструмент для этого используется?

Ответить
0

Рад, что вы нашли статью полезной!

Про ответы
Используется (не сочтите за рекламу) Яндекс.Трекер https://yandex.ru/tracker/ Функциональность называется "призыв". В момент написания комментария можно "призвать" коллегу. Трекер автоматически пропишет коллегу, которого "зовут" в специальное поле. Когда коллега ответит комментарием в задаче, трекер его имя автоматически из этого поля удалит.
Но думаю что современные таск-трекеры вроде JIRA или Trello что-то подобное тоже должны уметь.

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

Ответить

Комментарии

null