?

Log in

No account? Create an account

Previous Entry | Next Entry

Коллеги,

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

Есть две основных теории:

1. Все вести в одной системе. Это может быть, к примеру DevTrack, Jira или что-то подобное. Разделение между обращениями пользователей и багами происходит на уровне имени проектов, каких-то конфигурационных настроек WorkFlow и т.п

2. Использовать разные системы. По возможности, интегрированные. В багтрекинг обращение из техподдержки попадает только в случае, если это инцидент 3-го уровня, в идеале он заводится автоматом при присвоении инциденту данного уровня, на практике, по крайней мере, первое время, баг заводится ручками.

Какие имеются ограничения. В первую очередь, хотелось бы иметь бюджетное решение. Вбухивать бабки в систему а-ля BMC Remedy или HP OpenView никто не готов. Во-вторых, хотелось бы иметь решение, которое начало бы работать как можно быстрее. В третьих, хотелось бы иметь решение, которое было бы легко поддерживать.

Что еще могу сказать. Как сам продукт, так и служба техподдержки довольно молоды и находятся на стадии становления. Клиентов пока не настолько много, чтобы техподдержка представляла собой что-то монументальное. Но уже достаточно, чтобы наколеночные решения не работали. О колл-центре пока речи не идет, о регистрации обращений через интернет - возможно, но 99% обращений поступает в виде телефонных звонков. Основные пользователи нашего продукта (не системы HelpDesk) - люди, от IT далекие. В HelpDesk вообще пользователям доступа давать не планируется. Всегда на входе прокси в виде нашего оператора хелпдеска. Когда говорится о возможности заведения инцидентов через интернет, имеется ввиду, что система может автоматически отправлять сообщения об ошибках, если произошло обрабатываемое падение.

Возможно, все эти требования одновременно нереализуемы, про проектный треугольник я знаю. :-) Но тем не менее, хотелось бы. По-любому, ограничение в виде бюджета неубираемое.

Хотелось бы знать ваше мнение на тему. Если есть какие-то аргументы в пользу того или иного решения или альтернативные предложения, просьбы писать в комментах к опросу.

Также просьбы сослаться на этот опрос в своих блогах, чтобы максимальное количество людей могло принять участие.

Poll #1489701 Организация техподдержки

Как должны быть организованы системы техподдержки и багтрекинга

Это одна система, разделение тикетов техподдержки и багов происходит на уровне имени проекта и проч. конфигурации системы
6(37.5%)
Это разные системы, в той или иной мере интегрированные между собой
7(43.8%)
Другое
3(18.8%)

Comments

( 11 comments — Leave a comment )
greesha
Nov. 24th, 2009 10:32 am (UTC)
Проголосовал за разные системы. Попал в 100% (один голос :). Хотя, наверное, следовало выбрать "Другое".

По нашему опыту:

1) Во-первых, с каждым заказчиком нужно работать индивидуально. Кто-то умеет общаться только по телефону. Кто-то предпочитает e-mail с подробными описаниями своих действий. Кто-то у себя использует, например, MANTIS, и о других системах слышать не хочет (вы ему предложите свою Джиру, а он вместо этого начнёт регистрировать запросы в собственной системе, а вам присылать извещения).

В любом случае, первичную информацию часто нужно "выбивать" из заказчика или юзера всеми доступными способами - уточнять по телефону, аське, вплоть до личных встреч за бокалом пива.

2) Как правило, нельзя давать доступ в вашу внутреннюю систему трекинга снаружи. Вы для себя придумаете определённые правила классификации, приоритетов, жизненных циклов, ролей и т. п. Обучите свой персонал, напечатаете каждому инструкцию и памятку. А клиент зайдёт в систему и вывалит все свои проблемы ненумерованным списком в первую же форму подходящего размера. Не разбираясь, баги это, запросы на изменения, его личные домыслы или что-то ещё. Если выстраиваете техподдержку исходя из предположения, что сможете "обучить" клиента набору "простых" правил работы с вашей системой, то вы сильно рискуете.

Между "внешним" и "внутренним" трекером должен находиться человек, преобразующий поток сознания клиента в структурированные запросы согласно вашим внутренним правилам ("сюда мы поставим шлагбаум или толкового майора").
kstref74
Nov. 24th, 2009 10:37 am (UTC)
О доступе заказчика в систему пока речи не идет. Всегда на входе прокси в виде нашего оператора хелпдеска. Когда я говорила о возможности заведения инцидентов через интернет, я имела ввиду, что система может автоматически отправлять сообщения об ошибках, если ей произошло обрабатываемое падение. Поправлю основное описание, чтобы не было неясностей на эту тему.
greesha
Nov. 24th, 2009 10:42 am (UTC)
При этом, что характерно, мы сами активно пользуемся трекерами наши партнёров, которые предоставили нам прямой доступ в свои системы (MANTIS и Jira).

