Оценка стоимости разработки: как считают часы и почему сметы студий отличаются вдвое

Оценка — это прогноз трудозатрат при заданном понимании объёма работ. Три слова здесь важны все.

Прогноз. У любой оценки есть погрешность, и она тем больше, чем меньше определённости в требованиях. Оценка «1 200 часов» без указания разброса — не результат расчёта, а результат его сокрытия.

Трудозатраты. Считают часы, а не деньги. Деньги получаются на последнем шаге, умножением на ставки. Это разделение принципиально: часы можно обсуждать по существу («почему на интеграцию с 1С 80 часов, а не 40?»), а итоговую сумму — только торговать.

При заданном понимании объёма. Оценка всегда привязана к трактовке требований. Смените трактовку — законно изменится и цифра, без всякой недобросовестности.

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

Смета почти всегда собирается по одной схеме, даже если в коммерческом предложении вы видите одну строчку:

Цена = Σ (часы по задаче × ставка роли) + сопутствующие работы + риск-буфер + НДС

Слагаемые и типовые доли для заказной разработки — это ориентиры, а не норматив:

Методов много, но в заказной разработке рабочих три. Они не конкурируют — их применяют на разных этапах, по мере роста определённости.

Главная проблема одной цифры: она не различает «уверен» и «понятия не имею». Задача на 40 часов, где всё понятно, и задача на 40 часов, которая может занять и 20, и 200, в смете выглядят одинаково.

Трёхточечная оценка (PERT, Program Evaluation and Review Technique) решает это тем, что для каждой задачи называют три числа:

• O (optimistic) — если всё пойдёт хорошо: документация актуальна, доступы дали сразу, подводных камней нет;
• M (most likely) — как обычно бывает;
• P (pessimistic) — если вылезет всё, что может вылезти, но без катастроф.

Ожидаемая трудоёмкость считается по формуле взвешенного среднего:

E = (O + 4×M + P) / 6

Вероятная оценка входит с весом 4 из 6 — модель опирается на нормальный сценарий, но не позволяет игнорировать края. Разброс измеряется стандартным отклонением σ = (P − O) / 6, и практическая польза σ в том, что она показывает, где сосредоточен риск, а не только сколько его всего.

Фрагмент реальной сметы:

Вернёмся к трём цифрам из начала. Вот откуда берётся разброс — по убыванию влияния.

1. Разная трактовка одного и того же требования

Главная причина, и она не про деньги, а про чтение. Требование «система должна формировать отчётность по продажам» реализуется как минимум пятью способами:

Десять вопросов, на которые добросовестный подрядчик отвечает без раздражения. Технических знаний ни один из них не требует.

• 1. Смета разбита по задачам? Одна строка «разработка — 4 000 000 ₽» непроверяема, и обсуждать в ней нечего.
• 2. Есть три оценки или одна? Если одна — какой у неё разброс и откуда он взялся.
• 3. Итог по строкам равен итогу в шапке? Сложите столбец. Расхождение — признак того, что документы собирались руками из разных версий.
• 4. Какие роли и по каким ставкам? Должно быть видно, сколько часов у аналитика, разработчика, тестировщика.
• 5. Есть строки на тестирование и окружения? Их отсутствие — не экономия, а перенос работы на вас.
• 6. Включён ли риск-буфер и какой? И что происходит при выходе за него.
• 7. Что вынесено за границы работ? Раздел «не входит» должен быть конкретным: не «прочие работы», а «наполнение контентом», «покупка лицензий», «доработки на стороне 1С».
• 8. По какой ступени прочитаны крупные требования? Возьмите три самых дорогих строки и спросите, что именно в них входит.
• 9. Это разработка с нуля или доработка, и заложено ли время на изучение? Для brownfield явные строки обязательны.
• 10. Какие допущения? «Доступ к тестовому контуру 1С в первую неделю», «дизайн-система предоставляется заказчиком» — это условия, при которых цифра верна. Нет допущений — значит их не думали.

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

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

Полное ТЗ на входе — редкость. Обычно есть текст на 10–15 страниц, где часть требований описана детально, часть одной фразой, а часть противоречит другой части. Это не повод откладывать оценку — это повод сначала провести анализ пробелов.

