Введение

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

Теория

По классике — водопадной модели (Waterfall) по PMI, управление изменениями — это регламентированный процесс, где каждый запрос на изменение (ЗНИ) проходит через несколько этапов: регистрация, анализ требований, оценка, согласование с управляющим комитетом и, если нужно, корректировка бюджета. Все изменения нумеруются и записываются в лог изменений, чтобы ничего не потерялось. В Agile всё проще и гибче: ЗНИ попадают в Product Backlog, где Product Owner решает, что делать дальше, ориентируясь на ценность для клиента и бюджет спринта.

Этап воркфлоу	Waterfall (PMI)	Agile
Регистрация	ЗНИ фиксируются в логе изменений. Каждый запрос получает номер и описание.	ЗНИ добавляются в бэклог как user stories или задачи.
Анализ влияния	Команда анализирует влияние на бюджет, сроки и ресурсы.	Оценка в story points или часах, с учётом бюджета спринта и ценности для клиента.
Приоритизация	Управляющий комитет (Steering Committee) утверждает или отклоняет запрос, исходя из бюджета и целей.	Владелец продукта (Product Owner) приоритизирует в backlog, балансируя ценность и затраты.
Реализация	ЗНИ реализуются на соответствующем этапе (разработка, тестирование).	ЗНИ включаются в спринт или планируются на релиз.

Как видите, вне зависимости от того, какую методологию вы используете, процесс обработки ЗНИ делится на одни и те же этапы: регистрация, анализ, приоритизация (принятие решения о реализации) и разработка.

Проблема

Проблема в том, что ЗНИ могут прилетать неожиданно и по любому каналу — через почту, мессенджеры или устно на созвоне, и не всегда реципиент запроса - это тот человек, который может провести запрос правильно по всей цепочке решений. Если запрос не попадёт к менеджеру проекта, он может затеряться, а его дальнейшая судьба останется загадкой. Чем это может грозить? Если запрос потеряется, это может усложнить отношения с заказчиком. Если пообещать клиенту всё сделать, то может пострадать бюджет. Что делать? Как не потерять обращение и провести его по правильному пути таким образом, чтобы все стороны могли правильно оценить влияние данного запроса на будущее проекта?

Решение

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

Что такое service desk

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

Service Desk обычно используется для регистрации, мониторинга и управления инцидентами, запросами и проблемами, связанными с IT-сервисами, а также для коммуникации с пользователями и координации работ по решению проблем. Service Desk также может обеспечивать функции управления изменениями, управления конфигурациями и управления уровнем сервиса».

Преимущество такой системы состоит в том, что она:

Позволяет регистрировать запросы из любого источника, достаточно настроить интеграцию.
Даёт возможность настроить правила обработки (воркфлоу) в зависимости от типа обращения.
Регламентирует форму обращения.
Позволяет обогащать запросы метками приоритета, критичности или прикреплять файлы.
Предоставляет общий доступ к работе с обращениями.

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

Как подготовиться к работе с service desk

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

Выбор и развёртывание ПО. Подберите систему. В моём случае это была Jira, но сейчас можно найти и российские аналоги.
Разработка каталога услуг. Определите типы обращений. Я использовал следующие: запрос на изменение, инцидент, запрос на информацию, другое.
Создание шаблонов обращений. Для каждого типа обращения разработайте шаблоны с обязательными полями. Для ЗНИ это может быть: блок функционала (где требуются изменения), сценарий использования, критерии приёмки, и т.п.
Настройка интеграций. Подключите каналы связи — почту, мессенджеры, клиентские порталы, — чтобы ЗНИ не терялись, а поступали в систему автоматически.
Определение воркфлоу. Настройте правила обработки обращений в зависимости от их типа или канала по которому они пришли.

Как обрабатывать запросы

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

Трудоёмкость \ Критичность	До 8 часов	До 40 часов	Более 40 часов
Высокая	Добавлять в проект без изменения в бюджете	Анализ, риски, ТЗ, доп. соглашение к договору	Анализ, риски, ТЗ, доп. соглашение к договору
Средняя	Добавлять в проект без изменения в бюджете	Перенести на этап техподдержки	Заказ на доработку после проекта
Низкая	Перенести на этап техподдержки	Перенести на этап техподдержки	Заказ на доработку после проекта

Воркфлоу

Теперь последовательность действий в плане «Максимум» выглядит следующим образом:

Регистрация запроса — ПМ
Первичная классификация и приоритизация — ПМ
Анализ и оценка влияния на проект — Аналитик
Согласование решения с заказчиком — ПМ
Разработка ТЗ — Аналитик
Обновление проектной документации — ПМ
Подготовка дополнительного соглашения — Юрист
Выставление счёта (при необходимости) — Бухгалтер
Реализация изменений в проекте — Команда разработки
Контроль выполнения и закрытие запроса — ПМ

Для любителей диаграмм — в виде диаграммы.

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

Заключение

Подход с использованием системы Service Desk, скорее всего, подходит не для всех случаев, так как его внедрение связано с определенными издержками: необходимо приобрести и развернуть систему, обучить сотрудников работе с ней, а также согласовать процессы с заказчиком. Скорее всего, он будет наиболее полезен для компаний, реализующих крупные проекты с большим числом участников. В таких проектах Service Desk позволит держать изменения под контролем, обеспечит прозрачный процесс обработки запросов, что, в конечном итоге, поможет держать бюджет в узде, контролировать сроки и поддерживать конструктивные отношения с заказчиком.

Управление изменениями в проекте с помощью service desk