Техническое задание на сайт — главный риск любого проекта разработки. Не дизайн, не код, не сроки. Именно ТЗ. Заказчик не программист, он описывает желаемый результат своим языком, и в этом описании всегда остаются дыры — функционал, который «имелся в виду», но не был прописан. Разбираю на свежем кейсе, как это выглядит изнутри.
В апреле 2026 мы запустили обновлённый сайт Казахстанской горнорудной палаты — отраслевой ассоциации, которая представляет интересы горнодобывающих компаний в Казахстане. Я руководил проектом, в команде были дизайнер и программист.
Проект интересный сам по себе — B2B-сайт для ассоциации с членской базой, личными кабинетами, закрытыми разделами и админкой для управления реестром. Но ещё интереснее то, что произошло до того, как мы начали писать код.
Зачем горнорудной ассоциации новый сайт
Клиент пришёл с конкретной болью. У них была CMS October — выбор не самый редкий для серьёзных проектов, но с одной важной особенностью: контент-менеджер должен быть наполовину разработчиком, чтобы с ней работать.
В палате контент-менеджера-разработчика не было. Был обычный человек, которому нужно публиковать новости, обновлять список членов, выкладывать материалы мероприятий. Каждое такое действие превращалось в задачу со звёздочкой. А любая доработка функционала — в платный заказ внешнему подрядчику с длинными сроками.
Это типичная ловушка. Технологический стек выбирают на старте — часто по совету первого подрядчика — а живут с ним годами. October — мощная CMS для тех, кто умеет с ней работать. Для отраслевой ассоциации, которой нужно регулярно обновлять контент силами одного человека, она не подошла.
Мы переложили проект на WordPress. У команды большой опыт с этой платформой, и для задач палаты её хватает с запасом. Простая в использовании, простая в адаптации, огромная экосистема плагинов под любые нужды. Контент-менеджер теперь работает в визуальном редакторе без чьей-либо помощи — это и было главным критерием выбора.
Заодно освежили дизайн. Старый был сделан несколько лет назад и выглядел соответствующе. Переработали UX по современным стандартам — навигацию, иерархию страниц, мобильную адаптацию. Это была отдельная история, к которой я ещё вернусь.
Что должна уметь платформа отраслевой ассоциации
Сайт ассоциации — это не корпоративный лендинг и не интернет-магазин. У него своя логика, и она диктует архитектуру.
Главная задача — членство. Кто вступает, как вступает, что получает после вступления. Поэтому центральные сценарии: «вступить в палату», «зайти в личный кабинет», «посмотреть, кто уже состоит». Всё остальное — вокруг.
Личный кабинет члена палаты — это не e-commerce-логика. Здесь не покупают, здесь поддерживают статус. Поэтому в нём:
- заполнение и корректировка анкеты компании
- регистрация на закрытые мероприятия
- прямая связь с администратором палаты
- уведомление об истечении членства за 10 дней
- доступ к закрытым разделам — «своего рода клуб», как сформулировал клиент
Закрытые разделы — отдельная история. Изначально предполагался один общий «личный кабинет члена», но мы пришли к идее раздельных категорий: одни материалы видны всем членам, другие — только определённым группам. Это сделало логику ценнее: членство в палате теперь даёт доступ к разному уровню информации в зависимости от категории. Простое решение, но оно поменяло восприятие продукта целиком.
Каталог членов — публичный, но с фильтрами. И вот здесь была одна из самых интересных задач проекта.
Невидимая логика каталога: почему фильтры — это не просто фильтры
В типичном каталоге всё просто: список плюс фильтры по нескольким параметрам. Зашёл, отфильтровал, нашёл. Но в каталоге отраслевой ассоциации первое впечатление работает иначе. Когда инвестор или партнёр впервые открывает страницу членов палаты, он не должен видеть случайный список. Он должен видеть картину отрасли.
Поэтому мы сделали двухслойную логику. По умолчанию каталог отсортирован по внутренней иерархии — она учитывает дату вступления и размер компании в сочетании. Это даёт правильную «первую карту» отрасли: тот, кто открывает каталог в первый раз, видит структуру, а не алфавитный беспорядок.
Но как только посетитель начинает фильтровать — по категории членства, отрасли, любому другому параметру — иерархия отступает, и работают чистые фильтры. Так логика обслуживает оба сценария: первое знакомство и целевой поиск. Без этого получился бы либо бессмысленный список «как пришло», либо алфавитный порядок, который для палаты не несёт никакого смысла.
Похожая история с мероприятиями. Стандартный календарь даёт сетку по дате. Мы сделали по-другому: на любой странице сначала показываются ближайшие предстоящие события — для всех пользователей, по умолчанию. И только потом, если человек хочет копнуть глубже, включаются фильтры по дате и архивам. Это снова про сценарий «зашёл и сразу увидел, что важно сейчас», а не «зашёл и сам разбираешься в архиве».
Спор о количестве сущностей: меньше — больше
На старте обсуждения возникла классическая для B2B-проектов ловушка: заказчик хотел много категорий. Много отраслей, много направлений интересов, много типов компаний. Логика заказчика понятная — отрасль большая, компании разные, давайте всё это аккуратно разложить.
Я отговорил.
Каждая сущность в системе — это не только поле в базе. Это:
- одно лишнее поле в форме регистрации (а заполнять её человек, у которого нет времени)
- один лишний фильтр в каталоге (а пользователю и так есть, чем заняться)
- одна лишняя колонка в админской выгрузке
- один лишний параметр, который нужно поддерживать актуальным
Чем больше сущностей — тем медленнее всё работает с пользовательской точки зрения. Не технически, а психологически. Длинные формы пугают. Длинные списки фильтров никто не дочитывает.
Договорились ограничиться двумя-тремя основными интересами компаний. Это закрывает 90% реальных сценариев фильтрации, и при этом форма регистрации остаётся читаемой. Всё остальное при необходимости можно отразить в свободном поле «о компании».
Это правило я применяю в любом B2B-проекте: сначала минимальный набор сущностей, потом, через пару месяцев работы, расширяемся по реальному запросу пользователей. Расширить базу — задача на час. Сократить раздутую структуру, в которой уже сидят данные — задача на неделю.
Мультиязычность с сохранением страницы — почему это не очевидно
Сайт работает на трёх языках: казахский, русский, английский. Для Казахстана это норма, мы делаем все B2B-сайты с тремя языками по умолчанию. Но один технический момент стоит проговорить.
Стандартное поведение многих сайтов с мультиязычностью: переключаешь язык в правом верхнем углу — и тебя выбрасывает на главную страницу. Кто-то открыл статью про Кодекс о недрах на русском, переключил на английский — и оказался на главной. Дальше ему искать ту же статью заново. Большинство людей этого не делают, они просто закрывают вкладку.
Мы реализовали сохранение текущей страницы при переключении языка. Это требует чуть больше работы при настройке — нужно правильно связать языковые версии каждой страницы между собой — но это превращает мультиязычность из формальности в реально работающую функцию. Особенно важно для англоязычных инвесторов, которые приходят на сайт через ссылку из материала и не должны теряться.
Мелочь, но из таких мелочей состоит разница между «сайт переведён» и «сайтом можно пользоваться на трёх языках».
Скрытая работа: админка, выгрузки, рассылки
То, что видит посетитель сайта — небольшая часть проекта. Реальная работа сделана в админке. Для палаты это критично, потому что они управляют живым организмом: компании вступают, выходят, обновляют статус, продлевают членство.
Что было настроено в админке:
- Одобрение новых анкет — анкета поступает, администратор смотрит, открывает доступ к личному кабинету.
- Контроль сроков членства — система сама напоминает за 10 дней, и за 0 дней архивирует кабинет, если статус не продлён.
- Архивирование с возможностью восстановления — это важно, потому что компании часто продлевают с опозданием, и каждый раз создавать кабинет заново — глупость.
- Выгрузки — реестр членов в Excel с разделением по категориям, архив логотипов, база контактов для рассылок.
- Email-рассылки — массовые подписантам и точечные выбранным членам.
Без этой админки сайт превратился бы в красивую витрину, за которой ничего не происходит. С ней он становится рабочим инструментом ассоциации.
Главный риск любого проекта — ТЗ
Проект шёл около трёх месяцев. В целом мы уложились в сроки — но мелкие доработки продолжаются до сих пор. Это нормально. Я не верю в истории «сделали, сдали, забыли». Любой живой сайт дорабатывается по мере того, как пользователи им пользуются и появляется обратная связь.
Что в этом проекте, как и в любом другом, болит сильнее всего — это изначальное понимание функционала.
Заказчик не программист. Он описывает то, что хочет, своим языком — языком отрасли, в которой работает. Он формулирует через метафоры, аналогии, ссылки на «как у других». В этом описании всегда есть зоны, где разные люди понимают одно и то же по-разному.
Простой пример из нашего проекта. Заказчик говорит: «Нужно, чтобы новости можно было сортировать». Программист реализует сортировку по дате — это очевидное прочтение. А заказчик имел в виду: чтобы можно было закреплять важные новости сверху вне зависимости от даты. Это разные функции. Если они выяснились на этапе тестирования — это правки. Если на этапе сдачи — это уже разговор.
Поэтому я закладываю риски недопониманий в любой проект. Не как «возможный форс-мажор», а как гарантированную часть реальности. Идеальное ТЗ — это миф. Любое ТЗ содержит дыры, и наша задача — обнаружить их максимально рано.
Раньше для этого помогала только серия итерационных встреч с заказчиком. Долго, медленно, дорого. Сейчас в этом помогает другой инструмент — ИИ.
Как ИИ снижает риск ТЗ — практика, которую я уже применяю
Это не теория, это рабочая практика последних месяцев. У меня два сценария.
Сценарий первый — на стороне заказчика. Когда я понимаю, что у клиента мало технических компетенций — а это норма, и в этом нет ничего обидного — я прошу его перед нашей встречей сесть с любым удобным ИИ и поработать с ним над черновиком ТЗ. Не идеальное ТЗ от ИИ, а разговор с ИИ по своей задаче: «Мы хотим сайт для ассоциации. Какие функции обычно нужны? Какие риски? Что часто забывают учесть?»
После такой подготовки заказчик приходит на встречу со мной совершенно другим. Он уже знает, какие вопросы возникнут. Он уже подумал о вещах, о которых раньше не думал. Наша встреча превращается из «давайте я объясню, как делается сайт» в «давайте обсудим конкретные решения».
Это не убирает риск недопониманий — он остаётся всегда. Но снижает его на порядок.
Сценарий второй — на моей стороне. Когда я анализирую полученное ТЗ, я работаю с ИИ как с собеседником. Загружаю текст ТЗ, прошу разобрать на риски: что неоднозначно, что может быть истолковано двумя способами, что обычно упускают в проектах такого типа. ИИ выдаёт список — иногда очевидный, иногда с неожиданными пунктами, о которых я бы не подумал.
Потом я с этим списком иду к клиенту с конкретными вопросами. «Вот здесь у вас написано «удобный поиск». Уточните: поиск по заголовкам новостей, по тексту, по тегам? Только русский или все три языка? С автодополнением или без?» И так по каждому пункту, который ИИ подсветил как потенциально неоднозначный.
В последнее время я для этих задач работаю через Abacus — там можно прогонять одну и ту же задачу через разные модели (Claude, GPT, Gemini) и сравнивать ответы. Это полезно, потому что разные модели цепляются за разные аспекты. Но для базового сценария подойдёт любой удобный вам инструмент — ChatGPT, Claude, Gemini, неважно. Важно сам подход: ИИ как советчик, который читает ТЗ свежим взглядом и помогает увидеть то, что глаз уже замылил.
Я писал про общую логику использования ИИ для проектной работы в материале о маркетинговой стратегии без 100-страничного документа — там немного другой контекст, но та же идея: ИИ хорош как партнёр по мышлению, не как генератор финальных текстов.
Что я бы посоветовал заказчику до старта проекта разработки
Если вы — руководитель ассоциации, владелец B2B-компании, директор по маркетингу — и вы готовите запуск нового сайта или редизайн существующего, вот короткий список действий до того, как вы сядете писать ТЗ или искать подрядчика.
- Проведите интервью со стейкхолдерами внутри компании. Контент-менеджер, отдел продаж, служба поддержки, руководство. У каждого свои сценарии работы с сайтом, и часто между этими сценариями есть конфликты, о которых никто не подозревает.
- Соберите максимум референсов. Не «нам понравился вот этот сайт», а 10–15 примеров с пометками: «здесь нравится навигация», «здесь нравится логика каталога», «здесь не нравится перегруженная главная». Подрядчик так увидит ваш вкус и приоритеты гораздо точнее, чем по описанию.
- Сядьте с ИИ и поработайте над черновиком ТЗ. Опишите ИИ свою задачу, спросите про риски, спросите про функции, которые обычно упускают. Получите от него список вопросов — попробуйте на них ответить сами, и где не сможете — отметьте как «обсудить с подрядчиком».
- Отдайте получившееся ТЗ другому ИИ — на проверку адекватности. Свежий взгляд на свой же текст. Часто всплывают противоречия, которые свой глаз не видит.
- Только после этого идите к подрядчику. Не за тем, чтобы он написал ТЗ за вас — это его работа на следующем этапе. А за тем, чтобы вы могли разговаривать с ним на одном уровне понимания задачи.
Эти пять шагов сократят на проекте недели правок и спасут от ситуации, когда вы получили готовый сайт и поняли, что в нём не хватает чего-то базового.
FAQ
Сколько стоит сайт для отраслевой ассоциации в Казахстане в 2026 году?
Зависит от функционала. Корпоративный сайт-визитка для ассоциации — от 1.5–2 миллионов тенге. Сайт с членской базой, личными кабинетами и админкой — от 5 миллионов и выше. Стоимость определяется не дизайном, а количеством сущностей и логикой работы с данными.
Какую CMS выбрать для B2B-сайта с членской базой?
Универсального ответа нет, но для большинства задач отраслевых ассоциаций и B2B-проектов средней сложности WordPress работает хорошо: простой для контент-менеджеров, гибкий для разработчиков, с большой экосистемой плагинов. October, Drupal, Bitrix имеют смысл для специфических задач, но требуют квалифицированной команды поддержки.
Можно ли составить ТЗ на сайт самому, без агентства?
Можно — особенно если у вас есть понимание ваших процессов и стейкхолдеров. Современные ИИ-инструменты помогают собрать черновик ТЗ за несколько часов работы. Но финальное ТЗ обычно дорабатывается совместно с подрядчиком, потому что ему виднее технические нюансы реализации.
Как проверить ТЗ перед подписанием договора с разработчиком?
Прогнать ТЗ через ИИ на поиск неоднозначностей и пробелов. Задать ИИ вопрос: «Какие риски и упущения видишь в этом ТЗ для проекта типа X?» Список ответов использовать как чек-лист для уточнений с подрядчиком до старта работ.
Сколько времени занимает разработка сайта для ассоциации?
Кейс Казахстанской горнорудной палаты — около трёх месяцев от старта до запуска, плюс мелкие доработки после. Это типичный срок для B2B-проекта средней сложности с личными кабинетами и админкой. Простой корпоративный сайт делается за месяц-полтора, сложные платформы с интеграциями — от 6 месяцев.
Что делать дальше
Если вы готовите проект разработки или редизайна сайта — главный совет на старте простой: не торопитесь с ТЗ. Потратьте две-три недели на интервью, референсы и работу с ИИ-инструментами. Эти недели сэкономят вам месяцы правок и переделок потом.
Если упёрлись в собственные вопросы или хотите обсудить запуск конкретного проекта — разберём вашу ситуацию на консультации. Без воды, по делу.
Об авторе. Раимбек Искендиров — маркетолог и руководитель проектов разработки в Казахстане. Пишет про маркетинговую стратегию, GEO и применение ИИ в проектной работе в блоге raem.kz.
