На главную
Цифровая Россия
Индустрия 4.0
Снижение показателя Time to Market: как быстро и безопасно вносить изменения программного обеспечения в готовый продукт
Многие компании сталкивались с архаичным подходом к процессам разработки ПО, боролись с бесконечными багами и тратили время на мучительное тестирование. Для того, чтобы облегчить боль внедренцев, делимся опытом компании «Инфосистемы Джет» и рассказываем о современном подходе к ускорению Time to Market.
Или быстрый, или мертвый. Триллер с красивым концом из реальной жизни

Один наш клиент постоянно не успевал вовремя выпускать релизы  (обновления и новый функционал программного обеспечения) с клиентскими скидками. Его специалисты работали по 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).

Рис. 1

А вот как должно быть (см. рис. 2).

Рис. 2

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

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

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

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

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

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

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

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

Материал подготовлен Ольгой Шишелиной, руководителем отдела тестирования Дирекции по разработке и внедрению программного обеспечения компании «Инфосистемы Джет»