Даже типовые проекты иногда идут не по плану. Недавно мы сами в этом убедились, когда внедряли Naumen Service Desk в дочерней компании телекоммуникационного холдинга. На старте все выглядело максимально знакомо и привычно. И наша команда пошла путем, который не раз доказал свою эффективность, — выстроила реализацию на основе подхода Waterfall. Однако через некоторое время нам пришлось изменить подход и перейти на Agile. Рассказываем об этом интересном опыте.
На старте
Наш заказчик из
- перевести сервисные процессы на российское ПО (прежде компания использовала зарубежные системы 4me и Equipment Manager);
- автоматизировать регистрацию запросов и их маршрутизацию;
- автоматизировать обновление данных в CMDB за счет сведений, поступающих из корневого мониторинга;
- расширить спектр инструментов самообслуживания для пользователей.
Эти задачи можно отнести к классике внедрения Naumen Service Desk. Такой проект мы относим к типовым и реализуем по модели Waterfall. Она подразумевает планирование работ согласно спецификации, четкую очередность этапов и их последовательное выполнение, а также упрощает управление бюджетом и контроль.
На первом этапе предполагалась развернуть систему на инфраструктуре заказчика, интегрировать ее с корпоративными решениями, в том числе мониторингом, и настроить каталог услуг под потребности компании. На втором этапе предстояло настроить CMDB, портал самообслуживания, уведомления для специалистов поддержки, дашборды. На финальном этапе — тестовая эксплуатация, корректировки и сдача проекта. Все это было согласовано с заказчиком и отражено в документах.
Не по плану
Мы уже приступили к первому этапу проекта, когда выяснилось, что разработанный план не отвечает потребностям заказчика. Точнее, его клиентов. Именно они — заинтересованные лица, именно для них необходимо обеспечить комфортное и продуктивное взаимодействие со службой поддержки. Первоочередные потребности клиентов заказчика не совпали с его собственным видением приоритетов проекта. К сожалению, это выяснилось с некоторым опозданием.

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

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

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