Как оценить качество ИТ-продуктов

Критерии качества

При всем многообразии ИТ-решений критерии оценки их качества зачастую выглядят очень похоже.  Например, Владислав Вирясов, директор ООО «Авантелеком», предлагает такой перечень требований: 

• функциональность – продукт выполняет необходимые функции и решает задачи, поставленные перед ним;

• надежность – продукт стабилен, надежен и способен работать без сбоев или ошибок;

• производительность – скорость работы продукта, его отзывчивость, возможность обработки больших объемов данных и другие параметры производительности;

• безопасность – продукт защищен от несанкционированного доступа, атак и утечек данных;

• удобство использования – продукт интуитивно понятен, легко осваивается и удобен в использовании для конечных пользователей;

• масштабируемость – продукт способен масштабироваться и адаптироваться к изменяющимся потребностям и объемам работы;

• совместимость – продукт совместим по REST API или посредством кастомного решения с другими системами и технологиями, с которыми он должен взаимодействовать;

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

• приемлемые условия по поддержке и обслуживанию – наличие и качество технической поддержки, обновлений и исправлений ошибок со стороны поставщика продукта.

При этом, по мнению большинства экспертов, главный показатель качества ИТ-продукта – это его способность удовлетворять установленные бизнес- и пользовательские требования. Другими словами, продукт должен выполнять предполагаемые функции и задачи. При этом генеральный директор ООО «Искусство Автоматизации» Ахмад Боков уточняет, что, как правило, крупный бизнес подключает к формулировке функциональных требований ИТ-продуктов руководителей отделов и подразделений.

Инструменты оценки качества

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

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

Обратная связь от пользователей – то самое топливо, благодаря которому определяется дальнейшая судьба продукта. Ее сбор можно организовать по-разному:

• формы обратной связи непосредственно в продукте, например, через чат-бота;

• брейнсторминг с заинтересованными лицами;

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

• день открытых дверей;

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

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

Еще один действенный инструмент оценки качества продукта, по мнению генерального директора ООО «Искусство Автоматизации» Ахмада Бокова, – тестовый запуск на ограниченном участке использования, например, в одном из подразделений. Для решения задачи собирается тестовый изолированный стенд. В этой «песочнице» проводится знакомство бизнеса с новым решением и собирается обратная связь. При таком подходе бизнес без потерь может отказаться от нового продукта, если он не соответствует поставленным задачам.

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

Что мешает оценить качество ИТ-продукта

К сожалению, компаниям не всегда удается с высокой точностью дать оценку продукту. К примеру, Ахмад Боков к основным сложностям этой процедуры относит целый ряд факторов:

• отсутствие четко сформулированных требований к функциям продукта со стороны бизнеса;

• противоречивость требований со стороны разных отделов/департаментов – на принятие решения уходит много времени, процесс затягивается;

• часто меняющиеся требования к характеристикам ПО;

• отсутствие/неслаженность процессов сбора обратной связи об эксплуатации ПО. Например, не предусмотрен процесс формирования базы данных об инцидентах, которая бы позволяла делать соответствующие выводы для улучшения качества ПО, или в ролевой модели отсутствует специалист, ответственный за сбор и обработку обратной связи;

• дефицит ресурсов. Например, ресурсы на тестирование и оценку качества могут быть ограничены возможностями бизнеса, что заставляет команды выбирать между областями, на которых стоит сосредоточить усилия;

• сложность и обширность ИТ-продукта как объекта наблюдения. Это усложняет его полную проверку и понимание всех возможных сценариев использования. Кроме того, многие ИТ-продукты должны корректно интегрироваться с другими системами и программным обеспечением, что требует тестирования в разных средах и конфигурациях.

Владислав Вирясов дополняет: помешать оценке качества ИТ-продукта может и отсутствие достаточной экспертизы у компании-заказчика. В основном это касается организаций с небольшим штатом ИТ-специалистов или с ИТ-службой на аутсорсе. В этом случае специалист рекомендует заказчику обратиться к внешним специалистам.

Этапы оценки качества

Таким образом, процесс оценки качества можно разделить на несколько этапов, каждый из которых включает определенную последовательность действий. Ниже – небольшой чек-лист:

1. Разработайте список критериев, которые помогут оценить качество продукта, – производительность, наличие необходимого функционала, отказоустойчивость в периоды пиковой нагрузки, встроенные инструменты обеспечения безопасности данных. Если решение предназначено для широкого круга пользователей в организации, например, ERP или CRM-система, – важно оценить качество интерфейса: удобство использования, легкое погружение в продукт без длительного обучения, возможность использования на разных устройствах – десктоп, мобильная версия;

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

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

«Если говорить про абстрактные идеальные условия, то мы должны собрать довольно большой объем информации о портрете пользователя, для которого планируем создавать новый продукт. И чем точнее будет карта событий, тем больше удовлетворения будет от результата, – дополняет директор департамента ИТ-проектов Роскачества Валентин Павликов. – На практике ничего идеального не существует, и мы можем руководствоваться принципами Agile:

1) люди и взаимодействия важнее процессов и инструментов;

2) работающий продукт важнее точной и подробной документации;

3) сотрудничество с заказчиком важнее условий договора;

4) готовность к изменениям важнее следования изначальному плану».