Time to deal что это
Time to market: почему показатель важен в кризис и при чем тут облако
Что такое Time to market?
TTM — это время от начала разработки идеи до конечного запуска решения и его выхода на рынок. Например, для мобильного или корпоративного приложения Time to market начинается с момента, когда компания только решила его создать. И заканчивается, когда приложение публикуется в сторе или внедряется в компании.
Time to market — один из ключевых показателей для стартапов. Но он также важен для любых компаний, которые выпускают или внедряют новые решения.
Чем меньше значение TTM, тем лучше. Ведь если создание и запуск продукта затягиваются, компания может отстать от конкурентов и упустить выгоду. А инновационное решение — потерять свою инновационность. По данным Gartner, примерно 20% продуктов, выпущенных с задержкой, не достигают своих целей.
Почему этот показатель так важен в кризис?
Иногда эксперты называют срок выхода продукта на рынок термином Time to revenue, то есть временем до получения первой выручки. Это очень хорошо отражает ситуацию. Пока не пройдены все необходимые этапы подготовки и запуска, компания не начнет зарабатывать на новом решении.
В кризисные периоды у бизнеса, как правило, нет лишних ресурсов, чтобы вкладываться в проекты без быстрой отдачи. Тем более, что проект может «не полететь».
Но главное, сокращение Time to market позволяет компаниям серьезно экономить. Например, если речь идет о создании ИТ-продукта, зарплата ИТ-специалистов составляет сотни тысяч рублей в месяц. Уменьшив время выхода на рынок с нескольких месяцев до нескольких недель, эти ресурсы можно направить на другие цели.
Бизнес, прошедший через периоды экономической нестабильности, хорошо это понимает. После мирового кризиса 2008 года компания Amdocs отмечала рост внимания к TTM. Если в 2008-м его называли одним из важнейших бизнес-показателей только 58% поставщиков услуг и сервисов, то три года спустя цифра выросла до 70%. А сегодня сокращение TTM — одна из самых обсуждаемых тем в компаниях, которые выводят новые продукты на рынки.
Какие этапы включает в себя Time to market?
ТТМ включает несколько основных стадий, которые проходит команда при создании нового продукта или функции:
Чаще всего самый длительный этап — это разработка. К примеру, на создание приложения средней сложности может уйти от полугода.
Какие еще факторы влияют на Time to market?
Срок выхода на рынок прямо пропорционален сложности продукта и требованиям к его качеству. Многое также зависит от возможностей ИТ-подразделения компании, которая занимается разработкой. Однако даже в крупных корпорациях с собственным ИТ-департаментом релизы иногда готовятся намного дольше запланированного и содержат критические ошибки.
На TTM сильно влияет и выбранный подход к разработке: сроки создания решений полностью с нуля и из готовых компонентов отличаются в разы.
По подсчетам Gartner, только 55% продуктов запускается вовремя, а оставшиеся 45% релизов откладываются как минимум на месяц. «Продукт может не запускаться в запланированные сроки из-за нескольких факторов, включая отсутствие формализованных процессов запуска, задержки в разработке продукта (баги, ошибки, нестабильность функций), невыполнение требований клиентов, качество продукта или даже проблемы с поставками», — отмечают аналитики.
Как можно сократить Time to market?
Чтобы быстрее вывести продукт на рынок, компании часто готовят MVP (Minimum Viable Product — минимально жизнеспособный продукт, позволяющий получить обратную связь) с ограниченным функционалом и тестируют его на потребителях. Это позволяет выявить ошибки в продукте и оценить его востребованность.
Например, Uber начинался с упрощенного мобильного интерфейса, который использовали только основатели и их знакомые. Тарифные функции, платежи по кредиткам и отслеживание машин в реальном времени появились намного позже.
Однако после запуска MVP решение все равно приходится докручивать. Если делать это «по старинке», потребуется время.
Среди самых эффективных способов уменьшить TTM — использование облачных ИТ-ресурсов вместо физических серверов, отказ от архаичных подходов к разработке в пользу готовых решений на облачных платформах.
Каким образом облака помогают ускорить выход на рынок?
Облачные сервисы ускоряют процессы по двум основным направлениям.
Их предоставляют поставщики облачных услуг (облачные провайдеры) в рамках услуг PaaS — Platform as a Service. Эти сервисы специально спроектированы, чтобы ускорить и упростить процесс создания решений. Разработчики продукта получают готовую программную среду для написания, тестирования и размещения приложений вместе с набором дополнительных инструментов.
Так, на облачной платформе SberCloud.Advanced компании SberCloud интегрированы и инфраструктурные облачные услуги (IaaS), и платформенные PaaS-решения. Например, услуга развертывания приложений в облаке, бессерверные вычисления, облачные базы данных реального времени и другие продукты.
При этом облачные сервисы можно использовать как конструктор, собирая решение из готовых блоков. Это позволяет сначала без задержек создать MVP продукта, затем быстро протестировать его, внести изменения и выпустить на рынок готовую коммерческую версию.
Таким образом TTM решения сокращается в несколько раз. А сам процесс создания и запуска становится более прогнозируемым и надежным за счет автоматизированных систем работы с сервисами.
Как заявил президент, председатель правления Сбербанка Герман Греф, на встрече с инвесторами и акционерами (Investor Day 2020) переход на новую облачную цифровую платформу сократил Time-to-market новых продуктов «Сбера» в семь раз.
Каким компаниям и в каких проектах стоит использовать облако для сокращения TTM?
Облачные сервисы помогают выполнять почти любые задачи, связанные с созданием собственного ПО и кастомизированных корпоративных решений. Это может быть запуск чат-бота, дополнительный функционал для интернет-магазина, новый онлайн-сервис или приложение. То есть, речь не только о проектах ИТ-компаний и крупных «цифровых» корпораций. В облаке решения можно строить из уже готовых элементов, и для этого необязательно иметь глубокую экспертизу в ИТ.
В SberCloud отмечают, что их платформа позволяет создавать облачные продукты и сервисы в любых областях экономики, науки и образования — от мобильных приложений в ретейле до платформ дистанционного обучения для вузов и финтех-продуктов.
Наращивать использование облаков собирается большинство компаний, показало исследование Flexera: 59% предприятий ожидают, что облачные сервисы будут применяться шире, чем планировалось в доковидный период.
При этом эксперты отмечают рост интереса к PaaS и, в частности, контейнерным технологиям. Контейнеры — это автономные единицы ПО, в которых есть все необходимое для работы приложений — код, среда запуска, библиотеки и настройки. Компании используют их, чтобы быстрее разворачивать приложения и масштабировать процессы, указывают во Flexera.
Как это работает с ИТ-стартапом?
Возьмем один из самых распространенных примеров — технологический стартап, который активно работает с различными данными. Допустим, в стартапе активно используется ИИ. В этом случае ему понадобится облачная инфраструктура, желательно автомасштабируемая под клиентский трафик, управляемая база данных, сервис развертывания и управления контейнерами приложениями на основе Kubernetes, сервис аналитики данных, сервис мониторинга и управления приложениями и инфраструктурой и ряд других облачных услуг.
Почему облачных? Совершенно понятно, что cамостоятельная покупка оборудования, инсталляция и настройка взаимодействия всех этих приложений никак не вписывается в бизнес-модель стартапа с его ограниченным количеством финансовых, трудовых и временных ресурсов.
Единственный вариант успешно запустить такой стартап, это использовать готовые инфраструктурные (IaaS) и платформенные облачные сервисы (PaaS). Идеально, если они будут еще интегрированы между собой.
Поставщики облачных услуг уже предлагают такие варианты. Например, на платформе SberCloud.Advanced можно получить сразу и IaaS сервисы, такие как Elastic Cloud Server — легко конфигурируемый и масштабируемый виртуальный сервер с возможностью автомасшатбирования, а также все необходимые для быстрой реализации идеи платформенные сервисы (PaaS).
Что важно в такой бизнес-модели. Размер оплаты облачных сервисов зависит исключительно от количества клиентов стартапа. Клиентов мало — потребление небольшое, затраты на облако минимальны. Количество клиентов и размер выручки растут — соответственно есть возможность спокойно масштабировать бизнес и увеличивать потребление облачных услуг.
Мы уже используем облачные сервисы. Как еще можно сократить TTM?
Основной совет — работать над MVP, избавляться от всего лишнего и концентрироваться на ценности для клиента и компании. Также стоит обратить внимание на концепцию Lean startup. Обобщайте и проверяйте гипотезы и, главное, постарайтесь как можно раньше получить обратную связь от потребителей продукта. Как показывает опыт, даже самое длительное и детальное тестирование не заменит мнения живого пользователя.
Time to deal что это
Один наш клиент постоянно не успевал вовремя выпускать релизы (обновления и новый функционал программного обеспечения) с клиентскими скидками. Его специалисты работали по 14–16 часов в выходные и ненавидели «черные пятницы» и «киберпонедельники». Качество выпускаемого в таком режиме программного обеспечения оставляло желать лучшего, работу в выходные приходилось оплачивать по двойному тарифу, продуктивность падала, сотрудники уставали и увольнялись, покупатели, натыкаясь на критические ошибки при совершении покупок, злились и уходили на сайты других компаний.
При этом ФОТ составлял 13,5 млн рублей в месяц, выпуск «срочного» релиза занимал 2 месяца, релиз в среднем содержал 1–3 блокирующих и до 10 критичных проблем системы, что приводило к репутационным и финансовым потерям.
В попытке разобраться, в чём же причина такого долгого и проблемного релизного цикла, заказчик обратился к нам. Выполнив аудит, мы обнаружили стандартную историю, в которой каждый наверняка найдет знакомые детали: много ручного труда (начиная со сборок и наката релиза на тестовую среду и заканчивая подготовкой тестовых данных); отсутствие автоматизированного тестирования; низкая квалификация сотрудников; наличие полной экспертизы лишь у одного человека, который руководствуется исключительно своими приоритетами (узкое горлышко); нежелание что-то менять; пропасть между ИТ и бизнесом в попытке понять, почему всё так долго и так плохо.
В первую очередь мы занялись основными процессами: выделили самые критичные бизнес-сценарии, автоматизировали их проверку; реализовали автосборку; настроили автораскатку на стенды разработки, тестирования и на продуктив; автоматизировали подготовку тестовых данных; разбили проверки на важные и менее важные, важные начали автоматизировать; команда ручного тестирования получила список самых важных проверок при нехватке времени. К окончанию проекта мы имели 92% автоматизированных проверок из всего объема и смогли сократить команду тестирования на 30%. Разработчики же, освободившись от необходимости тратить время на ручные сборки и раскатки, начали выполнять больший объем работы за тот же период.
Сотрудники счастливы и проводят выходные с семьей, никто не увольняется, бизнес получает свои изменения вовремя и с достойным качеством, у покупателей нет проблем при выборе и покупке товаров на сайте.
Наряду с этим, время вывода среднего релиза сократилось до 2 недель при 30-процентной экономии ФОТ и выводе качества среднего релиза на уровень 0 блокеров, 0–5 критичных багов! Проект обошелся заказчику в один месячный ФОТ текущей ИТ-команды, занял 3,5 месяца и окупился примерно через 2 месяца после внедрения.
Одна крупная компания потеряла 200 млн рублей, выпустив плохо протестированный релиз в продуктив. Причиной этого стала попытка сэкономить на персонале (ФОТ, операционные затраты): тестировщик-стажер халатно отнесся к выполнению тест-кейса — пометил интеграционный кейс как пройденный, ничего на самом деле не проверив. «Честное» ручное прохождение теста заняло бы 15 минут с проверкой настроек системы и логов. Автоматизированный тест занял бы менее 1 минуты плюс пару минут на выяснение, в чём проблема. Цифры и удивляют, и убивают одновременно.
Всегда существует человеческий фактор: люди ошибаются, не высыпаются, ссорятся с женами/мужьями, просто не в настроении, наконец. Поэтому, автоматизируя процессы, мы убиваем двух зайцев: ускоряем процесс и обеспечиваем качество, исключая тот самый человеческий фактор. Автоматизация одного сквозного сценария (с проверкой интеграционных значений) занимает от 2 до 16 часов (в зависимости от сложности). Поэтому решительно непонятно, зачем многомиллиардная компания сэкономила на мелочи, получив потом такие убытки.
Добавим чуть-чуть технических деталей. Чем раньше найдена ошибка в программном обеспечении, тем дешевле обойдется работодателю ее исправление, так как:
1. Разработчик всё еще работает над тем же куском программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и правку он делает буквально «на лету».
2. Другие разработчики не вносят изменения в этот содержащий ошибки программный код.
3. Ветки кода не успели размножиться на последующие релизы, и не нужно будет исправлять один и тот же баг сразу в нескольких местах, учитывая версионность кода.
4. Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.
Маленький пример такой экономии для среднеразвитой системы, изменения в которую вносятся 1 раз в 2 месяца, представлен в таблице.
Умножьте эти цифры на ваш текущий ФОТ ИТ-команды и время вывода изменений в продуктив, и вы узнаете ваши потери.
В век информационных технологий трудно переоценить важность скорости, с которой компании могут внедрять изменения. На рынке всегда найдется пара конкурентов, которые сделают это быстрее или лучше.
Какой путь выберет компания и знает ли она о текущих возможностях?
Можно идти пешком. Можно воспользоваться транспортным средством: велосипедом, машиной, — но без учета пробок на дороге такое движение может оказаться значительно продолжительнее по сравнению с движением пешехода.
Конечно, вопрос о том, как добраться до цели в нужные сроки, правильно выбирая средства и обеспечивая оптимальные затраты, должны решать профессионалы, ведь иногда промедление смерти подобно.
У любой (не только из сферы ИТ) компании это может быть выпуск нового продукта для сохранения конкурентного преимущества при участии в тендере, если речь идет о B2B, или компания просто решила сделать продукт более привлекательным для существующих или новых клиентов в случае B2C.
В конце концов, это могут быть банальное обеспечение соблюдения сроков для устранения замечаний регулятора или доработка решения к какой-то фиксированной дате в связи с введением в действие нового законопроекта. В таких случаях, если компания не успела внести изменения в срок, приостанавливается действие ее лицензии, у нее нет деятельности, нет прибыли, она теряет клиентов.
Важно понимать, что все инструменты, методологии и подходы можно применять и по отдельности — они однозначно будут давать эффект и уменьшать время вывода продукта на рынок. Но наибольший эффект мы можем получить, только применяя все подходы сразу, — тогда сокращение Time to Market (T2M) может стать максимально большим за счет эффективности каждого из процессов.
Для среднего релиза (3 командо-месяца) картинка будет примерно такая: автоматизировали сборку — сэкономили 5% ФОТ и T2M, автоматизировали подготовку тестовых данных — сократили 10% ФОТ и T2M, автоматизировали smoke test — еще 5% ФОТ и T2M, регресс — 10–15%. Добавьте в этот коктейль гибкие методологии разработки, и получите свои законные 40–50% экономии ФОТ и времени вывода релиза.
При этом для системы средней сложности (и ее интеграционных взаимодействий) сам проект занимает не более 4 месяцев, а окупается уже за 2–3 месяца.
Когда непрофильные компании берутся за разработку ПО, они заново изобретают велосипед, не понимая, как улучшить процесс и сделать его по-настоящему эффективным. Как большинство не ИТ-компаний работает сейчас (см. рис. 1).
А вот как должно быть (см. рис. 2).
Правило простое: любое повторяющееся из раза в раз действие должно быть автоматизировано и настроено на регулярный запуск (по расписанию или событию), что позволяет сократить и время, и количество людей, поддерживающих данную рутину.
Кроме того, мы исключаем человеческий фактор: скрипт выполняет одно и то же действие из раза в раз, не устает, у него «не замыливается глаз», он не допускает ошибок, работает по выходным и по ночам — и даже не просит оплаты сверхурочных.
И да, в скором времени нас всех заменят роботы.
В завершение хочется сказать, что даже в одной компании может быть несколько десятков систем, находящихся на разном уровне развития в части автоматизации процессов.
Текущая картина в системе определяется при помощи ключевых точек в процессе разработки и тестирования, и мы легко можем сказать, находится ли система на нулевом уровне развития или она уже на стадии зрелых процессов и относится к продвинутому уровню.
Переход с начальных уровней на высокие, безусловно, дает максимальный и зримый эффект. Для того чтобы понять, на каком уровне развития (зрелости) находится та или иная система, в нашей компании используется четкая методика оценки, из которой легко вычленить цели и результаты, которых мы хотим добиться, автоматизируя процессы в системе. Так заказчик проверяет результаты внедренных изменений, опираясь на четкие KPI. Так он получает ясное представление о тех изменениях, которые будут внесены в процесс.
В настоящее время многие компании-интеграторы начинают предлагать свои услуги в области автоматизации процесса разработки и тестирования. Уже не такими новыми выглядят термины DevOps, CI/CD, pipeline, agile — даже для не ИТ-управленцев. О себе в контексте данной темы мы можем скромно сказать, что съели на этом собаку, кошку и даже маленького слона.
Материал подготовлен Ольгой Шишелиной, руководителем отдела тестирования Дирекции по разработке и внедрению программного обеспечения компании «Инфосистемы Джет»
Проблема time-to-market в екоме
Поговорим об одной из ключевых концепций электронной коммерции, о time-to-market. TTM — это время, которое проходит с момента возникновения намерения реализовать новую функцию до ее выпуска на реальных пользователей.
В этой статье под новой функцией мы понимаем любое изменение клиентского опыта: запуск новой товарной категории, дополнительный вид оплаты, более быстрая доставка, а также более масштабные вещи вроде доставки из оффлайн магазинов.
Способность быстро выпускать новые функции — ключевой фактор конкурентоспособности в екоме.
Ритейл меняется примерно с той же скоростью, что и смартфоны: вчерашние флагманы уже через год становятся рядовыми устройствами, а через 3 — безнадежно устаревают. Давайте посмотрим, как именно это происходит в современном екоме.
Еком развивается в духе эры Customer Capitalism, при котором фокус на удовлетворении ожиданий клиента — лучшая бизнес-стратегия. В интернете покупатель не имеет физической привязки к продавцу. Клиент может, не затратив ни малейших усилий, перейти к конкуренту, если текущая компания перестает соответствовать его ожиданиям.
С клиентскими ожиданиями работать не так просто. С ними есть 2 проблемы:
Лучшие еком компании удовлетворяют ожидания покупателя и создают превосходящий эти ожидания опыт.
То есть важно уметь не только быстро внедрять общеизвестные рынку функции, но и через эксперименты находить новые фишки, которые приведут клиента в восторг. При этом важно помнить, что превосходящий опыт имеет значение только при условии удовлетворения базовых ожиданий. Вот как это устроено с точки зрения впечатлений клиента.
Возможности, которые еком дает покупателю, удобно классифицировать по модели Кано и разбить их на группы: Must have, Would be nice, Killer feature (модель Кано предусматривает еще 2 группы, но об этом поговорим в отдельной статье).
Базовые ожидания, которые можно выявить с помощью исследований, укладываются в первые две категории. Функции, способные удивить клиента и выдвинуть компанию в лидеры, принадлежат в основном к группе Killer feature. Такие функции можно нащупать с помощью быстрых экспериментов на реальных пользователях.
В екоме функции очень быстро мигрируют из Killer feature в Would be nice и далее в Must have. Чтобы оставаться конкурентоспособным, нужно иметь низкий time-to-market внедрения новых возможностей и расширения товарного предложения.
Еще недавно возможность заказать неограниченное количество одежды для примерки было killer feature Wildberries. Но сегодня то же самое есть у Ламоды и некоторых других продавцов одежды. Функция уже переехала в категорию Would be nice и стремится стать Must have.
Причины большого ТТМ могут быть связаны:
Первые два случая мы рассмотрели в другой статье, а здесь упомянем максимально кратко: неспособность быстро принимать решение и чрезмерное анализирование. А вот этап реализации и эксплуатации рассмотрим подробнее.
Новые пользовательские функции в екоме появляются, когда вновь разработанная функциональность (или целые решения) отгружена на боевые системы, залиты актуальные данные и запущены операции. Системы разрабатывают либо внутреннее IT, либо подрядчики, либо гибридные команды, а значит источник проблем с ТТМ будем искать в деятельности этих ребят.
Для любой большой компании типична ситуация, когда внутренняя разработка занята на годы вперед. Нет единой причины, почему так происходит. Стоит упомянуть наиболее часто встречающиеся:
Сложности с внутренней командой подталкивают корпоративный еком к работе с внешними подрядчиками. В результате бизнес рискует получить новое узкое горлышко в виде скорости и компетенций сторонней компании. Особенно часто случаются такие ситуации:
Распространено заблуждение, что выбор правильного IT-решения — главная проблема разработки в екоме. А на самом деле в екоме не существует универсального ПО, которое само по себе обеспечит бизнесу продажи.
При этом позиционирование вендоров строится на том, что их система — лучшая и ее внедрение автоматически поднимает продажи.
Фокус должен быть не на решениях и технологиях, а на быстром запуске новых процессов. И не столь важно на каких решениях и технологиях.
Наш опыт показывает, что средний срок жизни произвольной системы в екоме — 3 года. Стоит ли тратить слишком много времени и денег на выбор и внедрение монструозных систем? Процессы в екоме разнообразны и многочисленны, но при этом довольно просты. Они не требуют сложных систем. Они требуют систем, которые работают прямо сейчас и способны быстро развиваться.
Выигрышная стратегия — иметь набор сервисов, каждый из которых легко заменить более совершенным аналогом без перестройки всего IT.
Развивать еком под требования целевой архитектуры непродуктивно. Системы должны эволюционировать под требования бизнеса, задача которого удовлетворять клиентов и зарабатывать.
Готовность систем не всегда позволяет запустить новые функции на реальных пользователей. Даже в екоме часто требуется много работы в офлайне, чтобы новые процессы по-настоящему заработали. Иногда на это уходят годы.
Ритейлеры алкоголя давно готовятся продавать в онлайне из-за слухов о легализации дистанционной торговли. В ожидании этого некоторые компании запустили онлайн продажи на полулегальных схемах.
Чаще всего на этапе эксплуатации ТТМ растет по следующим причинам:
✅ Раскатывать новые функции не на всю компанию сразу, а на отдельные подразделения.
✅ Начинать обучение сразу после окончания проектирования, а не ждать полной технический реализации новых функций.
✅ Сформировать команду внедрения, которая будет ездить по подразделениям и рассказывать, как пользоваться новыми функциями.
Основной проблемой time-to-market является то, что он часто находится вне зоны внимания людей, занимающихся екомом. Вместо этого команды сосредоточены на вещах, которые совершенно не интересуют покупателей, вроде технологического стэка или методологии гибкой разработки. Но если вы строите конкурентоспособный еком, вам нужно сосредоточиться на способности быстро удовлетворять новые ожидания клиентов и реагировать на изменения рынка (🦠).