Договор на разработку ПО

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

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

Так почему же команды не могут выполнить то, что обещают? Существует 2 причины: изменения и сроки.

Традиционные контракты и заявки на изменения

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

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

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

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

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

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

Картинка ниже отражает размер оригинального договора (справа) и заявок на изменения (слева).

Сроки

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

Дело в том, что поставщики просто недостаточно знают о проекте в самом начале, чтобы давать такие обещания. Рассмотрим конус неопределенности, который Барри Бем представил в 1981 году.

Конус неопределенности демонстрирует, что в начале любого проекта команды испытывают наибольшую неопределенность с дисперсией в диапазоне от 0,6 до 1,6. Это означает, что команда оценила проект на 6 месяцев, на самом деле он может занять от 3,6 до 9,6 месяцев! Тем не менее, когда команды находятся в состоянии неопределенности, они вынуждены писать договор с четким указанием сроков, объема работ и бюджетом.

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

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

Диапазоны и изменения

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

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

Контракт “открытие”: определите диапазон

Первый контракт является договором с фиксированной оплатой и фиксированными сроками. Он служит одной цели: позволить команде собрать достаточно информации для создания объема работ (бэклог продукта), сроков (предварительный план выпуска) и стоимости (сумма за спринт). Контракт “открытие” обычно составляется двумя или тремя членами команды в течение примерно двух недель. Если в конце договора “открытия” клиент выбирает другого поставщика, ему разрешается повторно использовать эти результаты.

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

Определите всех пользователей создаваемого ПО

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

Напишите пользовательские истории

Команда разработки отвечает за написание пользовательских историй по шаблону: «Как <пользователь>, я могу <действие>, чтобы <результат>». Стоит пригласить клиента на мероприятие по написанию пользовательских истории. Члены команды и представители клиентов могут обдумать идеи и написать истории. Даже если клиент решает не писать истории, присутствие клиента очень полезно, потому что оно дает команде возможность задать специфичные вопросы относительно пользовательских историй, которые помогают прояснить и сделать оценку историй более точными. Пользовательские истории составляют бэклог продукта.

Оцените истории

Исследовательская группа оценивает итоговые пользовательские истории в баллах (story points). Сюжетные пункты помогают заинтересованным сторонам и клиентам понять стоимость истории. Этот факт необходимо учитывать при расстановке приоритетов в бэклоге. Убедитесь, что клиент доступен для вопросов во время проведения оценки.

Контракт “открытие”: определение стоимости и сроков

После того, как команда поработала с клиентом и собрала информацию, команда работает самостоятельно. Команда определяет стоимость проекта и сроки. Это четырехэтапный процесс: определение скорости команды (velocity), расчет стоимости за спринт, составление плана релиза и определение вариантов оплаты.

Определить скорость команды

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

Рассчитайте стоимость за спринт

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

Создайте план релиза

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

Установите варианты оплаты

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

Контракт проекта: поставка товара

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

Изменения

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

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

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

4 важных элемента в договоре на разработку ПО в Scrum

Доступность клиентов

Включите определенное количество часов в неделю, которое клиент обязуется быть доступным для команды. Вы же не хотите, чтобы он периодически пропадал во время проекта. Короткие спринты требуют почти ежедневной доступности клиентов. Большинство Scrum-команд предпочитают короткие спринты (1-2 недели), потому что это позволяет клиенту более активно участвовать в проекте.

Ограничение времени на принятие работы

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

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

Вы также можете включать в договор на разработку ПО следующее. Если заказчик отказывается от какой-либо работы, выполненной в спринте, ему не нужно платить за нее. Будут ли заказчики пользоваться этой лазейкой? Да. Если вы решите включить это положение, выбирайте своих клиентов с умом. Научитесь говорить “нет” клиентам, которым вы не доверяете.

Приоритезация

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

Условия расторжения

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

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

Доверие

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