Agile/Scrum – в чем суть и в чем выгода для Заказчика при выполнении проектов?

Лисин Н. Г.

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

Agile, Scrum, Kanban – эти слова уже успели примелькаться всем, кто имеет какое-либо отношение к разработке продуктов, бизнес-процессам, организации труда. Многие считают, что за этими технологиями будущее. Но, что интересно, немногие могут объяснить различия между этими понятиями, например, ответить на вопрос о Scrum и Agile: разница существует и в чем она заключается?».

Итак, сперва определимся с методологическим аппаратом:

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

Scrum – одна из методологий в рамках Agile. В основе данной методологии лежат «спринты» – короткие жестко фиксированные по времени итерации, в рамках которых как исполнитель так и заказчик выполняются определенный набор задач. Подробнее о Scrum, разнице Scrum и Agile читайте здесь.

Kanban – система, которая предусматривает организацию разработки/труда/производства/снабжения в соответствии с принципом Just In Time (или точно в срок). В основе Kanban лежит производственная и снабженческая система Toyota, которая во второй половине XX века чуть было не уничтожила весь американский автопром.  Подробнее о Kanban читайте здесь.

Основными ценностями в концепции Scrum объявлены коммуникация и готовность к изменениям, а не жесткое следование первоначальному плану. Когда же Scrum может принести только пользу, а когда  — вред?

Чтобы разобраться, рассмотрим сначала традиционную «жесткую» технологию, основанную на так называемом «договоре подряда» (гл. 37 ГК РФ).

Жесткая подрядная технология

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

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

Подчеркнем ключевое положение этой модели взаимодействия: в результате оценки Исполнителем поставленной изначально задачи в договоре устанавливается жесткий срок и стоимость этапа. Поэтому изменение задачи в процессе выполнения работ не допускается. Это правило действует, например, и при ремонте квартиры, и при внедрении ERP-систем.

Если используется итерационный подход, то после окончания этапа работ становятся ясными задачи следующего этапа, а значит, следующие объемы работ. Соответственно, в дополнительном соглашении фиксируется срок и стоимость на следующий этап. Бывает еще интереснее — при внедрении ERP-систем Исполнитель (зачастую чтобы выиграть тендер) фиксирует бюджет на весь проект целиком, иногда на 1-2 года вперед.

Наивные Заказчики принимают бюджет, полагая, что и сроки, и бюджеты будут соблюдаться. При этом, согласно договору, этапы работ в любом случае закрываются актами и оплачиваются отдельно, чуть ли не помесячно. Не исключено, что через несколько месяцев выяснится, что бюджет необходимо увеличить в 2-3 раза (мол, требования к системе изменились, а «мы об этом не договаривались, в ТЗ этого нет!»). Не хотите — до свидания. Но такие неприятные ситуации — тема для другой статьи.

Основной недостаток жесткой технологии — существенные ограничения гибкости в требованиях и решениях, в условиях выполнения работ, ограничения гибкости участия Заказчика в процессе выполнения этапа. Такая гибкость в ходе выполнения работ крайне важна, так как в начале каждого этапа детальные, исчерпывающие, точные требования и организационные условия  сформулировать затруднительно – высока степень неопределенности системы. Интеграторы-исполнители часто говорят: «Клиент сам не знает, чего хочет»… Совсем тупиковые ситуации возникают, когда клиент – который не знает, чего хочет – требует сделать систему «под ключ».

Но это не Заказчик виноват… это всего-навсего специфика таких проектов.

Поскольку сроки и бюджеты определяются в начале каждого этапа, любые корректировки требований к системе со стороны Заказчика, а также любые изменения условий в процессе выполнения работ на этапе (например, объем участия и содействия со стороны Заказчика) могут создать дополнительную трудоемкость для Исполнителя, что потребует пересмотра бюджета и сроков. Но пересмотр бюджетов и сроков — потенциально конфликтная ситуация!

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

Для повышения гибкости — в бюджет и сроки закладываются риски. Кроме того, опытные Исполнители предусматривают и прописывают процедуру «Управления изменениями», согласно которой в конечном итоге все изменения первоначальных требований проходят через процедуры инициирования и оценки.

Стоимость рисков Исполнителя, отраженных в бюджете проекта, в подобных работах может достигать более 50% от стоимости этапа. Другими словами, Исполнитель продает заказчику не только результат работ, но и свои риски. Если риски не реализуются, стоимость работ для Заказчика оказывается завышенной относительно реальной трудоемкости этих работ, а Исполнитель получает дополнительную прибыль. Бывает и наоборот — реализовываются незапланированные риски сверх бюджета, в результате чего Исполнитель оказывается в убытке.

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

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

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

• Другие способы разделения ответственности для Заказчика менее комфортны. В договоре Заказчик заказывает, а Исполнитель – исполняет, эта логика порождает разделение ответственности сторон за проект, удобное для Заказчика.
• Другие (не подрядные) технологии  требуют большей ответственности со стороны заказчика.

Почему Исполнители охотно соглашаются на подряд?

• Чтобы обеспечить гибкость в требованиях, Исполнители закладывают в фиксированную стоимость проекта  риски. Если риски не реализуются, Заказчик переплачивает.
• Требования к результату согласуются «на берегу», а значит, Заказчик опять лишается гибкости, а Исполнитель получает возможность не делать нужный Заказчику функционал, ссылаясь на то, что «в ТЗ этого нет». Так работать спокойнее: зафиксировал требования и “вперед”…

