Техническое задание на разработку сайта: что включить

TL;DR

Техническое задание на сайт — это документ, который фиксирует, что именно вы получите, в какие сроки и за какие деньги, ещё до того как разработчик напишет первую строку кода. Без ТЗ почти каждый проект уходит в «расползание объёма» (scope creep): подрядчик делает одно, вы ждали другого, бюджет растёт, сроки срываются, и приёмку нельзя оспорить — потому что нечего сравнивать. Хорошее ТЗ описывает бизнес-цель, структуру страниц, функциональность и интеграции (Kaspi, 1С, 2ГИС, CRM), кто пишет и предоставляет контент, требования к SEO и скорости, стек, этапы с оплатой и — главное — критерии приёмки. Ниже разбираем каждый раздел и даём готовый скелет, который казахстанский предприниматель может скопировать и заполнить под свой проект.

Большинство конфликтов между бизнесом и веб-студией в Казахстане возникают не из-за плохого кода и не из-за недобросовестности — а из-за того, что стороны по-разному поняли одно и то же предложение в переписке. Заказчик читает «современный сайт с каталогом» и представляет себе фильтры, личный кабинет и выгрузку в Kaspi. Подрядчик читает ту же фразу и закладывает статичный список товаров на десять позиций. Через два месяца оба правы — и оба недовольны.

Техническое задание убирает это расхождение. Это не бюрократия и не «бумажка для галочки», а инструмент управления риском: чем дороже сайт, тем дороже стоит недопонимание. Для лендинга от 350 000 ₸ цена ошибки — несколько дней работы. Для интернет-магазина или тендерного портала от 1 200 000 ₸ цена ошибки — месяцы и сотни тысяч тенге переделок. ТЗ переводит ваши ожидания на язык, по которому потом можно принять или не принять результат. Ниже — структура, которую мы используем в Shipmint, с пояснениями, почему каждый раздел важен именно на казахстанском рынке.

Зачем вообще нужно ТЗ: что оно реально защищает

ТЗ работает на трёх уровнях одновременно, и предприниматели обычно недооценивают второй и третий.

• Юридический уровень. ТЗ — это приложение к договору. Если дело дойдёт до спора, суд или арбитр смотрит не на переписку в WhatsApp, а на подписанный документ. «Сайт сделан некачественно» — не аргумент. «Пункт 4.3 ТЗ требует загрузку каталога из 1С, функция отсутствует» — аргумент.
• Финансовый уровень. Когда объём зафиксирован, любая новая хотелка — это отдельная строка с отдельной ценой, а не бесплатная «мелкая правка». Без ТЗ подрядчик либо разоряется на бесконечных доработках, либо начинает экономить на том, чего вы не видите (тесты, скорость, безопасность).
• Управленческий уровень. ТЗ задаёт контрольные точки. Вы платите не «за сайт целиком», а за прохождение этапов, и на каждом видите, что деньги идут в дело.

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

Раздел 1. Бизнес-цель и целевая аудитория

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

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

Дальше — целевая аудитория. Для казахстанского рынка важно зафиксировать как минимум:

• Язык интерфейса. Только русский, только казахский или обе версии (ru/kk)? Двуязычность — это не «добавить кнопку», а удвоение объёма контента, отдельная логика хранения переводов и отдельная строка в смете. Решать это нужно в ТЗ, а не на этапе сдачи.
• Регион и устройства. Если ваша аудитория — регионы, а не только Алматы и Астана, закладывайте более жёсткие требования к скорости на мобильном интернете.
• Готовность платить онлайн. В Казахстане значительная часть покупателей привыкла к Kaspi и переводам, а не к классическому эквайрингу. Это влияет на выбор интеграций.

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

Раздел 2. Структура сайта (карта страниц)

Карта сайта — это перечень всех страниц с их иерархией. Именно по ней считается объём работ, поэтому пропущенная страница = пропущенные деньги и время.

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

