Как написать техническое задание на сайт: гид для заказчиков от эксперта

🎯 Введение: Почему 80% проектов проваливаются с первых слов

Знаете, что меня всегда удивляло? Люди тратят месяцы на выбор подрядчика. Изучают портфолио, читают отзывы, сравнивают цены. А потом за двадцать минут по телефону пытаются объяснить, что им нужно. И искренне не понимают, почему через месяц работы получается не то.

Был у меня случай лет пять назад. Клиент пришел с проектом интернет-магазина. Всё обсудили устно - "ну вы же понимаете, что нужно, стандартный магазин". Я молодой был, думал - да, понимаю. Начали делать. Через месяц выясняется: у него в голове был Amazon с персональными рекомендациями и сложной системой скидок. А я делал обычный каталог с корзиной. Кто виноват? Оба. Потому что не зафиксировали договоренности на бумаге.

И вот статистика, которая бьет наотмашь: клиенты теряют 100,000-300,000 рублей за полгода на неэффективных подрядчиках. Но часто проблема не в том, что подрядчик плохой. Проблема в том, что никто толком не понял, а что, собственно, мы строим.

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

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

📋 Что такое ТЗ на самом деле и зачем оно нужно

Не документ, а страховка от "А я думал по-другому"

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

И вот приходит ко мне клиент и говорит: "Зачем нам ТЗ, мы же с вами по телефону всё обсудили". Я уже знаю, что будет дальше. Через месяц работы эти "обсуждённые детали" превратятся в "я так не говорил" и "а я понял по-другому".

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

А дело в том, что память человека избирательна и ненадежна. То, что вы обсудили месяц назад по телефону, через месяц превращается в совершенно разные воспоминания у вас и у исполнителя. Вы помните акценты и детали, которые были важны для вас. Исполнитель помнит то, что было важно для него. И оба формально правы - но делаете разные вещи.

Техническое задание - это фиксация договоренностей. Точка отсчета. Когда через месяц возникает спор "а вы говорили" или "я понял иначе" - открываем ТЗ и смотрим, что там написано. Написано - делаем. Не написано - это дополнительная работа за дополнительные деньги.

И да, я видел такое сотни раз - не преувеличиваю. Проекты без ТЗ сталкиваются с проблемами в 8 случаях из 10. Проекты с нормальным ТЗ - в 2 из 10. Разница очевидна.

Три функции технического задания

Давайте разберемся, зачем вообще нужно это ТЗ. Не для галочки, а по существу.

Первая функция - синхронизация ожиданий. Вы в голове представляете Amazon с персональными рекомендациями и AI-помощником. Исполнитель думает, что вам нужна визитка с каталогом из 20 товаров. Пока эти картинки не совпали - вы делаете разные проекты, даже если формально договорились о "создании интернет-магазина".

ТЗ заставляет обе стороны сесть и прописать конкретно: что за сайт, для кого, с каким функционалом, каким дизайном. И выясняется, что представления были совершенно разными. Хорошо, что выяснилось до начала работы, а не после.

Вторая функция - основа для бюджета и сроков. Без технического задания любая смета - это гадание на кофейной гуще. Вы говорите "нужен интернет-магазин". А исполнитель должен угадать: на 100 товаров или на 10,000? С интеграцией с 1С или без? С личным кабинетом или без? С оплатой онлайн или только заявки?

Каждый из этих пунктов влияет на стоимость и сроки. Магазин на 100 товаров без интеграций можно сделать за 150-200 тысяч рублей за два месяца. Магазин на 10,000 товаров с интеграцией с 1С и личным кабинетом - это уже 500-800 тысяч и четыре-пять месяцев работы. Обе цифры адекватные - просто для разных проектов.

И третья функция - защита от scope creep. Это когда "добавьте вот еще одну маленькую штучку" превращается в бесконечность. У меня был кейс с каталогом iPhone. Изначально задача была простая: сделать каталог с фильтрами. Работа стоила бы 250,000-350,000 рублей при нормальном ТЗ. Но клиент говорил "давайте по ходу посмотрим", и я согласился. В итоге сделали за 32,000 рублей, потому что постоянно "ну это же мелочь, добавьте". Результат? Недовольный клиент, который считает что недоплатил, и я, который понимает, что переработал в десять раз.

Долго думал, почему так получилось. А потому что не было четких границ работ. Не было критериев "это входит в проект, а это нет". Всё было размыто и договорно.

