Время вывода продукта, или time to market, теряется между этапами

Разработка нового тарифа или дополнительной функции занимает несколько недель, а до клиента изменение нередко доходит через квартал. Остальное время уходит на другие этапы и на ожидание между ними. Весь путь от идеи до клиента называют временем вывода продукта на рынок, или time to market, сокращенно TTM.

Месяцами внедряют и изменения в ценообразовании. По данным глобального опроса Revenera среди разработчиков ПО, чаще всего на запуск новой модели монетизации уходит 3–9 месяцев: такой срок назвали 57% участников. Быстрее чем за квартал уложились только 14%.

Из чего складывается time to market

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

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

Инженерные метрики охватывают лишь отрезок этого пути:

• Срок поставки, или lead time. Его считают с момента, когда задачу взяли в работу, и до релиза.
• Время цикла, или cycle time. Метрика учитывает только активную фазу, когда исполнитель занят делом.
• TTM. Отсчет начинается раньше, с идеи, и заканчивается позже, на стороне клиента.

Свой участок разработка измеряет давно и подробно. В исследовании State of DevOps Russia 2025 команды делят на профили по метрикам доставки. Даже у самых медленных, из группы Low, срок поставки изменений сократился до 1–3 месяцев. Если выход продукта к клиенту занимает полгода и дольше, остальное время накапливается за пределами разработки: в паузе до старта, на постановке задачи, согласованиях и запуске. Эти потери редко кто замечает: разработка отчитывается своими метриками, отдел продукта сверяется с дорожной картой, а паузы не принадлежат ни одному из них.

Внутренние и внешние факторы time to market

На время выхода продукта на рынок влияют факторы двух типов. Внутренние зависят от устройства компании:

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

Внешние факторы компания учитывает в плане, но изменить не может:

• Отрасль и ее технологический цикл. Разработку автомобиля и мобильного приложения ведут в разном темпе.
• Регуляторные требования. Финансовые и медицинские продукты до выпуска проходят обязательный контроль.
• Конкуренция и запросы пользователей. От них зависит, как долго рынок готов ждать продукт.
• Требования площадок. Магазины приложений модерируют обновления перед публикацией.

От подхода к разработке зависит срок даже внутри одной отрасли. По оценке McKinsey, новые китайские производители электромобилей доводят модель от концепции до запуска примерно за 24 месяца. Это вдвое быстрее остальных автокомпаний: у тех этот путь занимает 40–50 месяцев и дольше.

Аналитики McKinsey посчитали, сколько месяцев экономят отдельные меры. Например, если машину тестируют на программных моделях и виртуальных образцах вместо физических прототипов, она выходит на рынок на 9–11 месяцев раньше.

22 октября 16:00 МСК Онлайн Бесплатно Онлайн-конференция: От «да» до первого шага Практика тех, кто каждый день доводит до результата дилеров, клиентов и сотрудников. Зарегистрироваться

Как измерить time to market: старт, финиш и подметрики

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

Точки старта и финиша time to market

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

Подметрики time to market и эталонные сроки

Телекоммуникационная компания t2 считает TTM отдельно для групп продуктов по сложности и типу. Сам показатель там раскладывают на подметрики:

• ожидание от появления идеи до начала работы;
• дизайн;
• согласование;
• разработка и тестирование.

Так видно, на каком этапе задача задерживается дольше обычного, — и команда перестраивает или убирает лишние шаги именно там.

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

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

Где теряется время: ожидание между этапами

Если TTM разложен по стадиям, в нем видны промежутки, когда задача зависла в статусе трекера. Типичные точки простоя выглядят так:

• «Готово к разработке». Задачу сформулировали, но ни один исполнитель ее еще не взял.
• «На паузе». Работу приостановили до решения внешнего вопроса.
• «Тестирование пройдено». Контроль качества закончен, задача ждет релиза.

