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

Question

[RadioAgent]

Не могу найти ни статей, ни литературы, может не по тем ключевым словам ищу…

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

В общем буду признателен, если кто опубликует статью на хабре или даст ссылку на существующие русско или англоязычные материалы на тему «статистика техподдержки на службе менеджера разработки ПО»

Answer 1

[Андрей]

Можно учитывать:
1. Сколько было обращений в техподдержку (после внедрения фичи стали больше писать, меньше писать, не изменилось?)
2. Сколько вопросов задается по каждой из фич?
3. Сколько багов было найдено в каждой из фич?
…

По первому вопросу в принципе посчитать просто. Но вот непонятно, связано ли изменение количества писем с изменениями в продукте, или же это сезонное? Или связано с чем-то еще (цены подняли/снизили, скидки дали, баннер на популярном сайте повесили)? Такая статистика у нас ведется, но она может показать, что компания в целом движется в правильном направлении.

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

Сколько багов нашли клиенты? Тут все довольно просто. Мы ведем такую статистику.
Все происходит следующим образом:
1. Если пришло письмо с новой проблемой, то сотрудник техподдержки информирует об этом тестировщика.
2. Тестировщик изучает проблему, выясняет, является ли это багом или нет. Если это не баг/не наш баг (браузера, джавы, флэш-плеера, дотнета и пр.), то просто отписываемся клиенту с советами, что делать и как от этого избавиться.
3. Если это оказывается наш баг, то тестировщик заводит тикет в баг-трекере, и в специальном поле указывает, что проблема была найдена клиентом.
4. В конце месяца подводится статистика: сколько % от общего числа багов найдено клиентами. Я считаю хорошим значение в 5%, но это удается достичь не по всем проектам. Где-то и 1% бывает, а где-то и 15%. Соответственно, видно, на каком проекте разработчики написали качественно, а тестировщики протестировали тщательно, а где команда сработала не очень хорошо. Затрат на внедрение практически не требует, а информация полезна.

Comments

[RadioAgent]

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

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

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

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

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

[Андрей]

П. 1,2:
1) Оценить, двигаемся ли мы вообще в правильном направлении: писем больше, при этом % сообщений об ошибках не увеличивается — все ок, писем много, но там вопросы «ничего не понятно!» или сообщения об ошибках — FAIL :(
2) Оценить востребованность модуля/фичи: чем больше вопросов и пожеланий по определенному модулю, тем он более интересен. Стало меньше вопросов, больше «а сделайте нам еще вот это и вот это!» — все ок, направление верное :)

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

[RadioAgent]

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

[Андрей]

Ну, «база» — громко сказано, таблички в Excel. Количество фич у нас исчисляется десятками на продукт, поэтому поиск/фильтр не составляет сложности.
Вопросы по соответствию проблем и задач пользователей с новыми фичами решают в нашем случае тестировщики как люди, лучше всего знающие все возможности продукта.

[RadioAgent]

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

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