С тех пор правило простое: есть ТЗ - есть понимание, что делаем и за сколько. Нет ТЗ - нет проекта. Кстати, если интересуют готовые решения, у нас есть шаблоны, которые можно быстро адаптировать под задачи - это дешевле и быстрее разработки с нуля.

🔧 Из чего состоит нормальное ТЗ

Бизнес-цели: Зачем вообще нужен этот сайт

Сейчас будет вопрос, который многих раздражает, но я его всё равно задаю: "Зачем вам сайт?"

И часто слышу в ответ: "Ну, у всех же есть..." Стоп. Не так. Это не ответ. Это как купить автомобиль, потому что "у всех же есть", не понимая, нужен он вам для поездок на работу, для путешествий или для перевозки грузов.

Честно говоря, меня выводит, когда клиент хочет "современный сайт" без понимания, что это значит для его бизнеса. Современный - это как? Красивый? С анимациями? На последней версии фреймворка? А главное - что этот "современный" должен делать для вашего бизнеса?

Правильные бизнес-цели звучат так: увеличить количество заявок на 30% за первые полгода. Снизить нагрузку на call-центр за счёт автоматизации приёма заказов. Выйти на новый регион и привлечь клиентов из соседних областей. Автоматизировать процесс оформления заказа для постоянных клиентов.

Видите разницу? Это конкретные, измеримые вещи. Через полгода можно будет открыть аналитику и сказать: "Да, мы достигли цели" или "Нет, не получилось, надо что-то менять".

А "хочу красиво" и "хочу продавать" - это вообще разные проекты с разными бюджетами. Красивый сайт можно сделать за 100 тысяч рублей. Продающий - начинается от 300-500 тысяч. Потому что там нужна совсем другая работа: аналитика аудитории, проработка путей пользователя, A/B тестирование, работа с юзабилити.

Я вот для себя решил: если клиент не может внятно объяснить, зачем ему сайт, кроме как "ну надо же" - это первый звоночек. Либо он сам не понимает, что ему нужно (и тогда нужно помочь разобраться), либо он просто хочет потратить деньги (и тогда вопрос - зачем мне такой проект).

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

Целевая аудитория: Для кого всё это

Вопрос номер два, который тоже многих напрягает: "Для кого вы делаете сайт?"

И снова классический ответ: "Для всех людей". Всё, стоп, приехали. Сайт для всех людей - это сайт ни для кого. Потому что невозможно одновременно угодить 18-летнему студенту и 60-летнему директору завода. У них разные потребности, разное поведение, разные ожидания.

Делать сайт без понимания аудитории - это как шить костюм без мерок. Можно, конечно, сшить средний размер и надеяться, что кому-нибудь подойдет. А можно снять мерки и сшить идеально сидящий костюм.

Что нужно знать о целевой аудитории: возраст и социальный статус (это влияет на дизайн и сложность интерфейса). Боли и потребности (что их приводит на ваш сайт). Как принимают решение о покупке (импульсивно или взвешенно, быстро или долго). Откуда приходят (из поиска, из рекламы, по рекомендации). С каких устройств заходят (ПК или мобильные).

И вот тут начинается самое интересное. Сайт для B2B и сайт для B2C - это два совершенно разных продукта, даже если они продают одно и то же.

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

B2C - это часто импульсивные покупки. Человек увидел, захотел, купил за пять минут. Ему нужна простая корзина, быстрая оплата, понятная доставка. Личный менеджер? Да ему даже звонить никому не хочется, дайте просто оформить заказ и всё.

Я заметил закономерность за годы работы: чем точнее понимаешь аудиторию на этапе ТЗ, тем проще делать сайт. Потому что каждое решение проверяется вопросом: "Удобно ли это нашей аудитории?" И сразу отсекается куча спорных моментов.

Структура и функционал: Что должно быть на сайте

А вот здесь клиенты часто говорят: "Ну, стандартно - главная, каталог, контакты". И думают, что этого достаточно.

На самом деле нет. Потому что "каталог" для разных проектов - это совершенно разные вещи. Каталог на 20 услуг с описанием - это одно. Каталог на 5000 товаров с фильтрами, сравнением, отзывами, вариантами товаров - это совсем другое по сложности и стоимости.

