Сайт находится в состоянии доработки. Извиняемся за неудобства.

x
© 1995-2020 Компания «Инфосистемы Джет»
№1-2 (293) / 2019
Программное обеспечение

Снижение показателя Time-to-Market

Автор
Ольга Шишелина Директор департамента контроля качества Центра программных решений компании "Инфосистемы Джет"

1114

0

12

0

3

Как быстро и безопасно вносить изменения в ПО готового продукта

 

 

Или быстрый, или мертвый. Триллер с красивым концом из реальной жизни

 

Один наш клиент постоянно не успевал вовремя выпускать релизы с клиентскими скидками. Его специалисты работали по 14–16 часов в выходные и ненавидели «черные пятницы» и «киберпонедельники». Качество выпускаемого в таком режиме программного обеспечения оставляло желать лучшего, работу в выходные приходилось оплачивать по двойному тарифу, продуктивность падала, сотрудники уставали и увольнялись, покупатели, натыкаясь на критические ошибки при совершении покупок, злились и уходили на сайты других компаний. 

 

При этом ФОТ составлял 13 500 000 руб. в месяц, выпуск «срочного» релиза занимал 2 месяца, релиз в среднем содержал 1–3 блокирующих и до 10 критичных проблем системы, что приводило к репутационным и финансовым потерям.

 

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

То, что доктор прописал…

В первую очередь мы занялись основными процессами: выделили самые критичные бизнес-сценарии, автоматизировали их проверку; реализовали автосборку; настроили автораскатку на стенды разработки, тестирования и на продуктив; автоматизировали подготовку тестовых данных; разбили проверки на важные и менее важные, важные начали автоматизировать; команда ручного тестирования получила список самых важных проверок при нехватке времени. К окончанию проекта мы имели 92% автоматизированных проверок из всего объема и смогли сократить команду тестирования на 30%. Разработчики же, освободившись от необходимости тратить время на ручные сборки и раскатки, начали выполнять больший объем работы за тот же период. 

 

Happy end

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

 

Наряду с этим время вывода среднего релиза сократилось до 2 недель при 30-процентной экономии ФОТ и выводе качества среднего релиза на уровень 0 блокеров, 0–5 критичных багов! Проект обошелся заказчику в один месячный ФОТ текущей ИТ-команды, занял 3,5 месяца и окупился примерно через 2 месяца после внедрения.

Фильм ужасов со страшным концом

 

Одна крупная компания потеряла 200 млн рублей, выпустив плохо оттестированнный релиз в продуктив. Причиной этого стала попытка сэкономить на персонале (ФОТ, операционные затраты): тестировщик-стажер халатно отнесся к выполнению тест-кейса — пометил интеграционный кейс как пройденный, ничего на самом деле не проверив. «Честное» ручное прохождение теста заняло бы 15 минут с проверкой настроек системы и логов. Автоматизированный тест занял бы менее 1 минуты плюс пару минут на выяснение, в чем проблема. Цифры и удивляют, и убивают одновременно.

 

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

 

Маленький пример такой экономии для среднеразвитой системы, изменения в которую вносятся 1 раз в 2 месяца, представлен в таблице.

 

Умножьте эти цифры на ваш текущий ФОТ ИТ-команды и время вывода изменений в продуктив — и вы узнаете ваши текущие потери.

 

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

Таблица 1. Зависимость стоимости исправления ошибки в ПО от оперативности ее обнаружения
  Критичная ошибка найдена в 1-й день кодирования На 7-й день На 30-й день Через 2 месяца
Влияние на ФОТ 0% или незначительное 5,0% 17,0% 40–60%
Влияние на время внедрения изменений 0% или незначительное 6,3% 19,0% 40–60%

Добавим чуть-чуть технических деталей. Чем раньше найдена ошибка в ПО, тем дешевле обойдется работодателю ее исправление, так как:

 

  1. Разработчик все еще работает над тем же куском программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и правку он делает буквально «на лету».

  2. Другие разработчики не вносят изменения в этот содержащий ошибки программный код.

  3. Ветки кода не успели размножиться на последующие релизы, и не нужно будет исправлять один и тот же баг сразу в нескольких местах, учитывая версионность кода.

  4. Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.

Какой путь выберет компания и знает ли она о текущих возможностях?

 

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

 

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

 

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

 

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

Рисунок 1. График окупаемости внедрения подхода Т2М

И овцы целы, и пастуху вечная память

 

Важно понимать, что все инструменты, методологии и подходы можно применять и по отдельности — они однозначно будут давать эффект и уменьшать время вывода продукта на рынок. Но наибольший эффект мы можем получить, только применяя все подходы сразу, — тогда сокращение time-to-market (t2m) может стать максимально большим за счет эффективности каждого из процессов.

 

Для среднего релиза (3 командо-месяца) картинка будет примерно такая: автоматизировали сборку — сэкономили 5% ФОТ и t2m, автоматизировали подготовку тестовых данных — сократили 10% ФОТ и t2m, автоматизировали Smoke Test — еще 5% ФОТ и t2m, регресс — 10–15%. Добавьте в этот коктейль гибкие методологии разработки — и получите свои законные 40–50% экономии ФОТ и времени вывода релиза.

 

При этом для системы средней сложности (и ее интеграционных взаимодействий) сам проект занимает не более 4 месяцев, а окупается уже за 2–3 месяца.

 

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

 

Кроме того, мы исключаем человеческий фактор: скрипт выполняет одно и то же действие из раза в раз, не устает, у него «не замыливается глаз», он не допускает ошибок, работает по выходным и по ночам — и даже не просит оплаты сверхурочных.

 

И да, в скором времени нас всех заменят роботы.

Рисунок 2. Цикл разработки ПО с автоматизацией и без нее

"А девочка созрела"

 

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

 

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

 

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

 

В настоящее время многие компании-интеграторы начинают предлагать свои услуги в области автоматизации процесса разработки и тестирования. Уже не такими новыми выглядят термины DevOps, CI/CD, Pipeline, Agile — даже для не ИТ-управленцев. О себе, в контексте данной темы, мы можем скромно сказать, что съели на этом собаку, кошку и даже маленького слона.

Следите за нашими обновлениями

Кластерные СУБД

Причем, если раньше кластеризация БД имела целью, прежде всего, создание высоконадежной и отказоустойчивой системы, то теперь, наряду с требованиями к надежности, все чаще преследуются цели распределения нагрузки по серверам, повышения производительности и масштабируемости систем, создания специализированных информационных «решеток» (grid) для параллельной обработки баз данных.

Как изменится ритейл в 2020 году

Какие тренды характерны для отечественного ритейла, и как мировые гиганты справляются с вызовами рынка

Обзор решений по защите от таргетированных атак

Обзор представляет решения Anti-APT от ведущих производителей: FireEye, Trend Micro Deep Discovery, Check Point SandBlast, Kaspersky Anti Targeted Attack Platform (KATA)

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику






Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на журнал







Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на новости







Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня