«Неудавшийся» релиз: почему разработка продукта может пойти не по плану

Ожидание: заказчик сразу одобряет ПО на предварительном тесте, а выпуск в продакшен проходит без багов и нервов. Реальность: после релиза пользователи не могут работать с приложением, сервер не справляется, а команда проекта проводит выходные за работой. К сожалению, идеальная разработка продукта — что-то из разряда единорогов. На проектах могут возникать проблемы и ошибки, как бы ты ни старался. И это нормально, главное — работать над ними и учиться снижать риски.

Привет! Меня зовут Екатерина Ремизова, я директор по качеству SimbirSoft. С момента основания компании мы поработали больше чем над 1200 IT-проектами и, конечно, совершали ошибки. Но с каждым годом их становилось всё меньше, поскольку мы смогли наладить процессы и свести количество инцидентов к минимуму. В этой статье на реальном кейсе покажу, почему разработка может пойти не по плану и как предотвратить проблемы на проекте.

У разработки IT-продукта под ключ есть свой жизненный цикл. Эта последовательность состоит из стандартных этапов:

• Идея. Клиент приходит в IT-компанию и рассказывает, какой продукт он хочет сделать.
• Анализ и сбор требований. Команда аналитиков оценивает жизнеспособность идеи, разрабатывает технические характеристики и описывает архитектуру продукта. После составляет ТЗ и отправляет на следующий этап.
• Разработка. Программисты по ТЗ от аналитиков пишут код и разрабатывают продукт.
• Тестирование. QA-специалисты проводят тестирование по сценариям, которые в идеале готовят до этапа разработки или параллельно с ним. Если что-то ломается, отправляют на доработку.
• Релиз приложения. Продукт выпускается в production и становится доступен пользователям.
• Мониторинг и поддержка. Команда следит за работой приложения и, если что-то не работает, подключается и чинит это.

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

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

👉 Желание клиента сэкономить или получить ПО как можно скорее. Заказчик может отказаться от некоторых этапов разработки, чтобы получилось быстрее или дешевле. Классический случай — отказ от тестирования на ранних этапах жизненного цикла ПО. Это приводит к тому, что баги могут обнаружиться уже на этапе регрессионного тестирования, когда версия ПО собрана. На их исправление уйдет больше времени и денег. А иногда может привести к изменению архитектуры и переписыванию приложения с нуля, что может вылиться уже в более крупные затраты.

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

👉 Неполная команда разработки на старте. Когда на проекте не хватает рук, приходится чем-то жертвовать, чтобы уложиться в сроки. Это может привести к непроработанным требованиям к продукту, пропуску важных этапов разработки. Например, отсутствие аналитиков на проекте может привести к тому, что в разработку пойдет нежизнеспособная идея и клиент не получит желаемого результата.

👉 Нехватка у IT-команды опыта на конкретном проекте. Если команда работает с чем-то новым, бывает сложно учесть все нюансы. Из-за банального незнания можно подобрать неправильное решение для продукта и усложнить себе жизнь: например, не предусмотреть, что мобильным приложением могут пользоваться в местах с плохим интернетом, и сделать сложную систему загрузки данных.

Однажды мы работали над классным проектом — приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Приложение вышло в магазинах, первый релиз состоялся 20 октября. И только за первый месяц работы уже было больше 50 000 скачиваний.

К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз — ему хотелось побыстрее запустить его. Мы пошли у него на поводу, и вот что из этого вышло.

Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя еще час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтен в аналитике.

Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps-инженером и предложил донастроить кеширование на стороне СУБД.

В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получаем срыв запуска нового курса тренировок клиента. Не самый лучший подарок под елку…

В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками. Более полную версию можно прочитать тут.

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

👉 Добавили архитектурный надзор в каждом производственном направлении разработки. Теперь проводим ревью архитектуры разрабатываемого продукта на контрольных точках проекта. Это помогает вовремя обнаружить баг и исправить его до релиза.

👉 При тестировании используем только релевантные данные и строго это контролируем. Это помогает увидеть реальную картину и проработать корректные требования для продукта.

👉 Проводим минимальное нагрузочное тестирование продукта, даже если клиент считает, что оно не нужно. И анализируем необходимость полноценных нагрузочных тестирований на каждом проекте, чтобы понять, сколько пользователей выдержит инфраструктура продукта и какие «узкие» места в ней есть.

👉 Не делаем релизов в предвыходные и предпраздничные дни :)

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

В IT нет отраслевых стандартов процессов по созданию ПО. Разработка подобных норм и правил — задача и ответственность каждой отдельной компании. Мы в SimbirSoft такие стандарты разработали на основании лучших практик и личных ошибок, накопленных за 22 года работы. Благодаря нашим стандартам и выстроенным процессам мы можем брать проекты любого уровня сложности. И мы продолжаем улучшаться. Это постоянный процесс, который выстроен на всех проектах. Обнаруживаются новые схемы работы, появляются устойчивые тренды, возникают проблемы в процессах — и всё это требует новых решений.