| Страница | Назначение | Ключевые блоки | |---|---|---| | Главная | Первое касание, навигация | Оффер, услуги, преимущества, отзывы, CTA | | Каталог / Услуги | Перечень того, что продаёте | Фильтры, карточки, цены в ₸ | | Карточка товара/услуги | Решение о покупке | Описание, фото, цена, кнопка заявки/оплаты | | О компании | Доверие, E-E-A-T | История, команда, реквизиты, БИН | | Блог | SEO и экспертность | Список статей, рубрики | | Контакты | Связь и доверие | Карта 2ГИС, телефон, форма, реквизиты | | Политика конфиденциальности | Требование закона РК | Текст согласия на обработку данных |

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

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

Раздел 3. Функциональность и интеграции

Это сердце ТЗ и главный источник споров. Описывайте функции по принципу «что система делает», а не «как она выглядит». Дизайн — отдельный раздел.

Как формулировать требования к функциям

Каждая функция должна быть проверяемой. Сравните две формулировки:

• Плохо: «удобная форма заявки».
• Хорошо: «форма заявки с полями Имя, Телефон, Сообщение; валидация телефона в формате +7; защита от спама через Cloudflare Turnstile; при отправке данные уходят на e-mail компании и в Telegram; пользователь видит сообщение об успехе».

Вторую формулировку можно принять или не принять. Первую — нет.

Интеграции, специфичные для Казахстана

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

• Kaspi. Уточните, что именно нужно: приём оплаты через Kaspi Pay, выгрузка товаров в Kaspi магазин (через XML-фид), или и то и другое. Это совершенно разные задачи по трудоёмкости.
• 1С. Если каталог и остатки живут в 1С, опишите направление обмена (сайт читает из 1С, или 1С пишет на сайт), частоту синхронизации и формат. «Интеграция с 1С» без деталей — гарантированный конфликт.
• CRM. Куда падают заявки — amoCRM, Bitrix24, Google-таблица, n8n-вебхук? Опишите поля и момент срабатывания.
• 2ГИС и карты. Виджет карты на контактах, кнопка построения маршрута.
• Эквайринг. Если нужна классическая оплата картой — какой банк/провайдер (Halyk, Kaspi, Freedom Pay и т.д.), потому что под каждый своя интеграция.
• Аналитика. Яндекс.Метрика и/или Google Analytics, цели и события.

Для каждой интеграции честно укажите, кто предоставляет доступы и кто отвечает за то, чтобы внешняя система была готова. Частая ловушка: разработчик ждёт XML-фид от вашего 1С-специалиста, тот в отпуске, проект встаёт — а виноватым назначают студию.

Раздел 4. Дизайн: референсы вместо вкусовщины

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

Включите в ТЗ:

• 2–4 сайта-референса с пояснением, что именно нравится в каждом: «вот эта главная — за чистоту и крупный оффер», «вот этот каталог — за фильтры». Без пояснений референс бесполезен: вам нравится цвет, а дизайнер скопирует структуру.
• 1–2 антиреференса — что категорически не нравится. Это экономит итерации сильнее, чем десять примеров «нравится».
• Бренд-материалы. Логотип в векторе, фирменные цвета (HEX), шрифты, готовые фото. Если их нет — это отдельная строка работ и расходов, и это нужно признать в ТЗ.
• Количество раундов правок на макет. Например: «два раунда правок по дизайну включены, третий и далее — по часовой ставке». Это единственный надёжный способ остановить бесконечную полировку оттенков.

Зафиксируйте, что приёмка дизайна (утверждённый макет) предшествует вёрстке. Менять структуру после того, как сайт сверстан, — это переделка, а не правка.

Раздел 5. Контент: кто пишет и кто предоставляет

Сорванные сроки чаще убивает не код, а контент. Сайт готов на 90%, но «рыба» вместо текстов, нет фотографий товара, не присланы реквизиты — и запуск стоит неделями. ТЗ обязано разнести ответственность по контенту явно.

Сделайте таблицу с владельцем и сроком по каждому типу контента.

| Тип контента | Кто отвечает | Срок предоставления | |---|---|---| | Тексты страниц | Подрядчик (копирайтинг) / Заказчик | До начала вёрстки | | Фото товаров | Заказчик | До наполнения каталога | | Логотип, бренд | Заказчик | До старта дизайна | | Описания услуг | Заказчик предоставляет тезисы, подрядчик дорабатывает | По этапам | | Реквизиты, БИН, контакты | Заказчик | До запуска | | Юр. тексты (оферта, политика) | Заказчик / его юрист | До запуска |

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

