Который раз встречаюсь с проблемой обеспечения качества при выполнении работ, в которых задействовано несколько групп ИТ-специалистов. Тема всплывает в поддержке, в обработке изменений, управлении конфигурациями. В каждой области со своими нюансами, но неизбежно в обсуждении проблемы присутствуют формулировки класса: "это не наша вина, мы свою часть сделали вовремя (качественно)".
Если взять, к примеру, поддержку, то проблема звучит так "обращение просрочено, но все участники уверены, что они не виноваты, т.к. они свою часть работы выполнили в срок и с должным качеством".
В управлении конфигурациями проблема может принимать вид "сервер установлен, но связи с прикладным ПО в CMDB не установлены, т.к. прикладники ждали, что это сделают инфраструктурщики, а инфраструктурщики, которые ПО не ставили, считали, что это должны делать прикладники".
В управлении изменениями результат реализации изменения не всегда соответствует ожиданиям, т.к. отдельные части изменения (например, подготовка стойки, подготовка сервера, подготовка сетевого сегмента) выполнены безупречно, но ожидаемый результат в виде работающего сервера не достигнут, т.к. собрать все воедино не удалось.
Несмотря на то, что приведенные примеры касаются разных процессов, давайте попробуем перечислить общие задачи, решение, которых поможет избежать проблем такого характера:
1. Четкое разграничение ответственности. Идеально если при разграничении ответственности зафиксировано не только то, за что отвечает та или иная группа, но явно указано, за что она не отвечает (спорные области). Например, за актуализацию связей прикладного ПО с серверами отвечают прикладники, которые устанавливают ПО.
2. Параметры качества выполнения работ отдельной группой. Работа должна быть не просто выполнена, но и соблюдены определенные параметры выполнения. Например, в случае с поддержкой это может быть время взятия в работу, время выполнения определенных видов работ и т.д.
3. Принципы передачи работ между группами. Необходимо определить, как результаты работ одной группы передаются другой. Возможно, для некоторых работ потребуются критерии приемки, возможно – документирование. Например, в случае реализации изменения – передача результатов работ с предыдущих этапов изменения.
4. Централизованный контроль. Способ реализации тоже зависит от процесса. Например, в управлении конфигурациями контроль может осуществляться координатором конфигураций определенной области инфраструктуры, в процессе управления инцидентами контроль может осуществляться старшим первой линии, в управлении изменениями – менеджером процесса или ответственным за конкретное изменение.
Список можно продолжить, если есть идеи – предалагайте 🙂
Ни раз всплывало “С нашей стороны пуля вылетела” , “На нашей стороны проблем нет” , “Мы ничего не меняли”.
В сложных ситуациях требуется посредник между 2-3 функциями и зачастую менеджер инцидента, который в некоторых компаниях является сотрудником 1-й линии, не обладает достаточной компетенцией\доверием повлиять на ситуацию.
Иногда спасает вторжение сервис менеджера или компетентного (или верхнеуровневого) руководителя, но при этом ожидаемые сроки исполнения заявки или разрешения инцидента уже прошли … давно.
Имхо эта ситуация рождается из-за отсутствия согласованных правил эскалации и контроля за их соблюдением.