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

> Техническое задание на сайт: подробная структура ТЗ на разработку сайта, которая защищает от срыва сроков, перерасхода бюджета и бесконечных правок в Казахстане.

Source: https://shipmint.kz/blog/tehnicheskoe-zadanie-na-razrabotku-sayta
Published: 2026-06-15
Category: Веб-разработка

---


## 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 году](/blog/skolko-stoit-razrabotka-sayta-kazakhstan-2026) — сверяйте сметы с ним, чтобы понимать, где подрядчик демпингует за счёт скрытой экономии.

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

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

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

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

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

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

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

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

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

Без явного пункта о праве собственности и доступах вы рискуете оказаться в заложниках у подрядчика: сайт работает, но сменить исполнителя или просто получить пароли невозможно. Перед самим запуском пройдитесь ещё и по нашему [чек-листу редизайна сайта перед запуском](/blog/cheklist-redizayna-sayta-pered-zapuskom) — он закрывает операционные мелочи, которые ТЗ обычно не описывает.

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

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

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

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 мы помогаем сформулировать техническое задание под вашу бизнес-цель, а затем реализуем его в рамках услуги [цифровой фундамент](/services/digital-foundation) — с прозрачными этапами, измеримой приёмкой и передачей всех доступов вам. Если планируете новый сайт или редизайн и хотите, чтобы проект не ушёл в бесконечные правки, [напишите нам](/contact) — разберём вашу задачу и поможем составить ТЗ, которое защитит и бюджет, и сроки.


---

## Related

- [Blog](https://shipmint.kz/blog)
- [Contact](https://shipmint.kz/contact)