Как вы поощряете конечных пользователей заполнять заявки на устранение неисправностей? - PullRequest
7 голосов
/ 01 февраля 2009

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

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

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

Ответы [ 9 ]

12 голосов
/ 01 февраля 2009

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

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

Сделайте это как можно более без трения.

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

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

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

5 голосов
/ 01 февраля 2009

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

4 голосов
/ 01 февраля 2009

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

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

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

2 голосов
/ 01 февраля 2009

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

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

2 голосов
/ 01 февраля 2009

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

2 голосов
/ 01 февраля 2009

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

2 голосов
/ 01 февраля 2009

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

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

1 голос
/ 01 февраля 2009

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

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

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

1 голос
/ 01 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...