Достаточно часто компании с собственным программным продуктом, будь то мобильное приложение, внутренние, CRM — системы и т.д., сталкиваются с необходимостью дальнейшего развития решения. Причины могут быть разные: существующее ПО не соответствует бизнес-требованиям, процессам, показатели растут не так быстро, как хотелось бы, завалена техническая поддержка, от пользователей мало положительных отзывов. В таких случаях выявить слабые места и точки роста позволит аудит качества продукта.
Один из наших заказчиков обратился к нам с проблемой выпуска корпоративного приложения для управления дочерними филиалами. Клиент – страховая компания, в сферу работы которой входит рисковое и накопительное страхование, прочие услуги. Для координации, управления и учета деятельности головного офиса и дочерних филиалов существует специальное программное обеспечение. Основной функционал которого – большое количество журналов учета, планирования и аналитики. Кроме автономных журналов, предназначенных для конкретного подразделения и исключительно для локальных целей, есть журналы совместного пользования. По ним информация собирается в головной офис и в обратном направлении также спускаются планы и показатели.
Основными проблемами данного программного обеспечения были:
- частые сбои сервера;
- потери данных при передаче из дочерних филиалов;
- приложение перестало справляться с нагрузкой при обработке возросшего числа сервисов (геолокация, интеграция со смежными сервисами);
- несоблюдение сроков выпуска новых версий.
Мы подготовили ряд вопросов и обсудили их в офисе заказчика. В результате получили четкую картину организации работ в команде Клиента. Данный подход позволил провести полный технический аудит проекта. По нашему опыту — это самый удачный метод для сбора максимально подробной и целостной информации по проекту, позволяющий в минимальный срок сформировать не только команду, но и процессы ее работы. Выявили необходимость подключения QA-специалистов и усиленной команды разработки.
Что удалось выяснить
До начала анализа приоритеты по работам выглядели следующим образом: 70% разработка новых фич, которые решат обозначенные проблемы, и 30% — тестирование существующего функционала, в том числе тестирование масштабируемости.
План работ до проведения аудита качества продукта
В процессе аудита крайне важно узнать, как работают исполнители из других направлений и их взгляд на основные задачи проекта и процессы.
Пообщавшись с командой заказчика, мы узнали о других, не менее важных проблемах:
- крайне низкая производительность интеграционной системы, на которую был завязан один из основных компонентов;
- необходимость значительной доработки по причине неверно понятого и реализованного функционала;
- отсутствие логирования ошибок;
- в релизную версию приложения попадали все задачи, даже те, которые не требовались для релиза. В результате значительно увеличивалось время на разработку и поиск багов;
- несоответствие тестовых стендов реальным: множество компонентов на тестовом стенде были устаревшими, что приводило к нахождению багов, которые никогда не могли воспроизвестись на реальных стендах с живыми пользователями, и наоборот — часть багов находили только сами пользователи;
- у заказчика не было опыта в настройке инфраструктуры серверов;
- приложение никогда не тестировалось полностью на предмет соответствия функциональным требованиями и на usabiluty.
Заказчик не обозначал заранее данные проблемы, они оказали существенное влияние на рост и развитие проекта. Зачастую проблемы такого рода не получают должного внимания, что может понизить эффективность внесения изменений всего проекта.
Что мы предложили
Пошаговый план, подготовленный экспертной командой решал обозначенные проблемы клиента. Более плавным и безболезненным методом был предложен индивидуальный подход — идея единой команды клиента, в основу которого положены следующие принципы:
- общая заинтересованность команды в достижении целей и выполнении задач;
- вовлечение всех лиц, влияющих на качество внутреннего продукта;
- постоянное консультирование специалистов заказчика нашей командой.
В итоге от изначального плана Заказчика, где подразумевалось обсуждение только разработки, мы перешли к утверждению расширенного списка работ по:
- процессам, по которым проходит жизненный цикл задач;
- выбору задач, которые попадут в релиз очередной версии, и приоритезации задач в целом;
- процессу тестирования, его организации для получения представления об общем качестве продукта;
- настройке Git Flow;
- разработке нового функционала и исправлению дефектов;
- настройке системы автоматического развертывания проекта.
План работ после проведения аудита качества продукта
В завершение аудита был составлен план на первые два месяца, не только включающий перечень работ, но и договоренности по процессам.
Результат
По прошествии 2-х месяцев был выпущен релиз с приоритетным функционалом в рамках запланированных сроков. Основную бизнес-логику приложения покрыли автоматическими и ручными тестами, что дало лучшее понимание уровня качества приложения, уменьшение концентрации дефектов, а также возможность выявить точки роста продукта.
Результаты работы в некоторых рабочих цифрах до и после аудита в области сопровождения продукта и обеспечения его качества.
Наш подход работы единой командой дал соответствующий результат:
- стабилизирован основной функционал приложения, уменьшилось количество сбоев сервера, потери данных;
- повышено удобство использования системы, что дало увеличение скорости работы сотрудников;
- налажен выпуск версий приложения в установленные сроки;
- увеличен процент возвращения и повышение лояльности постоянных клиентов в два раза от первоначального показателя;
- уменьшилось количество критических обращений в службу техподдержки на 70%.
Автор: SSul
