Как составить ТЗ для разработки, чтобы подрядчик не завысил стоимость

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

Сначала термины

Итак, что такое техническое задание (ТЗ) и зачем оно нужно каждой из сторон? Разберём определение, которое будет актуальным именно для разработки сайтов и цифровых сервисов.

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

«Почему так много»: что приводит к завышенным сметам

В начале нашей практики мы в Uplab часто сталкивались именно с этими ошибками при составлении ТЗ. Сейчас мы устраняем их на этапе брифинга, но хотим предостеречь тех, кто в начале пути.

• Расплывчатые формулировки типа «удобный интерфейс», «гибкая система». Все характеристики будущей системы должны быть конкретными, проверяемыми и понятными любому члену команды. Например, требования к интерфейсу можно описать так: «Основные действия (поиск, заказ, оплата) доступны с любого экрана не более чем в два клика».
• Отсутствие границ проекта. В ТЗ важно обозначить, будет ли у проекта MVP, а также что входит в первый релиз, а что — в развитие.
• Пропущены внешние зависимости: интеграции, API, хостинг и т.д. Некоторые интеграции, например, с сервисом ЕСИА (получение данных с сайта госуслуг) могут быть трудоёмкими и требовать много времени, поэтому их наличие нужно обсудить заранее.
• Ожидания вместо сценариев использования. Основные сценарии очень важно проработать уже на этапе составления ТЗ.

Обязательные пункты ТЗ

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

• Бизнес-цели и задачи: зачем мы вообще делаем проект.
• Основной функционал и его ограничения.
• Роли пользователей и ключевые сценарии.
• Описание внешних систем и предполагаемых интеграций.
• Описание релизов, MVP и их функционала.
• Нефункциональные требования: безопасность, производительность, нагрузка.
• Ограничения по платформам, технологиям, окружению.
• Детальная смета проекта.

Последний пункт (детализированную смету) мы в Uplab считаем очень важным; ниже рассказываем, почему..

Что делать, если не понятно: работа с зонами неопределенности

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

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

Также в TCO обычно включают непредвиденные (или неочевидные) расходы. Например, стоимость масштабирования: некоторые технические решения делают расширение системы очень дорогим, и это нужно понимать «на берегу». Приведём ситуацию из жизни: компания решила сделать онлайн-магазин с большим ассортиментом на 1С-Битрикс. Но наступила «чёрная пятница», и выяснилось, что сервис заявок перегружается. В таких системаз как 1С-Битрикс нельзя локально масштабировать один сервис, поэтому приходится это делать горизонтально: наращивать мощность серверов. В какой-то момент мощность начинает расти в геометрической прогрессии, пока не упирается в потолок. В результате получается дорогостоящая инфраструктура, для большинства «узлов» которой её мощность избыточна.

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

Три причины фиксировать TCO в ТЗ:

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

Хорошим решением будет запросить у разработчика совокупную стоимость владения хотя бы на три года, с разбивкой по месяцам, и прописать сценарии для разных вариантов нагрузки и числа пользователей (минимальный / базовый / пиковый).

Технический стек и поддержка: когда дешевле не значит лучше

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

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

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

Кстати, скорость устранения инцидентов — ещё один важный пункт, который нужно фиксировать в документах. Часто она связана именно с выбором технологического стека. И заказчику важно знать, как долго он будет ждать устранения проблем. Мы в Uplab всегда прозрачны в этом вопросе и всегда заранее предупреждаем о сроках, в которые будут проведены работы.

Детализированная смета — удобный инструмент для синхронизации

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

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

При компонентном подходе интерфейс собирается из готовых и переиспользуемых блоков (компонентов), а не создаётся «с нуля» для каждой новой экранной ситуации. В дизайне это — дизайн-система и библиотека компонентов; во фронтенде — общий кодовый каталог (UI-кит), типовые шаблоны и единые токены стилей.

Это особенно выгодно в сервисных интерфейсах с повторяющимися паттернами — например, личные кабинеты, корпоративные порталы. Там логика и UX предсказуемы: таблицы, фильтры, формы, статусы, уведомления. Здесь рационально использовать готовые UI-киты и наши проверенные решения, например Uplab X — ускоритель для личных кабинетов, который сокращает время разработки и снижает стоимость без ущерба качеству.

