Бэклог vs.ТЗ: сменить подход к планированию и не развалить проект для телеком-холдинга

В проектном менеджменте всегда есть риски. Запасаться планами на все возможные случаи, быстро принимать решения, передоговариваться и менять что-то по ходу — с этим столкнулась и команда внедрения Naumen Service Desk. При запуске ITSM-системы в дочернюю компанию телеком-холдинга ей пришлось отказаться от утвержденного техзадания и перейти на планирование по спринтам. Почему это произошло, как удалось завершить проект и сохранить продуктивные отношения с заказчиком, рассказывает Максим Платицин, руководитель отдела проектного управления Naumen. 

О проекте

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

Раньше для обработки клиентских обращений в компании использовали две зарубежные системы от 4me и Equipment Manager. От этих решений пришлось отказаться из-за недостаточной функциональности и рисков, связанных с невозможностью обновлений после ухода иностранных поставщиков из России.

В качестве замены выбрали Naumen Service Desk. Базовая конфигурация позволяла быстро запустить нужные процессы, а настройка с помощью Low-code — постепенно реализовывать недостающие функции и интеграции. Например, заказчик планировал организовать прием заявок через Telegram.

Ключевые цели заказчик формулировал так:

1. Импортозамещение зарубежных систем для управления ИТ-услугами с расширением функциональности для удобства пользователей, например, за счет подключения инструментов самообслуживания.
2. Автоматизация процессов первой и второй линии поддержки, таких как регистрация и распределение запросов.
3. Автоматическое наполнение и ведение системы управления конфигурацией (CMDB) на основе данных инфраструктурного мониторинга.

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

Этап 1. Развертывание базовой конфигурации решения, с настройкой каталога услуг и интеграцией с системой мониторинга.

Этап 2. Настройка CMBD, а также дополнительной функциональности, например, портала самообслуживания, дашбордов, системы уведомлений для сотрудников поддержки.

Этап 3. Тестовая эксплуатация, доработка и сдача проекта.

С какими сложностями столкнулись

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

По ходу проекта столкнулись с тем, что часть задач заказчику потребовались «вперед плана». И это привело к трудностям в работе. Команда не могла остановить активности, которые уже стартовали, иначе пострадали бы другие этапы.

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

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

Кроме того, на практике оказалось, что понимание ценности определенной функциональности системы со стороны заказчика не всегда совпадает с ожиданиями непосредственных пользователей. Вместе с невозможностью мгновенного внесения изменений в исходный план, который виделся нам оптимальным, это породило дополнительные трудности.

Сбор требований к проекту должен учитывать все стороны, которые будут оценивать результаты

Как решили проблему

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

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

Составили общий бэклог. Все работы, указанные в спецификации для каждого этапа, собрали в единый список с помощью нашей корпоративной системы управления проектами Naumen Project Ruler. В ней мы ведем все проектные задачи и фиксируем всю переписку с заказчиком.

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

Свели задачи в единое техническое задание. Сформировали новый список и согласовали смену подхода с заказчиком. Фактически наш договор стал больше похож на модель Time&Material.

 В рамках каждой трехнедельной итерации сначала оценивали ценность задач и только затем запускали в работу

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

В Naumen Project Ruler все задачи спринта можно сопоставить с целями на одном экране и далее оценить, верно ли определен список работ для достижения результата
Рекомендации и выводы

Хотя проект внедрения ITSM-системы столкнулся с определенными рисками и трудностями, мы успешно преодолели их с помощью перехода на гибкое планирование.

Этот ценный опыт можно обобщить в виде советов, которые пригодятся каждому проектному менеджеру:

1. Собирать больше информации о проекте. Чтобы избежать недопонимания по ходу работ, важно определить всех заинтересованных в результате лиц, пообщаться с ними и узнать ожидания. Так будет проще планировать активности и выбрать оптимальный подход к управлению проектом.
2. Вести задачи в единой системе. Если бы мы вели коммуникации с заказчиком в мессенджерах, почте и других каналах, пришлось начинать проект с нуля. Благодаря тому, что задачи и комментарии к ним хранились централизованно, нам удалось перестроить процессы.
3. Выбирать гибкие решения для управления проектами. Naumen Project Ruler стал ключевым инструментом для успеха проекта, поскольку он поддерживает гибридный подход к планированию. Нам не потребовалось резко менять инструменты и это сэкономило много времени и сил команды.