Оплата спринтами: как заказчику контролировать разработку

Оплата спринтами становится управляемой, когда заказчик видит три отдельные записи: согласованные расходы периода, проверенный результат и решение о следующем вложении. Само слово «спринт» не устанавливает цену и не гарантирует выпуск функции. Если счёт выставляют раз в две недели, а работа месяцами остаётся в статусе «почти готово», короткий платёжный период ничего не изменил. Нужны границы расходов и понятная проверка того, чем теперь можно пользоваться.

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

Сначала выясните, что именно продают под словом «спринт»

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

Спросите исполнителя, за что выставляется сумма: за согласованный результат, фактические часы, доступность определённой команды или сочетание этих условий. Затем уточните, что происходит при незавершённой задаче. Её остаток может переходить в следующий период, но переход не должен скрывать уже понесённые расходы. Ответ «мы гибкие, заранее ничего не фиксируем» не объясняет порядок расчётов и не помогает принять решение о продолжении.

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

Одна цель периода и отдельный список кандидатов

Предположим, компания разрабатывает кабинет для обслуживания оборудования. Для ближайшего периода выбрали цель: диспетчер видит новые обращения и назначает ответственного, а клиент узнаёт о принятии заявки. Эта формулировка позволяет проверить связанный рабочий сценарий. Перечень «дизайн, база, уведомления, исправления» такой проверки не даёт: все четыре пункта могут двигаться, пока ни одной заявкой ещё нельзя воспользоваться.

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

Не превращайте цель в обещание вместить всё. Лучше заранее согласовать, какую часть сценария можно уменьшить без потери смысла. Например, сначала оставить уведомление о принятии обращения, а напоминания и дополнительные шаблоны рассматривать отдельно. При этом нельзя незаметно убрать проверку прав доступа: объём удобств и обязательные требования к безопасности обсуждают по разным основаниям.

Условный расчёт: лимит не равен обещанию выполнить всё

Допустим, стороны для учебного примера согласовали предел в 100 расчётных единиц. К выбранным работам отнесли форму обращения на 30 единиц, назначение исполнителя на 25 и уведомление на 20. Получается 75 единиц оценённой работы. Оставшиеся 25 не являются автоматически проданными функциями. Нужно явно решить, являются ли они резервом внутри предела, доступным объёмом для дополнительного согласования или вообще не входят в заказ.

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

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

Посреди периода нужен прогноз, а не процент готовности

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

Если работа остановилась на ожидании заказчика, фиксируйте предмет ожидания. «Ждём согласование» слишком широко. «Нужно определить, кто видит обращения других подразделений» уже позволяет назначить ответственного. Затем оцените влияние задержки: может ли команда продолжить другую выбранную задачу или её время окажется занято ожиданием. Коммерческое последствие следует из согласованных условий, а не из молчаливого предположения одной стороны.

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

Демонстрация: проверьте путь, а не количество экранов

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

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

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

Незаконченная задача не исчезает при переносе

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

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

Перед следующим платежом оставьте три возможных решения

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

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