Чистое время работы определяется сложностью задачи — сократить его трудно. А простой в статусах зависит от устройства процесса — им можно управлять. Узкое место, как правило, находится там, где время в статусе растет от задачи к задаче. С этого статуса команда и начинает разбор: выясняет, почему работа там стоит.

Против таких простоев используют три приема:

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

«Сокращение даже по несколько часов в каждом статусе может ускорить выпуск задач на один или несколько дней, а значит, сделать больше задач за тот же объем времени».

Павел Кондратьев, руководитель проектов в ГК Юзтех

Срок теряется на входе: постановка задачи

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

«Домклик», платформа недвижимости и ипотеки, разрабатывает сервисы на моделях машинного обучения для оценки жилья. Команда проанализировала процесс по записям таск-трекера: разработка сервиса вместе с подготовкой данных для модели занимала от 10 до 13 недель. Этап «Анализ и создание ТЗ» длился до трех недель: требования выяснял сам исполнитель. Команда ввела четыре меры. По ее словам, весь процесс разработки сократился до пяти недель. Вот что изменили:

• Шаблон технического задания. Аналитики данных передают задачу разработчикам в едином формате.
• Стандартная архитектура и типовой каркас. Очередной сервис строят по готовой схеме.
• Общий фреймворк. Команды работают на одинаковых инструментах.
• Хранилище признаков. Готовые наборы данных для моделей используют повторно между сервисами.

Повторяющийся этап выгоднее превратить в конвейер

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

Так, в финтех-компании ЮMoney так поступили в департаменте аналитических решений. За год там насчитали 13 задач на подключение новых источников данных. Команда перешла на платформенный подход и кодогенерацию: объекты баз данных и процессы загрузки создаются по спецификации. Время от поступления задачи на разработку до развертывания релиза сократилось на 98% — с 10 дней до 4 часов. Цифра относится к одному типовому инженерному процессу, а не к TTM продукта целиком. В качестве проверки подход испытали на стажере без опыта: на весь путь у него ушло 4 часа 12 минут, из них личной работы — 51 минута.

Проверки в конце цикла превращаются в очередь

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

Чтобы задачи не копились перед проверкой, ее переносят в начало цикла:

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

«Если мы хотим сократить time-to-market, ИБ должна быть встроена в процесс разработки ПО».

Артём Калашников, управляющий директор Центра информационной безопасности дочерних и зависимых обществ Газпромбанка

Как сокращать time to market без потери качества

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

• Минимальный жизнеспособный продукт, или MVP. Команда запускает базовый вариант с одной главной возможностью.
• Инкрементальные обновления. Функции выходят частями, и ошибка в одной не задерживает остальные.
• Быстрое тестирование гипотез. На идею отводят ограниченное время, после которого ее либо развивают, либо закрывают.
• Обратная связь от пользователей. По отзывам и статистике использования команда решает, что делать в следующем выпуске.

Такой подход описывает SimbirSoft на примере финтех-сервиса оплаты частями «Подели», для которого компания как подрядчик разрабатывает мобильное приложение. За два года продакт-менеджеры проверили свыше 100 гипотез, а на тест одной функции отводили не более 20 дней. По данным SimbirSoft, результатом стало сокращение time to market на 17%. Оценки пользователей за тот же период улучшились: рейтинг приложения вырос с 3,6 до 4,4 в iOS и с 3,8 до 4,7 в Android.

Порядок сокращения time to market: сначала замер

Решения принимают по итогам поэтапного учета: без подметрик неизвестно, что именно ускорять. Порядок действий такой:

1. Договориться о точках старта и финиша: от идеи до момента, когда продукт доступен клиенту.
2. Разделить TTM на подметрики и отдельно считать простои. Установить эталонный срок по типам продуктов с опорой на собственную статистику.
3. Найти в трекере этап с самым долгим ожиданием.
4. Ввести шаблон технического задания для передачи задачи в разработку.
5. Стандартизировать и автоматизировать процессы, которые повторяются чаще всего.
6. Перенести контроль безопасности и юридические визы в начало цикла.