Как мы считаем стоимость студийных проектов: прозрачная методика

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

В этой статье разберу, как мы подходим к расчету стоимости в студийных проектах: от первичного брифа до финальной сметы, как закладываем риски, почему фикс-прайс не всегда выгоднее T&M и какие ошибки чаще всего ломают экономику проекта.

Почему цена проекта — это не «сколько стоит сайт»

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

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

Один и тот же внешний результат может стоить по-разному, если отличаются:

• глубина проработки;
• количество ролей и экранов;
• число интеграций;
• требования к UX и контенту;
• количество согласований;
• скорость запуска;
• уровень ответственности студии.

Именно поэтому прозрачная оценка начинается не с цены, а с состава работ.

Из чего складывается стоимость студийного проекта

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

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

Как мы считаем: пошаговая схема

1. Сначала фиксируем цель, а не список хотелок

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

Примеры целей:

• увеличить количество лидов;
• сократить время обработки заявки;
• автоматизировать согласование;
• вывести новый продукт на рынок;
• заменить устаревший портал;
• снизить нагрузку на менеджеров.

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

2. Разбиваем проект на блоки и сценарии

Дальше мы делим проект не на «сайт», а на конкретные пользовательские и бизнес-сценарии:

• вход на сайт;
• поиск информации;
• заявка или заказ;
• личный кабинет;
• интеграция с CRM;
• уведомления;
• загрузка файлов;
• админка;
• отчеты;
• роли и права.

У каждого сценария есть своя сложность. Например, простая форма заявки и форма с валидацией, загрузкой документов и маршрутизацией в CRM — это две разные по стоимости задачи. Я не раз видел, как на старте их оценивали одинаково, а потом разработчики тратили недели на логику, которую никто не закладывал в смету.

3. Оцениваем трудозатраты в часах

Мы считаем не «на глаз», а через нормочасы по ролям.

Типовая команда:

• аналитик;
• проектировщик;
• дизайнер;
• frontend-разработчик;
• backend-разработчик;
• тестировщик;
• менеджер проекта.

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

4. Применяем ставку и собираем смету

Когда есть часы по ролям, цена считается просто:

стоимость = трудозатраты × ставка роли

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

5. Добавляем рисковый буфер

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

• уточнение требований;
• правки после согласований;
• технические ограничения;
• доработки интеграций;
• задержки со стороны клиента;
• изменение состава работ в процессе.

Обычно буфер нужен в диапазоне 10–30%, но точное значение зависит от зрелости ТЗ, скорости принятия решений и сложности системы. На проектах, где заказчик долго согласует макеты или меняет требования на лету, я закладываю верхнюю границу. И это не «перестраховка», а трезвый расчет: лучше сразу показать реалистичную цену, чем потом объяснять, почему бюджет вырос.

Когда фиксированная цена работает, а когда нет

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

Фикс-прайс подходит, если:

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

Почасовая модель или T&M лучше, если:

• проект исследовательский;
• требования будут уточняться по ходу;
• много интеграций и неизвестных;
• важно быстро стартовать;
• заказчик готов управлять продуктом итеративно;
• есть R&D или сложная бизнес-логика.

Коротко о разнице

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

Что чаще всего забывают заложить в оценку

Вот список расходов, которые регулярно выпадают из первых смет. Я называю их «невидимыми работами» — они не бросаются в глаза на старте, но именно они съедают бюджет и нервы на финише.

• Согласования с несколькими стейкхолдерами.
• Подготовка контента и материалов.
• Адаптация под мобильные сценарии.
• Тестирование на реальных кейсах.
• Документация для передачи на поддержку.
• Права доступа, роли, админка.
• Интеграции с CRM, ERP, аналитикой, рассылками.
• Исправления после контентного наполнения.
• Обучение команды клиента.
• Пострелизная стабилизация.

Если эти пункты не учесть заранее, проект формально остается «в рамках бюджета», но реально съедает ресурсы уже после подписания договора. Например, на одном проекте мы не заложили обучение администраторов клиента — в итоге наш менеджер две недели отвечал на вопросы, которые должны были закрываться за час инструктажа. С тех пор обучение — отдельная строка в смете.

Пример прозрачного расчета

Допустим, нужно сделать корпоративный сайт с каталогом услуг, формой заявки и интеграцией с CRM.

Условный состав работ

• аналитика — 20 часов;
• прототипирование — 24 часа;
• дизайн — 40 часов;
• frontend — 48 часов;
• backend — 36 часов;
• тестирование — 16 часов;
• менеджмент — 20 часов.

Итого: 204 часа.

Если средняя ставка проекта составляет, например, 3 000 ₽/час, базовая стоимость будет:

204 × 3 000 = 612 000 ₽

Дальше добавляется буфер на риски и правки. Если заложить 15%, получится примерно:

