Agile или waterfall: как вести заказную разработку и что это меняет для заказчика

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

Чем waterfall отличается от agile простыми словами?

Waterfall («водопад») идёт последовательно: требования, дизайн, разработка, проверка, запуск — следующий шаг начинается после согласования предыдущего. Agile дробит работу на короткие циклы, в каждом из которых делают, показывают и уточняют план. Разница для вас — в том, когда фиксируется объём: до старта или по ходу.

Обе модели — не религия, а способ распределить неопределённость. В waterfall её снимают на старте: подробным брифом, прототипом, техзаданием. В agile её снимают по ходу: пользователи видят работающие части, и следующий шаг выбирают по их реакции.

• Waterfall — про предсказуемость. Вы заранее знаете сумму, дату и состав. Платите тем, что передумать дорого: изменение после согласования — новый документ, новая цена, новый срок.
• Agile — общее название семейства подходов, ценности которых записаны в Agile-манифесте 2001 года. Самый известный из них — Scrum. По Scrum Guide (редакция 2020 года) спринт длится не больше одного календарного месяца, в конце команда показывает результат на обзоре и вместе с владельцем продукта решает, что дальше.
• Kanban — поток задач без спринтов: берут следующую по приоритету, как только освободились. Подходит для поддержки и мелких доработок.

Важно: в Scrum есть роль владельца продукта — человека, который отвечает за ценность продукта и решает, что делать в первую очередь. В заказной разработке эту роль чаще всего играете вы или ваш сотрудник. Без него agile не работает: команда не знает, что важнее, и делает то, что проще.

Как каждая модель выглядит в договоре?

В waterfall договор описывает результат: техзадание, твёрдую цену, конечный срок и приёмку по акту. В agile договор описывает процесс: ставку, длину спринта, правила приёмки каждого цикла и порядок остановки. Методология — это не слово в презентации, а конкретные пункты договора.

Для договора подряда закон даёт обе опоры. По ст. 708 ГК РФ в договоре указывают начальный и конечный сроки, а по соглашению сторон — и промежуточные, то есть сроки этапов; если договор не говорит иного, подрядчик отвечает за нарушение любого из них. По ст. 709 ГК РФ цена бывает твёрдой или приблизительной. Подробно о плюсах и минусах каждой схемы оплаты — в статье «Фиксированная цена или почасовая оплата»; здесь — о том, как модель процесса ложится на текст договора.

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

Пункт договора	Waterfall	Agile	Гибрид
Объём работ	Техзадание целиком до старта	Цель продукта и список задач, который меняется	ТЗ на первую версию, дальше — список задач
Цена	Твёрдая сумма за весь объём	Ставка за спринт или за час, итог открыт	Твёрдая сумма за версию, развитие — по отдельным заказам
Срок	Конечная дата и, по желанию, сроки этапов	Длина спринта; дата релиза — прогноз	Дата первой версии; темп развития — по договорённости
Приёмка	Акт по всему объёму или по этапам	Демонстрация и приёмка каждого спринта	Акт за версию, затем акты за каждый заказ
Изменения	Дополнительным соглашением	Через список задач, без допсоглашений	Внутри версии — допсоглашением, после — новым заказом
Кто несёт риск недооценки	Исполнитель	Заказчик	Исполнитель — в версии, заказчик — в выборе следующих задач

Когда подходит waterfall, а когда agile?

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

Признаки того, что подойдёт waterfall:

• есть аналог или образец — «как у конкурента, но со своими услугами»;
• процесс уже идёт вручную, и его нужно перенести в систему без изменений логики;
• бюджет нельзя превысить — например, он утверждён собственником или выделен под проект;
• дата запуска привязана к событию: выставке, сезону, рекламной кампании.

Признаки того, что нужны итерации:

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

