У сметы есть свойство, которое сбивает с толку: она выглядит как ответ. Пришёл документ с суммой — значит, вопрос «сколько стоит» закрыт, остаётся сравнить с другим таким же и выбрать.
На самом деле смета — это ответ на задачу, которую подрядчик восстановил по вашему описанию. Насколько верно восстановил, какие пустые места заполнил своими предположениями и что решил не включать — из самого документа не видно. Видно только сумму.
Отсюда практический вопрос: как проверить смету, не будучи разработчиком. Ответ — не читать её внимательнее, а задать по ней вопросы. Ниже семнадцать, которые я задал бы на вашем месте, и то, что означает отсутствие ответа на каждый.
И сразу оговорка: тем, что приходит в ответ на запрос, нередко оказывается не смета, а оценка стоимости разработки — прогноз, а не документ с разложенной суммой. С разницы между ними и начну, потому что от неё зависит, чего вообще можно требовать.
Смета и оценка стоимости разработки — разные документы
Разница практическая, и путаница в ней портит сравнение.
Оценка стоимости разработки — это прогноз объёма работ. Она может быть вилкой, она меняется по мере того, как задача проясняется, и её нормально давать до того, как всё известно. Честная оценка звучит как «от такой-то суммы, а вот от чего она сдвинется вверх».
Смета — документ, где сумма разложена по работам. Она отвечает не только «сколько», но и «за что».
Проблема в том, что «сметой» часто называют письмо с одним числом. Это оценка, и требовать от неё точности бессмысленно — надо либо доводить её до сметы вопросами ниже, либо принимать как ориентир и не сравнивать с чужим документом построчно.
Как задавать эти вопросы
Три правила, без которых список превращается в чтение.
Письменно. Устный ответ через месяц не вспомнит никто, а ответ в переписке остаётся частью договорённостей — и часто переезжает в договор дословно.
Одинаково всем, кого сравниваете. Если одному подрядчику вы задали семнадцать вопросов, а другому три, вы сравниваете не предложения, а собственную дотошность.
Смотрите не только на ответ, но и на то, как он даётся. Встречный уточняющий вопрос — хороший признак: значит, человек думает о вашей задаче, а не заполняет шаблон.
Что перед вами за документ: вопросы 1–3
1. Сколько в смете строк и что стоит за самой крупной? Одна строка «разработка приложения — сумма» проверке не поддаётся вовсе: в ней нечего разбирать. Попросите разложить хотя бы на блоки работ. Если подрядчик не готов раскрывать внутреннюю калькуляцию — это нормально, она его дело. Но состав работ и границы результата должны быть понятны в любом случае: без них вы не сможете сравнить это предложение с другим.
2. По какому описанию задачи её считали? Попросите вернуть вам это описание своими словами. Если подрядчик считал по вашему письму в три предложения, часть недостающих деталей ему пришлось предположить. Разница между двумя сметами на «одно и то же» может оказаться не разницей ставок, а разницей в том, что каждый понял под задачей.
3. Это фиксированная цена, вилка или оплата по факту работ? Три разных обещания, которые в документе выглядят одинаково. У фиксированной цены должен быть зафиксирован и объём — иначе она держится ровно до первого уточнения. У вилки надо спросить, что двигает её к верхней границе.
Что входит в сумму: вопросы 4–9
4. Входит ли проектирование и что будет его результатом? Экраны, состояния, правила поведения — кто-то должен это описать до того, как начнётся код. Если этапа нет в смете, спросите, кто примет эти решения и когда. Ответ «по ходу разберёмся» означает, что способ принятия этих решений пока не зафиксирован: стоит уточнить, кто их принимает и в какой момент участвуете вы.
5. Чей дизайн и по скольким экранам считали? Количество и сложность экранов заметно влияют на объём дизайна и разработки — один экран бывает формой в три поля, а бывает редактором или картой. Поэтому набор, по которому считали, должен быть назван. Если макеты ваши, спросите, что произойдёт, когда они не подойдут технически. Если их делает подрядчик, спросите, сколько кругов правок входит.
6. Кто делает тестирование и на чём? Отдельный человек, разработчик сам или вы после сдачи. Все три варианта бывают, но третий стоит знать заранее. Для мобильного приложения уточните набор устройств: «работает на моём телефоне» и «работает на распространённых устройствах» — разный объём работы.
7. Сколько кругов правок входит в сумму? Не «предусмотрены ли правки», а сколько. Даже при хорошем описании задачи по ходу проекта появляются уточнения, поэтому важно заранее понимать, где заканчиваются входящие в цену изменения и начинаются оплачиваемые отдельно.
8. Входит ли запуск? Для приложения — публикация в магазинах и прохождение модерации. Для сайта — перенос на боевой сервер, домен, почта, сертификат. Для бота — размещение и подключение к вашим каналам. Это работа, а не нажатие кнопки, хотя разработкой она и не выглядит. Проверьте отдельно, включена она в предложение или оплачивается сверх него.
9. Что входит в интеграцию с чужой системой? Интеграции — одно из мест, где легко недооценить объём работы. Разобраться в чужом API, дождаться доступов, столкнуться с ограничениями, которых нет в документации, — это заметная часть работы, и она плохо видна в строке «интеграция с CRM». Спросите прямо: что вы делаете, если выяснится, что нужного метода в их API нет?
Чего в сумме нет: вопросы 10–12
10. Покажите список исключений. Не «а это входит?» по каждой строчке — попросите готовый перечень того, что оплачивается отдельно. Готовый список исключений — хороший признак: границы предложения сформулированы заранее, а не выясняются по одному пункту. У меня границы описаны прямо на странице разработки приложений, рядом с ценами.
11. Какие допущения вы сделали, когда считали? Для меня это один из самых полезных вопросов списка. Если часть исходных данных не определена, подрядчику приходится что-то предполагать за вас: объём каталога, число ролей, что дизайн будет типовым, что данные приедут в готовом виде. Пока эти предположения не названы вслух, они выглядят как ваши договорённости — а выяснится это в момент, когда смета вырастет.
Если после получения сметы выйдет задать всего один вопрос — я бы спросил именно про допущения.
12. Что происходит, если объём изменится по ходу? Не «можно ли добавить функцию», а как это оформляется: кто оценивает добавку, за сколько дней, что происходит со сроком остальных работ. Порядок изменений легко оставить «на потом», хотя именно он определяет, что произойдёт с ценой и сроком, если объём поменяется по ходу. Ответ потом стоит закрепить в договоре — вместе с приёмкой, сроками и тем, что передаётся по коду.
Срок: вопросы 13–14
13. Из чего сложен срок? «Три месяца» и «три месяца по этапам с датами демонстраций» — разные документы. Из второго видно, когда вы впервые увидите работающий продукт, а не описание.
14. Что произойдёт со сроком, если задержу я? Тексты, фотографии, доступы к системам, ответы на вопросы, согласование внутри компании. Спросите, чего ждут от вас и к какому моменту. Задержка со стороны заказчика тоже может сдвинуть проект — поэтому лучше договориться заранее, какие материалы и решения нужны от вас и к какому сроку.
Люди и деньги: вопросы 15–16
15. Кто именно будет делать и чьё время в сумме? Разработчик, дизайнер, тестировщик, менеджер, аналитик. Менеджмент в смете — это нормально и честно, если он назван. Хуже, когда состав команды не раскрыт вовсе: тогда непонятно, что вы сравниваете, когда сравниваете два числа.
16. Как устроены платежи и что считается сдачей этапа? Размер предоплаты, число платежей, привязка к этапам. И главное — по какому признаку этап считается принятым. «Оплата по факту выполнения» без определения факта — это отложенный спор.
Что происходит после сдачи: вопрос 17
17. Что входит в поддержку, сколько она длится и что дальше? Гарантийный срок, что именно в нём исправляется бесплатно, чем это отличается от доработок и по какой ставке идёт работа после. Ответ на этот вопрос особенно важно получить письменно: он касается расходов уже после сдачи — когда проект перестанет быть проектом, а платить по нему вы продолжите.
Отдельно замечу, что этот вопрос — про смету, а не про весь список расходов после запуска. Тех больше, и они разобраны в статье о том, почему дешёвая разработка обходится дороже.
Что слышите и как это читать
Часть ответов звучит успокаивающе, а сведений не несёт. Короткая расшифровка — её удобно держать рядом со сметой.
| Что слышите | Что уточнить |
|---|---|
| «Входит всё» без перечня | попросить зафиксировать состав письменно |
| «Оценим потом» | правило пересчёта: кто оценивает добавку и в какой срок |
| «Три месяца» | этапы и точки, где вы увидите работающее, а не описание |
| «Интеграция включена» | границу работ на стороне чужого API |
| «Поддержка есть» | срок и что именно считается гарантийным случаем |
| «Дизайн наш» | число экранов и сколько кругов правок входит |
Как проверить смету по ответам, а не по сумме
Пройдя список, вы получите не оценку «хорошая смета или плохая», а карту: на что документ отвечает и на что нет. Дальше полезнее смотреть на три вещи.
Где ответов не оказалось. Пустые места — это будущие разговоры о деньгах, и сами по себе они ещё не проблема. Но если дополнительная работа всплывает после старта, обсуждать её приходится уже внутри идущего проекта: со сроками, которые сдвинутся, и бюджетом, который распределён.
Совпадают ли ответы с документом. Бывает, что на словах входит многое, а в смете этого нет. Тогда просьба одна: допишите в документ. Отказ дописать то, что уже пообещали словами, говорит сам за себя.
Как разошлись ответы у разных подрядчиков. Если два предложения сильно расходятся в цене при одинаковых вводных, часть разницы обычно становится видна по составу: у одного нет проектирования, у другого не заложено тестирование, третий не считал интеграцию. Остаток уже можно обсуждать предметно — как ставку, процесс, состав команды и заложенный риск. А вот если вводные вы давали разные — сравнивать пока нечего, и начинать надо с описания задачи, а не со сравнения смет.
Чего в этих семнадцати вопросах нет
Юридической части. Договор, ответственность, права на исходный код, порядок расторжения — это отдельный документ и отдельный разговор. Смета отвечает на вопрос «что и за сколько», договор — «что будет, если что-то пойдёт не так».
Оценки «дорого или дёшево». Список не отвечает, справедлива ли сумма. Он отвечает на другой вопрос — за что она названа. Без понимания состава оценивать «дорого или дёшево» почти бессмысленно: сначала предложения надо сделать сопоставимыми.
Проверки квалификации. Портфолио, отзывы, разговор с прошлыми заказчиками — всё это про то, сделает ли подрядчик хорошо, а не про то, что написано в смете. Часть таких вопросов я вынес в ответы на частые вопросы.
Что делать со списком
Задавать все семнадцать в одном письме не обязательно и, честно говоря, не всегда уместно. Если хочется начать с малого — начните с вопросов 1, 10 и 11: из скольких строк состоит смета, что в неё не входит и какие допущения подрядчик сделал за вас. Даже эти три ответа уже покажут, насколько вообще можно доверять сравнению по итоговой сумме.
Я собрал все семнадцать в рабочий лист: вопрос, зачем он нужен и две колонки под короткие пометки — лист рассчитан на сравнение двух предложений сразу. Его можно заполнять для себя, а можно отправить подрядчику как есть: там же лежит и сопроводительная фраза, чтобы это не выглядело допросом.
Напишите слово «смета» в Telegram или Max (контакты в подвале сайта) — пришлю лист.
А если хотите взгляд со стороны, пришлите состав работ из своей сметы, суммы можно закрыть. Скажу, на какие из семнадцати вопросов она уже отвечает и что я бы уточнил до подписания. Если окажется, что смета хорошая, — так и скажу: это тоже нормальный результат разбора.