Как составить ТЗ на сайт или бота: чтобы получить то, что нужно

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

Зачем вообще ТЗ

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

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

Что обязательно включить

Хорошее ТЗ отвечает на несколько простых вопросов. Не нужно писать роман — нужно закрыть эти пункты честно и конкретно.

Цель. Зачем вам этот сайт или бот и какую бизнес-задачу он решает. «Принимать заявки на услуги», «отвечать клиентам на типовые вопросы 24/7», «продавать курс». Цель — это то, по чему потом судят, удался проект или нет.

Аудитория. Кто будет этим пользоваться. Клиенты со смартфонов, сотрудники за компьютером, пожилые люди — от этого зависят и интерфейс, и приоритеты. Бот для молодёжи в Telegram и форма заявки для оптовых закупщиков устроены совсем по-разному.

Функции. Что именно должно работать, списком. Не «удобный каталог», а «каталог с фильтром по цене и категории, карточка товара, корзина, оформление заказа с оплатой». Каждая функция — отдельный пункт, который можно проверить: работает или нет.

Интеграции. С чем всё это должно соединяться: CRM, платёжная система, мессенджеры, 1С, службы доставки, рассылки. Интеграции забывают чаще всего, а именно они обычно и съедают время. Лучше выписать их сразу.

Контент и материалы. Кто даёт тексты, фото, логотип, товары. Если этого нет и делать должен подрядчик — это отдельная задача, деньги и сроки. Молчание тут потом оборачивается простоем.

Критерии приёмки. Как мы поймём, что готово. Список функций, которые должны работать, устройства и браузеры, где всё проверяется. Это ваша защита от «почти доделали».

Частые ошибки в ТЗ

За годы работы одни и те же грабли повторяются из проекта в проект. Вот те, что дороже всего обходятся.

• Описывать «как красиво», а не «что работает». «Современный дизайн» и «удобный интерфейс» невозможно проверить — это вкусовщина. А «форма заявки отправляет данные в CRM и на почту» проверяется однозначно.
• Забывать про интеграции. «Ну там же просто форма» — а форма должна попадать в CRM, слать уведомление в Telegram и письмо клиенту. Три интеграции, о которых не было ни слова.
• Не фиксировать границы. Без явного «что НЕ входит» проект пухнет: сначала «добавьте ещё страничку», потом «и вот эту функцию», и вот сроки уехали в два раза.
• Оставлять всё на устный договор. «Договоримся по ходу» на старте звучит гибко, а на приёмке превращается в «вы обещали». Что не записано — того не было.
• Смешивать обязательное и желаемое. Стоит помечать, что критично для запуска, а что хотелось бы «когда-нибудь». Иначе бюджет уходит на украшения вместо главного.

Большинство этих ошибок пересекается с общими промахами при заказе — я собрал их в разборе десяти ошибок при заказе сайта и бота. ТЗ — это как раз инструмент, который половину из них снимает заранее.

Простой шаблон

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

• 1. Что делаем. Сайт, лендинг, бот, интернет-магазин — в одной строке.
• 2. Зачем. Какую задачу решает и как поймём, что она решена.
• 3. Для кого. Кто пользователь и с какого устройства заходит.
• 4. Что должно работать. Список функций, каждая отдельным пунктом, простыми словами.
• 5. С чем соединяем. CRM, оплата, мессенджеры, 1С, доставка, рассылки — всё, к чему подключаемся.
• 6. Материалы. Что даёте вы (тексты, фото, логотип, товары), что делает подрядчик.
• 7. Примеры. Две-три ссылки на сайты или ботов, которые нравятся, с пометкой, что именно нравится.
• 8. Что НЕ входит. Явно перечислите, чего в этом проекте не будет, чтобы не спорить потом.
• 9. Как принимаем. Список того, что должно работать на приёмке, и где это проверяем.
• 10. Сроки и бюджет. Ваши ожидания и жёсткие ограничения, если есть.

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

Частые вопросы

Обязательно ли писать ТЗ самому? Нет. Достаточно ответить на вопросы из шаблона своими словами — оформить это в нормальное задание помогу я. Главное, чтобы вы честно сформулировали цель, функции и границы; красивую упаковку сделаем вместе.

Насколько подробным должно быть ТЗ? Ровно настолько, чтобы каждую функцию можно было проверить — работает или нет. Не нужно 40 страниц. Нужно, чтобы формулировки были однозначными, а не «удобно» и «красиво».

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

Можно ли менять ТЗ по ходу? Можно, изменения — это нормально. Важно фиксировать их письменно и понимать, как они влияют на сроки и бюджет. Проблема не в изменениях, а в устных «ну мы же договаривались», которых никто не записал.

Коротко о главном

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