Знакомая ситуация?

Гибкость требований в процессе выполнения работ

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

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

Но гибкость требований и подряд – антагонизмы!

Гибкая технология (Scrum)

Смысл концепции Scrum в том, что каждый этап работ разбивают на короткие итерации фиксированной длительности (от 1-й недели до месяца). В начале каждой итерации определяют задачи сторон — Заказчика и Исполнителя — только на данную итерацию. В процессе итерации (в терминологии Scrum – «Спринт») изменения в задачах Сторон, требованиях и условиях выполнения работ не допускаются. По завершении итерации Стороны анализируют результаты и ставят задачи на следующую итерацию; и при этом уже допускается изменять условия выполнения работ.

Очень важно плотное и непрерывное взаимодействие Исполнителя и Заказчика. Как можно больше общаться, быть одной командой — вот ключевой момент данного подхода!

Такие работы удобнее выполнять по договору оказания услуг (ГК РФ, глава 39), а не по подрядному договору. Преимущество гибкой технологии:

• За счет того, что итерации намного короче, чем весь этап работ, достигается гораздо большая гибкость в принятии решений и управлении изменениями в ходе работ. Между итерациями Заказчик не ограничен в принятии организационных решений, изменении рамок проекта и так далее. Очевидно, что стороны движутся к результату более коротким путем, чем при подряде, поскольку могут непрерывно вносить изменения в проект.
• Исключаются конфликтные ситуации  по причине изменений, так как в центр  такой технологии поставлена возможность изменения. Если при подряде изменение — это неприятное отклонение, требующее разборок и выяснения, кто кому должен, то в Scrum изменения — это суть и составляющая процесса.
• Тарификация итераций тоже может быть гибкой – либо оплата  производится по фактической трудоемкости  (согласно почасовой ставке работы сотрудника); либо стоимость итерации фиксируется в начале итерации, исходя из прогноза ее трудоемкости. В результате, Заказчик оплачивает только фактическую трудоемкость и не переплачивает за риски.

Прогноз стоимости каждой итерации выполняется достаточно просто по почасовому тарифу (если известно количество сотрудников Исполнителя,  планируемых на итерацию с полной загрузкой).

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

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

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

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

Поэтому если есть возможность тщательно продумать функционал и требования до начала реализации, ей надо воспользоваться. Разумеется, если есть вся необходимая информация. Это идеальный случай, и такое бывает редко, поэтому наилучшим вариантом в таких ситуациях является Scrum, позволяющий формировать требования к системе в процессе ее реализации и эксплуатации. Если же изменения не предвидятся, то Scrum — не лучший выбор.

Например, при разработке типовых решений (не под конкретного заказчика с его неочевидными «хотелками») систему лучше продумывать сразу в полном объеме, целостно. Поскольку внешнего непредсказуемого заказчика нет – в данном случае заказчиком, по сути, является сама команда разработчиков – требования к системе известны изначально. Конечно, если разработчики знают, за что берутся.

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

Договор подрядный, а работаем по Scrum

Преимущества Scrum все чаще можно наблюдать, когда реализуется один из классических проектных рисков – “сваливание” проекта в Scrum по факту, хотя по договору работа выполняется по подряду – с жесткими сроками и стоимостью. Такое “сваливание” очень выгодно активному Заказчику, т.к. позволяет достичь желаемого результата, отталкиваясь каждый раз от фактического результата промежуточного этапа работ. Заказчику гораздо проще понять, что он хочет получить на самом деле, если он отталкивается от того, что уже сделано.

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

На ИТ проекте “сваливание” проявляется следующим образом.

Как правило это происходит на этапе реализации (кодирования). Как только Заказчик просит показывать промежуточные результаты, и начинает их принимать, не дожидаясь предъявления всего объема работ на испытания, ждите переход по факту в Scrum. Приемка Заказчиком уже первой итерации работ скорее всего повлечет за собой частичный пересмотр Заказчиком всего технического задания, а это уже Sсrum. Разумеется, для конечного результата и удовлетворения Заказчика это благо. А пересмотр ТЗ — это изменение трудоемкости, обычно в большую сторону. И если не заключить дополнительное соглашение на увеличение стоимости, то ущемляются интересы Исполнителя. А это конфликтная ситуация.

Возникает вопрос – не проще ли изначально договориться работать по Scrum? Ведь справедливая оплата работ должна соответствовать фактической трудоемкости, которая при “сваливании” в Scrum не поддается точному расчету!

Что же получается? Заказчик может отрицать Scrum при заключении договора, но потом фактически заставить Исполнителя работать по Scrum. В рамках фиксированного срока и   бюджета. И не забываем, что просрочка срока сдачи работ (из-за постоянного внесения Заказчиком мелких корректировок в задачу) грозит Исполнителю серьезной ответственностью, т.к. Исполнитель отвечает за срок сдачи работ. Неисполнение срока дает право Заказчику предъявлять обоснованные претензии. Более того, Заказчик может упрекать Исполнителя в недостаточном профессионализме, т.к. Заказчик склонен часто свои корректировки в постановку Задачи расценивать как свои требования исправить недостатки…

 О применении Scrum на проектах ИТРП>>>

[evc_social_likes]