Основные разделы нужно описывать не списком, а с пониманием, что там должно быть. Главная страница - это не просто красивая картинка с логотипом. Это витрина вашего бизнеса, где за 10 секунд посетитель должен понять: что вы предлагаете, почему вам стоит доверять, и что ему делать дальше.

Каталог товаров или услуг - это сердце коммерческого сайта. Но опять же, что в него входит? Просто список с ценами? Или детальные карточки с характеристиками, фото с разных ракурсов, видеообзоры, калькулятор стоимости? Сравнение товаров? Фильтры по параметрам? Быстрый заказ без регистрации?

Раздел "О компании" многие считают формальностью. Но для определенной аудитории это критически важно. Особенно в B2B, где доверие решает. Там нужны не только красивые слова про "лидеров рынка", но и реальные кейсы, сертификаты, команда, история компании.

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

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

Подводный камень тут вот в чем: разница между "нужен каталог" и детальным описанием работы каталога - это разница в стоимости в 5-10 раз. Простой каталог-список можно сделать за неделю. Каталог с фильтрами, умным поиском, сравнением, отзывами, вариантами товаров - это месяц разработки минимум.

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

⚙️ Технические требования без воды

CMS, хостинг и интеграции

Вот тут обычно начинается самое интересное. Клиент приходит и говорит: "А на чём делать будем?" И в глазах уже видно - он где-то нагуглил, что WordPress - это прошлый век, Битрикс - неоправданно дорого, а Tilda - вообще не серьёзно для бизнеса.

А дело в том, что вопрос изначально неправильный. Это как спросить "какая машина лучше?" Для чего лучше? Для такси в городе? Для семейных поездок на дачу? Для перевозки стройматериалов? Вот и с CMS так же - всё зависит от того, что вы собираетесь строить и как будете с этим работать дальше.

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

Да, дороже на старте. Лицензия 1С-Битрикс стоит от 60 до 200 тысяч в зависимости от редакции. Но посчитайте сколько вы потратите на доработки и костыли в бесплатной CMS, когда через год захотите что-то изменить. Обычно получается дороже.

Только вот что важно понимать: выбор CMS - это не самоцель. Это инструмент. В техническом задании нужно описать не "хотим на Битриксе", а "нам нужна система, которая позволит управлять правами доступа для 10 менеджеров, интегрируется с 1С, поддерживает мультиязычность". А уж какая CMS для этого подойдёт - это уже вопрос технический.

Теперь про хостинг. И вот тут у нас произошли интересные изменения за последние пару лет. После санкций российские серверы - это не прихоть и не патриотизм. Это банально безопаснее и стабильнее.

Цифры говорят сами за себя: запросы по фразе "российский сервер" выросли на 59%. Люди массово переносят сайты с зарубежных хостингов, потому что никто не хочет в один прекрасный день обнаружить, что его сайт просто перестал быть доступен в России. Или что хостинг заблокировал аккаунт из-за санкций.

Мы сейчас работаем в основном с тремя провайдерами - Beget, Timeweb, REG.RU. Все российские, все надёжные, все с нормальной техподдержкой. У нас есть варианты хостинга под разные задачи и бюджеты.

Но в техническом задании про хостинг нужно указывать не "хотим на Beget", а требования: какая нагрузка ожидается, нужен ли выделенный сервер или достаточно виртуального, какие требования к скорости и безопасности. А конкретного провайдера уже подберём исходя из этих требований.

И вот мы добрались до интеграций. Честно говоря, меня всегда удивляет, когда клиент в ТЗ пишет "нужен сайт" и всё. А про то, что сайт должен обмениваться данными с их 1С, выгружать товары из МойСклад и отправлять заказы в CRM - молчок. Как будто это само собой разумеется.

Нет, не само собой. Интеграция - это отдельная серьёзная работа. И стоит она соответственно.

Возьмём самую популярную интеграцию - с 1С. Казалось бы, стандартная задача, Битрикс из коробки умеет обмениваться с 1С. Но на практике... На практике интеграция может стоить от 60,000 до 200,000 рублей в зависимости от сложности вашей конфигурации.

Почему такой разброс? Потому что у одних всё стандартно - УТ 11, типовая конфигурация без доработок, один тип цен, один склад. А у других - конфигурация доработана под себя, пять типов цен для разных категорий покупателей, три склада, характеристики товаров, варианты, серийный учёт. И вот тут уже не "настроили типовой обмен", а "написали индивидуальное решение".

