Ускорение 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 — это фактически приговор. На реальных проектах наши ребята из отдела разработки и тестирования постоянно сталкиваются со следующими проблемами заказчиков:

  • несоответствие итогового ИТ-продукта запросам заказчика по функционалу/качеству;
  • несоблюдение сроков вывода на продуктив, нарушение SLA;

  • недостаточно современные подходы и инструменты управления качеством;

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

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

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

  1. разработчики решают поставленную перед ними задачу;
  2. тестировщики проверяют новые функции и дают фидбэк разработчикам для исправления различных недочетов;
  3. по завершении процесса новинку начинают предлагать пользователям, которые, в свою очередь, также могут обнаружить какие-то проблемы (но в этом случае закрывать “дыры” приходится в экстренном режиме).

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

Долго

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

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

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

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

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

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

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

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

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

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

Дорого

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

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

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

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

Неидеально

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

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

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

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

Автоматизация необходима

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

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

График окупаемости инвестиций в автоматизацию
График окупаемости инвестиций в автоматизацию

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

  • автоматизация сборки ПО (3-7% ФОТ);
  • автоматизация подготовки тестовых данных (9-11% ФОТ);
  • автоматизация smoke-тестов (4-6% ФОТ);
  • автоматизация регрессионного тестирования (10-15% ФОТ);
  • внедрение гибких методологий разработки (4-6% ФОТ).

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

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

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

2222
16 комментариев

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

Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?

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

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

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

Так что, даже если "секунды" были гиперболизацией, то все равно, до фазы тестирования вам(нам/всем) ничего не светит.

3
Ответить

Мммм, ну лаааадноооо... )

>>Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?<<<<

Ну так то разработать могут как разработчики, так и тестировщики (в некоторых случаях и мануальные) ровно в тот момент, когда разработчик приступает к написанию кода (т.е. в параллели пишется и сам код, и автотесты на него) - ведь тут не обзательно речь только о Unit тестах. Никто же не говорил, что это обязательно UI тесты. Для API автоматизация ложится легко, поддерживается просто, а окупается очень быстро. И да - применимо далеко не всегда, да и подсчет ROI перед автоматизацией никто не отменял. Но! Важно тут не вырывать один кусочек из контекста. К сокращению времени, а значит, и затрат, приводит именно комплекс мер, а не просто автоматизированные тесты (речь в статье шла и об авторазвертывании, и об автоматической подготовке данных, и о гибких методологиях), - там, где он целесообразен. Принцип необходимости и достаточности никто не отменял.

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

В любом случае, и тестировщик, и разработчик опираются на спецификацию. Да, в ней тоже бывают ошибки - и они выявляются на этапе тестирования документации - т.е. также заранее, а не после того, как код уже был разработан и пришел в тестирование. Как простой пример - вот есть xsd. Никто не мешает нам сгенерить из нее xml (или проверить генерируемую нашей системой xml - в случае, когда наша система - инициатор вызова) и проверить обработку этой xlm в нашем api на соответствие спецификации еще на этапе кодирования. Все это просто и заранее можно автоматизировать. 

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

Утверждения в большинстве своем верны для UI тестов. Поэтому - подход с умом.

2
Ответить

Если у крупной компании нет автоматизированного тестирования, а только ручное - что-то там не так с руководством. Автоматизация тестов - не панацея, а лишь способ срезать косты на ручное тестирование, умнее и грамотнее разработчиков она не делает, все равно будут ошибки в релизах. Чтобы уменьшить Time-To-Market надо либо оптимизировать процессы, либо нанять более квалифицированных людей, либо резать количество новых фич.

2
Ответить

Проблема больших компаний в первую очередь в чрезмерном количестве людей в подразделениях. Есть эффективное количество людей на проект, это крайне емкое количество (на минуточку рассчитывается индивидуально, но как правило 3-7 человек). Как ни парадоксально, но если добавить людей, быстрее продукт не будет готов. Напротив, сроки увеличатся.

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

ИМХО. Статья ради пиара. 

1
Ответить

Все в этой жизни либо ради пиара, либо ради лени :)

Большие = неповоротливые, маленькие = юркие - это аксиома еще из 6 класса биологии, согласен. Автоматизация хоть как-то позволяет играть большим если не наравне, то +- рядом с мелкими ребятами ))

3
Ответить

Что-то суммы на графике смешные. Вопрос к автору.

Дана некая ИС, не очень большая, примерно 50 человеко-лет, возрастом 4 года. Обслуживается 3 командами спецов, в сумме - 24 человека. Легаси, спагетти, куча фреймворков - всё там есть, документация сделана "для галочки", некоторые компоненты совсем не документированы. Автотестов считайте, что нет, усё ручками.

Вопрос: сколько времени и денег (верхние и нижние границы) понадобится на то, чтобы покрыть автотестами хотя бы 10-15% "золотых" сценариев продукта?

Ответить

@Вася Бездомный а в чем смех? Про задачку - хотите оценку с точностью - нужна нормальная постановка задачи - с описанием технологий, интерфейсов и проч., все остальное будет так же примерно, как с цифрами на графике, куча дополнительных вводных, которые влияют на ответ. Каждая система уникальна и находится на разном уровне зрелости. У какой-то системы внедрение автотестов не даст большого эффекта, потому что например часть работ уже была автоматизирована. А у системы на подобии той, что в примере, как раз должен быть весьма ощутимый эффект. Опять же почему-то при упоминании автоматизации все видят только автотесты. А речь-то шла и об автоматизации сборки, и подготовки данных - эта история про автоматизацию/совершенствование самих процессов разработки и тестирования в целом, а не про автотесты

2
Ответить