Разработка по фиксированной цене: как мы держим сумму из договора

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

Фиксированная цена работает, когда объём зафиксирован до сметы, а не после. Разбираем, как выглядит честный проект по фиксированной цене: что должно быть в договоре, от чего зависит стоимость, где модель ломается, что проверить в договоре в Казахстане и как мы ведём такие проекты в Pazl.

Что на самом деле значит «фиксированная цена»

Договор с фиксированной ценой задаёт одну сумму за один описанный объём к одной дате. Вся идея в этом. Подвох в слове «описанный». Если ТЗ расплывчатое, «фиксированная цена» значит лишь то, что исполнитель выбрал число и надеется.

Чтобы цену можно было честно назвать фиксированной, нужны три вещи:

1. Письменное ТЗ, которое подписали обе стороны: экраны, сценарии, интеграции, данные, что входит и что нет.
2. График оплаты, привязанный к этапам и приёмке, а не к отработанным часам.
3. Порядок изменений для всего, что попросили после фиксации ТЗ: отдельно, письменно и до начала работы.

Без всех трёх «фиксированная цена» на деле почасовая оплата с цифрой для рекламы. Клиент узнаёт разницу, как только просит «одно маленькое дополнение».

Три способа назвать фиксированную цену и где прячется риск

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

Цена при расплывчатом ТЗ. В договоре есть сумма, но ТЗ это страница пунктов, а не описание того, как работает система. Каждая неясность в ходе работы решается в пользу исполнителя, потому что нет документа, на который можно сослаться.

Сначала ТЗ, потом цена. ТЗ написано и утверждено до того, как названа сумма. Цена отражает описанный результат, поэтому разрастание объёма видно сразу: это то, чего нет в документе. Только такой вариант ведёт себя как настоящая фиксированная цена.

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

Как мы строим работу по фиксированной цене

Наш порядок построен на том, чтобы зафиксировать объём раньше цены, и он одинаков для проектов любого размера.

Звонок. Говорим о том, что должна делать система, кто ею пользуется и с чем она связана: банк и оплата, Kaspi, 1С, CRM, касса, внутренняя база. На этом звонке цену не называем.

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

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

Разработка с регулярными показами. Клиент видит работающую версию по ходу проекта, а не письма со статусом. Это и самый быстрый способ поймать неверно понятое требование до того, как оно обойдётся переделкой.

Приёмка. Клиент проверяет сделанное по подписанному ТЗ и подписывает акт.

Гарантия 6 месяцев на всё, что мы сделали, с момента приёмки.

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

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

Исходный код и доступы передаём клиенту. Как именно переходят права на программу, должно быть явно написано в договоре, с нами или с кем угодно ещё; формулировку стоит проверить у юриста.

Стартовые цены у нас: сайт от 540 000 ₸, веб-приложение или личный кабинет от 1 000 000 ₸, типовая интеграция двух систем (например, 1С и Kaspi) от 270 000 ₸. Крупные проекты растут от объёма, а не от отработанных часов.

Что влияет на цену: типовые проекты

Цены ниже это нижняя граница нашего прайса, а не готовое предложение. Итог зависит от интеграций, объёма данных и сложности дизайна. Считайте таблицу началом разговора, а не сметой.

Две ловушки объёма всплывают почти в каждом споре о смете. Первая: слово «интеграция», которое каждая сторона понимает по-своему (только чтение данных или двусторонний обмен с обработкой ошибок?). Вторая: «админка», которая для одной стороны экран входа, а для другой полноценная система ролей и прав. Опишите оба пункта в ТЗ письменно до того, как названа цена. Как мы описываем обмен с учётной системой, видно на странице интеграции 1С.

Где фиксированная цена ломается

Неописанные зависимости от сторонних сервисов. Если система зависит от API банка, Kaspi или поставщика кассы, и этот API меняется посреди работы, кто платит? Хороший договор прямо говорит, что исполнитель не отвечает за изменения у третьей стороны, потому что никакая фиксированная цена не может учесть чужие планы.

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

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

Оплата по времени, а не по этапам. Если счета уходят каждую неделю независимо от того, что сдано, интересы сторон не совпадают. Это почасовая оплата под вывеской фиксированной цены.

Договор в Казахстане: что проверить

Этот раздел не заменяет консультацию юриста, но несколько вещей стоит проверить в любом договоре на разработку:

• Стороны и предмет. Договор между вашим ТОО или ИП и исполнителем, ТЗ приложением, цена в тенге, срок и порядок приёмки.
• Этапы и оплата. Оплата привязана к сданным этапам и подписанным актам, а не к календарю.
• Закрывающие документы. Счёт и акт выполненных работ. Плательщики НДС выписывают счёт-фактуру в электронной форме через ИС ЭСФ (Налоговый кодекс РК, ст. 492 п. 1, текст на adilet.zan.kz). Какие документы нужны именно вашей бухгалтерии, уточните у бухгалтера.
• Права на код. Кому и когда переходят права на программу и исходный код. Пропишите это явно и проверьте формулировку у юриста.
• Изменения. Любая работа вне ТЗ оформляется дополнительным соглашением с ценой и сроком.
• Персональные данные. Если система хранит данные граждан Казахстана, база должна находиться в республике (Закон РК от 21.05.2013 № 94-V «О персональных данных и их защите», ст. 12 п. 2, текст на adilet.zan.kz). Это закладывается в ТЗ с первого дня, а не дописывается потом.
• Споры. Порядок претензий и подсудность. Обычно сначала переговоры и письменная претензия.

Как это выглядит на наших проектах

Мы делали системы по нескольким повторяющимся схемам, которые хорошо ложатся на фиксированную цену.

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

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

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

Во всех случаях фиксированную цену удерживало ТЗ. Когда граница ясна, разработка становится простой частью.

Итог

Фиксированная цена не уловка, а дисциплина, которая целиком зависит от того, насколько хорошо описан объём до того, как названа сумма. Смета без подписанного ТЗ это догадка с цифрой. Смета на основе ТЗ, с оплатой по этапам, понятным порядком изменений и гарантией, которая начинается после сдачи, это настоящее обязательство, которое стороны могут друг с друга спросить. Как этот подход работает на первой версии продукта, читайте в статье как мы разрабатываем MVP.