Поэтому в ТЗ нужно максимально подробно описать что и откуда должно синхронизироваться. Товары? Цены? Остатки? Характеристики? Изображения? Заказы обратно в 1С? Статусы заказов? Акты и счета? Всё это влияет на сроки и стоимость.

То же самое с CRM, платёжными системами, сервисами доставки, аналитикой. Каждая интеграция - это время и деньги. И лучше всё это учесть сразу в техническом задании, чем через месяц после запуска сайта обнаружить, что "ой, а мы забыли про интеграцию с нашей учётной системой".

Дизайн и адаптивность

Знаете, какую фразу я слышу раз в месяц минимум? "Сделайте нам как у Apple". И в этот момент я уже знаю, что следующий вопрос будет про бюджет 100-150 тысяч рублей. Ребята, у Apple на дизайн одной иконки могут потратить больше, чем весь бюджет вашего проекта. Это не злость, это просто факт.

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

И вот тут начинается самое сложное. Как описать в техническом задании то, что хочешь увидеть, но не можешь объяснить словами?

Я вот для себя решил так: лучшее описание дизайна - это референсы. Три-пять сайтов, которые вам нравятся, с конкретными комментариями что именно нравится. Не "вот сделайте как здесь", а "смотрите, мне нравится как здесь решена навигация в шапке - компактно, всё видно, ничего лишнего. И ещё обратите внимание на карточки товаров - они большие, с качественными фото, без перегруза информацией".

Скриншоты с пометками вообще идеальный вариант. Обвели красным нужный элемент, написали комментарий - и всё сразу понятно. У нас в портфолио проектов можете посмотреть разные варианты реализации, может что-то подойдёт как референс.

Но есть один момент, который нужно понимать. Референс - это источник вдохновения, а не шаблон для копирования. Вы не можете просто сказать "хочу точно так же" и ждать один в один. Потому что у того сайта своя структура контента, свои задачи, своя айдентика. У вас будет другое. И дизайнер должен адаптировать идею под ваш случай.

А теперь про адаптивность. Тут без вариантов - это не опция, это стандарт. Более 60% трафика сейчас идёт с мобильных устройств. Если ваш сайт на телефоне выглядит как попытка уместить слона в чемодан - вы теряете больше половины потенциальных клиентов.

Причём адаптивность - это не просто "уменьшить всё пропорционально". Это переосмысление интерфейса под маленький экран. Навигация становится другой. Формы работают иначе. Приоритеты контента меняются. На десктопе можно показать много информации сразу, на мобильном нужно выбрать самое важное.

В техническом задании про дизайн должно быть следующее:

Референсы - конкретные примеры того, что вам нравится, с пояснениями.

Брендбук - если у вас есть фирменный стиль, логотип, корпоративные цвета, шрифты. Всё это нужно учитывать в дизайне сайта.

Требования к UX - как должен вести себя интерфейс. Например: "главная информация о товаре должна быть видна без прокрутки", "до любого раздела каталога не больше трёх кликов", "форма заказа помещается на одном экране".

Особенности аудитории - для кого дизайн. Если ваша аудитория 55+, им нужны крупные шрифты и простая навигация. Если молодёжь - можно более смелые решения.

И да, про адаптивность даже упоминать не нужно. Это как указывать в ТЗ на строительство дома "должна быть крыша". Само собой разумеется. Любой нормальный исполнитель сделает сайт адаптивным по умолчанию. Если не делает - это повод задуматься о выборе исполнителя.

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

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

📝 Как правильно описать требования

Язык без двусмысленностей

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

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

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

Ещё классический пример - "интуитивно понятный интерфейс". Лет десять назад я тоже так писал в ТЗ. До первого спора с клиентом о том, что считать интуитивным. Оказалось, у нас с ним совершенно разные представления об этом. С тех пор прошу конкретики: какие действия пользователь должен совершить за какое количество кликов, где должны быть ключевые элементы управления.

А "современный дизайн"? Это вообще шедевр неопределенности. Для одних современно - это минимализм и много белого пространства. Для других - яркие градиенты и анимации. Для третьих - брутализм с нарочитой "сломанностью". Поэтому вместо "сделайте современно" лучше дать три примера сайтов и объяснить, что именно в них нравится.

