Обсуждение прошлой заметки заставляет меня сформулировать мой тезис бо́льшим количеством слов. Я утверждаю, 1) что номер инцидента создаёт удобства поставщику услуг при решении каких-то внутренних проблем, однако из этого не следует, что для пользователя от знания номера тоже есть какие-то удобства; 2) что для пользователя качество сервиса не повысится от того, что он этот номер знает; 3) качественный сервис можно предоставлять, не сообщая пользователю никаких номеров. Отдельно замечу, что если уж невыносимо хочется пользователю какой-то номер инцидента всучить, разумно ограничиться скромным трёхзначным номером, чем самонадеянно рассчитывать, что пользователь захочет посчитать, сколько нолей в вашем INC000000030889.
Один из комментаторов сказал: «Как руководитель подразделения я точно знаю, что сотрудников дисциплинирует понимание, что раз заказчик знает номер, то разгильдяй будет обнаружен». Мне понравилось: пользу для внутрениих дел поставщика продают, как пользу для потребителя. Нет, не нужен мне ваш номер, дайте качественный сервис.
Однако, иногда я бы хотел знать номер инцидента.
Однажды я пытался стать клиентом «Тачбанка». По каким-то причинам приложение Touchbank отказывалось переводить к себе деньги. После нескольких попыток в течение пары недель я даже не стал обращаться в поддержку. Решил, что лучше не связываться: сейчас не работает пополнение, а вдруг потом не сработает снятие? Месяца через три банк обо мне вспомнил и стал требовать 4 доллара за услуги. Я считал, что никаких услуг банк мне не оказал, больше их н ехотел, и просил расторгнуть наш контракт. Первый тачбанкир, которому я сказал об этом, пообещал, что мне позвонит специальный расторгатель контрактов. Наврал. Поддержка на письма сначала не отвечала, а когда их заставили со мной общаться, повела себя не так, как ведут себя люди, собирающиеся помочь. После второго письма ни о чём я попросил сообщить мне номер моего дела, инцидента, обращения или что у них там. Сделали вид, что не понимают, чего я хочу. Тоже поставили наглеца на место, я надеюсь.
О чём я? Нет, не о том, что если бы я знал номер, то мог бы сообщить его директору банка, и тот уволил бы сначала вруна, а потом любителей из поддержки. Внутренние проблемы банка мне не интересны. Не о том, что знай я номер, мой вопрос решился бы быстро и вежливо. Я говорю о том, что если потребитель требует сообщить ему номер инцидента, это звоночек. Он не доверяет поставщику, он уже верит, или, хуже, знает, что тут работают плохо. Велика вероятность, что он скоро уйдёт. Номер инцидента для него, как соломинка для утопающего — последняя, но часто пустая надежда. Уверенный в поставщике потребитель номеру инцидента предпочтёт продолжение хорошего сервиса.
Краткое содержание предыдущей заметки: короткие номера инцидентов лучше длинных, если вы уважаете пользователя.
Краткое содержание сегодняшней заметки: пользователю номера инцидентов не нужны вообще.
Знание идентификатора своего взаимодействия с поставщиком (INC000000030889) не приносит пользователю никакой пользы. Но этот номер приносит пользу поставщику, даже три:
Первая польза — считается, что оператор или инженер могут найти инцидент только по номеру. Ведь номер уникальный, по нему можно найти ровно один инцидент, если он есть, а если номер неправильный или пользователь его не знает или не помнит, то и разговаривать с ним не о чем. Это миф. Если пользователь обращается по поводу какого-то инцидента, то это точно не инцидент десятилетней давности — ИТСМ-системы столько не живут. Это точно не инцидент пятилетней давности — люди сейчас не работают по пять лет на одном месте. Это даже не пятинедельный инцидент, потому что тем, кто за 5 недель не может решить инцидент, уже должны были позвонить из отдела кадров. Посмотрите в ваши регламенты и SLA, там, скорее всего, написано, что со всеми ожиданиями и откладываниями максимальный срок решения инцидента не больше трёх недель. А за три недели в норме пользователь генерирует полтора инцидента. Так что как только вы идентифицировали пользователя, и он звонит по поводу ранее открытого инцидента, в норма вам не нужно спрашивать у пользователя номер, вам нужно только узнать, идёт речь о вчерашнем инциденте, или об инциденте, открытом на прошлой неделе.
Вторая польза — номер нужен для расследований. «Мы просрочили решение INC000000030889 на 130 недель, кто-то должен за это ответить!» Полностью согласен с постановкой вопроса, но хочу заметить, что это внутреннее дело поставщика услуг, и пользователь тут ни при чём, и номер инцидента ему знать ни к чему.
Про третью пользу недавно читал в чьей-то заметке: «Он нам звонит за помощью, а мы ему [вместо помощи]: „А какой номер инцидента?!“ Поставили наглеца на место!»
Большинство транзакций в жизни мы исполняем, не зная их идентификаторов, а если бы и знали, нам это никак не помогло бы. Мы не обращаем внимания на номер чека в магазине, на номер билета в самолёте, не знаем идентификаторы своих звонков и электронных писем. Не ищем на стоянке свою машину, а на улице свой дом по номеру, как-то обходимся без этого. Точно так же отсутствие номера инцидента не мешает его быстрому решению:
Компания, в которой работает Соня, могла бы заставить её отвечать: «Вашему обращению присвоен номер INC000000030889, oбязательно указывайте этот номер при всех последующих обращениях в службу поддержки!», но вместо этого Соня сразу быстро решает инцидент. Вот бы все так делали!
Конечно, у каждого инцидента есть полезный для поставщика идентификатор, и часто не один. Но не всё, что у вас есть, стоит выкладывать клиенту под нос.
Пару лет, а то и больше, я не слышал от сотрудников ИТ-подразделений слова «юзверь». По-моему, это хорошо: тех, кто нам платит за работу, нужно уважать. Следующим шагом в развитии уважения к пользователю может стать отказ от издевательских номеров обращений.
«Ваш инцидент зарегистрирован под номером INC000000030889. Обязательно указывайте этот номер при всех последующих обращениях в службу поддержки!»
Номер INC000000030889 не подходит ни для запоминания, ни для проговаривания вслух. Особенно мешает ряд нулей, их трудно сосчитать. Вот несколько рекомендаций, как улучшить этот номер.
В параллельной вселенной, где именно такая форма и такая длина номера являются оптимальными, я бы улучшил номер, разбив в нём символы на группы по три: INC 000 000 030 889. Или INC_000_000_030_889, если кто-то опасается, что пользователь не поймёт, что это один номер, а не несколько. Впрочем, для фразы «Ваш инцидент зарегистрирован под номером INC 000 000 030 889» риск непонимания отсутствует.
Для организаций, живущих в реальном мире, вполне достаточно будет номера покороче: INC 030 889 хватит для регистрации миллиона обращений. Много это или мало? Если в норме (константа Конакова) один пользователь генерирует 26 обращений в год, и вы планируете пользоваться этой ИТСМ-системой и её номерами 10 лет, то 6-значных номеров хватит для организации, у которой 3846 пользователей.
А если система продержится дольше 10 лет? Ничего страшного. Нумеруйте обращения и инциденты, как счета-фактуры, начиная с 1 с началом каждого года. Тогда шестизначных номеров хватит для 38 461 пользователя. Если же запускать нумерацию обращений с 1 каждый месяц, то трёхзначных номеров (INC 889) хватит для компании с 500 пользователями. Месяц — слишком короткий промежуток, и возникнет путаница: о каком INC 889 идёт речь, о январском, февральском или мартовском? Во всех SLA, которые я видел, крайние сроки решения выражены в единицах и десятках часов, поэтому если февральский INC 889 ещё не закрыт к моменту появления мартовского INC 889, у этой организации проблемы такого масштаба, которые переход к 6-значным номерам точно не решит.
Приставку INC (REQ, CHG, TAS …) требуют устаревшие ИТСМ-системы, чтобы оператор знал, в каком интерфейсе искать запись. Сегодня поиск устроен, как в «Яндексе»: одно поле ввода, ищет везде. Поэтому вместо принадлежности к интерфейсу (INC 889) полезнее в приставке отразить принадлежность запроса к компании. «Тачбанк» мог бы написать так:
«Вашему обращению присвоен номер TBN 889.»
При чём тут этот банк и куда пропала вторая фраза, про «указывайте номер», читайте в следующих заметках.
Три дня боролся с программой rtorrent — начинает качать быстро, но через 4 минуты скорость падает со 11 500 до 200 килобайт в секунду. Чего только не делал: удалял и переустанавливал, ставил новейшую версию, менял настройки и самой программы, и компьютера, и роутера. Ничего не помогало. Конечно, я ни в настройках, ни в сетях особо не разбираюсь, поэтому все советы, которые я пробовал применить, были нагуглены. И что странно, в точности такая ситуация, как у меня, ни разу не попалась. Похожие — да, но другие, что на русском языке, что на английском. Решение я в конце концов нашёл, и в самом обидном месте: в разделе «Известные ошибки» на странице программы rtorrent. Текст дальше для тех, кто столкнётся с такой ситуацией, как у меня.
Симптомы: rtorrent 0.9.6 / 0.13.6 начинает скачивать на максимальной скорости, но после нескольких (у меня примерно после 4) минут работы скорость падает до 200 КБ/сек, и сам rtorrent начинает очень медленно реагировать на команды. Перезапуск rtorrent не помогает, перезагрузка компьютера помогает, но на те же 4 минуты.
Решение: я сохранял скачиваемое на NTFS-раздел, а в первой строчке в списке известных ошибок написано: rtorrent has issues with ntfs partitions. Когда я перенацелил параметр directory на ext4-раздел, проблема была немедленно и полностью решена.
Problem: rtorrent 0.9.6 / 0.13.6 starts at full speed, but after several (about 4) minutes the speed drops to 200 KB/s or even less. Aslo rtorrent became vary unresponsive to keys pressed. Restarting rtorrent doesn't help. Restarting the computer does, but only for another 4 minutes.
Solution: if you're saving the files to an NTFS partition, please be informed, that rtorrent has issues with NTFS partitions. Point 'directory' parameter to an ext4 partition, and the problem will be solved immediately.
Грустная часть: починив качалку, я вознамерился что-нибудь наконец скачать, но понял, что ничего не хочу.
