Это довольно общий вопрос - вам, вероятно, нужно быть более конкретным.Тем не менее, вот некоторые отправные точки, о которых вы могли бы подумать.
Стоимость поддержки пользователей - количество инцидентов поддержки пользователей в виде доли от пользовательской базы.Разбейте его по задачам, модулям или другим разбивкам, которые можно связать с реальными функциональными возможностями приложения, которые можно исправить.Бонус, если вы можете получить статистику по числу эффективных исправлений.
Стоимость исправлений данных - в зависимости от вашего приложения стоимость исправления неверных данных может быть метрикой стоимости поддержки, которую выдолжен отслеживать.
Количество ошибок - если вы можете обнаружить ошибочные шаблоны навигации в журналах веб-сервера, вы можете попытаться снизить уровень этого.
Сохранение или количество прерванных попыток.Если у вас есть общедоступный веб-сайт, возможно, вы захотите определить, сколько пользователей теряют интерес.
Это все вопросы, на которые вы, скорее всего, сможете получить достоверные данные (по крайней мере для веб-приложения), и они дадут вам некоторые объективные меры, которые связаны с реальными аспектами производительности.Обратите внимание на соотношение затрат и эффективности (пользователи, покидающие сайт, стоимость звонков в службу поддержки).С «наивной» экономической точки зрения они дадут вам основные количественные показатели эффективности работы сайта (я полагаю, вы работаете на кого-то, обслуживающего веб-приложение).
Возможно, вы подумаетеаналогичных мер, которые более непосредственно подходят для вашего приложения.
Чтобы получить более глубокое представление, вы можете захотеть заняться некоторыми традиционными маркетинговыми / HCI-вещами, такими как опросы или даже фокус-группы или юзабилити-тестирование.Помимо этого, вы оцениваете основную стратегию системы, которая (я полагаю), вероятно, начинает выходить за рамки ваших заданий.Начните с того, что вы можете измерить первым.