Как правило, это один из первых вопросов, возникающих у компаний-разработчиков, ведь клиента не особо интересует, каким модным словечком называются рабочие процедуры внутри вашей студии. Именно на этом крайне важно пояснить заказчику, что он сможет:
-
каждый спринт изменять требования (если необходимо) к продукту,
-
каждый спринт (например, 10-14 дней) получать новый функционал,
-
корректировать сроки и цену работ благодаря возможности окончить проект после любого спринта.
Другой вопрос заключается в том, как отразить эту специфику в договоре? Лучший вариант – заключить контракт типа «Время и материалы» (T&M). Согласно его условиям заказчик оплачивает стоимость команды плюс процент. Преимущество таких отношений – возможность заказчиком управлять сроками и стоимостью. Но в таком случае риски тоже перекладываются на него. Кстати, в такой системе этап анализа проекта минимален – просто нет необходимости точно оценивать общие сроки и гарантировать их.
В России традиционно заключают контракты с конкретной ценой (Fixed price). Кажется, что в таком случае большинство рисков несет исполнитель. На деле же он закладывает их в стоимость проекта. В итоге это приводит к борьбе сторон и переплатам. Выход из ситуации – найти взаимовыгодного решения Win-Win и прийти к взаимному доверию.
Также по мере возможного нужно вовлекать заказчика в традиционные практики Scrum. Как минимум – присутствие на всех демонстрациях. Таким образом вы втянете заказчика в свой темп работы, а у него появится желание получать в конце каждого спринта очередной инкремент продукта. Так создаются отношения доверия и сотрудничества.
Максимальная задача — привлекать заказчика/представителя на прочие мероприятия. Это может быть покер-планирование, где заказчик увидит объемы и сложность задач, поймет и оценит, что команда выкладывается на 100%. В ходе ретроспектив заказчик тщательней вникнет в задачи и риски команды и сможет активно поучаствовать в оптимизации процессов.