Fixed price или time & material: модель оплаты разработки выбирают под определённость ближайшего этапа. Фиксированная цена требует согласованного результата, а оплата по времени — лимита и регулярных решений заказчика. Ни одна модель не делает формулировку «удобная система» достаточно точной для контроля бюджета.
Разберём, когда фиксировать объём, когда сначала оплачивать проверку неизвестного и что получить при остановке этапа. Практический результат — карточка условий для предметного обсуждения с исполнителем.
Сначала определите, что именно пока неизвестно
Возьмите ближайший результат и перечислите основания оценки. Для системы заявок это могут быть согласованные статусы, роли, пример входного файла, доступ к внешнему сервису, правила назначения исполнителя и критерии завершения заявки.
Напротив каждого основания поставьте одно из трёх обозначений:
- Подтверждено: правило проверено на рабочих примерах, ответственный согласовал описание.
- Нужна проверка: правило известно со слов сотрудника, исключения ещё не разбирали.
- Неизвестно: нет доступа, решения владельца процесса или самого образца данных.
Не заменяйте такой список субъективной оценкой «требования готовы на восемьдесят процентов». Один неизвестный способ авторизации во внешней системе может влиять на весь этап сильнее десяти согласованных экранов.
Если дорогая часть задачи неизвестна, выделите ограниченную проверку до большой оценки. Результатом могут быть пригодный образец данных, подтверждённое подключение или согласованное правило. Зафиксировать цену реализации после такой проверки проще, чем скрыть неизвестное внутри общего резерва.
Когда подходит фиксированная цена
Рассматривайте её для ограниченного результата с проверяемыми условиями. Например, импорт одного согласованного формата файла, проверка обязательных полей, создание заявки и отчёт об отклонённых строках. Есть обезличенный набор примеров, определено поведение при повторной загрузке, известен объём данных.
До согласования нужны:
- перечень включённых сценариев и явно исключённых работ;
- исходные данные и доступы, которые предоставляет заказчик;
- критерии приёмки и срок проверки результата;
- порядок оценки изменений;
- порядок действий при нарушении исходных допущений;
- состав передачи: код, документация, настройки, обучение, если они входят в этап.
Фиксированная цена не означает, что любое будущее уточнение автоматически включено. Но и ошибку в реализации согласованного правила нельзя без объяснения переименовывать в новую потребность. Основание для различия — зафиксированный сценарий, а не мнение стороны, которой удобнее текущая трактовка.
Когда подходит оплата по времени
Такая модель уместна, если решение меняется после проверки гипотез: неизвестна пригодность старых данных, несколько подразделений по-разному описывают процесс, интеграцию нужно исследовать на стенде.
Заказчик оплачивает согласованный труд, а не получает неограниченное обещание результата за заранее известную сумму. Поэтому необходимы короткие циклы проверки, журнал работ и понятный предел расходов.
Запрашивайте не только перечень часов. Отчёт должен отвечать, какой риск снят, какой сценарий работает, что блокирует следующий шаг и сколько примерно стоит оставшийся согласованный объём. Иначе подробный учёт времени создаёт видимость контроля без понимания результата.
Свяжите оплату с управлением: кто выбирает следующую задачу, как подтверждаются часы, когда пересчитывается остаток и при каком пороге работа останавливается. Эти договорённости важнее самого названия коммерческой модели и должны быть понятны обеим сторонам.
Матрица выбора без формального подсчёта баллов
Для обсуждения используйте четыре оси. Каждая приводит к отдельному решению.
Стабильность требований. Если основной сценарий и исключения подтверждены, можно обсуждать фиксированный этап. Если неизвестна даже последовательность действий, сначала нужен исследовательский этап с ограниченным бюджетом.
Срочность. Жёсткая дата не делает неопределённую работу предсказуемой. При фиксированной дате разделите обязательный минимальный результат и отложенные возможности. Определите, кто вправе исключить второстепенный сценарий.
Доступность эксперта. При оплате по времени отсутствие ответственного заказчика быстро превращается в простои или реализацию догадок. Укажите конкретного заместителя и допустимый срок ответа. Фиксированная модель тоже требует участия, особенно при приёмке.
Контроль бюджета. Если сумма ограничена, задайте денежный предел и точки пересмотра. Лимит расходов не равнозначен гарантии полного объёма. При приближении к нему команда должна показать готовый результат и предложить выбор дальнейших действий.
Если по двум осям ситуация противоречива, не усредняйте её. Например, стабильные формы при неизвестной интеграции позволяют выделить интеграцию в самостоятельную проверку, а не объявлять весь проект одинаково понятным.
Заполненный пример: этап с неопределённой интеграцией
Предположим, компания согласовала обработку заявок, но доступ к внешнему справочнику пока не проверен. Это учебный пример, а не оценка конкретного проекта.
Первый этап — проверить авторизацию, чтение справочника и обработку недоступности на тестовой среде. Лимит — 120 часов по условной единой ставке 3 000 рублей: максимум 360 000 рублей в согласованной налоговой базе.
После 60 часов команда показывает журнал экспериментов, работающий пробный запрос и список ограничений. После 90 часов — обновлённый прогноз завершения. Дальнейшие работы сверх 120 часов требуют отдельного решения. Неиспользованные часы не превращаются автоматически в обязательный платёж: порядок расчёта фиксируют заранее.
Если потрачено 72 часа, фактическая сумма составляет 216 000 рублей. До лимита остаётся 48 часов, или 144 000 рублей. Эти числа описывают финансовый остаток, а не гарантированную трудоёмкость оставшейся задачи.
Результат проверки: подтверждённый способ подключения, ограничения доступа, пример ошибок, решение о следующем этапе. После этого обработку заявок можно оценить с меньшей неопределённостью и выбрать для неё другую модель.
Шаблон решения для рабочей встречи
Заполните одну карточку на этап:
- Результат: какой рабочий сценарий или доказательство получает заказчик.
- Границы: какие роли, объекты и исключения входят.
- Неизвестные: что требуется проверить и кто предоставляет данные.
- Модель: фиксированная цена либо согласованный труд с лимитом.
- Бюджет: ставка или сумма, налоговая база, дополнительные расходы.
- Контроль: периодичность демонстрации, состав отчёта, прогноз остатка.
- Остановка: порог расходов и человек, принимающий решение.
- Приёмка: наблюдаемые результаты, примеры данных, проверяющий.
- Изменения: канал запроса, оценка влияния, полномочия согласующего.
- Передача: доступные заказчику материалы на каждой контрольной точке.
Перед подписью попросите обе стороны независимо пересказать карточку. Если подрядчик обещает «готовую систему», а заказчик ожидает только проверку интеграции, разногласие уже видно.
Ошибки, которые делают любую модель неудобной
Не сравнивайте фиксированное предложение полного запуска с почасовой оценкой только программирования. Сначала выровняйте состав работ: это разобрано в статье о сравнении предложений подрядчиков.
Не превращайте лимит в молчаливое согласие на перерасход. Предупреждение должно приходить до исчерпания бюджета и содержать варианты: сократить объём, завершить исследование, увеличить лимит либо остановиться с передачей материалов.
Не выбирайте модель только по страху переплатить. Проверяйте, способен ли ваш сотрудник регулярно принимать решения и готов ли подрядчик показывать промежуточный результат. Если нет, исправлять нужно организацию проекта.
Проверьте, что происходит при остановке этапа
Возможность остановиться полезна только при понятном результате передачи. До старта согласуйте, какие материалы заказчик получает на контрольной точке: актуальное описание сценариев, результаты исследований, доступный код, инструкции запуска и список незавершённых задач. Состав зависит от этапа, но не должен выясняться после возникновения спора.
Отдельно обсудите работы без видимого экрана: настройку среды, проверку данных, технический эксперимент. Для них тоже нужен результат, например воспроизводимый опыт и вывод о пригодности подхода. Отчёт «занимались интеграцией» не объясняет, что изменилось в знаниях команды.
Проверьте, кто оплачивает повторную работу при изменении входных условий и как фиксируется ожидание доступа. Это позволяет отличать продуктивное исследование от простоя. Наконец, убедитесь, что следующий подрядчик сможет понять переданные материалы: возможность продолжить проект является практической проверкой качества промежуточного результата.
Следующий шаг
Заполните карточку одного этапа и назовите три неизвестных, сильнее всего влияющих на оценку. На обсуждение разработки с ExtentLab принесите пример ожидаемого результата и доступные данные. Это позволит выбрать проверку, границу бюджета и условия продолжения по фактам.