И да, избегайте слов "обычно", "стандартно", "как у всех". У всех по-разному. То, что стандартно для вашей отрасли, может быть экзотикой для исполнителя из другой сферы.

Референсы и примеры

Вот тут начинается магия. Одна ссылка на сайт-пример может заменить пять страниц описаний. Но - и это важно - референс нужно давать правильно.

Неправильно: просто скинуть ссылку со словами "хочу как здесь". Что именно "как здесь"? Дизайн? Структуру? Функционал? Цвета? Шрифты? Скорость загрузки? Исполнитель начинает гадать, а вы потом удивляетесь, почему он угадал не то, что вы имели в виду.

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

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

Только помните: референс - это источник вдохновения, а не шаблон для копирования. Вы не можете просто сказать "сделайте мне точно как у Apple", потому что у Apple на дизайн тратят миллионы долларов и десятки специалистов. И кстати, если ваш бюджет 100 тысяч рублей, а вы требуете Apple - это разговор не про референсы, а про адекватность ожиданий.

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

Можно ли просто дать ссылку без объяснений? Можно. Но тогда будьте готовы, что исполнитель может понять её по-своему. А через месяц работы выяснится, что вам нравилась не вся концепция сайта, а только один конкретный элемент. Вот и получается недопонимание.

Кстати, у нас есть портфолио проектов - можете посмотреть примеры реализованных решений для вдохновения.

Контент: кто готовит, кто заливает

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

По нашим наблюдениям, в 70% случаев проекты тормозятся именно из-за контента. Не из-за разработки, не из-за дизайна - а из-за того, что некому написать тексты или сделать нормальные фотографии.

Поэтому в техническом задании нужно четко зафиксировать: кто готовит контент. Есть несколько вариантов.

Вариант первый - клиент готовит всё сам. Тексты, фотографии, видео, описания товаров. Хорошо, тогда в ТЗ должны быть прописаны сроки. Например: "Клиент предоставляет все тексты до 15 марта, фотографии товаров до 20 марта". И если сроки сорваны - это не проблема исполнителя. Кстати, такой подход работает хорошо, когда у вас есть свой маркетолог или контент-менеджер.

Вариант второй - исполнитель создает контент. Но это отдельная работа, которая стоит денег. И немалых. У нас есть услуги по наполнению сайта, можете посмотреть, что входит и сколько стоит. Копирайтинг для 50 товаров - это может быть 50-100 тысяч рублей дополнительно к основному проекту. Фотосъёмка - ещё столько же. Всё это нужно заложить в бюджет сразу.

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

Ещё важный момент - кто заливает контент на сайт. Может клиент самостоятельно через админку (для этого нужно обучение). Может исполнитель как часть работ. Может третья сторона - ваш маркетолог или помощник. Всё это нужно обговорить заранее.

И потом выясняется, что у вас нет описаний товаров вообще. Есть только прайс-лист с названиями и ценами. А описания нужно писать с нуля. Вот и получается ступор на месяцы.

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

⚠️ Типичные ошибки в ТЗ и как их избежать

Слишком общо vs слишком детально

Есть две крайности в составлении технического задания, и обе одинаково плохи.

Крайность первая - ТЗ на одну страницу. "Нужен интернет-магазин". И всё. Серьёзно, я видел такие "технические задания". На весь магазин с каталогом, корзиной, оплатой, доставкой - одна страница общих фраз. Как на основе этого делать смету? Как понять объем работ? Это как прийти к строителям и сказать "постройте дом". Какой дом? Сколько этажей? Из чего? С какой отделкой? Без ответов на эти вопросы можно построить что угодно.

Крайность вторая - ТЗ на сто страниц с указанием размера каждой кнопки в пикселях и цвета каждого элемента в формате RGB. Я встречал техническое задание на 147 страниц для обычного корпоративного сайта. В нём была расписана каждая деталь, вплоть до того, на сколько пикселей должна сдвигаться кнопка при наведении мыши. Знаете, что получилось? Исполнитель потратил неделю только на изучение этого ТЗ и выставил цену в три раза выше рыночной. Потому что работать по такому документу - это кошмар.

Правильный баланс - это когда ТЗ как карта путешествия, а не пошаговая инструкция как дышать. Вы описываете "что" нужно сделать достаточно детально, но "как" именно это реализовать - доверяете профессионалам.

