Можно и без ТЗ: как Scrum экономит время и деньги компаний

Как сэкономить время на реализацию проектов и одновременно снизить риски их невыполнения? Примерами, связанными с созданием ПО для автоматизации бизнеса, делится Максим Якубович, партнер компании «КейТуБи». Одна из идей, о которой рассказывает эксперт, - сократить время для составления технического задания, используя Scrum.

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

---

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

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

Пример 1: выбор из трех вариантов

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

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

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

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

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

3. Разработка продукта под заказ и его внедрение - оставался еще один вариант. После оценки объема работ и бюджета на разработку решения (1 час) требования на разработку были разделены на 2 части:

• Требования, которые должны войти в первый релиз продукта
• Требования, которые, возможно, войдут во второй релиз (если он будет).

Стоимость первого релиза оказалась меньше, чем стоимость аренды. На все обсуждения ушло около 10 часов работы. В результате было решено разрабатывать продукт под заказ и внедрять его. После этого был подписан договор на первый релиз, разработан Устав проекта (согласно требованиям гибких методологий), и работы стартовали.

Релиз должен был быть сделан за один месяц. Была выбрана работа по Scrum:

• Работа длилась недельными спринтами
• В течение 1 месяца было три демонстрации прототипа продукта. По итогу было взято в работу несколько дополнительных требований.

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

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

Что позволило достичь положительных результатов:

1. Частые демонстрации продукта (1 раз в неделю). Это помогало быстро обсудить новые идеи и принять часть из них в работу на следующий спринт.

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

2. На базе 1С есть несколько готовых продуктов по управлению проектами. Их анализ помог нашей команде понять, какими могут быть интерфейсы нового программного продукта, и сэкономить время на их проектировании.

Пример 2: без технического задания

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

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

Особенности проекта:

• Было решено не составлять техническое задание. Но при этом в договоре был зафиксирован перечень из функциональных блоков, которые должны быть реализованы.
• Для оценки объемов работ был проведен предварительный сбор требований - срок 1 месяц. Техническое задание не оформлялось как документ - для того, чтобы не затягивать сроки. При этом проект был разбит на спринты, и перед каждым из них уточнялись требования.

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

Сейчас он внедряется.

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

• Экономия - больше месяца - на описании бизнес-процессов «как есть» и согласовании модели процессов «как будет»
• Экономия около 2−3 месяцев на сборе и анализе требований и разработке технического задания, а также нескольких месяцев на разработке документа по описанию технической реализации требований. Это, конечно, и экономия средств - в среднем $ 15 000 (средняя стоимость на рынке с учетом почасовой оплаты) на все эти процессы.
• Все сделанные во время проекта разработки были задокументированы. Но это было после того, как функционал продукта уже был принят.

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

1. Доверие между заказчиком и исполнителем.

Как мы уже говорили, проект был сделан без ТЗ. Это сэкономило много времени. Благодаря тому что перед каждым спринтом уточнялись требования, риски не соответствовать им были минимизированы. Тем не менее у заказчика в таких случаях не должно быть сомнений в честности и компетентности подрядчика.

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

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

Основной вывод

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

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

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

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

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

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

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

Обратная связь с экспертом возможна по электронной почте: max.yakubovich@gmail.com