«Сколько будет стоить доработать каталог?» — вопрос, на который честный ответ звучит неудобно: от 30 тысяч до 300, смотря что значит «доработать». Это не увиливание, а отражение того, как устроена оценка разработки.
Разбираем, из чего складывается цена, почему вилка в начале разговора широкая и что делает её уже.
Оценка — это часы, умноженные на ставку
Любая цена разработки раскладывается на две величины: сколько часов займёт работа и сколько стоит час. Вторая величина у подрядчика фиксирована и публична. Весь разговор о цене — это разговор о первой.
Поэтому первое, что стоит спросить у подрядчика: сколько часов он заложил и на что. Если в ответ звучит общая сумма без разбивки, проверить её нечем — и сравнить с другим предложением тоже.
Из чего складываются часы
Собственно написание кода — обычно меньше половины сметы. Остальное:
- Разбор задачи. Что именно должно получиться, как это ведёт себя в крайних случаях, что происходит при ошибке. На этом шаге половина задач меняется до неузнаваемости.
- Разработка. То, что все представляют под словом «сделать».
- Тестирование. Проверка не только того, что новое работает, но и того, что старое не сломалось.
- Выкладка. Перенос на боевой сайт, проверка после переноса, откат, если что-то пошло не так.
- Запас на неизвестное. Чем меньше известно о проекте, тем он больше.
Когда смета выглядит как «доработка каталога — 40 часов», это означает, что подрядчик сложил все пять пунктов и округлил. Разбивка по ним и есть то, что отличает оценку от угадывания.
Почему вилка в начале широкая
Разброс в оценке отражает незнание. В начале разговора подрядчик не видел код, не знает, какие в проекте костыли, и не представляет, сколько мест придётся затронуть. Вилка «от 30 до 300» — это честное «я пока не знаю».
Сужают её разбором задачи, чтением кода, прототипом — уговоры тут не помогают. После аудита проекта вилка обычно сходится до 20–30%, и это нормальная точность для разработки.
Подозрительна как раз обратная ситуация: точная сумма, названная по описанию задачи в двух предложениях. Либо подрядчик делал ровно это десять раз, либо называет цифру, которую потом скорректирует.
Что делает оценку больше
Одна и та же по описанию задача стоит по-разному на двух сайтах. Факторы, которые поднимают цену, почти всегда одни и те же.
Правки ядра. Если предыдущий подрядчик менял файлы в bitrix/modules, сайт нельзя обновлять, а любая доработка делается с оглядкой. Разбор таких правок — отдельная работа, иногда больше самой задачи.
Нет тестовой копии. Разработка прямо на боевом сайте дороже: каждое действие выполняется осторожно, в нерабочее время, с планом отката. Поднять копию — день работы, который окупается на первом же проекте.
Старая версия платформы. На ядре пятилетней давности часть современных механизмов недоступна, и то, что сегодня решается штатно, приходится писать руками.
Интеграция с чужой системой. Цена здесь зависит от чужой стороны: есть ли документация, отвечает ли их поддержка, работает ли тестовый контур. Это самый частый источник срыва сроков, и не по вине разработчика.
Много согласований. Если решение принимают четыре человека в разных отделах, срок растягивается, а вместе с ним растёт и стоимость сопровождения проекта.
Что делает оценку меньше
Понятная постановка. Описанная задача с примерами экранов и поведением в спорных случаях сокращает разбор вдвое. Необязательно оформлять техническое задание — достаточно внятно описать, что должно получиться.
Пакетная работа. Пять мелких правок, собранных в один релиз, стоят дешевле, чем те же пять по отдельности: выкладка и проверка делаются один раз.
Готовность отказаться от половины. В любой задаче есть часть, которая даёт 80% пользы, и часть, которая стоит как всё остальное вместе. Разделить их — работа аналитика, и она окупается прямо в смете.
Три способа оценить
По аналогии. Подрядчик делал похожее и называет вилку. Быстро, бесплатно, точность невысокая. Годится, чтобы понять порядок цифр.
Декомпозицией. Задача разбирается на шаги, каждый оценивается отдельно, сумма складывается. Занимает от нескольких часов до нескольких дней, точность заметно выше. Для крупных проектов такой разбор часто делают платно — и это разумно: он сам по себе результат, с ним можно идти к другому подрядчику.
Прототипом. Сначала делается работающий кусок, по нему уточняется остальное. Дороже и дольше, зато снимает главный риск — обнаружить на середине, что задумано было неверно.
Как читать смету
На что смотреть, когда смета пришла:
- есть ли разбивка по задачам и часам, или одна строка на всё;
- заложены ли тестирование и выкладка, или только разработка;
- что написано про изменения в процессе — как оформляются и как оцениваются;
- что входит в гарантию и сколько она длится;
- кто отвечает за задержки на стороне третьих систем.
Смета без этих пунктов — не оценка, а намерение.
Ориентиры по порядку цифр
Чтобы разговор был предметным, вот наши отправные точки: автоматизация процессов — от 90 000 рублей, обмен сайта с 1С — от 45 000, корпоративный сайт — от 300 000, интернет-магазин — от 450 000.
Слово «от» здесь означает нижнюю границу для простого случая, а не цену вашего проекта. Прикинуть свою вилку по параметрам можно калькулятором внедрения — он считает по тем же правилам, по которым мы оцениваем вручную.
Если нужна не вилка, а конкретная смета — напишите нам: разберём задачу, посмотрим проект и дадим оценку с разбивкой по часам.
Статья была полезна?
Частые вопросы
Почему подрядчик не называет точную цену сразу?
Потому что в начале разговора он не видел код, не знает, какие в проекте накопились костыли, и не представляет, сколько мест затронет задача. Широкая вилка — это честное «пока не знаю». После разбора проекта она обычно сходится до 20–30%.
Что должно быть в смете?
Разбивка по задачам и часам, заложенные тестирование и выкладка, порядок работы с изменениями в процессе, условия гарантии и ответственность за задержки на стороне третьих систем. Смета одной строкой на всю работу не поддаётся проверке.
Из-за чего одна и та же задача стоит по-разному?
Чаще всего из-за правок ядра у предыдущего подрядчика, отсутствия тестовой копии, старой версии платформы и зависимости от чужой системы, где нет документации или тестового контура.
Как удешевить работу, не теряя результат?
Внятно описать, что должно получиться, собирать мелкие правки в один релиз вместо пяти отдельных выкладок и отделять ту часть задачи, которая даёт основную пользу, от той, что стоит как всё остальное.