ИТ-сервис держится на людях

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

Но давайте посмотрим на действительность. За любой технологией стоят люди. Визионеры, которые придумывают. Архитекторы, которые проектируют. Разработчики, которые создают. И сервисные инженеры, которые делают так, чтобы всё это работало каждый день.

О последних я и хочу поговорить. Про них редко пишут, а зря: когда сервис работает хорошо, его не замечают. Замечают, когда он ломается.

Сто человек — ещё не сервис

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

Не справимся. Массовый набор — не гарантия хорошего сервиса. Иногда — наоборот.

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

Такого человека не найти по объявлению за неделю. И даже если нанять сто хороших инженеров, сервиса ещё не будет. Будет сто хороших инженеров.

Чтобы получился сервис, нужны ещё три вещи.

Первое: команда, а не штатное расписание

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

Я говорю о команде в настоящем смысле слова. Как в футболе. Как в спецназе. Где каждый знает свою роль, понимает, что делает сосед, и может его подстраховать. Где проигрыш — общий, и победа — тоже.

Исследователи Джон Катценбах и Дуглас Смит в известной статье Harvard Business Review дали очень точное определение: команда — это небольшое число людей с взаимодополняющими навыками, которые разделяют общую цель, общие показатели и общий подход к работе — и вместе отвечают за результат (Harvard Business Review, 1993). Ключевое здесь — «вместе отвечают». Пока каждый отвечает только за свою заявку, это рабочая группа, а не команда.

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

И ещё одна вещь, которую я проверял на практике много раз. В хорошей команде инженер не боится сказать: «Я ошибся» или «Я не знаю, как это починить». Американский исследователь Эми Эдмондсон изучила 51 рабочую команду производственной компании и показала: команды, где люди не боятся признавать ошибки и задавать вопросы, быстрее учатся и работают лучше (Edmondson, Administrative Science Quarterly, 1999). В сервисе это напрямую влияет на время восстановления. Инженер, который боится признаться, что не справляется, теряет часы, которые у заказчика стоят денег.

Второе: экосистема, которая работает как часы

Даже сильная команда беспомощна, если работает вслепую.

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

• ITSM-система, где живёт каждая заявка — от звонка пользователя до закрытия. С приоритетами, сроками и понятной маршрутизацией.
• CMDB — база конфигурационных единиц, где видно, что у заказчика стоит, где, в какой версии и с чем связано. Без неё инженер едет на объект, не зная, что найдёт.
• База знаний, где описаны типовые проблемы и решения. Чтобы ночной дежурный не изобретал заново то, что дневная смена решила месяц назад.
• Нотификации, которые приходят нужному человеку в нужный момент. Не всем подряд и не через час после события.
• Мониторинг, который замечает проблему раньше пользователя.

Важно слово «работающая». Внедрить систему — полдела. Мне доводилось видеть ITSM, в которую заявки вносят задним числом, CMDB, которую последний раз обновляли при внедрении, и базу знаний из трёх статей. Формально всё есть. По факту — нет ничего.

Национальный стандарт ГОСТ Р ИСО/МЭК 20000-1-2021 описывает менеджмент ИТ-сервисов как систему, где процессы связаны между собой и постоянно улучшаются (Росстандарт). На практике это значит простую вещь: если один инструмент «врёт», ошибается вся цепочка.

Третье: руководитель, который отвечает

Третий пункт — самый трудный. И, к сожалению, именно его сейчас найти сложнее всего.

Команда должна видеть настоящего руководителя. Не начальника, который пересылает письма. А человека, который:

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

Я много раз видел, как всё это ломается. Инженер приходит к руководителю: «Нам не хватает запасных дисков, через месяц будет проблема». Руководитель отвечает: «Потом обсудим». Через месяц проблема случается. На разборе виноват инженер, который «не эскалировал».

После двух-трёх таких историй инженеры перестают приходить. Зачем, если всё равно не услышат? И руководитель остаётся без главного источника информации о том, что происходит на самом деле.

Эдмондсон в своём исследовании отдельно отмечает: на то, насколько люди в команде готовы говорить о проблемах, влияет и поведение руководителя (Edmondson, Administrative Science Quarterly, 1999). Говоря проще: команда смотрит на руководителя и делает выводы.

Без любого из трёх — заложник

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

Если убрать любое из них, конструкция начинает шататься:

• команда без экосистемы — героизм, который выгорает за год;
• экосистема без команды — дорогие системы, в которых никто толком не работает;
• команда и экосистема без руководителя — сильные люди, которые постепенно уходят туда, где их слышат.

А в итоге в заложниках оказывается заказчик. Он платит за сервис, а получает лотерею: повезёт с дежурным — починят быстро, не повезёт — ждите.

Хороший сервис — это когда заказчику не нужно везение. Роботы и искусственный интеллект в этом помогут. Но построить такой сервис по-прежнему могут только люди.