Поставить дату выхода продукта нетрудно, а вот понять, успеет ли команда к этому сроку, — уже задачка посложнее. Без данных о прошлых запусках каждый новый проект приходится оценивать почти с нуля, а сроки часто пересматривать уже в процессе 😢
Представим, что команда рассчитывает выпустить новую функцию за два месяца, но задачи задерживаются на тестировании. Если не учитывать такие задержки, следующий релиз снова не выйдет вовремя.
Чтобы объективно оценивать сроки и находить такие слабые места, используют Time to Market. О нём и расскажем.
Что такое Time to Market и зачем его измерять
— срок от старта работы над продуктом до его выхода на рынок
Time to Market используют не только в IT. Метрика особенно важна в сферах, где быстро меняются тренды и предпочтения покупателей. Например, в моде, косметике, товарах для ухода и электронике. Здесь скорость выхода на рынок помогает быстрее реагировать на изменения спроса и действия конкурентов.
Time to Market помогает:
- Ставить более реалистичные дедлайны
- Планировать загрузку команды
- Вовремя замечать в работе задержки и «бутылочные горлышки» и пересматривать процессы
- Оценивать, как быстро компания может отвечать на новый запрос пользователей, изменение спроса или действия конкурентов
- Рассчитывать затраты на проект и ещё до старта отказываться от невыгодных запусков
Наш кейс при разработке нового модуля для приложения. Разработчики быстро закрывали задачи, поэтому бизнесу казалось, что мы движемся к релизу хорошими темпами. Но когда посчитали честный TTM от одобрения идеи до релиза, получили 60 дней. При этом сама разработка заняла только 10 дней, а остальные 50 ушли на согласования с юристами, комплаенсом, дизайнерами и смежными командами
Проработав и скорректировав подходы и процессы на каждом этапе TTM удалось сократить до 25 дней
Чем Time to Market отличается от Lead Time, Cycle Time и Time to Value
Кроме TTM, в работе используют и другие метрики времени. Они связаны между собой, но отвечают на разные вопросы. Для наглядности сравнили показатели в таблице:
| Показатель | Что оцениваем | Стартовая точка | Конечная точка |
|---|---|---|---|
| Time to Market | Весь путь продукта до рынка | Появилась идея, её одобрили или начали работу над продуктом | Продукт выходит на рынок или становится доступен пользователям |
| Lead Time | Путь от запроса до готового результата | Появилась задача или запрос | Работа завершена |
| Cycle Time | Активную работу над отдельной задачей | Задачу взяли в работу | Задача завершена |
| Time to Value | Время до первой пользы для клиента | Клиент начал пользоваться продуктом | Первый полученный результат |
Если разложить эти метрики по одной временной линии, получится так:
Например, на одном из наших проектов Cycle Time выглядел хорошо. Но общий TTM при этом продолжал расти. Когда стали разбирать Lead Time по этапам, выяснилось, что готовый код надолго застревает в очереди на тестирование. Команда QA просто не успевала справляться с потоком задач. Разделение метрик сразу показало: нужно расшивать ресурсы QA
📌 Разберём на примере. 8 мая команда решила добавить автоматические напоминания о дедлайнах. 20 мая задачу внесли в бэклог, а 4 июня начали над ней работать. Пользователям функция стала доступна 14 июня. В этом случае Cycle Time равен 10 дням, Lead Time — 25 дням, а Time to Market — 37 дням. Первое напоминание пользователь получил 16 июня, поэтому Time to Value составил 2 дня.
Как рассчитать Time to Market
Сначала нужно определить, с какого момента команда будет считать Time to Market. Это может быть новая идея, её согласование или начало разработки чего-то. Тут надо выбрать одну точку отсчёта и использовать её для всех похожих запусков.
Но может быть такое, что идея лежит в бэклоге месяцами. В этом случае включать это время в TTM команды не стоит. Иначе метрика превратится в «среднюю температуру по больнице», а разработчикам придётся отвечать за задержки, на которые они не могли повлиять. Время в бэклоге лучше считать отдельно с помощью метрики Ideation Time
Конечной точкой обычно становится релиз — момент, когда продукт выходит на рынок или новая функция становится доступна пользователям. Чтобы посчитать Time to Market, достаточно узнать, сколько времени прошло между стартом работы и релизом:
Например, работу над новой функцией начали 10 апреля, а пользователям открыли её 30 мая. Time to Market составил 50 дней. В этот срок входит всё время: и задержки, и согласования, и другие ситуации, которые обычно случаются в проектах.
Из чего складывается TTM
До релиза продукт проходит несколько этапов — они зависят от проекта, но чаще путь выглядит так:
Анализ ➡️ подготовка ➡️ создание продукта ➡️ проверка ➡️ подготовка к релизу ➡️ запуск
К слову, путь не всегда идёт строго по плану. На тестировании команда может найти ошибку и вернуть функцию в разработку. Команда исправляет проблему и снова отправляет задачу на тест.
И важно помнить, что при расчёте TTM учитывают не только время активной работы. Если дизайнер подготовил макет за один день, а согласования ждал ещё три, в Time to Market войдут все четыре дня.
Что влияет на Time to Market
На срок запуска влияют и процессы внутри команды, и внешние обстоятельства. Вторые не всегда можно изменить, но их стоит учитывать в плане. Например, обновление уже готово, а релиз приходится отложить, пока его проверяет магазин приложений или подрядчик.
С внутренними причинами команда может работать сама. Вот что чаще всего увеличивает Time to Market:
📝 Долгие согласования. Чем больше людей должны одобрить решение, тем дольше задача ждёт следующего шага
📦 Слишком большой первый релиз. Команда пытается сразу выпустить весь запланированный функционал, хотя часть возможностей можно перенести на следующие версии
🔀 Многозадачность. Когда сотрудники постоянно переключаются между проектами, часть работы останавливается, а на возвращение в контекст уходит дополнительное время
🔗 Зависимости между этапами. Иногда работу нельзя продолжить, пока другая команда или специалист не закончат свою часть. Если таких зависимостей много, задержка на одном участке сдвигает весь запуск
💬 Неясные требования. Во время работы выясняются детали, которые не обсудили на старте, поэтому часть решений приходится пересматривать или переделывать
🧱 Технический долг. Накопленные проблемы в коде усложняют новые изменения: разработчикам приходится сначала разбираться со старыми ограничениями и только потом двигаться дальше
🚀 Задержки перед релизом. Продукт уже готов, но запуск приходится переносить, если к нему ещё не подготовились другие команды, например поддержка
Как сократить Time to Market без потери качества
Чем короче TTM, тем раньше продукт выходит на рынок. Клиенты быстрее получают ценность, а компания — выручку. При этом важно не жертвовать качеством.
Ниже разберём, что для этого можно изменить в работе команды 👇
Пересмотри рабочий процесс
Начни с того, как команда работает от старта до релиза. Посмотри, какие шаги можно убрать, где задачи чаще всего задерживаются и на каких этапах нагрузка распределена неравномерно. Всё это может растягивать Time to Market.
Ускорь согласования
Проверять и согласовывать материалы всё равно нужно, так как от этого зависит качество результата. Но команда часто тратит время не на саму проверку, а на то, чтобы найти актуальную версию, собрать правки и переслать файлы другим участникам. Оптимизировать этот процесс помогают сервисы для онлайн-согласований, в которых вся информация хранится в одном месте.
Автоматизируй ручные действия
Во многих процессах есть действия, которые команда повторяет из проекта в проект. Например, отправляет напоминания о дедлайнах или передаёт задачу следующему исполнителю. Часть таких действий можно автоматизировать.
Автоматизацию можно использовать и шире. Например, подключить ИИ или специальные инструменты, которые пишут текст, создают визуалы и готовят презентации.
Собери данные в одном месте
Важно, чтобы у каждого участника команды был доступ к нужной информации независимо от того, в каком городе и часовом поясе он работает. Поэтому храни задачи, файлы и договорённости в одном рабочем пространстве. Если без нескольких инструментов не обойтись, настрой между ними интеграции. Так не придётся переносить данные вручную.
Сохраняй гибкость
Команда должна уметь быстро пересматривать приоритеты и порядок работ, если меняется рынок или появляются новые требования. При этом важно, чтобы рабочие инструменты тоже позволяли легко переносить сроки, перераспределять задачи и доносить изменения до всех участников.
Как внедрить метрику TTM в работу команды
А вот сокращать TTM за счёт тестирования или качества кода не стоит. Если выпустить сырой продукт, попытка сэкономить может обернуться экстренными фиксами, ночными дежурствами и падением метрик и лояльности. В свою очередь создав лавину в командах технической поддержки или увеличив TTM следующих фич, потому что команда «тушит пожары». На рост технического долга имеет смысл идти только осознанно, понимая сроки его устранения. Любой продукт требует эффективной и понятной поддержки. Ускорить запуск — круто, как следствие красить кнопку неделю — не круто
Определи, для каких запусков считать TTM
Необязательно сразу отслеживать метрику для всей работы команды. Начни с одного типа запусков. Например, новых функций или MVP. Так будет проще собрать первые данные и сравнить результаты между собой.
Зафиксируй точки старта и финиша
До начала проекта реши вместе с командой, с какого момента пойдёт отсчёт и где он закончится. Например, старт — после одобрения идеи, финиш — когда функция стала доступна пользователям. Закрепи это правило и не меняй его от проекта к проекту.
Сразу запиши даты
Как только проект стартовал, сразу зафиксируй дату. То же самое сделай в день релиза. Запиши даты в таск-трекер или таблицу, чтобы после запуска не искать их в переписках. Если работа остановилась, отметь и эту паузу. Потом будет проще понять, из чего сложился итоговый TTM.
Посчитай TTM после релиза
После запуска найди разницу между датой старта и датой релиза. Первый результат пока не стоит оценивать как хороший или плохой. Он нужен, чтобы появилась точка отсчёта для следующих запусков.
Посмотри, где чаще всего теряется время
Когда данных станет больше, разбери запуски по этапам. Если несколько функций регулярно ждут тестирования по четыре дня, проблема, скорее всего, именно там. А если каждый раз задерживаются разные этапы, искать одно универсальное решение рано.
Полезно отдельно отмечать внешние причины задержек. Например, проверку в магазине приложений команда почти не контролирует, а долгую очередь на внутреннее ревью может сократить.
Меняй по одному процессу и снова измеряй
Выбери проблему, которая регулярно увеличивает срок запуска, и попробуй изменить процесс. Например, сократи число согласующих или введи лимит на задачи, которые одновременно ждут ревью.
После следующих запусков снова посчитай Time to Market и сравни результат. Так будет видно, действительно ли изменение помогло команде выпускать продукт быстрее.
Как измерять и улучшать TTM в Weeek
Чтобы было проще отслеживать Time to Market и находить причины задержек, лучше использовать таск-трекер. Покажем, как встроить эту метрику в рабочий процесс с помощью Weeek.
Создай проект для нового продукта
Перейди в сервис Задачи и открой раздел Все проекты. Над списком проектов нажми кнопку Добавить проект. В открывшемся окне введи название продукта и нажми Создать.
Создай Канбан-доску и настрой этапы запуска
Открой проект и выбери режим просмотра Доски. Ты сразу увидишь доску с тремя колонками по умолчанию: К работе, В работе и Готово. При необходимости переименуй этапы и добавь новые, чтобы они соответствовали рабочему процессу в твоей команде.
В нашем примере с сервисом онлайн-записи можно использовать такой путь задачи: Бэклог → К работе → В работе → На проверке → Готово.
Создай родительскую задачу и зафиксируй старт TTM
Добавь на доску родительскую задачу, которая будет объединять все работы. В описании кратко зафиксируй, что команда запускает и какой результат будет считать готовым. Здесь же назначь ответственного за проект и сразу же зафиксируй дату начала — с неё и пойдёт отсчёт Time to Market.
Добавь подзадачи
Разбей работу на шаги и добавь их в родительскую задачу. Для каждой задачи назначь исполнителя и срок. При необходимости добавь теги, чтобы обозначить этап работы.
Перемещай подзадачи по доске
По мере выполнения переноси карточки между колонками. Если работа остановилась, зафиксируй причину в комментарии. Например, «Ждём согласования» или «Нашли ошибку на тестировании». После релиза эта информация поможет восстановить ход работы и понять, где и почему появились задержки.
Зафиксируй дату релиза
Когда все обязательные подзадачи перейдут в Готово и сервис станет доступен пользователям, открой родительскую карточку и укажи дату окончания. Так у тебя появятся две точки для расчёта Time to Market.
Выгрузи данные и рассчитай TTM
Перейди в сервис Аналитика, открой раздел Экспорт → Задачи за период и выбери нужный проект. Выгрузи данные в формате XLSX или CSV. В файле найди родительскую задачу и посчитай разницу между датой старта и датой релиза. Это и будет Time to Market проекта.
Разбери задержки и скорректируй процесс
Если запуск занял больше времени, чем ожидалось, вернись к доске и посмотри, на каких этапах команда задерживала работу чаще всего. Проверь сроки выполнения, возвраты между этапами и комментарии.
Дальше подбери решение в зависимости от причины задержки. Например, если в работе одновременно скапливается слишком много карточек, можно настроить WIP-лимиты.
А если команда забывает передавать задачи дальше или пропускает сроки, настрой автоматизацию. Например, Weeek может заранее отправлять напоминания о дедлайне или менять исполнителя при переходе карточки на новый этап.
Частые вопросы о Time to Market
Осталось разобрать несколько вопросов, которые обычно появляются во время подсчётов 🧮
