Как не попасть в ловушку качества при выводе на рынок IT продукта

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

Насколько важен баланс между скоростью выхода продукта на рынок и его качеством? Обсудим в этом материале. 

Кейс из практики

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

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

Мобильное приложение представлено на двух платформах: IOS и Android. 

Команде предстояла  реанимация старого приложения и увеличение его монетизации. В задачи входило: переработка frontend‑части приложения. При этом для backend и API требовалось задействовать уже разработанные командой заказчика решения.

Такая ситуация уже накладывает определенные риски — их нужно учесть в процессе. 

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

Команда шла по согласованному плану работ (roadmap): проводили регулярные демо, получали положительную обратную связь и незначительные доработки. Мы работаем над множеством проектов и постоянно отслеживаем метрики. Для этого у нас есть несколько внутренних инструментов — они обеспечивают контроль на всех этапах разработки и взаимодействия с командой или заказчиками. Например, у компании есть Дашборд здоровья проектов — веб‑интерфейс  с набором основных метрик по всем разработкам. 

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

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

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

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

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

 Выводы из текущего кейса

Итак, какие выводы сделала команда. 

1. Любой показ промежуточных результатов — это, по сути, релиз, в котором необходимо представлять качество передаваемого продукта и заранее сообщать обо всех нюансах. Это дает команде возможность управлять релизом, багами/дефектами. Практика известная, но часто пропускается, чтобы сократить время разработки. 

2. При передаче сборок команда внедряет понятие «оценка качества сборки», по которой совместно с заказчиком принимается решение о дальнейшем релизе. Перед передачей сборки необходимо провести хотя бы часть критичных тестов (даже если время на исходе). Здесь важна приоритизация и грамотное планирование.

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

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

Чек-лист: ускоряем релиз без потери качества

Итак, что делать, чтобы ускорить выход продукта на рынок, но не потерять в его качестве? 

• Определить минимально жизнеспособный продукт (MVP) и основные пользовательские сценарии.
• Определить критерии качества, с которыми вы готовы выпускать продукт на рынок: с какими багами вы готовы смириться сейчас и включить их в следующие релизы.
• Управлять релизами на постоянной основе: что будет включать релиз, когда, как и кем будет осуществлена публикация.
• Не забывать про  критические негативные сценарии, которые свойственны мобильным приложениям (работа приложения при потере сигнала, сворачивание приложение, фоновая работа и прочее).
• Учитывать особенности платформ iOS и Android.
• Управлять дефектами/багами: по каждому дефекту иметь решение (в какой релиз оно пойдет или и как будет правится).
• Принимать решение по релизу с учетом качества сборки.

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