Благодаря компонентному подходу в проекте становится меньше уникального дизайна, и это делает возможной быструю сборку экранов. Оценка сроков также строится по готовой библиотеке и становится более предсказуемой.
Для заказчика это означает меньше рисков и меньший TCO при сохранении нужной гибкости.

Чтобы убедиться, что разработчик использует компонентный подход, в ТЗ стоит прописать обязательное использование дизайн-системы («Нужна библиотека компонентов с токенами (цвет, типографика, сетка), гайдлайном и каталогом в Storybook/аналог») и политику переиспользования («Приоритет — существующие компоненты; кастом только при обосновании бизнес-ценности»). И не забыть о праве собственности: исходники библиотеки и документация, как правило, передаются заказчику; оговариваются порядок обновлений и поддержки.

MVP как способ снизить цену разработки и быстрее вернуть инвестиции

MVP (Minimum Viable Product) — это первая версия сервиса с минимальным набором функций, достаточным для запуска на реальных пользователях и проверки ключевых гипотез. Вместо попытки «впихнуть всё в первый релиз» вы выводите ядро продукта, получаете данные и корректируете дорожную карту. В результате снижаете стартовый бюджет и ускоряете возврат инвестиций.

MVP позволяет снизить затраты на первых этапах работы: меньше функций — меньше дизайна, разработки и интеграций на первом этапе. Его главное преимущество — быстрый time-to-market: компания выходит на рынок раньше конкурентов, раньше начинает монетизацию.

Также прототип показывает, что реально важно пользователям, а что можно отложить. Нередко часть функционала, заложенная в изначальном проекте, после запуска и тестирования MVP отсекается как ненужная и не идёт в разработку.

Как правило, в MVP попадают только главные задачи пользователя (например: регистрация → заявка → оплата), ограниченное количество ролей пользователей, несколько сегментов товаров и услуг. Также в прототипе может не быть сложных интеграций и дорогих «фич».
Если заказчик готов к выпуску MVP, в ТЗ фиксируется описание версии, срез функциональности и дорожная карта релизов.

Итак, мы рассмотрели главные пункты при составлении ТЗ (технического задания) и пояснили базовые принципы, которыми пользуемся при работе с заказчиками. А теперь кратко вспомним главные тезисы.

Саммари

1. Завышенные сметы чаще возникают из-за неопределенности в требованиях: подрядчик закладывает резервы «на всякий случай».
   
2. Хорошее ТЗ — общий «язык» сторон: фиксирует цели, объём работ и измеримый результат, снижая риск завышения цены.
   
3. Типовые причины перерасхода: расплывчатые формулировки, отсутствие границ проекта и MVP, неучтенные интеграции, сценарии и зависимости.
4. Обязательные разделы ТЗ: бизнес-цели, функционал и ограничения, роли и ключевые сценарии, интеграции, план релизов/MVP, нефункциональные требования, стек/окружение, детализированная смета.
5. В ТЗ важно учесть TCO (Total Cost of Ownership, или стоимость владения), рассчитанную на 3–5 лет.
6. Компонентный подход и дизайн-система ускоряют сборку прототипа, делают сроки и бюджет предсказуемыми и снижают TCO. Рекомендуется закрепить это требованиями к библиотеке компонентов и политике переиспользования.
7. MVP как способ сэкономить бюджет: выпускаем прототип с главными бизнес-функциями, быстрее выходим на рынок и начинаем окупаемость. ТЗ должно содержать чёткое определение MVP и описание последующих версий.

Как правило, в MVP попадают только главные задачи пользователя (например: регистрация → заявка → оплата), ограниченное количество ролей пользователей, несколько сегментов товаров и услуг. Также в прототипе может не быть сложных интеграций и дорогих «фич».
Если заказчик готов к выпуску MVP, в ТЗ фиксируется описание версии, срез функциональности и дорожная карта релизов.

Итак, мы рассмотрели главные пункты при составлении ТЗ (технического задания) и пояснили базовые принципы, которыми пользуемся при работе с заказчиками. А теперь кратко вспомним главные тезисы.