612 000 × 1,15 = 703 800 ₽

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

Почему две сметы на похожие проекты могут сильно отличаться

Потому что внешне похожие проекты могут отличаться по внутренней сложности. Например:

• у одного сайта 5 страниц и простая форма;
• у другого 5 страниц, но три роли пользователей, интеграция с CRM и нестандартная логика заявок.

Снаружи они выглядят одинаково. Внутри — это два разных проекта по ресурсам. Я не раз сталкивался с ситуацией, когда клиент говорил: «Но у конкурентов такой же сайт стоил в два раза дешевле». А потом выяснялось, что у конкурентов нет ни интеграций, ни ролевой модели, ни кастомной логики.

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

Как понять, что смета составлена честно

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

Признаки нормальной оценки

• есть состав работ по этапам;
• указаны роли и трудозатраты;
• отдельно выделены интеграции и сложная логика;
• описаны допущения и ограничения;
• обозначено, что не входит в объем;
• есть условия по правкам и изменению ТЗ;
• понятен порядок приемки этапов.

Красные флаги

• одна цифра без расшифровки;
• обещание «всё включено» без границ;
• отсутствие буфера;
• нет списка исключений;
• непонятно, кто отвечает за контент;
• не описаны интеграции и сторонние сервисы;
• в смете нет управления проектом и тестирования.

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

Как клиенту проверить оценку перед стартом

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

Чек-лист клиента

• Понятна ли цель проекта?
• Есть ли список функциональных блоков?
• Описаны ли интеграции?
• Ясно ли, что входит в контент?
• Отделены ли обязательные работы от опциональных?
• Есть ли буфер на изменения?
• Понятно ли, как считать допработы?
• Зафиксированы ли этапы и приемка?
• Есть ли ограничения по числу правок?
• Ясно ли, кто предоставляет материалы и в какие сроки?

Если на половину вопросов ответ «нет», смету рано утверждать. Сначала нужно доработать входные данные. Лучше потратить пару дней на уточнение требований, чем потом месяцами разбираться с последствиями размытых договоренностей.

Типовые ошибки при расчете стоимости

1. Считать только разработку

Дизайн, аналитика, тестирование и менеджмент часто оказываются «невидимыми» для клиента, но именно они делают проект жизнеспособным. Я видел проекты, где на разработку закладывали 80% бюджета, а на всё остальное — по остаточному принципу. В итоге получался технически рабочий продукт, которым невозможно пользоваться.

2. Игнорировать интеграции

Интеграция с CRM, 1С, платежами, уведомлениями или внутренними сервисами может увеличить объем в разы. Особенно коварны «простые» интеграции: на словах всё легко, а на деле всплывают нестыковки API, отсутствие документации и необходимость писать промежуточные обработчики.

3. Переоценивать готовность материалов

На старте почти всегда кажется, что контент уже есть. В реальности его еще предстоит собрать, структурировать и адаптировать. Мы обычно закладываем на контент минимум 20–30% от общих трудозатрат, и это редко бывает избыточным.

4. Не закладывать правки

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

5. Не фиксировать допущения

Если не записать, что именно принято в расчет, спор о бюджете возникнет уже на середине проекта. Я всегда настаиваю на том, чтобы допущения были прописаны прямо в смете: «считаем, что API предоставлено заказчиком», «дизайн-макеты согласуются в два раунда», «контент передается в формате X». Это спасает от множества неприятных разговоров.

Минимальная структура прозрачной сметы

Хорошая смета для студийного проекта обычно содержит:

• описание цели;
• состав работ;
• этапы и сроки;
• трудозатраты по ролям;
• стоимость по этапам;
• список допущений;
• список не входящих работ;
• порядок изменений;
• условия приемки;
• условия пострелизной поддержки.

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

Вывод

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

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

FAQ

Почему нельзя назвать точную цену сразу на первом звонке?

Потому что без понимания состава работ любая цифра будет угадкой. На старте можно дать только вилку, а точная оценка появляется после брифа и декомпозиции задач. Я обычно называю диапазон «от и до» с оговоркой, что финальная цифра зависит от результатов аналитики.

Что лучше: фиксированная цена или почасовая оплата?

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

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

Потому что буфер нужен не из-за неопытности, а из-за неопределенности. Даже сильная команда не может заранее предсказать все изменения требований и внешние зависимости. Буфер — это не «запас на ошибки», а плата за реалистичность оценки.

Можно ли удешевить проект без потери качества?

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

Что сильнее всего влияет на цену проекта?

Обычно это сложность логики, количество интеграций, глубина проектирования, объем контента и скорость принятия решений со стороны заказчика. Последний пункт часто недооценивают, но затянутые согласования могут увеличить бюджет на 20–30% просто за счет простоя команды и повторного погружения в контекст.