Это прекрасно работает, но, скорее всего, только потому, что общаются между собой технические специалисты, хорошо разбирающиеся в предметной области.
morrozmsk
Nov. 24th, 2009 09:05 pm (UTC)
чоорт!
напишем же сами! с блэкджеком и ...
saveug
Nov. 30th, 2009 09:25 am (UTC)
Поскольку поддерживается программный продукт, то на мой взгляд, лучше и дешевле будет работать вариант 1, то есть когда и поддержка и разработка ведется в одной системе.

Опишу пример того, как мы это делаем при помощи DEVPROM.

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

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

В DEVPROM есть замечательная возможность: интеграция с формой обратной связи. Ее можно установить на внешнем или внутреннем сайте, либо использовать программно. То есть обеспечить автоматический репортинг об ошибках при падении приложения. В проекте http://projectscloud.ru/main/feedback есть готовый класс на C#, при небольшой доработке которого, Вы сможете при падении сразу завести ошибку в DEVPROM.

maximkr
Nov. 30th, 2009 11:46 am (UTC)
Я бы рассмотрел этот вопрос вот с какой стороны: у систем одни и те же пользователи или разные ?

В вашем случае клиенты непосредственно работать с системой не будут, поэтому заводить еще одну систему для саппорта (с которой будет работать только внутренний специалист) смысла нет. Т.е. в данном случае этот специалист будет разделять поток сознания пользователей и задачи для программистов, этого будет достаточно.

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

Кстати, JIRA - типичная программа именно для общения с клиентами, они ее сами для управления внутренней разработкой не используют. Подробнее я писал тут
http://maximkr.livejournal.com/13933.html
и тут
http://maximkr.livejournal.com/8942.html

_ok_
Nov. 30th, 2009 04:14 pm (UTC)
На работе:
система тикетов одна, клиенты к ней доступа не имеют, HelpDesk имеет и активно использует.
kkrasov
Nov. 30th, 2009 05:02 pm (UTC)
1) Вы не учитываете слишком многих факторов. Так например, от Jira я бы рекомендовал отказаться хотя бы ввиду Jira-1330.

2) Про проектный треугольник. Для вас самый главный вопрос - Why? (зачем/почему). На него вы ответить пока не смогли. Сможете - поймете какая вам нужна система. Вполне может быть, что $100 000 - это совсем недорого, по сравнению с потерями от бесплатного мантиса.

3) Очень рекомендую посмотреть мои рекомендации по выбору BTS http://software-testing.ru/trainings/online/details/66 (есть запись).
pbear51
Dec. 1st, 2009 08:27 am (UTC)
Посмотрите в сторону этих продуктов
ManageEngine ServiceDesk Plus
ipi.manager
Naumen Service Desk
bas4all
Dec. 7th, 2009 01:53 pm (UTC)
Я бы смотрел с двух сторон:
1. С т.з. типов Пользователей, как правильно написал maximkr. Т.е. как им будет удобнее. Если это одни и те же Пользователи, то логичнее их один раз научить и они будут юзать один интерфейс.
2. С т.з. потоков обработки Заявок (или типов потоков): какие будут разрывы если будут 2 ИС, как будет разруливаться ситуация с разными типами запроса и т.д.
golub
Dec. 8th, 2009 10:06 am (UTC)
Привет! Пришел по ссылке Саши Орлова.

У нас ситуация существенно отличается, но расскажу вкратце.

Продаем модули для систем интернет-коммерции. Система саппорта увязана с магазином (используем собственную, которую и продаем в том числе), сообщения ходят почтой. Логично: клиенты и их ордера - данные, относящиеся к магазину, поэтому система близко привязана к магазину же.

Багтрекер + менеджмент - FogBugz. Логично: продукты, разработка, багфиксинг - в офисе, поэтому и система близка к офису. Экспорт "багослучаев" и саппорта в багтрекер автоматизирован, далее связка между кейсом в багтрекере и тикетом в саппорте двусторонняя - по йадишникам. Клиенты доступа к багтрекеру не имеют.

Впрочем, сейчас работаем над логгером, который ускорит и облегчит попадание информации о проблеме непосредственно из системы клиента в багтрекер.
( 11 comments — Leave a comment )