Agile для ускорения проектов автоматизации

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

Максим Якубович– эксперт Академии управления WINbd, соучредитель и директор по проектам компании «ДрайвИТ», Agile-коуч, консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас», преподаватель курса «Управление проектами» в РАНХиГС.

Начнем с большого кейса, который я реализовал до работы в Академии управления WINbd – проекта по разработке программного продукта для автоматизации управления проектами компании, оказывающей аутсорсинговые услуги ведения бухгалтерского учета у своих клиентов.

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

Для решения проблемы нужно было оценить экономическую эффективность нескольких вариантов

1. Аренда SaaS-продукта для управления проектами

Для расчета затрат на SaaS-решение мы выбрали один подходящий продукт.

2. Покупка коробочного продукта и его внедрение

После обсуждения требований заказчик уточнил, есть ли готовые продукты на платформе 1С для управления проектами. Мы объяснили, что такие продукты есть, но их функциональность будет использоваться на 10-20%, при этом часть требований в них не будет реализована. Еще стоимость коробочных продуктов с учетом их доработки под требования клиента оказалась выше, чем аренда на два года выбранного нами сервиса.

3. Разработка продукта под заказ и его внедрение

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

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

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

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

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

Второй проект связан с разработкой программного продукта для автоматизации работы железнодорожного узла, который оказывает услуги по перегрузке грузов из автомобилей в вагоны, из одних вагонов для узкоколейной дороги в другие для перевозки по железной дороге в СНГ, хранению грузов на складе, а также занимается оптовой торговлей.

Что было на старте проекта

Это был четвертый совместный проект, заказчик доверял команде. Проект запустился без технического задания, используя тот же Scrum. Для договора зафиксировали перечень из функциональных блоков, которые должны быть реализованы. А для оценки объемов работ провели предварительный сбор требований за один месяц, причем техническое задание не оформляли как документ. Мы реализовали этот проект за пять месяцев, уточняя требования перед каждым спринтом. В результате проекта мы разработали коробочный продукт для управления работой железнодорожного узла на базе 1С.

Какие бонусы дало использование философии Agile и подхода Scrum в этом проекте

1. Сэкономили больше месяца на описании бизнес-процессов «как есть» и согласовании модели процессов «как будет» с клиентом (и приличную сумму денег)

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

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

Какие факторы позволили нам успешно завершить проект

1. Доверие между клиентом и нашей командой. Мы уже делали вместе четвертый проект и клиент не сомневался в нашей честности и компетентности.

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

3. Большая часть ребят из команды проекта уже работали до этого по Scrum вместе не один год.

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

1. Заказчик проекта доверяет компетентности команды в вопросах сбора и анализа требований, принятии решений о том, как реализовать требования.

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

3. Команда исполнителей умеет работать по Scrum.

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

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

Как понять, что обучение будет полезно