Связаться с редакцией
Как быстро и безопасно вносить изменения в ПО готового продукта
Или быстрый, или мертвый. Триллер с красивым концом из реальной жизни
Один наш клиент постоянно не успевал вовремя выпускать релизы с клиентскими скидками. Его специалисты работали по 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% |
Добавим чуть-чуть технических деталей. Чем раньше найдена ошибка в ПО, тем дешевле обойдется работодателю ее исправление, так как:
- Разработчик все еще работает над тем же куском программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и правку он делает буквально «на лету».
- Другие разработчики не вносят изменения в этот содержащий ошибки программный код.
- Ветки кода не успели размножиться на последующие релизы, и не нужно будет исправлять один и тот же баг сразу в нескольких местах, учитывая версионность кода.
- Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.
Какой путь выберет компания и знает ли она о текущих возможностях?
Можно идти пешком. Можно воспользоваться транспортным средством: велосипедом, машиной, — но без учета пробок на дороге такое движение может оказаться значительно продолжительнее по сравнению с движением пешехода.
Конечно, вопрос о том, как добраться до цели в нужные сроки, правильно выбирая средства и обеспечивая оптимальные затраты, должны решать профессионалы, ведь иногда промедление смерти подобно.
У любой (не только из сферы ИТ) компании это может быть выпуск нового продукта для сохранения конкурентного преимущества при участии в тендере, если речь идет о B2B, или компания просто решила сделать продукт более привлекательным для существующих или новых клиентов в случае B2C.
В конце концов, это могут быть банальное обеспечение соблюдения сроков устранения замечаний регулятора или доработка решения к какой-то фиксированной дате в связи с введением в действие нового законопроекта. В таких случаях, если компания не успела внести изменения в срок, приостанавливается действие ее лицензии, у нее нет деятельности, нет прибыли, она теряет клиентов.
И овцы целы, и пастуху вечная память
Важно понимать, что все инструменты, методологии и подходы можно применять и по отдельности — они однозначно будут давать эффект и уменьшать время вывода продукта на рынок. Но наибольший эффект мы можем получить, только применяя все подходы сразу, — тогда сокращение time-to-market (t2m) может стать максимально большим за счет эффективности каждого из процессов.
Для среднего релиза (3 командо-месяца) картинка будет примерно такая: автоматизировали сборку — сэкономили 5% ФОТ и t2m, автоматизировали подготовку тестовых данных — сократили 10% ФОТ и t2m, автоматизировали Smoke Test — еще 5% ФОТ и t2m, регресс — 10–15%. Добавьте в этот коктейль гибкие методологии разработки — и получите свои законные 40–50% экономии ФОТ и времени вывода релиза.
При этом для системы средней сложности (и ее интеграционных взаимодействий) сам проект занимает не более 4 месяцев, а окупается уже за 2–3 месяца.
Когда непрофильные компании берутся за разработку ПО, они заново изобретают велосипед, не понимая, как улучшить процесс и сделать его по-настоящему эффективным.Правило простое: любое повторяющееся из раза в раз действие должно быть автоматизировано и настроено на регулярный запуск (по расписанию или событию), что позволяет сократить и время, и количество людей, поддерживающих данную рутину.
Кроме того, мы исключаем человеческий фактор: скрипт выполняет одно и то же действие из раза в раз, не устает, у него «не замыливается глаз», он не допускает ошибок, работает по выходным и по ночам — и даже не просит оплаты сверхурочных.
И да, в скором времени нас всех заменят роботы.
"А девочка созрела"
В завершение нашего разговора хочется сказать, что даже в одной компании может быть несколько десятков систем, находящихся на разном уровне развития в части автоматизации процессов.
Текущая картина в системе определяется при помощи ключевых точек в процессе разработки и тестирования, и мы легко можем сказать, находится ли система на нулевом уровне развития или она уже на стадии зрелых процессов и относится к продвинутому уровню.
Переход с начальных уровней на высокие, безусловно, дает самый максимальный и зримый эффект. Для того чтобы понять, на каком уровне развития (зрелости) находится та или иная система, в нашей компании используется четкая методика оценки, из которой легко вычленить цели и результаты, которых мы хотим добиться, автоматизируя процессы в системе. Так заказчик проверяет результаты внедренных изменений, опираясь на четкие KPI. Так он получает ясное представление о тех изменениях, которые будут внесены в процесс.
В настоящее время многие компании-интеграторы начинают предлагать свои услуги в области автоматизации процесса разработки и тестирования. Уже не такими новыми выглядят термины DevOps, CI/CD, Pipeline, Agile — даже для не ИТ-управленцев. О себе, в контексте данной темы, мы можем скромно сказать, что съели на этом собаку, кошку и даже маленького слона.
