Как основателю читать коммерческое предложение на разработку

У полного предложения одни и те же основные разделы, кто бы его ни писал. Используйте эту таблицу как карту при чтении.

Хороший объём работ описывает, что может сделать пользователь, а не только названия экранов. «Пользователи регистрируются по email или через Google и могут восстановить пароль» можно проверить. «Модуль авторизации» проверить нельзя.

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

Например, ProAnalizy переводит результаты медицинских анализов на понятный язык. Его основной сценарий можно записать как результат: посетитель загружает PDF, JPG или PNG с результатом анализа и получает объяснение, без регистрации. Такая строка точно говорит обеим сторонам, что значит «готово».

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

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

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

Инженером быть не нужно, но после чтения предложения вы должны уметь ответить на эти вопросы:

• На чём будет сделан продукт и почему этот стек подходит именно ему?
• Кому принадлежат код и аккаунты: репозиторий, хостинг, домен, магазины приложений, аналитика?
• Где будет хостинг и сколько примерно он будет стоить в месяц после запуска?
• Будет ли код задокументирован настолько, чтобы его мог подхватить другой разработчик?
• Как команда работает с типичными рисками безопасности, например из OWASP Top 10?

Хорошее агентство объясняет свои решения простыми словами. «Мы всегда так делаем» не считается объяснением.

По правам: попросите, чтобы репозиторий с первого дня был в аккаунте вашей компании. Перенести его потом можно, как показывает инструкция GitHub по передаче репозитория, но это зависит от доброй воли другой стороны.

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

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

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

Сравниваете предложения прямо сейчас? Пришлите нам бриф, и вы получите предложение, написанное по этим правилам, которое можно положить рядом с остальными.

Проверьте, упоминаются ли в предложении тестирование, скорость и доступность или только функции. Ищите конкретику:

• Какие браузеры и устройства поддерживаются?
• Какой скорости должен достичь продукт? Распространённый ориентир дают Core Web Vitals от Google: контент загружается за 2,5 секунды, отклик на действия укладывается в 200 миллисекунд.
• Кто тестирует продукт до запуска и как сообщают об ошибках и исправляют их?
• Входит ли базовая доступность, например работа с клавиатуры и читаемый контраст?

Если «готово» не определено, последние недели проекта превращаются в спор. Письменное определение превращает их в чек-лист.

Уточните, что именно покрывает цена и как разбиты платежи. Аванс плюс платежи по этапам считаются стандартом, а 100% вперёд нет.

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

Проверьте и условия выхода. Честное предложение позволяет остановиться между этапами, не оплачивая работу, которая ещё не начата. Подробнее о двух основных моделях оплаты читайте в статье «Фиксированная цена или почасовая оплата».

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

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

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

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

Один тревожный знак означает вопрос, который стоит задать. Три и больше обычно значат, что агентство недостаточно поняло проект, чтобы его оценить.

Предложение остаётся черновиком, а не окончательной офертой. Хорошие агентства ждут вопросов и обновляют документ, а то, как они отвечают, тоже часть вашей оценки.

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

Если агентство до подписания отказывается что-либо уточнить письменно, после подписания добиться ясности будет ещё труднее.

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

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

Только после этого сравнивайте суммы. Если одно предложение намного дешевле, ищите, что в нём упущено.

Если одно намного дороже, спросите, что в него входит такого, чего нет у других. Иногда разница в гарантийном периоде или этапе дизайна, который вам действительно нужен.

Возьмите их на последний созвон с агентством. Ясные и конкретные ответы значат, что можно подписывать.

• Что именно не входит в эту цену?
• Кто будет работать над проектом каждый день?
• Что будет, если нам понадобится изменить объём работ?
• Кому в итоге принадлежат код и все аккаунты?
• Какая поддержка входит после запуска?

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