«Ничего не работает». Ладно, а что именно?

«Ребят, у меня ничего не работает». Восемь слов. Ни скриншота, ни названия программы, ни текста ошибки.

Через минуту в общем чате ИТ появляется ответ: «Перезагрузитесь». Ещё через десять — «Не помогло». Ещё через полчаса инженер поднимается на третий этаж, садится за чужой ноутбук и за четыре минуты выясняет, что человек пытался открыть отчёт в CRM. Отчёт не открывается. И не только у него — у всего отдела продаж, потому что в пятницу вечером выкатили обновление.

Полтора часа от сообщения до понимания. Полезных в них — минут пятнадцать.

«Ничего» — это не преувеличение

Соблазн — прочитать такое сообщение как каприз. Мол, взрослый человек, работает в компании четвёртый год, мог бы и написать по-человечески.

Но «ничего не работает» — на самом деле довольно точное описание. Просто оно описывает не систему, а состояние человека в 9:12 понедельника. Он открыл ноутбук, собирался сделать одну конкретную вещь, и эта вещь не сделалась. С его точки зрения сломалось всё, потому что всё, что ему сейчас нужно, — вот эта одна вещь.

Для бухгалтера «ничего» значит, что не открывается 1С. Для менеджера — что не грузится карточка сделки. Для склада — что принтер этикеток печатает пустое. Три разных инцидента, три разных исполнителя, три разных срока. И одно и то же сообщение в чате.

Человек не знает вашей номенклатуры сервисов. Он не обязан отличать проблему с доступом от проблемы с сетью, а падение сервиса — от истёкшего профиля VPN. Требовать от него правильной формулировки — это примерно как требовать от клиента автосервиса, чтобы он вместо «стучит спереди» сразу называл узел.

Так что вопрос не в том, как приучить сотрудников писать грамотные заявки. Приучить, кстати, можно — на месяц-полтора, после большой рассылки про правила обращения в поддержку. Потом всё возвращается, потому что в момент поломки человек думает не про правила, а про то, что у него горит.

Вопрос в другом: что спросить в ответ.

Почему «пришлите скриншот» — плохой первый ход

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

Потому что он смещает разговор не туда.

Во-первых, скриншот приходит не сразу. Человеку надо вспомнить сочетание клавиш, найти, куда сохранилось, перетащить в чат. У части сотрудников это занимает пять минут и одно раздражение. За эти пять минут вы не узнаёте ничего.

Во-вторых, он часто показывает не то. Люди фотографируют экран телефоном, обрезают самое важное, присылают момент после того, как окно уже закрылось. «Вот, смотрите» — и на картинке пустая таблица без единого признака причины.

В-третьих, и это главное: скриншот показывает симптом, но молчит о контексте. На нём не видно, что человек делал до, работало ли это в пятницу и есть ли такое же у соседа. А именно контекст сужает поиск.

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

Первый вопрос: что вы пытались сделать

Не «какая ошибка». Не «что именно не работает». Не «пришлите скриншот».

«Что вы пытались сделать, когда это случилось?»

Разница тонкая, но она решает. «Какая ошибка» — вопрос про систему, и человек, который не разбирается, отвечает на него плохо: «Ну, красное такое». «Что вы пытались сделать» — вопрос про него самого, и на него он отвечает мгновенно и точно: «Хотела выгрузить отчёт по марту».

Из этого ответа сразу становится видно три вещи. Какой сервис задействован. Какой у задачи приоритет — отчёт по марту в понедельник утром может быть срочнее, чем кажется. И что человек будет считать решением: не «мы починили сервис», а «я выгрузила отчёт».

Побочный эффект: после этого вопроса скриншот часто приходит сам. Человеку становится понятно, что с ним разговаривают, а не отмахиваются, и он идёт снимать экран без просьбы.

Второй вопрос: когда это работало в последний раз

Этот вопрос отделяет два совершенно разных инцидента, которые в чате выглядят одинаково.

Если ответ — «в пятницу вечером работало», это поломка. Что-то изменилось между пятницей и понедельником: обновление, права, срок действия сертификата, чья-то правка в настройках. Искать надо в изменениях.

Если ответ — «никогда, мне вчера выдали ноутбук», это не поломка. Это незавершённая настройка. Совершенно другая работа, другой человек её делает, и никакие логи сервиса тут не помогут.

А если ответ — «работало утром, а после обеда перестало», это третья история: ищем, что произошло между. И почти всегда находим.

Формулировка важна и здесь. «Когда это работало в последний раз» звучит нейтрально. «А раньше работало?» звучит как «вы точно всё правильно делаете?» — и человек начинает защищаться вместо того, чтобы вспоминать.

Третий вопрос: у соседа так же?

Самый недооценённый из трёх. Он за одну реплику меняет масштаб инцидента.

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

Без этого вопроса инженер по умолчанию считает, что случай единичный, и полчаса ковыряет один ноутбук. Потом приходит второе такое же сообщение, и всё начинается заново.

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

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

Поэтому вопрос задают с готовым выходом. «Если рядом есть кто-то, кто делает то же самое, — спросите одного, это сразу сузит поиск. Если рядом никого, ничего страшного, разберёмся так». Человек делает ровно одно движение и не чувствует, что на него переложили работу.

Как это выглядит в переписке

Компания на сто с небольшим человек, ИТ-поддержка — два инженера и общий чат. Помощник в этом чате отвечает первым, круглосуточно, и его работа заканчивается там, где начинается ремонт.

9:12, Ирина, отдел продаж: «Всем привет, у меня ничего не работает 😔»

9:12, помощник: «Доброе утро, Ирина. Сейчас разберёмся. Что вы пытались сделать в тот момент, когда стало не работать?»

