Как вы поощряете конечных пользователей заполнять заявки на устранение неполадок?

Question

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

Полагаю, я мог бы просто сказать: «Эй, не могли бы вы в следующий раз заполнить карточку неисправности?», но тогда я бы выглядел плохим парнем, потому что другие этого не делают.Я также не хочу, чтобы конечные пользователи чувствовали, что я недоступен.Я просто хочу, чтобы они поняли, что есть правильный способ попросить о помощи.

Так что же мне лучше всего сделать в такой ситуации?

Answer 1

Сделайте это привлекательным.

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

Сделайте это как можно более беспроблемным.

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

Поговорите со своей командой.

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

Answer 2

Похоже, ваш менеджер вас подводит, не заставляя пользователей отправлять заявки, прежде чем получить помощь.Проблема начинается там и продолжается только до тех пор, пока ваши коллеги допускают такое поведение.Мы используем Redmine на работе для поддержки приложений и добились хороших успехов в том, чтобы говорить пользователям: «отправьте заявку, и мы ее рассмотрим», но это должно быть единое мнение всех вовлеченных людей.

Answer 3

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

Люди, которые используют систему продажи билетов, должны получить золотую звезду, нет, серьезно.

В февральском выпуске Harvard Business Review была очень короткая статья об использовании социального давления для влияния на поведение.В нем обсуждались некоторые новые исследования, но в статье не было ссылок.

Answer 4

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

Однако даже ЕСЛИ вы сможете убедить своих коллег и пользователей ввести заявки, вы, вероятно, все равно обнаружите, что заявки неполные/неинформативные.Мы все видели множество заявок типа «Функция X не работает, исправьте ее, пожалуйста» и не содержат никакой другой информации.В зависимости от количества билетов, которые вы получаете в день, я, вероятно, просто стисну зубы, пройдусь мимо пользователя и узнаю, в чем его проблема, из первых рук.

Answer 5

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

Answer 6

В таких случаях мы часто регистрируем заявку от имени пользователя.

Answer 7

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

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

Answer 8

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

Answer 9

Совет Simucal хорош.В какой-то момент вам придется вместо этого сказать им «подать заявку».Если вы спросите их постфактум, им будет все равно, потому что они получили то, что им было нужно.

Отличный способ справиться с этой проблемой — найти специального человека для поддержки.Моя команда сделала это, и это значительно повысило нашу производительность и устранило как минимум 90% наших перерывов.

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