На начальном этапе стоит понимать, что сформулировать максимально точно объект договора практически невозможно: модель конечного продукта описана лишь в общих чертах. Цель будет реализовываться с помощью маленьких этапов — они будут фиксироваться в заявках, отчетах, актах приема и передачи работ. Постепенно, по мере продвижения работы над проектом, задачи будут становиться все более конкретными.
Исходная цель в процессе может потребовать внести изменения, и это совершенно нормально. Например, компания после анализа новинок конкурентов решила внести коррективы, чтобы укрепить свои позиции после релиза. Либо же предпочтения пользователей изменились: их нужно учесть, иначе приложение после выпуска может оказаться никому не нужным.
Чтобы клиент мог своевременно скорректировать курс, исполнитель передает работу после каждого спринта. Это положительный момент для клиента: ему не приходится долго ждать, чтобы посмотреть на уже готовый продукт, который по истечении срока может уже не соответствовать требованиям. Также заказчик может не принять промежуточную работу, если она его не устраивает, не соответствует требованиям договора. Все издержки в этом случае будет нести исполнитель.
Как следует из названия типа договора, оплата производится за время, которое разработчик тратит на выполнение задач. Это значит, что фиксированной цены, которая будет затрачена на проект, нет. Изначально оговаривается стоимость часа специалиста, который будет задействован в работе. Однако здесь, на первый взгляд, может возникнуть случай, невыгодный для клиента, когда разработчики будут специально тянуть время, чтобы заработать больше денег. Договор предусматривает этот факт: заранее определяется лимит часов, за которые нельзя выходить. Кроме того, оплачиваться будет только то время, которое было потрачено на выполнение задач.
Вторая часть формулировки — оплата за материалы. Сюда входят материальные затраты разработчика, которые необходимы для реализации продукта.
Работа в формате спринтов предполагает, что заказчик будет постоянно контактировать с исполнителем — обе стороны заинтересованы в выполнении своих обязательств. Также при такой модели немаловажно качество разработки, поэтому заказчик будет тщательно прорабатывать все корректировки. Это только положительно скажется на конечном продукте.