Введение

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

Теория

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

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

Проблема

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

Решение

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

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

1. Позволяет регистрировать запросы из любого источника, достаточно настроить интеграцию.

2. Даёт возможность настроить правила обработки (воркфлоу) в зависимости от типа обращения.

3. Регламентирует форму обращения.

4. Позволяет обогащать запросы метками приоритета, критичности или прикреплять файлы.

5. Предоставляет общий доступ к работе с обращениями.

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

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

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

1. Выбор и развёртывание ПО. Подберите систему. В моём случае это была Jira, но сейчас можно найти и российские аналоги.

2. Разработка каталога услуг. Определите типы обращений. Я использовал следующие: запрос на изменение, инцидент, запрос на информацию, другое. 

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

4. Настройка интеграций. Подключите каналы связи — почту, мессенджеры, клиентские порталы, — чтобы ЗНИ не терялись, а поступали в систему автоматически.

5. Определение воркфлоу. Настройте правила обработки обращений в зависимости от их типа или канала по которому они пришли.

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

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

Воркфлоу

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

1. Регистрация запроса — ПМ

2. Первичная классификация и приоритизация — ПМ

3. Анализ и оценка влияния на проект — Аналитик

4. Согласование решения с заказчиком — ПМ

5. Разработка ТЗ — Аналитик

6. Обновление проектной документации — ПМ

7. Подготовка дополнительного соглашения — Юрист

8. Выставление счёта (при необходимости) — Бухгалтер

9. Реализация изменений в проекте — Команда разработки

10. Контроль выполнения и закрытие запроса — ПМ

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

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

Заключение

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