Разделите требования на однозначные и неоднозначные. Однозначные оцениваются сразу. Неоднозначные не оцениваются, пока не выбрана трактовка.

Соберите список открытых вопросов — обычно их 10–30, и большинство закрывается одним письмом или получасовым звонком: «сколько ролей в системе?», «нужна ли интеграция с 1С в первой версии?», «кто наполняет каталог?».

Зафиксируйте допущения по тем вопросам, которые не закрылись. Не «оценим позже», а «оцениваем при условии X; если условие не выполняется — строка пересчитывается».

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

Уже на этом этапе можно получить рабочую вилку. Оценка по неполному ТЗ с честным диапазоном полезнее, чем ожидание идеального ТЗ: она показывает порядок бюджета и то, какие решения на этот бюджет влияют сильнее всего.

Если ТЗ нет вообще, начинать надо не с оценки, а с концепции: цели, пользователи, ключевые сценарии, границы первой версии. Про то и другое у нас есть отдельные разборы — как писать техническое задание и что такое концепция проекта. Отдельно стоит сказать, что разработка ТЗ с нуля — это уже платная работа с обследованием и интервью, обычно 5–15% от стоимости проекта, а разбор присланного ТЗ у нас бесплатный.

Ситуация, в которой оказывается едва ли не каждый второй заказчик: смета пришла на 6 миллионов, согласованный бюджет — 3. Плохие способы известны: требовать скидку в 50% (получите ту же работу худшими руками) или молча вычеркнуть тестирование и аналитику (получите те же деньги, потраченные дважды).

Работающих рычагов, по убыванию эффекта, четыре.

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

Вынести интеграции во второй этап. Интеграции — обычно самые рискованные строки сметы: в примере выше σ по обмену с 1С была 22,7 против 4,0 по платёжному модулю. Запуск без обмена, с ручной выгрузкой раз в день на первые три месяца, снимает и часы, и риск срыва сроков, и позволяет начать эксплуатацию раньше.

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

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

Чего делать не стоит ни при каком бюджете: убирать тестирование, убирать аналитику и убирать окружения. Эти три строки выглядят как накладные расходы, а работают как страховка, и их отсутствие обходится дороже их стоимости — обычно в течение первого же квартала.

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

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

Считаем декомпозицией с PERT. Каждая задача получает O, M и P, ожидаемая трудоёмкость — по формуле (O + 4M + P) / 6. Минимальная единица — 2 часа. Итог — всегда диапазон, а не одно число.

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

Три роли вместо шести. Product Engineer Lead держит весь скоуп — требования, архитектуру, ведение, приёмку. AI Developer делает backend и frontend. Платформенная команда подключается за QA, DevOps и дизайн-ревью. Отдельного проектного менеджера в смете нет: его функция — часы инженера, который и так ведёт проект.

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

Калибруем по истории. У нас есть реестр оценённых проектов с планом и фактом. Если по похожим работам коэффициент недооценки выше 1,05 — M-оценки корректируются, а не остаются оптимистичными «потому что в этот раз получится».

Проверяем готовые решения раньше кастома. Если opensource или штатный механизм вашей платформы закрывает 70% требований, в смете стоит адаптация, а не разработка с нуля.

Отдельно про сроки самого процесса. Пресейл мы автоматизировали: разбор ТЗ, классификацию, извлечение требований, расчёт по PERT и сборку документов делает собственный пайплайн на AI-агентах. С середины апреля по конец июля 2026 года через него прошло 57 технических заданий — тендерных и от прямых запросов. Структурированную оценку с разбивкой по задачам вы получаете за часы, а не за недели.

Что до порядка величин по нашим работам: заказная разработка под процесс начинается от 1,7 млн ₽, мобильная — от 1,8 млн ₽, но точная цифра появляется только после разбора ТЗ, и сам разбор бесплатный.

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

Тот же пайплайн мы открыли снаружи. Оценщик Code Pilots — это всё описанное выше, превращённое в четыре экрана: загружаете ТЗ в PDF, DOCX или TXT и получаете PERT-смету, коммерческое предложение и нормализованное ТЗ.