Ваша ситуация	Что подойдёт	Почему	Ориентир по прайсу
Нужен сайт компании с понятными разделами	Waterfall	Объём известен, а бюджет и дата важнее гибкости	Корпоративный сайт — от 56 000 ₽, 3–4 дня
Интернет-магазин с каталогом, оплатой и одной связкой со складом	Waterfall с этапами	Функции типовые, риск — в интеграции, её выносим в отдельный этап	Интернет-магазин — от 104 000 ₽, от 5 дней
Новый сервис, спрос на который не проверен	Гибрид: первая версия с одной гипотезой, дальше итерации	Полное ТЗ сейчас — это догадки, а деньги разумнее тратить после реакции пользователей	Веб-приложение / SaaS — от 160 000 ₽, от 10 дней
Работающий продукт, который растёт по обратной связи	Agile	Список задач меняется каждую неделю, фиксировать его на год бессмысленно	Поддержка и развитие — от 7 900 ₽ в месяц
Связать CRM и 1С по известной схеме обмена	Waterfall	Схему можно описать до старта и проверить на реальных данных	Интеграции — от 32 000 ₽, от 2 дней

Можно ли совместить фиксированную цену и итерации?

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

Как это устроено у нас. Цена фиксируется в договоре до старта, оплата — 50 % предоплата и 50 % по акту, объём меняется только по соглашению сторон отдельным документом. Итерации встроены внутрь фиксированного проекта в двух местах:

1. Прототип до кода. Структуру и экраны согласуем до того, как начнётся сборка. Это и есть короткий цикл «показали — уточнили», только до того, как изменения стали дорогими.
2. Раунды правок. До 2 раундов: на макете или прототипе и после сборки. У интернет-магазина, веб- и мобильного приложения — до 2 раундов на прототипе и до 2 на готовой сборке. Правки — в рамках согласованной структуры, смена концепции — отдельно.

После запуска начинается развитие: подписка на поддержку и развитие — от 7 900 ₽ в месяц или разовые задачи. Каждую доработку оцениваем отдельно, так что вы в любой момент решаете, продолжать или остановиться. Ход работ виден на доске задач в личном кабинете — подробнее в статье о прозрачности в разработке.

Для нового сервиса гибрид выглядит так: первая версия с одной-двумя ключевыми функциями по тарифу «Веб-приложение / SaaS» — от 160 000 ₽, от 10 дней, затем развитие по результатам. Как выбрать сценарий для первой версии, мы разбирали в статье «MVP или полная версия». Пример быстрого пути до работающего продукта — «Довод», ассистент юриста: от первой строки кода до работы на своём домене прошло 7 дней, а в основе — своя база законов и сноски, которые сервер проверяет перед показом.

Признаки, что «agile» — отговорка

Гибкость должна давать вам контроль, а не отнимать его. Если подрядчик говорит «у нас agile», но не показывает работающих частей, не называет ставку и длину цикла и не даёт остановиться, — это не методология, а способ не брать на себя обязательств. Вот на что смотреть.

• Нет демонстраций. Спринты идут, а вы видите только отчёты «готово 60 %». По Scrum Guide результат спринта — пригодный к использованию инкремент, который показывают на обзоре; его можно открыть и проверить.
• Нет цены за единицу. Не названа ставка за спринт или за час, нет потолка в месяц. Тогда бюджет действительно бесконечный.
• Нельзя остановиться. В договоре нет права прекратить работы после любого спринта с оплатой только сделанного.
• Код и доступы недоступны. Вы не видите репозиторий и тестовый стенд. Без них проверить результат цикла невозможно.
• План меняет подрядчик, а не вы. Приоритеты в списке задач расставляет команда, «потому что так технически правильнее», а вас ставят перед фактом.
• Срок «когда будет готово». Нет даже прогнозной даты первой рабочей версии и нет контрольных точек.
• Гибкость в одну сторону. Добавлять задачи можно, а убрать ненужные из оценки — нет.

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

Когда спор о методологии вам не нужен