Раздел 6. Требования к SEO, скорости и безопасности

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

SEO-минимум, который должен быть в ТЗ:

• Уникальные title и description для каждой страницы, возможность их редактировать.
• ЧПУ (человекопонятные URL): /uslugi/montazh, а не /page?id=42.
• Корректные robots.txt и sitemap.xml, автоматически обновляемый при добавлении страниц.
• Разметка Schema.org (Organization, Article, LocalBusiness, BreadcrumbList).
• Заголовки H1–H3 в семантической структуре, alt у изображений.
• Открытость для AI-краулеров, если для вас важна видимость в нейропоисковиках.

Пример минимального правила для robots.txt, которое стоит указать как требование:

User-agent: *
Allow: /

User-agent: YandexBot
Allow: /

Sitemap: https://vashsite.kz/sitemap.xml
Host: vashsite.kz

Директива Host для Яндекса в Казахстане до сих пор полезна — Яндекс остаётся значимым источником трафика в регионе, и ТЗ должно явно требовать корректной работы с ним, а не только с Google.

Скорость. Задайте измеримый порог: например, «оценка Core Web Vitals в зелёной зоне на мобильном по PageSpeed Insights» или конкретные значения LCP и INP. Без числа «быстрый сайт» недоказуем.

Безопасность. SSL-сертификат (HTTPS), защита форм от спама, регулярные бэкапы, а для систем с личными данными — соответствие требованиям закона РК о хранении персональных данных. Если вы храните данные граждан РК, уточните вопрос о локализации хранения — это требование, которое лучше согласовать на берегу.

Раздел 7. Стек, сроки, этапы и оплата

Технологический стек

Заказчику не обязательно разбираться в технологиях, но в ТЗ стоит зафиксировать стратегические вещи, потому что они определяют вашу свободу в будущем:

• CMS или фреймворк. Сможете ли вы сами редактировать контент, или для каждой правки нужен разработчик? Это вопрос вашей независимости.
• Хостинг и домен. Где размещается сайт, на чьём аккаунте, кто платит. Домен .kz должен быть зарегистрирован на вас, а не на подрядчика — это частая и болезненная ловушка.
• Совместимость. С какими браузерами и версиями, минимальная мобильная адаптивность.

Сроки и этапы с оплатой

Никогда не оплачивайте проект двумя платежами «50% и 50% в конце». Разбейте на этапы, привязав оплату к измеримому результату.

| Этап | Результат | Оплата | |---|---|---| | 1. Прототип и структура | Утверждённая карта сайта и каркас | 20% | | 2. Дизайн | Утверждённые макеты ключевых страниц | 25% | | 3. Вёрстка и разработка | Рабочий сайт на тестовом домене | 30% | | 4. Интеграции и наполнение | Подключены Kaspi/1С/CRM, залит контент | 15% | | 5. Приёмка и запуск | Сайт на боевом домене, передача доступов | 10% |

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

Раздел 8. Критерии приёмки и передача проекта

Это раздел, ради которого пишется всё ТЗ. Без чётких критериев приёмки сдача проекта превращается в спор «работает / не работает».

Критерии приёмки

Сформулируйте приёмку как чек-лист с бинарными (да/нет) проверками, а не как оценочные суждения. Примеры проверяемых пунктов:

• Все страницы из карты сайта существуют и открываются.
• Формы отправляют данные на указанный e-mail и в Telegram, приходит уведомление.
• Сайт корректно отображается на iPhone, Android и в настольных Chrome/Safari.
• Каталог синхронизируется с 1С: тестовый товар появляется на сайте после выгрузки.
• Оплата через Kaspi проходит на тестовой транзакции.
• PageSpeed мобильный — в согласованной зоне.
• sitemap.xml доступен и содержит все страницы.
• Установлена и фиксирует визиты Яндекс.Метрика.

Каждый пункт либо выполнен, либо нет. Спорить не о чем — в этом вся ценность.

Передача и право собственности

Финальный и часто забываемый блок. Зафиксируйте, что именно вы получаете при закрытии проекта:

• Доступы: домен, хостинг, админ-панель, аналитика, почта — всё на ваши аккаунты.
• Исходный код (если разрабатывался не на закрытой платформе) и право его использовать и дорабатывать у других подрядчиков.
• Документация: как редактировать контент, как добавлять товары, контакты на случай сбоя.
• Гарантийный период: сколько недель/месяцев подрядчик бесплатно исправляет ошибки, найденные после запуска.

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

Готовый скелет ТЗ, который можно скопировать

Соберём всё в один шаблон. Скопируйте, удалите пояснения в скобках и заполните под свой проект.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ САЙТА

1. О проекте
   1.1. Заказчик (компания, БИН, контактное лицо)
   1.2. Бизнес-цель сайта (измеримая)
   1.3. Целевая аудитория и язык(и): ru / kk / обе
   1.4. Ключевые сценарии пользователя

2. Структура сайта
   2.1. Карта страниц (дерево/таблица)
   2.2. Главное меню и подвал
   2.3. Обязательные юр. страницы (политика, согласие)

3. Функциональность
   3.1. Список функций (проверяемые формулировки)
   3.2. Интеграции: Kaspi / 1С / CRM / 2ГИС / эквайринг / аналитика
   3.3. Ответственный за доступы по каждой интеграции

4. Дизайн
   4.1. Референсы (с пояснениями) и антиреференсы
   4.2. Бренд-материалы (логотип, цвета, шрифты)
   4.3. Число раундов правок

5. Контент
   5.1. Таблица: тип контента — ответственный — срок
   5.2. Правило блокировки этапа при непредоставлении контента

6. SEO / скорость / безопасность
   6.1. SEO-минимум (title, ЧПУ, sitemap, Schema.org)
   6.2. Порог скорости (Core Web Vitals)
   6.3. SSL, бэкапы, персональные данные (закон РК)

7. Стек и инфраструктура
   7.1. CMS/фреймворк, возможность самостоятельного редактирования
   7.2. Хостинг и домен (.kz на заказчика)

8. Сроки и оплата
   8.1. Этапы с результатами и процентом оплаты
   8.2. Условия сдвига сроков

9. Приёмка и передача
   9.1. Чек-лист приёмки (бинарные проверки)
   9.2. Передаваемые доступы и исходники
   9.3. Право собственности
   9.4. Гарантийный период

Этот скелет одинаково подходит и для лендинга от 350 000 ₸, и для корпоративного сайта от 720 000 ₸, и для магазина или тендерного портала от 1 200 000 ₸ — меняется только глубина проработки разделов 3 и 9.

Часто задаваемые вопросы

Нужно ли ТЗ для простого лендинга?

Да, но в сокращённом виде. Даже для лендинга от 350 000 ₸ стоит зафиксировать структуру блоков, что делает форма заявки, куда уходят данные, кто пишет текст и сколько раундов правок входит в цену. Это занимает одну-две страницы и снимает 90% будущих споров. Чем проще проект, тем короче ТЗ — но не «никакое».

Кто должен писать ТЗ — заказчик или подрядчик?

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

Что делать, если в процессе разработки появились новые хотелки?

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

Как защититься от срыва сроков из-за контента?

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

Обязательно ли прописывать интеграцию с Kaspi и 1С?

Если эти системы участвуют в вашем бизнесе — обязательно, и максимально детально. «Интеграция с Kaspi» без уточнения (оплата через Kaspi Pay, выгрузка фида в Kaspi магазин или и то и другое) — это разные по трудоёмкости задачи, и расплывчатая формулировка почти гарантирует конфликт на приёмке. То же касается направления и частоты обмена с 1С.

Кому должны принадлежать домен и доступы после сдачи?

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

Грамотное ТЗ — это половина успеха проекта, но написать его в одиночку, особенно с учётом казахстанской специфики (Kaspi, 1С, ru/kk, требования закона о персональных данных), бывает непросто. В Shipmint мы помогаем сформулировать техническое задание под вашу бизнес-цель, а затем реализуем его в рамках услуги цифровой фундамент — с прозрачными этапами, измеримой приёмкой и передачей всех доступов вам. Если планируете новый сайт или редизайн и хотите, чтобы проект не ушёл в бесконечные правки, напишите нам — разберём вашу задачу и поможем составить ТЗ, которое защитит и бюджет, и сроки.

Следующий шаг

Ваш сайт теряет лиды прямо сейчас