Как Вы поощряете конечных пользователей заполнять заявки на устранение неисправности?
Одним из возможных подходов является использование именованных параметров:
public static void M(Action action) { /* do stuff */ }
public static void M(Func<int> func) { /* do stuff */ }
public static void Main()
{
M(action: () => throw new Exception());
}
Это, вероятно, должно быть задокументировано в коде, чтобы не удивлять следующего разработчика, и, как отмечено в комментариях, написать соответствующий вызывается автоматический тест для проверки правильности перегрузки.
9 ответов
Сделайте его обращающийся, чтобы сделать так.
Упомяните пользователю, который выходит с заявками на устранение неисправности, просматриваются всей группой разработчиков и, как находили, были зафиксированы значительно быстрее. Скажите, что что-либо без билета имеет потенциал, чтобы потеряться в перестановке. Предоставьте им исходящие ссылки направления, таким образом, они могут просмотреть прогресс, и разработчик/поддержка комментирует их билет. Предоставьте предупреждения по электронной почте, таким образом, они чувствуют, что они - часть процесса и имеют мгновенную информацию об их проблеме.
Сделайте его максимально лишенным трения.
Сделайте пользовательскую часть записи системы настолько простой в использовании и интуитивной насколько возможно. Никому не нравится заполнять билеты, и я, конечно, не собираюсь переходить через любые обручи, чтобы сделать так. Никакие логины, никакие входы в систему, просто не выводят мою проблему и контактную информацию и идут.
Говорите со своей командой.
В конечном счете никакой объем тяжелой работы в вышеупомянутых системах не будет иметь значение, если Ваша команда и Вы не находитесь на той же странице. Призовите к обсуждению в команде и разговору с ними о проблеме. С Вашим присутствующим боссом попытайтесь поместить его в условия, которые он может понять. Упомяните потерянное бесценное время, проблемы, отслеживающие клиентские проблемы, которые не находятся в системе, и т.д., и т.д.
Вы, вероятно, не сделаете много прогресса, если Вы не убедите своих коллег использовать систему сначала. После все достижения соглашения о процессе, который Вы хотите, затем можно говорить пользователями. Если все в Вашей команде играют по тем же правилам, можно, вероятно, вынудить пользователей использовать систему при наличии медленных оборотных времен для проблем, в которые не вводят система или возможно даже забыть их в целом.
Однако, даже если можно убедить и коллег и пользователей вводить билеты, Вы, вероятно, все еще найдете, что билеты неполные/не информативный. Мы все видели, что много билетов как "Функция X повреждается, зафиксируйте ее" и не предложите никакую другую информацию. В зависимости от количества билетов Вы добираетесь в день, я, вероятно, просто стиснул бы зубы и техническая победа пользователь и видел бы то, что их проблема является личной.
Используйте немного психологии на них. Для людей, которые не отправляют в заявках на устранение неисправности, напомните им, что 80% людей в их отделе используют систему покупки билетов. Даже если это будет ложь, то это поощрит хорошее поведение из-за эффекта побеждающей стороны. Помните что, чем более подобен человек демографической статистической величине, тем более вероятно она должна влиять на их поведение. Так "Ваши непосредственные коллеги" будут работать лучше, чем "люди в этой всей компании".
Люди, которые используют систему покупки билетов, должны получить золотую звезду, нет, серьезно.
Была очень краткая статья в "Гарвард бизнес ревью" в феврале при использовании социального давления для влияния на поведение. Это обсудило некоторое новое исследование, но статья не включала ссылки.
Кажется, что Ваш менеджер подводит Вас, не вынуждая пользователей отправить билет прежде, чем получить справку. Проблема запускается там и только продолжается Вашим коллегам, позволяющим такое поведение. Мы используем redmine на работе для поддержки приложений и добились существенного прогресса в говорящих пользователях, "отправляют билет, и мы заглянем к нему", но это должна быть последовательная речь от всех вовлеченных людей.
Вы не делаете. Пользователи ненавидят тот материал, даже я делаю. Вместо этого Ваша политика должна быть, "не заставляют меня думать". Необходимо собрать все, в чем Вы нуждаетесь сами и автоматически обрабатываете это невидимым способом к Вашим пользователям. После того, как они подписываются при установке.
Мы часто регистрируем билет от имени пользователя в этом виде случая.
Также - прекращают поощрять поведение. Используйте свой IM фильтрация опций только казаться онлайн команде разработчиков. Не проверяйте свою электронную почту - или устанавливайте фильтры, которые фильтруют высокоприоритетный материал (Ваш босс, Ваша команда разработчиков) к Вашему ящику входящих сообщений и всему остальному к папке, которую Вы проверяете один раз в день или один раз в другой день.
Совет Simucal хорош.-will-необходимо сказать им "регистрировать билет" вместо этого, в какой-то момент. Если Вы спрашиваете их после факта, они не собираются заботиться, потому что они получили то, в чем они нуждались.
Отличный способ обработать это состоит в том, чтобы иметь преданного человека для поддержки. Моя команда сделала это, и она помогла нашей производительности очень и устранила по крайней мере 90% наших прерываний.
Запрещая это (или место), можно каждый ежедневно вращаться относительно того, кто добирается для обрабатывания пользовательских запросов. Это имеет результат создания заявки на устранение неисправности, более или менее требуемой; его необходимое для отслеживания то, что произошло в запросе, когда кто-то еще начинает работать над ним. Со временем это также приносит больше сцепления к Вашим процессам: люди создают маленькие сценарии, чтобы сделать общие задачи, работа, которая сделана, перемещена в управление версиями и т.д.
На моем старом рабочем месте мне сказали, что ничто не могло быть сделано без заявки на устранение неисправности. Когда я спросил, почему, мне сказали, что производительность службы поддержки измерялась при помощи заявок на устранение неисправности. Это имело эффект того, чтобы вынуждать меня использовать заявки на устранение неисправности (так как они требовались), и предоставление мне мотивация, чтобы сделать так (я не хотел, чтобы мои коллеги выглядели плохо).
На моем новом рабочем месте на всю техническую поддержку заключают субподрядный договор. Я буквально должен назвать техническую поддержку, и они создают тикет от моего имени.