От ТЗ к бэклогу: зачем мы поменяли подход посреди проекта

Даже типовые проекты иногда идут не по плану. Недавно мы сами в этом убедились, когда внедряли Naumen Service Desk в дочерней компании телекоммуникационного холдинга. На старте все выглядело максимально знакомо и привычно. И наша команда пошла путем, который не раз доказал свою эффективность, — выстроила реализацию на основе подхода Waterfall. Однако через некоторое время нам пришлось изменить подход и перейти на Agile. Рассказываем об этом интересном опыте.

На старте

Наш заказчик из телеком-отрасли специализируется на техническом обслуживании клиентов, и при внедрении новой ИТ-системы он ставил следующие цели:

• перевести сервисные процессы на российское ПО (прежде компания использовала зарубежные системы 4me и Equipment Manager);
• автоматизировать регистрацию запросов и их маршрутизацию;
• автоматизировать обновление данных в CMDB за счет сведений, поступающих из корневого мониторинга;
• расширить спектр инструментов самообслуживания для пользователей.

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

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

Не по плану

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

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

Как вышли из ситуации

Решение увидели в радикальном изменении подхода к реализации проекта. С учетом новых обстоятельств, подходящим выглядел Agile. Он оставляет возможность для новых вводных, работы с ними и основывается на относительно краткосрочных итерациях — спринтах. Это позволяет избежать планирования на большой период и строить работу в зависимости от наиболее важных на текущий момент задач. Мы согласовали смену подхода с заказчиком и перестроились на гибкую методологию.

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

Так как при таком подходе объем работ по проекту не является фиксированной величиной, формат взаимоотношений с заказчиком перестроился ближе к модели Time&Material. Она подразумевает оплату фактически затраченных часов на работу каждого участника проекта.

Как прошло

Переход с Waterfall на Agile произошел значительно проще, чем ожидали. Нам хватило буквально дня, чтобы перестроиться. Значительно упростило дело то, что мы ведем проекты в автоматизированной системе Naumen Project Ruler. В ней собрана вся информация, которой владеем: зафиксированы решения, договоренности, согласования, документы, работы, задачи, риски и бюджет. При смене формата нам нужно было только сделать дополнительные настройки.

Выводы

1. Даже в типовых проектах нужно быть готовым к неожиданностям, которые вряд ли можно предусмотреть через работу с рисками. Но бояться их не нужно.
2. Сменить подход к реализации проекта прямо на ходу — возможно.
3. При разработке проекта по автоматизации сервисных процессов необходимо учитывать не только цели заказчика, но и конечных пользователей услуг.
4. Ведение проекта в автоматизированной системе позволяет оперативно и гибко реагировать изменения.