Если проект небольшой и типовой — лендинг, бот, сайт компании, — обсуждать спринты бессмысленно: работа занимает дни, а не месяцы. Лендинг у нас — от 24 000 ₽ за 2 дня, Telegram-бот — от 16 000 ₽ за 1–2 дня. Здесь важнее хороший бриф и прототип, чем название процесса.

Ещё несколько ошибок, которые встречаются чаще, чем неправильный выбор модели:

• Выбор по моде. Agile выбирают, потому что «так все делают», хотя у заказчика нет человека на роль владельца продукта.
• ТЗ без приоритетов. В waterfall всё в ТЗ кажется одинаково важным, и при нехватке бюджета резать нечего. Разметьте пункты на «обязательно» и «потом».
• Приёмка «на глаз». Ни в одной модели нельзя принимать работу без критериев. По нашему договору у заказчика 5 рабочих дней, чтобы подписать акт или направить мотивированный отказ с перечнем замечаний; если ничего не направить, работы считаются принятыми.
• Гарантия путается с развитием. Гарантия — это устранение ошибок по вине исполнителя, у нас 30 календарных дней с даты акта. Новые функции в неё не входят ни в waterfall, ни в agile.

Если вы не готовы описать задачу сами, это не повод сразу уходить в почасовую оплату. Часто достаточно разобрать задачу на брифе и составить ТЗ вместе — как это сделать без опыта, мы описали в статье о техзадании.

Что спросить у подрядчика про процесс?

Не спрашивайте «вы agile или waterfall» — ответ ничего не скажет. Спросите, что будет записано в договоре, когда вы увидите первую работающую часть, как оформляются изменения и как остановиться. По ответам станет понятно, как на самом деле устроена работа.

1. Что фиксируется в договоре: объём, цена, срок — или ставка и длина цикла?
2. Когда я увижу первую работающую часть — прототип, тестовую сборку, стенд?
3. Сколько раундов правок входит и что считается правкой, а что — новой задачей?
4. Как оформляется изменение объёма и кто считает его цену и срок?
5. Есть ли сроки этапов и какая ответственность за их срыв? У нас, например, пеня за просрочку — 0,1 % от стоимости работ в день, не более 10 % от суммы договора, и она действует для обеих сторон.
6. Где я вижу статус задач и могу ли открыть репозиторий и тестовый стенд?
7. Могу ли я остановить работы после любого этапа и что я получу на этот момент?
8. Кто с моей стороны должен принимать решения и сколько времени в неделю это займёт?
9. Что будет после запуска: сколько длится бесплатная поддержка и как оплачивается развитие?

Последний вопрос часто забывают, хотя именно после запуска гибкость становится полезной. У нас бесплатная поддержка после запуска — 7 дней для лендинга, бота, интеграций, автоматизации маркетплейсов и ИИ-ассистента, 14 дней для интернет-магазина, веб- и мобильного приложения и 1 месяц для корпоративного сайта; дальше — поддержка и развитие по подписке или разовыми задачами. Тарифы — на странице цен, полные формулировки — в типовых договорах.

Короткие ответы на частые вопросы

Что выгоднее заказчику — agile или waterfall?

Если задачу можно описать заранее, waterfall: цена и срок известны до старта, риск недооценки на исполнителе. Если описать нельзя, потому что продукт новый или требования меняются по обратной связи, — итерации, но тогда бюджет контролируете вы, ограничивая спринты.

Можно ли работать по Scrum, если в договоре фиксированная цена?

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

Что такое спринт простыми словами?

Отрезок фиксированной длины, обычно одна-две недели, за который команда делает согласованный кусок работы и показывает его заказчику. По Scrum Guide спринт длится не больше месяца, а в конце проходит обзор результата.

Нужно ли заказчику участвовать в agile-проекте?

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

Как ограничить бюджет при гибкой разработке?

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

Услуги и кейсы по теме: заказная разработка · веб-приложения и SaaS · кейс «Довод» · цены и сроки