Time to market: почему заказчики выбирают по скорости

Что значит TTM

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

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

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

TTM, lead time и cycle time

Три метрики часто путают. Разница в том, какой отрезок процесса они меряют.

Почему заказчики выбирают по скорости

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

У задержки есть цена. Дональд Рейнертсен в книге «The Principles of Product Development Flow» 2009 года называет её стоимостью задержки — cost of delay. Это деньги, которые бизнес недополучает за каждую неделю, пока функция не в проде.

Как прикинуть стоимость задержки

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

Такой расчёт быстро меняет разговор о приоритетах. Спорить о мелких доработках сложно, когда на столе цифра.

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

Как измерить скорость команды

Для разработки есть устоявшийся набор метрик DORA. Его описали Николь Форсгрен, Джез Хамбл и Джин Ким в книге «Accelerate» 2018 года.

• частота деплоев — как часто код уходит в прод;
• lead time for changes — сколько проходит от коммита до прода;
• доля неудачных изменений — сколько релизов приходится откатывать;
• время восстановления — за сколько команда чинит сбой.

Какие значения считаются хорошими

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

Сравнивать себя с лидерами напрямую я бы не стал: у банка и у стартапа разные требования к надёжности. Полезнее смотреть на собственную динамику. Если lead time за квартал вырос с недели до трёх, это сигнал разбираться, даже если до отчёта DORA далеко.

Что считать началом и концом

Метрики DORA покрывают только техническую часть. Чтобы видеть весь путь, я бы добавил две точки: дату, когда бизнес принял решение, и дату, когда пользователь впервые воспользовался функцией. Разрыв между ними и есть реальный срок выхода на рынок.

Как сократить TTM без найма

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

Причина в коммуникациях. В команде из 5 человек 10 каналов связи, в команде из 10 — уже 45. Каждый должен рассказать каждому про изменения, и на это уходит время, которое раньше шло на работу.

Что работает вместо найма

• резать объём: первая версия решает одну задачу, а не десять — это идея MVP из «Бережливого стартапа» Эрика Риса;
• выпускать маленькими порциями: релиз раз в день проще, чем раз в квартал;
• автоматизировать сборку и тесты через CI/CD;
• прятать незаконченное за флагами функциональности, а не держать в отдельной ветке;
• брать готовое: SaaS, библиотеки и коробочные модули вместо разработки с нуля;
• назначить одного человека, который принимает решения, а не собирать комитет.

Какая команда быстрее

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

Что может сделать заказчик

Срок запуска зависит и от заказчика, а не от одного подрядчика. Многие задержки возникают на стороне бизнеса: команда ждёт решения, доступов, текстов или приёмки.

Неделя ожидания ответа на вопрос разработчика — это неделя, на которую сдвигается релиз. Команда в это время переключается на другое, а потом тратит ещё день, чтобы вернуться в контекст.

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

Короткие итерации вместо большого запуска

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

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

Типичные ошибки

• считать срок только от старта разработки и не видеть очередь согласований;
• докидывать разработчиков в горящий проект;
• откладывать релиз до «идеальной» версии;
• переключать ведущих людей между проектами — каждое переключение стоит дней;
• мерить скорость часами, а не сроком до пользователя.