Время прихода на работу и дисциплина.

На глаза попалась хорошая статья про два различных подхода к тому должны ли все сотрудники приходить на работу в одно и тоже время, например, строго к 9, или же возможен гибкий график, когда каждый приходит в то время когда, ему удобнее, но соблюдая при этом определенные правила.
Совсем недавно я пытался объяснить руководству, почему я не настаиваю, чтобы сотрудники моего отдела приходили ровно в 9, но вот сам написать такую статью и привести хорошие аргументы, как в этой статье (http://bishop3000.livejournal.com/35767.html) не смог. Думаю, что, если бы я вооружился аргументами из этой статьи, моя позиция была бы убедительнее.

Хорошее описание ошибки.

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

Возьмем, для примера, заявку увидев которую и возникло желание написать этот пост:
Заявка от пользователя, зарегистрированная сотрудником 1 линии поддержки:

Просьба рассмотреть вопрос и принять необходимые меры по внесению своевременных изменений данных в базе товара Axapta. Менеджеры говорят о том, что резервируемое кол-во тех или иных позиций в течение нескольких часов / дня не списывается, что приводит к неверному информированию секретарями клиентов. Таким образом, преподносимая информация на 2-ю половину дня не является актуальной.

А вот ответ более опытного коллеги, сразу чувствуется, что второй матерый:

Не понятно:
Какие своевременные изменения должны происходить в Аксапте?
По словам каких менеджеров?
Что значит резервируемое количество тех или иных позиций?
Что значит резервируемое количество не списывается?
Куда преподносится информация и почему считается, что она не актуальна?
Где смотрится данная информация (полный путь)?
Абсолютно не понятна проблема пользователя.
Следует уточнить, что и где смотрит пользователь, какие данные хочет получить и какие ошибки возникают?
Если пользователь считает что какие то данные не актуальны, то нужны конкретные примеры.

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

Просто покажите новичку такую памятку:

Вопросы, которые необходимо задавать пользователю для уточнения сути возникшей проблемы:

1. При работе в каком приложении происходит ошибка? Программа должна быть одной из списка, программ на сопровождении. При этом требуется узнать конкретное название программы.
2. Какое действие делает пользователь перед возникновением ошибки? Желательно указать пункт меню.
3. Как должно быть? Какой результат ожидал получить пользователь? Например:
   • ввести данные
   • напечатать отчет
   • что еще?
4. Желательно узнать, когда пользователь перестал получать ожидаемый результат. Другими словами, когда работало? Например, «Вчера в 18:30 программа работала, а сегодня в 10:00, уже нет»
5. Если ошибка происходит при входе пользователя в программу, то необходимо выяснить выполнил ли пользователь вход в сеть.
6. Нужно узнать, есть ли еще пользователи, выполняющие такие же (или аналогичные) действия, у которых при этом нет проблем.
7. Если пользователь сообщает о проблеме с каким-то отчетом, то нужно узнать параметры, заданные при формировании отчета.

Каждое хорошее описание ошибки должно содержать ровно три вещи:

1. Какие шаги привели к ошибке.
2. Что вы ожидали увидеть.
3. Что вы в самом деле увидели.

Hyper-V ну очень ожидаемый релиз.

Вот такую вот картинку наблюдал сегодня утром открыв Google Reader комментарии излишни:

Правило умной ошибки.

Хочу рассказать про одно простое правило, которое может здорово облегчить сотрудникам службы поддержки пользователей их работу. Сложность современных бизнес-приложений вообще, и например ERP-систем в частности, такова, что держать все настройки, и все возможные ситуации в голове одному человеку сложно, да и не нужно. Если вы, что то забыли, то всегда можно обратиться к документации, которая поставляется вместе с системой, а также к той документации, которую вы создали сами. Но, вот ведь в чем беда - зачастую для того чтобы решить пустяковую задачку сотрудникам поддержки приходиться "перелопатить" кучу документации, а также потратить немало времени создавая примеры на тестовых приложениях.
Облегчить повседневную работу можно, если использовать правило, назову его правилом умной ошибки, которое состоит в том, что любое сообщение об ошибке или информационное сообщение, которое ваша система выдает на экран, должно содержать идентификатор этой ошибки, по которому можно быстро и легко найти дополнительную подробную информацию о причинах её возникновения.
Приведу простой пример:
Допустим от пользователя поступила заявка, что мол "Я не могу выписать счет, т.к. система ругается "Не указан ответственный менеджер по клиенту ХХХ". Если сотрудник поддержки уже встречался с такой ошибкой, то конечно, он быстро разберется, где в настройках клиента указывается ответственный менеджер, а вот если он встретился с такой ошибкой в первый раз, то вынужден будет вначале самостоятельно разобраться, кто такой ответственный менеджер, за что он ответственный и почему, если он не указан нельзя выписать счет клиенту, где его нужно указать, и кто это должен сделать.
И вот тут на помощь приходит умное сообщение об ошибке, которое могло бы выглядеть, например так: "Не указан ответственный менеджер по клиенту ХХХ (см. NKS-11348)", где NKS-11348 - это ссылка на подробное описание этой ошибки. Описание может быть в виде статьи в базе знаний, или просто ссылкой на какой-то раздел руководства пользователя. Особенно актуальной такая идентификация каждой ошибки становиться, если вы вносите модификации в стандартный функционал вашей ERP-системы. В этом случае даже опытному консультанту без подобной "подсказки" будет трудно разобраться в нестандартном "поведении системы".
Несмотря на всю очевидность и простоту этого правила, к сожалению, разработчики приложений зачастую им пренебрегают. А ведь, если всегда придерживаться этого правила в разработке, то последующая работа с вашим приложением, выполнение настроек и разрешение трудных ситуаций становятся гораздо менее трудоемкими занятиями.