Ускорение 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, в ходе которого увеличение частоты выхода релизов и повышение качества версий помогло компании снизить затраты на десятки процентов. При этом возможность возникновения значимых ошибок в работе своего интернет-магазина была полностью исключена.

{ "author_name": "Владимир Молодых", "author_type": "self", "tags": [], "comments": 16, "likes": 22, "favorites": 14, "is_advertisement": false, "subsite_label": "dev", "id": 84456, "is_wide": true, "is_ugc": true, "date": "Tue, 24 Sep 2019 17:51:29 +0300", "is_special": false }
0
16 комментариев
Популярные
По порядку
Написать комментарий...
3

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

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

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

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

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

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

Ответить
1

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

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

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

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

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

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

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

Ответить
0

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

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

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

Если не секрет, как много лет опыта в сфере тестирования у вас, что вы так очень уверенно высказываетесь о легкости автоматизации сценария одновременно с разработкой компонента?

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

Но! Важно тут не вырывать один кусочек из контекста

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

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

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

Я, если честно, не совсем понимаю зачем вы написали такой длиный и отвлеченный ответ на простой, по сути, мессадж - автотестирование не будет работать так, как было описано в вышеупомянутой цитате.

Разработчик написал компонент, прогнал тесты и через секунду понял, что все хорошо/плохо без стадии тестирования - так не бывает. А если так попытаться сделать, то это будет или дорого или assert(true).

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

Ответить
2

@Что Тут ,  с таким подходом все этапы - уже этап раннего тестирования:) и это именно то, чего хочется достичь в нормальном процессе разработки. я в тестировании более 15ти лет, и с тезисами Александра согласна. Впечатление, что спор больше ради спора. Статью-то прочитали?

Ответить
1

@Что тут, правда в твоих словах есть, но и другие её версии тоже имеют место быть :) Важно применять комплекс мер. Sure thing, только автотесты - не панацея.

Ответить
2

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

Ответить
1

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

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

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

Ответить
3

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

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

Ответить
0

коэффициент полезности разный.

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

Ответить
0

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

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

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

Ответить
2

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

Ответить
0

На графике в статье написано "График окупаемости инвестиций в автоматизацию" - в нём конкретные числа и сроки. Вот по нему и возник вопрос. Раз так точно можно прикинуть окупаемость некой абстрактной автоматизации, то более конкретная ситуация позволит более конкретные числа. Выходит, что нет.

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

А насчёт того, что автоматизация это не только автотесты, совершенно верно замечено, есть такие данные, подготовка которых раз в 10 сложнее чем сами тесты. И это всё надо еще уметь делать. И ничего не поломать при этом.

Ответить
2

Почему же на мороз?) Логичнее выпускать больше фич за то же время. Или столько же фич за более короткий срок. 

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

Ответить
1

Потому, что фичи надо выпускать не как можно быстрее, а так, чтобы прибыль от них росла. В этом смысле time2market это не цель, а просто одна из метрик, причём не самая ключевая. Малый t2m не гарантирует высокой прибыли. 

А насчёт "на мороз" - это первое что хотят собственники бизнеса от автоматизации, сокращения ФОТ. Сэкономленная копеечка всё равно что заработанная.

Ответить
2

Согласна со всем, кроме мороза:) спрос на аналитиков-разрабов-тестировщиков такой, что все компании живут в режиме постоянного "недобора" и поиска. Смысл избавляться от ценного ресурса? Хотя конечно собственники именно так и думают:) о том, как сократить штат ИТ-бездельников и порезать на фиг все эти непонятные девопсы и автоматизации... а 12 шапок из одной шкурки можешь?:))

Ответить
0

Сообщение удалено

Ответить

Комментарии

null