Реальные примеры выгоды от Agile в проектах автоматизации бизнеса на решениях 1С

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

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

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

Первый проект

Первый проект – разработка программного продукта для автоматизации управления проектами для компании, оказывающей аутсорсинговые услуги по ведению бухгалтерского учета у своих клиентов. Учет проектов и задач в рамках проектов ведется сейчас в MS Excel.

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

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

1. Аренда SaaS продукта для управления проектами;
2. Покупка коробочного продукта и его внедрение;
3. Разработка продукта под заказ и его внедрение.

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

После обсуждения требований клиент уточнил, а есть ли готовые продукты на платформе 1С для управления проектами, которые удовлетворяют его требованиям? Дело в том, что у клиента уже используется продукт 1С для ведения бухгалтерского учета и логично было обсудить вариант автоматизации оперативного учета на базе продукта от 1С. Такие продукты конечно есть, но функциональность этих продуктов будет использоваться клиентом на 10-20%, при этом часть требований в них не была реализована. Не очень хороший вариант с учетом того, что платить придется за весь функционал, да и стоимость коробочных продуктов с учетом их доработки под требования клиента оказалась выше, чем 2-годичная аренда Easy Projects.

Перешли к обсуждению третьего варианта: разработка продукта на платформе 1С под заказ. В течение одного часа мы с коллегами по компании оценили объем работ и бюджет на разработку решения, полностью удовлетворяющего всем требованиям клиента. После этого, обсудили бюджет проекта с клиентом и разделили требования на 2 части: требования, которые должны войти в первый релиз продукта, и требования, которые, возможно, войдут во второй релиз (если он будет). Стоимость первого релиза оказалась меньше, чем стоимость аренды Easy Projects. На все обсуждения ушло около 10 часов работы нашей команды. После этого мы подписали договор на первый релиз, разработали Устав проекта и стартовали проект, по условиям которого релиз должен был быть сделан за один месяц. В течение этого месяца было три демонстрации прототипа продукта клиенту, по итогу которых мы взяли в работу пару дополнительных требований.

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

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

Почему использование фреймворка Scrum в этом проекте дало выигрыш по срокам минимум в три месяца:

1. Аналитик с нашей стороны более 15 лет использует различные программные продукты для управления проектами и имеет большой пользовательский опыт в этих продуктах. Это помогло не просто слушать требования клиента, а и быстро предлагать какие-то интересные фишки, которые будут полезны для решения проблемы клиента.  Все обсуждения требований мы смогли вести в устном виде и записывать нам нужно было только согласованные пользовательские истории
2. На базе 1С есть несколько готовых продуктов по управлению проектами, анализ которых помог нашей команде понять, какими могут быть интерфейсы нового программного продукта и сэкономить время на их проектировании
3. Частые демонстрации продукта (раз в неделю) заказчику проекта позволили быстро обсуждать новые идеи и принимать часть из них в работу на следующий спринт. На демонстрациях мы также быстро поясняли клиенту как реализованы требования и объясняли почему именно так. Мы сэкономили очень много времени на согласовании подходов к реализации требований, обсуждая их на уже готовых прототипах.

Второй проект

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

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

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

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

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

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

1. Доверие между клиентом и нашей командой. Мы уже делали вместе четвертый проект и клиент не сомневался в нашей честности и компетентности;
2. У клиента не было понимания того, какие требования у него есть к программному продукту, и он поверил нам в том, что мы сможет отловить самые важные требования с помощью интервью и быстрых прототипов;
3. Большая часть ребят из команды проекта уже работали до этого по Scrum вместе не один год.

Выводы

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

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

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