Например, вместо "кнопка размером 120 на 40 пикселей, цвет #FF5733, шрифт Roboto 16px, отступы 10px сверху и снизу" достаточно написать "заметная кнопка призыва к действию на каждой странице услуг". Дизайнер сам подберет размер, цвет и шрифт так, чтобы они гармонировали с общей концепцией.

Или возьмем каталог. Не нужно расписывать каждый элемент карточки товара. Достаточно сказать: "карточка товара содержит фото, название, цену, краткое описание, кнопки 'купить' и 'в избранное', информацию о наличии". А уж как именно это будет выглядеть - это работа дизайнера, а размер кнопок пусть он подберет сам под общую концепцию.

Нужно ли в ТЗ указывать размер кнопок? Нет, не нужно. Достаточно сказать "заметная кнопка призыва к действию", и этого хватит для работы.

Забыли про бюджет и сроки

Вот здесь у меня болит. Потому что есть такое странное табу - многие клиенты боятся называть свой бюджет. Думают, что если скажут "у нас есть 300 тысяч", то исполнитель магическим образом за эти 300 тысяч сделает работу, которая стоит 100. То есть накрутит цену.

Знаете что? Если исполнитель накручивает цену только потому, что узнал ваш бюджет - бегите от такого исполнителя. Это не ваш человек. Нормальный специалист оценит работу адекватно, независимо от того, озвучили вы бюджет или нет.

А вот без понимания бюджета исполнитель просто не может сделать нормальное предложение. Потому что для 100 тысяч рублей и для миллиона - это совершенно разные решения. И обе имеют право на жизнь.

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

То же самое со сроками. "Когда будет готово?" - "А когда нужно?" - "Желательно вчера". Да-да, знаю, все хотят вчера. Но физика не позволяет, к сожалению.

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

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

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

Нет критериев приемки

А вот это вообще больная тема. Как понять, что работа выполнена? Как определить момент, когда можно подписать акт и закрыть проект?

Был у нас проект - сайт технически "готов", но клиент говорит "ну я же не это хотел". А что хотел? "Ну не знаю, но не это". По каким критериям оценивать? Ни по каким, потому что их не было прописано изначально. Проект провисел в подвешенном состоянии ещё два месяца, пока мы не сели и не написали конкретный список того, что должно быть сделано.

Критерии приемки - это конкретные пункты, на которые можно ответить только "да" или "нет". Никаких "вроде работает" или "примерно то, что нужно". Только чёткие формулировки.

Примеры хороших критериев приемки: каталог отображает все товары из базы данных 1С, при этом цены и остатки обновляются автоматически раз в час. Сайт открывается корректно во всех популярных браузерах - Chrome, Firefox, Safari, Edge, последние три версии каждого. Формы обратной связи отправляют уведомления на указанную почту в течение минуты после отправки. Скорость загрузки главной страницы не превышает трёх секунд на стандартном интернет-соединении. Видите? Всё измеримо и проверяемо.

Плохие критерии: "сайт должен быть удобным", "дизайн должен нравиться", "всё должно работать хорошо". Это не критерии, это пожелания. Их нельзя проверить объективно.

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

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

🎯 Шаблон структуры ТЗ для копирования

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

Начните с бизнес-целей и задач. Зачем вообще вам нужен этот сайт? Не "потому что у конкурентов есть", а реальные измеримые цели. Например: увеличить количество заявок на 40% за первые полгода после запуска. Или снизить нагрузку на отдел продаж за счёт автоматизации приёма заказов. Или выйти на новый регион и привлечь клиентов из соседних областей. Конкретные задачи, которые можно измерить и проверить через полгода.

Дальше опишите целевую аудиторию. Для кого вы это делаете? Кто ваш клиент? Средний возраст, род занятий, боли и потребности, как принимает решение о покупке. Если у вас B2B - учтите, что решение принимают несколько человек, и цикл сделки может растянуться на три-шесть месяцев. Если B2C - важны импульсивные факторы, эмоции, простота процесса покупки. Чем точнее вы опишете аудиторию, тем проще будет делать сайт под её потребности.

Пропишите структуру сайта. Какие разделы и страницы должны быть? Главная как витрина вашего бизнеса, каталог товаров или услуг как основа, раздел "О компании" для доверия, страница контактов для связи, может быть блог для контент-маркетинга, личный кабинет для постоянных клиентов. Прикиньте, сколько примерно страниц получится, это важно для сметы. Интернет-магазин на тысячу товаров - это совсем другой объем работы по сравнению с корпоративным сайтом на десять страниц.