Шаг 1. Загрузка и рамка расчёта. Кроме самого файла здесь два переключателя, которые прямо соответствуют причинам №5 и №6 из семёрки. Первый — весь объём ТЗ или выделение MVP: в первом случае считается каждое требование одной ценой, во втором в базовую цену входит минимум, без которого продукт не решает главную задачу, а остальное выносится отдельными опциями с ценами. Второй — режим тендерной заявки, где цена дополнительно сверяется с НМЦ.

Шаг 2. «Так мы поняли ваш проект». Прежде чем показать хоть одну цифру, система показывает трактовку: тип проекта, домен, количество извлечённых требований и краткий пересказ задачи своими словами. Это буквально то место, где расходятся 2,1 и 9 миллионов, — и здесь его можно поправить: под пересказом стоит поле «чего не хватает, что поняли не так». Правки учитываются в оценке и в КП.

Шаг 3. Уточняющие вопросы. Обычно их семь–пятнадцать, и каждый помечен приоритетом («критично», «важно»), категорией (скоуп, интеграции, инфраструктура, данные) и — самое полезное — влиянием на оценку в часах: «+50 ч», «+40 ч», «+28 ч». Каждый вопрос привязан к конкретным требованиям ТЗ по их идентификаторам, так что видно, откуда он взялся.

Это и есть визуализация главного тезиса про диапазон: вопрос «какой механизм синхронизации нужен для интеграции с HR-системами — real-time, cron или только экспорт откликов» стоит 48 часов разницы, и пока на него нет ответа, эти 48 часов честно сидят в разбросе.

Отвечать не обязательно — у каждого вопроса есть «не уверен, пропустить», и тогда строка просто останется с широким σ. Это честнее, чем подставить средние значения и выдать красивую одну цифру.

Шаг 4. Оценка. На выходе — взвешенная PERT-оценка в часах, диапазон от оптимистичной до пессимистичной, сумма без НДС и с НДС отдельными строками, распределение часов по фазам проекта и блок «не входит в базовую цену» с опциями и ценой каждой. Последнее — тот самый принцип про тихую урезку: отложенный объём выписан явно, а не выкинут молча.

В пакете четыре файла: Excel-смета с PERT по задачам, ролям и фазам, коммерческое предложение на одиннадцать разделов, нормализованное ТЗ с функциональными и нефункциональными требованиями и подборка похожих проектов из портфолио. Отдельной опцией — кликабельные прототипы экранов одним HTML-файлом: цифры оценки они не меняют, но позволяют показать заказчику или руководству, как это будет выглядеть, до начала разработки.

Загрузка, разбор ТЗ и уточняющие вопросы — бесплатно: вы видите трактовку, число требований и вопросы, ничего не заплатив. Платная только сборка документов: 399 ₽ за смету с коммерческим предложением, 599 ₽ за то же плюс кликабельные прототипы. То есть проверяемая смета на проект в полтора миллиона стоит меньше, чем обед.

И главное про этот инструмент: он полезен и без нас. Смета с O/M/P, разбивкой по задачам и списком допущений — ровно тот документ, с которым удобно идти проверять предложения других подрядчиков по чек-листу из этой статьи. Мы сознательно не прячем за формой контактов ни трактовку, ни вопросы, ни структуру расчёта.

2,1 млн, 4,3 млн и 9 млн по одному ТЗ. Теперь этот разброс раскладывается на понятные слагаемые, и почти в каждом реальном случае они одни и те же.

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

Третья прочитала по верхним. Отчётность — дашборд с drill-down, интеграция — двусторонний обмен в реальном времени, плюс явные строки на нагрузочное тестирование и аттестацию по 152-ФЗ, которых в ТЗ прямо не было, но которые следуют из того, что система работает с персональными данными. Плюс 25% буфера, названных вслух.

Вторая оказалась посередине — и не потому, что она «средняя», а потому что по половине требований выбрала ступень выше, чем первая, а по половине ниже, чем третья.

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

И три ошибки, которые в этой логике стоят дороже всего.

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

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

Экономить на аналитике. Строка «аналитика — 120 часов» выглядит как то, что можно вычеркнуть первым: кода в ней нет. Но неснятое противоречие в ТЗ стоит не 120 часов аналитика, а переделки модуля.