Практика использования Agile подхода в проекте внедрения электронного архива в «кровавом enterprise»

Автор: Андрей Карасов, руководитель отдела продаж BTLab

Пару лет назад мы стали работать с заказчиком, который не хотел писать больших и сложных ТЗ. И мы решили работать в методологии Agile – получилось невероятно круто. Тиражировать это «невероятно круто» сложно. Но обо всех плюсах, минусах и тонкостях мне бы хотелось рассказать в этой статье.

Успех внедрения новой ИТ-системы зависит от коммуникации, которая сложится между командами заказчика и интегратора. Пока гибкие методологии ведения проекта вроде Agile, Scrum набирают популярность и признание, в проектах внедрения ИТ-систем взаимодействие интегратора и заказчика чаще всего строится по водопадной системе.

Традиционный waterfall подход

Традиционно внедрение осуществляется поэтапно:

1. Подготовка технического задания.

2. Базовые настройки ИТ-системы, автоматизация процессов по ТЗ.

3. Настройка дополнительных требований в системе.

4. Интеграция с другими ИТ-системами.

5. Обучение пользователей и ввод системы в эксплуатацию.

6. Сопровождение системы, техническая поддержка.

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

Запрос клиента

Год назад к нам обратился заказчик — крупный девелопер в России. Его задача – внедрить новую ИТ-систему для электронного архива. Для этого заказчик выбрал платформу Docsvision. Но уже на старте команда заказчика была категорично настроена против громоздких и больших ТЗ на проект. И нам как исполнителю ничего не оставалось, как попробовать вести проект итеративно. Результат – успешный проект, который обрастает теперь новыми фичами, довольная команда заказчика, увлечённая команда с нашей стороны, а руководство заказчика приводит в пример другим этот кейс быстрого внедрения. Но мне бы хотелось поделиться, какие условия стоят за этим.

Agile-подход к проекту внедрения Docsvision

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

2. Собранные требования мы фиксируем в кейс-стори и реализуем в тестовой среде ИТ-системы.

3. На еженедельном демо показываем прогресс по настройке новой фичи. Если есть дополнения, изменения ТЗ, то доработка фичи уходит на новый виток. И так до тех пор, пока функциональность не будет доведена до готовности к промышленной эксплуатации.

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

5. Пользователи накапливают пожелания к внедрённой функциональности в процессе работы, которые реализуются за спринт.

Сколько будет спринтов в процессе реализации требования, зависит от сложности требования, от того, насколько верным было представление о реализации. Бывает, что уже на первом демо понятно, что требования были некорректными, требуется пересмотреть постановку задачи. В целом, скорость доставки новой функциональности в систему высокая — каждые 2 недели мы обновляем ИТ-систему на базе платформы Docsvision заказчику, добавляя новые фичи. При этом мы не развиваем тупиковые идеи или задачи, то есть не доводим их даже до системы.

Преимущества Agile для команды разработки и заказчика:

1. Требования к системе быстро реализуются на платформе Docsvision настройками, доработками, но это также позволяет сам продукт.

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

3. В ТЗ фиксируется требование по автоматизации процесса кратко, команды не тратят время на детальную проработку.

4. Обучение новых пользователей происходит параллельно.

5. Приоритет в работе — важным функциям, которые определяются будущими пользователями системы.

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

Agile-подход к проекту дал нам многое, но даже тут есть по ложке дёгтя для каждой команды.

Минусы для заказчика в применении Agile:

1. В начале сотрудничества у заказчика «на руках» была ещё не настроенная до конца система с неполной функциональностью. И требуется доверять исполнителю, проявлять терпение и понимание, чтобы спустя время получить то, о чём договорились.

2. Рост финансовых затрат на реализацию функциональности, если она не была с первого раза правильно описана, если задача поставлена некорректно. Но, с другой стороны, нет необходимости платить за реализацию функциональности, которой никто не будет пользоваться, но на момент проектирования она казалась необходимой.

Вызовы для команды интегратора:

1. Необходимость выдерживать высокий темп, чтобы исполнять договорённости в срок, сформировать доверие. Необходимость дополнительно быстро изучать бизнес заказчика.

2. Не огорчаться, если первая реализация функциональности оказалась неверной из-за неправильной постановки задачи.

3. Исходя из нашего опыта, мы бы хотели чаще работать в рамках Agile-методологии в проектах, но видим ограничения. Вряд ли их удастся сломить.

Почему Agile сложно тиражировать в другие проекты

1. Высокий и равный уровень компетенции команд с двух сторон.

2. Традиционно на российском рынке большинство контрактов — это не Time&Material, а заказы на внедрение конкретной системы с конкретным функционалом.

3. Неизменный состав команды проекта с двух сторон и необходимость сильного погружения в проект и включённость со всех сторон. Часто у заказчиков не хватает времени и ресурсов на работу с интегратором.

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