9:13, Ирина: «Отчёт по продажам за март выгрузить. Нажимаю — крутится и потом пусто.»

9:13, помощник: «Поняла. Когда этот отчёт открывался в последний раз?»

9:14, Ирина: «В пятницу вечером делала такой же, всё было нормально.»

9:14, помощник: «Спасибо. Последнее: у коллег рядом отчёты открываются? Если можно, спросите одного-двух — это сразу сузит поиск.»

9:19, Ирина: «У Лены тоже пусто. У Максима говорит открывается, но он из дома.»

Дальше помощник собирает заявку и отдаёт её живому инженеру. В заявке написано не «ничего не работает», а вот что: не открывается отчёт по продажам в CRM, работало в пятницу вечером, воспроизводится минимум у двоих в офисе, у сотрудника на удалёнке не воспроизводится.

Инженер читает это в 9:24 и через шесть минут находит причину. В пятницу вечером обновляли CRM, у группы «Продажи» при обновлении слетело право на выгрузку отчётов в офисной сети — то самое, которое в домашнем профиле выдавалось отдельно и потому уцелело. Право вернули в 9:41. Ирина выгрузила отчёт в 9:44.

Дальше произошло то, ради чего вообще задавался третий вопрос. В 9:26, ещё до починки, инженер написал в общий рабочий канал одну строку: «Видим, что не выгружаются отчёты в CRM у отдела продаж из офиса. Чиним, отпишусь». За следующие двадцать минут в ИТ-чат не пришло ни одного нового обращения по этой теме — хотя отчёты в понедельник утром выгружают человек восемь. Лена, у которой было то же самое, просто подождала.

Без третьего вопроса эта строка не появилась бы. Инженер разбирался бы с ноутбуком Ирины, а остальные семеро писали бы по одному, и каждому кто-то отвечал бы «перезагрузитесь».

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

Кто задаёт эти вопросы

Теоретически их может задать и человек. Практически — не задаёт.

Дежурный инженер в 9:12 понедельника разбирает почту, догоняет пятничные хвосты и параллельно смотрит на мониторинг. Сообщение «ничего не работает» он видит, вздыхает и отвечает первое, что не требует включения головы: «Перезагрузитесь». Не потому что плохой специалист, а потому что три вопроса — это три переключения контекста, и каждое стоит ему минут.

Есть ещё одна вещь, которая решает больше, чем кажется. Скорость первого ответа.

Если ответ приходит в 9:12, человек ещё сидит перед экраном и помнит, что делал. Если в 9:40 — он уже ушёл за кофе, отвлёкся на звонок, и теперь ответ «когда это работало в последний раз» требует от него усилия по вспоминанию. Часть точности теряется просто из-за паузы.

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

Вопрос, который лучше не задавать

Есть четвёртый вопрос, который напрашивается сам и портит всё.

«А вы точно нажимали ту кнопку?» В разных видах: «вы уверены, что вводили правильный пароль», «а вы перезагружались», «у всех работает, странно».

Формально это нормальная проверка. Опечатки в пароле действительно случаются чаще, чем падения сервисов. Перезагрузка действительно решает заметную часть случаев. Беда в том, как это звучит с той стороны.

С той стороны это звучит как «вы, наверное, сами напутали». Человек, который и так чувствовал себя неловко из-за того, что отвлекает занятых людей, получает подтверждение: он тут не с проблемой, а с собственной неаккуратностью. Дальше одно из двух. Либо он начинает оправдываться и пересказывать, какой он внимательный, — и вы теряете две минуты на разговор не о том. Либо в следующий раз он вообще не напишет, а будет полдня мучиться сам или попросит соседа что-нибудь нажать за него. Второе хуже: такие случаи в статистику поддержки не попадают вообще.

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

Заявки, где уточнять уже поздно

Честно про границы, иначе получится реклама.

Когда человек в панике. «У меня через пять минут презентация клиенту и не работает экран» — не место для трёх вопросов по порядку. Здесь нужен один: «Вы в переговорке или у себя?» — и живой человек с запасным кабелем. Помощник должен уметь распознавать такие сообщения по признакам срочности и сразу передавать их, а не вести диалог.

Когда инцидент массовый и уже известен. Если сервис лежит и в ИТ это знают, задавать сотруднику три вопроса — издевательство. Правильный ответ: «Да, мы видим, чиним, напишем, когда поднимется». Это значит, что у помощника должен быть доступ к текущему статусу инцидентов. Без него он будет бодро опрашивать сороковую жертву одного и того же сбоя.

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

И главное: это не анкета. Соблазн превратить три вопроса в форму из семи полей — с категорией, приоритетом, инвентарным номером и выпадающим списком сервисов — возникает всегда. Каждое добавленное поле выглядит разумным. Все вместе они приводят к тому, что сотрудники перестают писать в чат и начинают ходить к инженеру ногами, потому что так быстрее. Три вопроса работают именно потому, что их три и они звучат как разговор.

Заявка, с которой можно начать работу

Если убрать всё лишнее, три ответа складываются в одну строку, и эта строка — и есть заявка.

Не «пользователь сообщает о проблеме». А: что человек делал, когда это в последний раз получалось, у кого ещё так же.

Вот из чего состоит разница между «пойди посмотри, там что-то у Ирины» и «не открывается выгрузка отчётов в CRM, работало в пятницу, воспроизводится в офисной сети минимум у двоих». Первое — это поручение сходить и разобраться. Второе — это задача, у которой уже есть гипотеза.

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

Попробуйте как-нибудь посмотреть в свой ИТ-чат за прошлую неделю и найти там сообщения, в которых нет ни одного из трёх ответов. А потом — сколько сообщений понадобилось, чтобы эти ответы появились.

Сколько их было в среднем: два? пять? И в какой момент разговор наконец начался?