Собираясь работать с компанией, готовой предоставить вам необходимые услуги, нужно начать с определения объема работ, распределения бюджета и ресурсов, а также выбрать модель контракта, которой будут следовать обе стороны. Являясь компанией по разработке ПО на заказ, мы всегда открыты для поиска вместе с клиентом золотой середины. Мы понимаем, что вы хотите лучших решений и стремитесь к минимальной трате ресурсов. Поэтому, при обращении к нам, вы можете ожидать индивидуального подхода к вашему проекту.
Некоторые из клиентов хотят работать по определенному договору, другие же не уверены, какой тип будет лучшим выбором в их случае. Существуют различные типы контрактных моделей, включая Time and Materials, Fixed Price и другие, поэтому мы понимаем эти муки выбора. В сегодняшней статье мы хотим поговорить о типе контракта «Бюджет с плавающим объемом работ» (также известный среди наших клиентов как Budget with Float Scope или BFS) и о том, чем он отличается от контрактов Time & Materials (Время и материалы) и Fixed Price (Фиксированная цена).
Разрываясь между T&M и FP
Возможно ли разработать продукт работая с вендором по контракту «Время и материалы»? А по контракту с фиксированной ценой? Лучше ли выбрать второй вариант?
Да, да и зависит от обстоятельств.
Без сомнения, вы можете выбрать работу на основе контракта T&M или FP, если для вас это важно. Например, наша компания далеко не первый год работает с заказчиками по разным моделям сотрудничества, потому что выбор контракта во многом зависит от первоначальных требований. В том числе мы работаем и по моделям Time & Materials и Fixed Price, поэтому давайте сначала разберемся, что вы можете ожидать от них и выясним подходят ли они для вашего проекта.
Работа по договору Time & Materials
Если ваш выбор пал на этот тип контракта и вы хотите следовать принципам Agile, то процесс разработки запускается с раскрытия вашей идеи. После этого выбирается итеративная или инкрементальная модель разработки. Таким образом, вы экономите свое время и деньги на создании спецификации требований к программному обеспечению (SRS). Для создания каждой функции приложения ставится задача, и вы просто отправляете их в систему управления задачами, чтобы лучше ориентироваться и качественно выполнять поставленные цели.
При выборе этого типа контрактной модели успех вашего проекта зависит от того, насколько четко вы определили конечную цель и понимаете стоимость ее достижения. Не существует методов создания приемлемой точности по озвученной идее, можно только опираться на аналогии. Например, некий другой проект по разработке продукта с похожей идеей, длился 5 человеко-лет. Это не означает, что график вашего проекта обязательно совпадет по срокам.
Работа по договору Fixed Price
Такой тип контракта хорошо подходит для разработки MVP (Minimum Viable Product или Минимально жизнеспособный продукт) или других небольших проектов, особенно зависящих от дедлайнов. При выборе Контракта с фиксированной ценой процесс начинается с создания спецификации требований к ПО и наброска прототипа будущего продукта. Это помогает установить более-менее точный бюджет и определить план реализации проекта (PEP), а также оценить целесообразность ваших усилий. При выборе типа контракта «Фиксированная цена» успех проекта зависит от того, насколько четко вы определили конечную цель.
Рекомендуем прочитать План реализации проекта (PEP) и План управления проектом (PMP): Какой из них вам нужен и почему стоит выбрать оба?
Нужны ли вам все функции, включенные в вашу идею? Уверены ли вы, что их реализация обязательно именно в том виде, как указано в спецификации? Ответы на эти вопросы вы сможете узнать только после окончания проекта и демонстрации его вашей целевой аудитории. Но чаще всего бывает так, что пользователям не все функции продукта нравятся: какие-то могут оказаться неинтересными или вовсе ненужными.
В итоге, вы, вероятно, получите продукт, который будет нуждаться в доработке. Следовательно, вам придется потратить еще больше своего времени и денег. Таким образом, иллюзорная уверенность в запланированном бюджете и графике разобьется вдребезги из-за неправильного понимания, какие функции нужны пользователям.
Как видите, с одной стороны, обе модели контрактов требуют четкого и ясного понимания конечной цели. С другой стороны, они могут не дать вам уверенности в бюджете и графике и, как следствие, в успехе проекта.
Двух зайцев одним ударом
Если ни один из этих вариантов не подходит для вашего проекта, мы предлагаем нашим клиентам в таких случаях смешанный тип. Мы называем его контрактом «Бюджет с плавающим объемом работ» или Budget with the Float Scope (BFS), но вы также можете знать его как Договор на разработку ПО (Product Development Agreement). Как и у любого другого типа контракта, у него есть свои плюсы и минусы, поэтому давайте рассмотрим подробнее.
Допустим, у вас есть идея, и вы готовы потратить немного денег, чтобы получить продукт к определенной дате – это ваши первоначальные требования. Итак, на входе мы имеем следующее – это идея, бюджет и дедлайн, на выходе вы получаете ценный продукт. Ваш бюджет и сроки являются частью модели FP, в то время как ваша идея и ценный продукт являются частью T&M или Agile-модели.
Объединив все воедино, вы получаете проект по разработке продукта, который приведет вас к реализации идеи и даст максимальную ценность в рамках бюджета и сроков. Так и формируется модель BFS контракта.
Подход к реализации данного метода отличается от T&M и FP и основан на следующих правилах:
- Сотрудничество;
- Каждая заинтересованная сторона хорошо осведомлена об идее, бюджете и сроках;
- Увеличить бюджет, выделенный на одну функцию, можно только после уменьшения бюджета на другую.
Эти правила создают определенный процесс реализации такого проекта, который включает в себя следующие этапы:
- Для понимания масштаба проекта идея должна иметь приблизительное описание;
- Затем продукт разбивается на функции, которые должны быть реализованы;
- Бюджет распределяется между этими функциями, а также рекомендуется иметь в запасе некоторую сумму на случай непредвиденных ситуаций. Как правило, это около 10%;
- Далее начинается процесс разработки функции. Определяется фронт работ, которые разбиваются на соответствующие задачи, которые необходимо оценить и определить их приоритетность. Функция реализуется в рамках выделенного бюджета, а остальные задачи переносятся на последующие версии продукта. Если по каким-то причинам бюджета не хватило, следует обратиться к правилу номер 3.
- Когда все готово, создается демо с реализованными функциями. Это необходимо для того, чтобы получить обратную связь от лояльных пользователей, которые могут оценить ценность продукта.
Управление процессом: 3 практических совета
Любой процесс должен отслеживаться и контролироваться, иначе он возьмет власть над вами. Чтобы иметь возможность управлять им, вы можете использовать Метод освоенного объема (Earned Value management или EVM). Он показывает состояние реализации проекта по сравнению с первоначальным планом. EVM — критически важный инструмент, потому что он помогает увидеть первые следы отклонения от графика или бюджета в случае, если оно произойдет. Таким образом, вы сможете вносить изменения, контролируя ситуацию и определяя, что не так.
Очень важно избегать ловушек самообмана, которые приводят к потере контроля над проектом и увеличению бюджета. Поэтому хотим поделиться некоторыми полезными советами и рекомендациями, чтобы сделать процесс более понятным.
Совет №1
Согласно третьему правилу, о котором мы упоминали выше, увеличивая одно уменьшаем другое. Однако следует понимать, что сокращать следует только то, что известно. Это значит, что вам нужно описать функцию, разбить ее на задачи, оценить их, и только тогда вы сможете понять, на какие из функций может уйти меньше бюджета. Слепо уменьшая бюджет (например, устанавливая 250 часов вместо 300 и рассчитывая потом как-то разобраться с нехваткой времени), вы получаете все больше и больше «уменьшенных» функций. В результате вам придется иметь дело с большим количеством недоработанных функций, не имея достаточного бюджета.
Совет №2
После оценки пользователями демо-версии вашего продукта все отзывы должны быть зарегистрированы так же, как вы создавали иные задачи для функций ПО. Каждая задача должна быть оценена, чтобы понять приоритеты и определить ее целесообразность, исходя из вашего бюджета. У вас может возникнуть соблазн угодить всем пользователям и реализовать все, что они попросят, но не стоит забывать о бюджете, выделяемом на каждую функцию.
Совет №3
Сокрытие бюджет проекта (когда вы опасаетесь, что вендор израсходует любую сумму) снижает эффективность рекомендаций и предложений поставщика. Нужно понимать, что ценность функции и выделенный бюджет сильно зависят от способа ее реализации. А решение о том, как будет реализована функция, зависит от бюджета и стоимости. Поэтому возникает вопрос, как вендор может помочь определить оптимальный способ, зная только половину правды?
Кроме того, все функции должны соответствовать их ценности. Не зная доступного бюджета, вендор, скорее всего, посоветует сначала разработать функции с высокой стоимостью, оставив функции с низкой на конец проекта.
Допустим, вы сообщаете, что у вас есть X бюджета на проект, но на самом деле вы готовы потратить в два раза больше. Не так важно сколько у вас денежных ресурсов, важно сколько вы готовы вложить в разработку.
Поэтому, если вы заявили, что ваш бюджет равен X, то и придерживайтесь этой суммы. Если возникает необходимость повысить бюджет для какой-либо функции, а с вашей стороны вендор услышит мгновенное соглашение, то у вендора может сложиться впечатление, что ваш бюджет отличается от озвученного, а следовательно команде поставщика не известен истинный выделенный бюджет. Такое поведение сбивает с толку вендора, потому что у команды нет четкого представления о том, чего ожидать и как действовать: по бюджету или нет?
Если не произойдет ничего неожиданного, ближе к концу проекта у вас останется 10% того самого неиспользованного бюджета. Эти средства можно будет направить на выполнение задач с высоким приоритетом. Кроме того, вы сможете заниматься более ценными задачами, которые были созданы на основе собранных отзывов.
К сожалению, иногда непредвиденные события все-таки происходят, и внедрение первостепенных функций потребует больше выделенного бюджета. Например, недопонимание между сторонами произошло при описании идеи или поставщик решил сделать что-то иначе, чем обсуждалось. По каким-то причинам задания не были тщательно оценены или возникли новые требования. В любом из этих случаев нужно поставить проект на паузу и выяснить, что с ним происходит. Возможно, вам придется пересмотреть некоторые функции или решить, стоит ли вообще продолжать процесс разработки.
Рекомендуем прочитать Клиент в Зазеркалье или Как не обесценить проект отсутствием документации
В заключение
Первое правило модели Бюджета с плавающим объемом работ – это сотрудничество. Если вы не будете следовать ему, а решите придерживаться правила «берись за работу или откажись», вам будет гораздо проще попасть в ловушку и неудачно закончить проект. Удалось ли вам создать приятную атмосферу, основанную на сотрудничестве и ясности с вашим поставщиком? Обычно ответ можно найти, когда вы описываете свою идею, функции разбиваются на задачи, вы обсуждаете бюджет на каждую функцию и т. д. То есть непосредственно перед началом процесса разработки и расходования бюджета. Поэтому нужно подготовиться заранее и подойти к вопросу со всей ответственностью, а контрактная модель BFS поможет вам воплотить вашу мечту в реальность.
Если вы хотите узнать больше о контракте «Бюджет с плавающим объемом работ» или хотите получить бесплатную консультацию и описать свою идею, свяжитесь с нами, и мы будем готовы помочь.
