IT-роли: продуктивность и доступность

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

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

Второй тип роли технического специалиста можно обобщённо назвать ролью «поддержки». К профессиям в области поддержки могут относиться сотрудники службы помощи (helpdesk), системные администраторы, специалисты по поддержке рабочих мест (desktop support), специалисты по мониторингу сетей, операторы командного центра и т. д. То, что отличает специалистов по поддержке от инженеров, состоит в том, что они не занимаются творческими процессами, связанными с новыми проектами или внедрениями, а работают с существующими системами, обеспечивая их правильную работу и быстрое устранение неполадок при возникновении проблем.

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

Практический смысл идентификации ролей состоит в понимании того, как измерять и управлять техническим персоналом. Измерение инженеров и управление ими, на высоком уровне, достаточно хорошо изучено. Концепция продуктивности весьма проста и содержательна применительно к инженерным ролям. Цель управления инженером или командой инженеров — создать условия, позволяющие и побуждающие эту роль производить как можно больше творческих проектных решений или реализаций. Разумеется, существует и понятие качества, однако об инженерных ролях всё равно можно думать в относительно конкретных терминах: количество написанных функций, количество созданных пакетов развёртывания, размер спроектированной сети и т. д. Метрики — штука нечёткая, но у нас есть хотя бы общее понимание того, что означает эффективность для инженера, даже если мы не можем точно её измерить.

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

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

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

Роли поддержки являются «событийно-управляемыми». Мне нравится эта терминология, поскольку я считаю её наиболее точно описывающей режим работы почти всех специалистов по поддержке. Является ли событие телефонным звонком, мгновенным сообщением, электронным письмом или тикетом — это «событие», которое инициирует переход специалиста поддержки из состояния ожидания в состояние действия или, в некоторых случаях, от задачи с низким приоритетом к задаче с высоким приоритетом. Так или иначе, событие представляет собой «переключение контекста» для специалиста поддержки. Без события специалисту поддержки нечего делать. Даже если «событие» представлено очередью тикетов или бэклогом электронной почты — это всё равно форма события.

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

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

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

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

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

Итак, думая о том, как управлять IT-специалистами, думайте о назначении их роли. Цель инженера — продуктивность. Цель специалиста по поддержке — доступность.