Подскажите литературу про оценку ПО с помощью статистики от техподдержки

да, у нас тоже табличка )) Только вот предложений от пользователей очень много, а срок их реализации весьма высок (т.к. в силу ряда объективных причин почти все запросы пользователей имеют низкий приоритет)… думаю, что направим поток предложений в редмайн, однако не понятно, как решать проблему дублирующихся фичреквестов.

Спасибо за интересное общение!

Подскажите литературу про оценку ПО с помощью статистики от техподдержки

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

Подскажите литературу про оценку ПО с помощью статистики от техподдержки

Спасибо за сообщение!
По поводу пункта 3: тот вопрос, что касается отправки сообщения тестировщику и заведение задачи в багтрекере с пометкой «обнаружено пользователем» — это очень правильно, но это уже на стороне багтрекинга. Багтрекер же дает понять какой модуль программы (фича) наиболее бажна. Мне же необходимо взять то, что не дает багтрекер.

По поводу пункта 1 (по сути он же пункт 2): этот параметр для чего? Чтобы оценить популярность модуля(фичи)? Его неудобство или глючность? но если он популярнее прочих модулей, значит и фидбека будет по нему больше. Впрочем, тут Вы совершенно справедливо подметили, что этот параметр нужно оценивать не в статике, а в динамике. Модуль скорее всего останется одинаково популярным все время, а вот снижение или повышение количества вопросов по нему (удельное) будет свидетельствовать о подвижках в работе над юзабилити, например.

Будет ли техподдержка где-то отмечать, по какой части продукта был вопрос? По новой, по старой? Какого типа был вопрос — не поняли, как делать? Поблагодарили? Попросили новую фичу в дополнение к существующим? Такие подсчеты будут отнимать время у техподдержки и снизят ее эффективность.

На самом деле, с моей точки зрения, это не проблема. Мы используем, например, OTRS. Начиная с версии 3.1 там появились динамические поля. Я просто могу завести пару обязательных для заполнения полей типа список с возможностью выбора нескольких элементов. Один список- модуль программы, по которому задается вопрос (+ варианты типа — документация, проблема со сторонним ПО и т.д.), второй — версия программы (+релиз, демо-версия, тестовая версия, устаревшая версия) и др. Пара кликов много времени не отнимут у сотрудника, а забить или забыть он не сможет, для ответа или закрытия обращения обязательно понадобится сделать выбор в этих полях.

Спасибо за сообщение, очень интересно, кто как и что выжимает из этого.