Практически повсеместно в производственных и коммерческих компаниях отделы ИТ сталкиваются со смешанной нагрузкой - часть “проектная”, часть “операционная”.
Как правило, операционная часть воспринимается сотрудниками как неинтересная и рутинная. Однако, от качества выполнения этих рутинных работ зависит то, как внутренние клиенты воспринимают отдел ИТ. Своевременно-ли доставляются сервисы? Быстро-ли устраняются инциденты? Поддерживается-ли адекватный уровень коммуникации с заказчиком во время разрешения проблемы? И так далее.
Понятно, что все ожидания внутренних клиентов от отдела ИТ должно выражаться в виде SLO (Service Level Objectives). Вот только количество сервисов и SLO со временем растет, и сама задача контроля становится тяжелой рутиной.
Если у вас в компании есть процесс ежегодной постановки целей для сотрудников и контроля их достижения, то скорее всего этот процесс запускается в начале года - в течение следующих недель.
В этой статье я хочу поделиться практикой постановки и внедрения S.M.A.R.T. (Specific, Measurable, Attainable/Achievable, Relevant, Time-bounded) целей для операционной части загрузки отдела. Как мы к этому подходили, какие результаты получили и какие побочные эффекты наблюдаем.
В чем, собственно, проблема?
Особенность контроля операционной деятельности
Как правило, пока все идет хорошо - никто не обращает внимание на “текучку”. Обращать внимание начинают когда что-то пробуксовывает. Таким образом, в основном фиксируются только “нарушение ожиданий”. Такой процесс контроля прост, но создает сложность мотивации (”ругают за ошибки, не хвалят когда все хорошо”)
Затраты на администрирование
У вас может быть до нескольких десятков SLO или вспомогательных метрик, которые вы хотите контролировать. Это нужно делать регулярно, и, желательно, проактивно, чтобы избежать нарушений. Если вы хотите ставить и отслеживать персональные цели, то контроль метрик тоже должен быть по каждому сотруднику.
При этом контроль должен быть абсолютно прозрачным для сотрудников и руководства.
Привязка к ежегодным целям
Цель должна быть поставлена так, чтобы учитывать все многообразие (и, возможно, расширение) контролируемых метрик, но без повышение затрат на администрирование.
Должна быть “положительная” мотивация на достижение цели. Нужно уметь оценить ситуацию когда “все хорошо”
Цели необходимо ставить заранее, на весь отчетный период - это необходимо по S.M.A.R.T. Как численно указать ожидания от выполнения SLO с учётом приведенных выше пунктов?
Идея
Идея процесса родилась не сразу, и является синтезом опыта непосредственного управления сервисным ИТ отделом в большой компании, и некоторых процессов контроля качества готовой продукции на промышленном предприятии.
Контроль качества
Как контролируется качество на производстве? Если очень упрощенно: регулярно отбираются образцы, образцы исследуются на все необходимые параметры качества, отклонения от целей фиксируются, по каждому отклонению можно определить насколько качественный продукт.
Однако есть нюанс. Что если продукты разнородные, и контролируемые параметры несопоставимые, а руководство хочет получить простой ответ - наши продукты качественные или нет?
В этом случае есть прием перехода к более абстрактным оценкам. Например: будем “штрафовать” условными баллами за отклонение от цели по каждому параметру, а начисленные баллы суммировать по всем параметрам у образца. Таким образом: чем больше штрафных баллов - тем хуже качество образца.
(Подобный метод применяетя и для оценки качества ML моделей - в качестве "штрафных баллов" выступает значение функции потерь. Чем больше значение функции потерь - тем хуже модель)
Чтобы еще больше упростить восприятие абстрактного качества - можно перейти к интервалам набранных штрафных балов. Например: От 0 до X1 - “Прекрасно”, X1..X2 - “Хорошо”, больше X2 - “Плохо”. И вот такую оценку уже очень легко транслировать напрямую, а при необходимости показать все детали из которых оценка складывается.
Применение к операционной деятельности
Что, если попытаться также оценить “качество операционной деятельности”? По аналогии:
“образцами” становится факт наблюдения текущего состояния сервиса
Нарушение SLO или метрик - контроллируемые параметры. Цель - “0” (не должно быть нарушений метрик)
Штрафные балы начисляются за каждую “нарушенную” метрику. В этот момент мы абстрагируемся от многообразия метрик и а дальнейшем формулируем цели в терминах “штрафных баллов”
Договариваемся об интервалах штрафных баллов - что такое “Отлично”, “Хорошо” и “Плохо”
А теперь, доведем это до процесса регулярного контроля и включим в план годовой оценки:
Будем “собирать образцы” регулярно - раз в неделю, например.
Оценивать SLO и метрики для задач, будем по каждой задаче, которую ведут отдельные сотрудники - тогда и “баллы” будут начисляться сотруднику.
Сумму набранных балов за отчетный период (год) отразим на шкале соответствующей годовой оценки. В разных командах и компаниях это может быть по своему: “от 1 до 5” или “Отлично-хорошо-плохо”, или “Выше ожиданий - В соответвии с ожиданиями - Ниже ожиданий”
Настройки мотивации
“Отлично” по умолчанию
Давайте признаем, что всегда в операционной деятельности бывают “косяки”, и договоримся считать “Отличным” показателем когда количество таких “косяков” не превышает небольшого N. Это поддержит мотивацию сотрудников возможностью достичь высших показателей, оставляя возможность на незначительные огрехи.
“Хорошим” показателем будем считать интервал, соответствующий среднему числу ошибок в работе. Выход за верхний предел “хорошего” интервала будет оцениваться как “Плохо”.
Калибровка целей
По умолчанию нарушение каждой метрики может штрафоваться 1 баллом. Однако, для каждой метрики можно ввести количество штрафных баллов, отличных от единицы. Таким образом можно “тонко” настраивать приоритет метрик в финальной годовой оценке.
Разумеется, интервалы штрафных баллов для оценок "отлично" и "хорошо" могут меняться повышая или понижая общий фокус на операционной деятельности.
Промежуточные поощрения
Можно вводить практики поощрения сотрудников, не получивших штрафных балов за определенный период наблюдений, например 4-6 недель.
Важное замечание #1: “качество образца”
В контроле качества важным аспектом является процесс отбора образцов - как, когда, при каких условиях отбирать образцы, чтобы они адекватно представляли весь объем произведенной продукции.
При применении метода к оценке операционной деятельности это также очень важно.
Частота контроля
Слишком редкий или неравномерный во времени контроль может привести к “всплескам уровня качества”: вспоминать про "текучку" будут только под контрольное мероприятие.
Повышение частоты контроля возможно только если ваш процесс автоматизирован и его “стоимость” не зависит от количества проверок.
Учет загрузки
Ретроспективно пожно сказать: нельзя применять подход без учета загрузки сотрудников. При равной доле операционных ошибок менее загруженный сотрудник будет оценен выше чем более загруженный (“успеха бездельника”). А это уже контр-мотивация.
В контроле качества это достигается “взвешиванием” применяемых штрафов на объем производства, представляемого образцом: чем больше объем продукта в контролируемой партии - тем существеннее выявленные отклонения в качестве.
При контроле операционной деятельности все наоборот: чем меньше было работы ("тикетов") - тем сложнее объяснить снижение качества сервисов (нарушение SLO или метрик). Однако, к сожалению, подход не применим “в лоб”.
Важное замечание #2: “владелец образца”
Если ваши метрики касаются сервисных запросов (”тикетов”), то очень важно с самого начала определить, кто несет ответственность за нарушение метрики. Это может быть отдельный ответственный, все причастные к тикету за все его существование, или те кто отвечал за тикет на момент проведения контроля.
Выбор должен быть обусловлен правилами, которые уже наверняка существуют у вас в компании / отделе. Это решение существенно влияет на модель взаимодействия сотрудников при переназначении заявок внутри отдела.
Реализация
Что обязательно понадобится
Система отслеживания заявок / работ
Это основа функционирования любой операционной деятельности в ИТ. Все задачи, которые находятся под SLO, дожны отслеживаться в системе.
Система должна фиксировать все основные компоненты контролируемых метрик - даты создания, назначения, закрытия тикетов.
Реализация метрик в виде отчетов из системы
Для реализации предложенной идеи все контролируемые метрики должны быть представлены как отчет из системы учета заявок.
При этом отчеты должны подчиняться общей логике:
Каждый отчет должен представлять ровно одну метрику, точнее показывать те работы (тикеты) для которых эта метрика нарушена.
Каждая строка такого отчета должна четко показывать ответственного за нарушение метрики.
Тогда интерпретация отчета для сотрудника будет очень простой: “если ты видишь здесь свое имя - надо открыть тикет X и починить метрику Y”.
Процесс регулярного контроля
Процесс просматривает все отчеты-метрики в контрольные моменты времени.
Сотрудники получают штрафной балл за каждый факт появления их имени в любой строке любого отчета при его просмотре в контрольный момент.
Набранные штрафные баллы сохраняются с указанием контекста:
Когда был применен контроль (дата)
За что были начислены штрафные балы (номер тикета, название метрики)
Сколько балов начислено
Для прозрачности необходимо чтобы общее хранилище штрафных баллов, как и исходные отчеты, были всегда доступны всем для просмотра.
Сотрудник и руководитель должен быть оповещен о начислении штрафных баллов электронным письмом. Желательно также отправлять руководителю сводку о всех штрафных баллах, начисленных всем сотрудникам подразделений в рамках выполнения контроля.
Фиксируйте загрузку сотрудников
Обязательно нужно фиксировать количество задач, назначенных на сотрудника в момент применения контроля. Это понадобится когда вы определитесь с порядком учета загрузки для вывода финальной оценки. Также это поможет увидеть тренд загруженности отдельных сотрудников и всего подразделения.
Для этого, возможно, придется создать дополнительный отчет из системы отслеживания задач.
Что можно сделать дополнительно
“Система раннего оповещения”
Дополнительный процесс может просматривать отчеты чаще, чем наступает контрольный момент и отправлять оповещение сотрудникам, которые получили бы штрафной бал при проверке. Это способ привлечения внимания сотрудников к факту нарушения метрик, но без назначения штрафа.
Оповещение в общий чат
Оповещения о потенциальных штрафах можно публиковать в общем пространстве - рабочих группах. Некоторые ответственные сотрудники отдела могут добровольно взять на себя обязанность напоминания и помощи менее внимательным или более загруженным сотрудникам.
Как внедрять
Собрать статистику прошлых периодов и сделать “dry run”
Поскольку подход построен на мониторинге метрик выполнения заявок, нужно собрать статистику прошлых периодов: общее количество заявок на отдел, среднее количество заявок на сотрудника, количество нарушений SLO (если есть).
Желательно запустить контроль в режиме мониторинга (контроли работают, но начисленные баллы пока не учитываются в годовой оценке), чтобы собрать базовую информацию о текущем уровне выполнения SLO.
Статистику необходимо показывать сотрудникам - каждый сможет увидеть свою статистику и подкорректировать свою работу.
Данные, полученные в ходе мониторинга, помогут сформулировать годовые цели, а также оценить насколько процесса контроля работает.
Полная прозрачность правил и текущего состояния
Регулярные сессии с объяснениями “почему и как” - понадобится для онбординга новых сотрудников, равно как и для напоминания правил существующим.
Правила оспаривания штрафных баллов и “исключительных ситуаций” - может быть полезно приготовить заранее для ситуаций введения новых сервисов и метрик, на период адаптации.
Особое правило для "отчаявшихся". Если сотрудник набирает большое количество штрафных баллов, попадающий в оценку "Плохо", есть риск получить сотрудника, который полностью демотивирован заниматься операционной деятельностью.
Либо придумывайте правила чтобы "можно было отыграться" и сбросить штрафные очки, или двигайтесь по пути эскалации введением более серьезных мер для систематически не справляющихся.
Контроль равномерной загрузки
Если команда загружена существенно неравномерно, необходима дополнительная корректировка начисления или агрегации штрафных баллов с учётом загрузки. Но со многих точек зрения лучше, если все загружены равномерно.
Автоматизация
На стадии запуска и адаптации контроль может осуществлять координатор отдела.
Но после того как процесс стабилизируется, сбор метрик надо автоматизировать. Осуществлять контроль должно что-то, что “не устает, не ходит в отпуск, и не ошибается”.
Результаты нашего внедрения
Систему мониторинга мы начали внедрять у себя в команде (15 человек) в начале 2022. В целом результаты внедрения контроля - очень хорошие: объективно сократилось количество нарушений метрик, все понимают, что ожидается и как будет оцениваться.
Метод также распространен на внешнюю подрядную организацию.
Как проходил запуск
Тестовый период и набор статистики начался в конце января и продолжался до марта (на графике - до красной полосы). Параллельно мы провели несколько сессий в отделе: объясняли подход, планы увязку с годовыми оценками.
С апреля мы запустили контроль полностью. Счетчик всех штрафных баллов был сброшен в ноль, и новые баллы уже шли в годовой план. В результате мы увидели резкое снижение количества "забытого и недоделанного"
Однако, конец апреля и начало мая - период отпусков. Много людей оставили без присмотра свои задачи, что и привело к всплеску штрафных баллов. Пришлось еще раз обговорить, что отпуск - не причина не следовать правилам, задачи надо закрывать или передавать коллегам.
После майской просадки все окончательно поняли "правила игры". Далее все было хорошо (после зеленой полосы на графике) - количества штрафных баллов осталось под контролем.
Всплеск в декабре обусловлен исключительными ситуациями (нестандартные запросы, изменение некоторых процессов). Хотя и "отпускной" эффект отчасти присутствует.
Параметры процесса контроля
Всего контролируется 11 метрик. Подавляющее количество метрик соответствует корпоративным SLO для ИТ, часть представляют обязательства нашего отдела перед нашими внутренними клиентами.
Метрики контролируются еженедельно - каждое утро понедельника. При этом аналогичный корпоративный контроль осуществляется существенно реже - раз в месяц.
Все метрики оценены одинаково - 1 штрафной балл за нарушение.
Если одна задача нарушает сразу несколько метрик - за каждое из них начисляется балл.
Постановка целей
Постановка годовых целей в части операционных задач были сформулированы просто: "Регулярно и качественно осуществлять операционную деятельность. Не допускать нарушения установленных метрик. Цель - ноль нарушений".
При этом перечень и описание всех метрик, контрольные отчеты из системы обработки заявок, текущие результаты контролей, презентации, итд - постонно доступны всем сотрудникам.
Финальная оценка проходила исходя из следующих интервалов баллов, набранных за год:
"Отлично" - 0..5 баллов
"Хорошо" - 6..20 баллов
"Плохо" - более 21 баллов
Из 15 сотрудников в результате получили годовые оценки:
"Отлично" - 7
"Хорошо" - 7
"Плохо" - 1
Наблюдения, некоторые выводы и планы
Классы метрик и влияние контроля
Мы условно разделяем все метрики на два больших класса:
"follow up" - надо проследить, не забыть сделать что-то простое. Например: оповестить пользователя о статусе его проблемы. Таких метрик - большинство.
"analyses" - требует аналитической работы. Например: провести функциональный анализ запроса, подготовить отчет о причине инцидента, и.т.д.
По графику видно, количество штрафных баллов по метрикам "follow up" снизилось гораздо более значительно, чем по метрикам "analyses".
Это можно объяснить одинаковым весом метрик. При этом метрики "follow up" проще поддерживать в требуемом состоянии.
Что сработало хорошо
Ежедневное персональное оповещение сотрудников по почте о нарушении метрик. Письма извещают сотрудников о нарушении метрики до момента проведения регулярного контроля. С учетом выбранной частоты контроля (раз в неделю) это поддерживает необходимый фокус на операционной деятельности и позволяет быстро включить всех в ритм работы.
Ежедневное выкладывание списка нарушенных метрик в отдельный канал MS Teams. Такая общая видимость ситуации породила "групповой контроль" и взаимопомощь.
Регулярный автоматизированный контроль породил необходимость передавать дела коллегам более тщательно перед уходом в отпуск. Поскольку без этого, после отпуска можно было увидеть несколько штрафов за оставленные без присмотра работы.
Еще одна внутренняя инициатива: команда создала отчеты, показывающие потенциальные нарушения метрик, которые наступят в течение следующих недели-двух.
Как и ожидалось, сформулированный по SMART цель на год вызвала ноль вопросов и обсуждений на финальных сессиях годовой оценки деятельности.
Побочные эффекты
"Что не контролируется - не важно". К сожалению, обратной стороной введения контроля по метрикам явилась ситуация, когда деятельность, не покрытая метриками и контролем, становится низкоприоритетной.
"Лучше избегать того, что контролируется". Люди стараются избежать работы над задачами, по которым стоят метрики и осуществляется контроль. Это выражается в передаче таких задач внешним подрядчикам, для которых (пока) строгий персональный контроль не выстроен. Или перевод задачи в иные категории, которые могут контролироваться (пока) слабее. Все понятно, все объяснимо.
Привыкание к ежедневным напоминаниям. Многие сотрудники выстроили свой рабочий процесс вокруг обработки ежедневных напоминаний. Это понижает ответственность сотрудника за контроль собственной работы, и перекладывает контроль на систему. Если в какой то момент система остановится - велик риск, что качество операционной деятельности также упадет.
Что будем улучшать
Ожидаемо, неравномерная нагрузка (в частности из-за #7) привела к тому, что высокие годовые оценки получили сотрудники с наименьшим количеством задач - меньше шансов недоглядеть. В этом году мы введем дополнительные условия финальных оценок в зависимости от количества обработанных задач.
Текущая схема с ежедневными оповещениями все-таки показывает ситуацию нарушений, которые уже состоялись. В новом году мы перейдем к оповещениям по прогнозируемым/ожидаемым нарушениям.
Возможно, "ежедневное напоминание" заменим на "еженедельное", основанное на прогнозе - чтобы вернуть рабочему процессу элемент личной ответственности за планирование работы.
Будем дальше расширять перечень операций и шагов процессов, управляемых метриками.
Вместо заключения
Предложенный подход к контролю операционной деятельности помог нам ставить и отслеживать цели очень прозрачно и просто. И хотя остается большое поле для совершенствования процесса, уже сейчас мы видим явные и измеримые улучшения - их отмечают и внутренние клиенты, и руководство.
Расскажите в комментариях, как у вас организован процесс контроля "текучки"?
А еще, если вы видите подводные камни, скрытые проблемы, или потенциально негативные сценарии применения процесса в предложенном виде - поделитесь. Нам будет о чем подумать и куда развиваться.