Ускорение Time to Market: реально ли выпускать обновления в 3-5 раз быстрее?

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

Крупные банки, страховые, ритейл и даже промышленность последние 5-6 лет говорят о себе, как об ИТ-компаниях. Но если для fin-, ed-, food-стартапов приставка tech и скорость работы — это их свойства с рождения, то для крупного бизнеса — 4 месяца на выпуск релиза с блокирующими и критическими ошибками на продуктиве — это печальная реальность, с которой компании ведут неравный бой.

По данным Capgemini 25%-40% бюджета в общепринятой мировой практике разработки ПО тратится на Quality Assurance. Это говорит о том, что отсутствие автоматизации является распространенной проблемой, и в результате слишком много ресурсов тратится на ручное тестирование. Больше всего пугает в этом контексте то, что ручное тестирование не решает проблемы качества и скорости разработки, и по мере роста сложности проектов и увеличения объема кода, отсутствие автоматизации все равно приводит к потерям.

У меня сложилось впечатление, что отставание крупных компаний в вопросах ускорения Time2Market объясняется тем, что руководители либо не слишком близко знакомы с ИТ, либо недостаточно погружены в существующие процессы. На некоторых проектах только после длинной серии итераций и общения с ИТ-специалистами (как своими, так и на стороне партнера/подрядчика) у руководства формируется понимание, что своевременный выход релизов с нужным качеством приводит к росту основных показателей бизнеса.

В самых разных отраслях — от розницы и банковского дела до промышленности и добычи полезных ископаемых — финансовые показатели стали напрямую зависеть от того, насколько быстро и качественно была внедрена очередная система. Поэтому все чаще топы VP или C-level уровней откладывают в сторону стратегии и подсчеты P&L и EBITDA и стараются научиться говорить с ИТ на одном языке во имя повышения скорости изменений.

Мы в "Инфосистемы Джет" практически на каждом нашем проекте, связанном с внедрением инструментов и методологий CI/CD/DevOps, сталкиваемся с фактом, что самая трудоемкая часть — не автоматизация, которую умеют делать почти все. Сложнее всего оказывается изменить образ мышления ИТ и бизнеса, помочь им обрести точки контакта и научить говорить на языке друг друга.

Чтобы добиться этого, нам приходится сначала расположить разные отделы к себе как к подрядчику, а далее — подтолкнуть к правильным действиям и научить задавать нужные вопросы. Мы стремимся сделать все возможное, чтобы внутри компании заказчика развернулся и заработал конвейер — пайплайн доставки софта на продуктив.

Без ошибок. Без перерасхода трудозатрат. Без потерь денег. Быстрее конкурентов.

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

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

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

Несмотря на то, что во многих организациях считают этот процесс очень простым, именно недостаточная оптимизация вывода ПО на продуктив значительно снижает эффективность работы отдела, приводя к росту затрат и снижению удовлетворенности клиентов. Ведь разработка и тестирование без выстроенных процессов автоматизации — это:

Долго

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

Разработчик: “Я закончил, нужно разворачивать стенд и тестировать”.

Инженер: “Сейчас уже нет времени, завтра запустим”.

Тестировщик: “Сегодня все уже забито, проведём тесты в ближайшие дни”.

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

Разработчик: “Я уже другую задачу решаю. Как закончу, вернусь, попробую вспомнить, что там было”.

Инженер: “Ну что ж такое, опять стенд готовить”.

Тестировщик: “А, это я уже тестировал, теперь проверю только найденные баги”.

В итоге — критическая ошибка — в заказах теряется информация из поля “телефон клиента”. Приходится срочно откатываться, вносить изменения, выпускать релиз снова.

На реальных проектах видно, что за счет автоматизации хотя бы только этого этапа компания может уменьшить ФОТ проекта до 10%. Если же автоматизировать подготовку данных для последующих тестов, дополнительная экономия может составить еще около 12%. Инвестиции в подобные оптимизации обычно окупаются в срок не более полугода.

Дорого

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

Проблема заключается в том, что при обнаружении ошибки уже после релиза, компания вынуждена:

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

Неидеально

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

Например, как сообщали Ведомости, интернет-магазин «Связной» из-за сбоя в программном обеспечении продавал смартфоны по заниженным ценам. Клиенты могли заказать iPhone 8 с объемом памяти 64 Гб по цене около 6000 рублей, хотя обычно его цена не ниже 35 000. Более старые модели продавались по 49 рублей. Поскольку речь идет про федеральную сеть и популярный интернет-магазин, такой “распродажей” всего за 15 минут смогли воспользоваться 854 человека, а при сумме “скидки” в десятки тысяч рублей ущерб составил десятки миллионов.

Отсутствие выстроенных процессов приводит к срыву дедлайнов. А это означает, что на финальный этап, подразумевающий тестирование, остается минимальное количество времени. Даже если сотрудники работают без выходных и сидят над проектами ночью накануне выпуска релиза, они просто не смогут гарантировать его 100% работоспособность, если все предыдущие сроки были сорваны.

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

Поэтому без внедрения средств автоматизации любое бизнес-направление начнет терять прибыль и сталкиваться с растущими затратами. Это связано с ростом общих объемов разработки, увеличению количества строк кода и взаимосвязанных программных продуктов. Из-за высокой нагрузки разработчики начинают чаще допускать ошибки, а отсутствие консолидированного подхода к выпуску обновлений требует большого объема трудозатрат в области тестирования и исправления ПО.

Наше подразделение тестирования собрало интересную статистику. Например, в системе средней сложности без автоматизации процессов, где трудится 7-10 разработчиков, 1 релиз выпускается за 3-5 месяцев, причем в нем допускается до 100 критичных и важных ошибок! А цена их исправления в продуктиве оказывается несоразмерно выше. Эту проблему подтверждает и мировая практика.

Внедрение автоматизированных тестов и унификация процессов тоже не сразу приводит к экономии. Например, для среднестатистического релиза, на который обычно уходит три месяца работы команды, экономия за счет уменьшения фонда оплаты труда (ФОТ) складывается из таких компонентов как:

При этом проект автоматизации и оптимизации системы средней сложности (и ее интеграционных взаимодействий) занимает не более 4 месяцев, а окупается уже за 2-3 месяца только на экономии ФОТ. На графике четко видно, как затраты возрастают на период старта проекта по построению автоматизации и организации процессов CI/CD, но уже с 5 месяца они оказываются на 25% меньше, продолжая снижаться со временем. То есть с 8 месяца изменения в процессах начинают "приносить прибыль", не говоря уже о том, что мы добиваемся сокращения Time to Market в 1,5-2 раза.

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

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