Детализируйте функциональные требования. Что конкретно должно работать на сайте? Формы обратной связи с отправкой на почту и в CRM, корзина с возможностью оформления заказа, фильтры в каталоге по ключевым параметрам, поиск по сайту, личный кабинет с историей заказов, онлайн-оплата, калькулятор стоимости, онлайн-запись на услуги. Перечислите всё, что должно быть. И да, лучше написать сразу, чем потом добавлять за отдельные деньги.

Укажите технические требования. Выбор CMS - по нашему опыту, 1С-Битрикс оптимален для серьёзного бизнеса с планами роста, но есть и другие варианты. Хостинг - после санкций лучше сразу на российских серверах, это стабильнее и безопаснее. Интеграции - если у вас 1С, МойСклад, CRM, платежные системы, это всё нужно прописать. Кстати, интеграция с 1С стоит от 60 до 200 тысяч рублей в зависимости от сложности, закладывайте это в бюджет сразу.

Добавьте требования к дизайну и UX. Не надо расписывать каждый пиксель, но дайте референсы - три-пять сайтов, которые вам нравятся, с комментариями, что именно понравилось. Если есть брендбук компании - приложите его. Укажите основные требования к интерфейсу: адаптивность под мобильные устройства обязательна (это уже не опция, а стандарт), интуитивная навигация, не больше трёх кликов до любого товара или услуги.

Договоритесь про контент. Кто готовит тексты - вы или исполнитель? Кто делает фотографии - профессиональный фотограф, или возьмёте стоковые, или будете снимать сами на телефон? Кто размещает всё это на сайте? В какие сроки контент должен быть готов? Мы помогаем с наполнением, если нужна поддержка, но это нужно заложить в бюджет и сроки.

Зафиксируйте бюджет и сроки. Да, я понимаю, что это неудобно. Но без этого проект превращается в бесконечную историю. Реалистичный бюджет с учётом всех дополнительных работ. Реалистичные сроки с учётом согласований и доработок. И небольшой запас на непредвиденное - он всегда пригождается.

Пропишите критерии приемки. Как мы поймём, что работа выполнена? Конкретные пункты с возможностью проверки. Каталог синхронизируется с 1С. Сайт работает во всех браузерах. Формы отправляют письма. Скорость загрузки соответствует требованиям. Всё, что можно проверить объективно.

Используйте этот шаблон как основу, адаптируя под свой проект. У кого-то будет упор на дизайн, у кого-то на сложные интеграции, у кого-то на большой объём контента. Главное - не пропустить ни один важный раздел.

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

🚀 Заключение: Хорошее ТЗ = успешный проект

Вот мы и прошли весь путь от понимания, зачем нужно техническое задание, до конкретного шаблона, который можно использовать. И сейчас, когда я пишу эти строки, я думаю: почему так много проектов начинаются без нормального ТЗ?

Долго думал, почему одни проекты взлетают, а другие буксуют месяцами. И понял: дело не в бюджете и не в крутости исполнителя. Дело в понимании задачи с самого начала. Когда обе стороны - и клиент, и подрядчик - чётко видят, куда идут и что должно получиться, проект идёт как по маслу. Когда этого понимания нет - начинается та самая история с "а я думал по-другому" и бесконечными переделками.

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

Знаете, за пятнадцать лет работы я видел всякое. Видел проекты, которые разваливались из-за того, что всё было "на словах". Видел, как из-за отсутствия критериев приемки клиент и подрядчик месяцами не могли договориться, готов сайт или нет. Видел, как проекты стопорились на полгода, потому что никто заранее не подумал про контент.

И видел проекты, которые шли идеально. Где всё было прописано, понятно, согласовано. Где не было сюрпризов по срокам и бюджету. Где в итоге и клиент доволен, и мы довольны результатом. Разница между этими двумя категориями проектов - именно в наличии или отсутствии нормального технического задания.

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

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

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

Удачи в ваших проектах. И помните: хорошее начало - это половина успеха. А хорошее техническое задание - это и есть то самое правильное начало.

Дополнительная помощь:

• Комплексные услуги для сайта - если нужна поддержка на всех этапах
• Каталог готовых решений - для быстрого старта с готовыми шаблонами
• Техническая диагностика - оценим ваш проект перед началом работ