Как правильно составить ТЗ для разработчика сайтов: понятный язык вместо сложных терминов

"Самые сложные проблемы требуют самых простых объяснений" — Лев Толстой

🔮

Почему разработчики не читают мысли

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

Знакомо, да? И так...

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

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

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

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

💰

Почему хорошее ТЗ спасает ваши деньги, нервы и отношения

Знаете, что говорит статистика? По данным PMI, около 28% IT-проектов проваливаются именно из-за проблем с коммуникацией. А ещё 52% превышают бюджет по той же причине.

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

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

И вот к чему приводит отсутствие нормального ТЗ:

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

2. Выход из бюджета. Ведь каждая правка — это дополнительное время, а время в нашей сфере — это деньги. Прямо как говорил Бенджамин Франклин, только он не сталкивался с клиентами, которые на пятом круге правок удивляются, почему итоговая цена выросла в полтора раза.

3. Упущенные сроки. "К запуску рекламной кампании" превращается в "когда-нибудь, наверное, если повезёт".

А ведь можно было просто потратить пару часов на составление нормального ТЗ! Я как-то работал с клиентом, который на подготовку ТЗ потратил больше времени, чем мы на саму разработку. И знаете что? Это был один из самых гладких проектов в моей практике — ни одной правки, идеальное попадание в сроки и бюджет.

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

Как правильно составить ТЗ для разработчика сайтов: понятный язык вместо сложных терминов

🛑

Стоп, снимаем розовые очки: чего НЕ стоит делать в ТЗ

Есть у меня один клиент (давайте назовем его "Семен Семенович"). Приходит он как-то и говорит: "Мне нужен сайт как у Яндекс.Маркета, только лучше. И чтобы через неделю уже работал. Бюджет — 40 тысяч".

Я ему говорю: "Семен Семенович, вы понимаете, что Яндекс потратил сотни миллионов рублей и годы разработки на свой Маркет?"

А он мне: "Ну так они же всё уже придумали, вам только повторить надо!"

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

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

"Просто добавьте баннер"

Классика! Вроде всё очевидно, да? Но давайте копнем глубже:

• Где именно должен быть баннер? На главной странице? В каталоге? В карточке товара?
• Какого размера? Может, вы хотите полноэкранный слайдер, а может — скромный прямоугольник в сайдбаре?
• С какими настройками? Статичный? Слайдер? Автопрокрутка или по клику?
• Какой контент должен быть на баннере? Что произойдет при клике?

Если вы не ответите на эти вопросы в ТЗ, то разработчик решит их за вас. И, спорим, его решения вам не понравятся?

"Интегрируйте с 1С"

О, эта чудесная фраза! Интеграция с 1С — это как сказать: "Я хочу поехать". Куда? На чем? Когда? С кем? Зачем?

Интеграция бывает разная:

• Односторонняя (только из 1С на сайт или только с сайта в 1С)
• Двусторонняя (в обе стороны)
• По расписанию или в реальном времени
• Только товары или еще заказы
• С сохранением истории изменений или без

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

"Сделайте по макету из Фигмы"

Такое ТЗ — это как дать строителям только фасад дома без чертежей и сказать: "Стройте". Макет в Фигме показывает только внешний вид, но не говорит о:

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

Я однажды получил красивейший макет интернет-магазина, где в каталоге было ровно 6 товаров, идеально подогнанных по размеру и формату. А потом мне скинули реальную базу — 5000 товаров с названиями от 2 до 50 слов, с квадратными и вертикальными фотками, с ценами от 10 рублей до миллиона. И ни слова в ТЗ о том, как это всё должно выглядеть в реальной жизни!

Почему "на словах" никогда не работает

"Давайте я просто объясню всё на словах, зачем писать?" — вот еще одна фраза, от которой у меня начинается нервный тик.

И так, проблема устных договоренностей в том, что:

1. Человеческая память избирательна. Вы запомните одно, разработчик — другое.

2. Устные формулировки расплывчаты. "Сделайте покрасивее" в вашем понимании и в понимании разработчика — это две большие разницы.

3. Нет точки отсчета. Когда возникает спор, не к чему апеллировать. "Но я же говорил!" — "Нет, не говорили!" — и доказать правоту невозможно.

4. Детали теряются. При устном обсуждении легко упустить важные нюансы, которые всплывут только на этапе реализации.

Помню, был у меня клиент, который категорически отказывался писать ТЗ. "Мы же всё обсудили по телефону!" — говорил он. И каждый раз, когда я показывал ему результат, он удивлялся: "Но я же имел в виду совсем не это!" Мы переделывали раз пять, пока я не настоял на письменном ТЗ. И вуаля — с первой попытки попали в точку.

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

📋

Структура понятного ТЗ: говорим на языке результатов, а не процессов

Знаете, что общего между ТЗ и рецептом пирога? В обоих случаях, если пропустить пару важных ингредиентов или перепутать последовательность действий, на выходе получится совсем не то, что вы ожидали увидеть. Только в случае с пирогом вы потеряете несколько сотен рублей, а в случае с сайтом — десятки тысяч.

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

Главный принцип: говорите о результатах, а не процессах

Вот в чём суть проблемы. Когда заказчик пишет ТЗ, он обычно думает в категориях "что нужно сделать" (добавить кнопку, изменить шрифт, настроить выгрузку). А разработчику на самом деле важнее понять "зачем" и "что должно получиться".

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

Пять ключевых разделов понятного ТЗ

1. Зачем вам это нужно (бизнес-цель)

   Начните с объяснения, какую бизнес-задачу должна решать эта доработка. "Нам нужно увеличить конверсию из просмотра товара в добавление в корзину", "Мы хотим упростить оформление заказа для мобильных пользователей" или "Нам необходимо автоматизировать обновление остатков из 1С".

   Когда разработчик понимает вашу цель, он может предложить более эффективное решение, чем то, что вы изначально придумали.

2. Что конкретно нужно сделать

   Здесь уже можно перейти к конкретике: какая часть сайта требует изменений, какие элементы нужно добавить или удалить. Например: "Переработать карточку товара на странице {URL} — добавить дополнительную кнопку 'Купить в один клик', видимую без прокрутки страницы".

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

3. Как это должно работать (функциональность)

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

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

4. Как это должно выглядеть (визуал)

   Если у вас есть визуальные требования, опишите их максимально конкретно: цвета (желательно в HEX или RGB), размеры (в пикселях), отступы, шрифты.

   Если есть макет в Фигме или другом редакторе — отлично! Но не забудьте дополнить его описанием функциональности, которую невозможно показать на статичной картинке.

5. Как вы поймёте, что всё готово (критерии приёмки)

   В конце опишите, при каких условиях вы будете считать задачу выполненной. Например: "Кнопка 'Купить в один клик' корректно отображается на всех устройствах (десктоп, планшет, мобильный), форма отправляется без ошибок, данные заказа корректно сохраняются в системе и приходят оповещения на email менеджера".

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

Превращаем туманные запросы в чёткие ТЗ

Вот пара примеров трансформации запросов из разряда "а вы догадайтесь сами" в нормальное человеческое ТЗ:

Было: "Надо сделать, чтобы при оформлении заказа автоматически подтягивался адрес доставки"

Стало: "При оформлении заказа в форме ввода адреса доставки добавить функцию автоматического заполнения. Когда пользователь начинает вводить адрес в поле 'Улица, дом', под полем должен появляться выпадающий список с подсказками от сервиса Dadata. При выборе адреса из списка поля 'Улица', 'Дом', 'Корпус', 'Город' и 'Индекс' должны заполняться автоматически. Пользователь должен иметь возможность вручную отредактировать автоматически заполненные поля."

Чувствуете разницу? В первом случае разработчик будет гадать, что именно вы хотели. Во втором — у него есть чёткое представление о том, что нужно сделать.

А теперь еще один пример:

Было: "Хочу, чтобы на сайте были отзывы"

Стало: "Необходимо создать раздел 'Отзывы' на сайте с возможностью модерации. Посетители должны иметь возможность добавлять отзывы через форму с полями: Имя, Email, Текст отзыва, Оценка (от 1 до 5), Фото (опционально). Все отзывы перед публикацией должны проходить модерацию через админ-панель. На странице отзывов должна быть пагинация (по 10 отзывов на странице). Также нужно реализовать виджет с последними 3 отзывами для размещения на главной странице."

Видите, насколько конкретнее стала задача? А ведь изначально заказчик, скорее всего, и сам не представлял, какие именно отзывы ему нужны. Пока не задумался и не прописал это в ТЗ.

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

Как правильно составить ТЗ для разработчика сайтов: понятный язык вместо сложных терминов

🎯

Практикум: превращаем "хочу красивый баннер" в понятное ТЗ

Вот один из моих любимых примеров из реальной жизни. Клиент пишет: "Нужен красивый баннер на главной странице".

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

Что не так с "красивым баннером"?

1. "Красивый" — это субъективное понятие. Моё "красиво" и ваше "красиво" могут драматически отличаться. Для кого-то красиво — это минимализм в стиле Apple, для кого-то — буйство красок и анимаций как в рекламе казино. Разработчик просто не может читать ваши мысли!

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

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

4. Неизвестно содержание. Что должно быть на баннере? Товар? Акция? Информация о компании? Какие тексты? Какие изображения? Какие цвета? Без этого дизайнер будет работать наугад, а результат, скорее всего, вас разочарует.

5. Что происходит при клике? Многие почему-то забывают, что баннер — это не просто картинка, это еще и элемент интерфейса. Куда он должен вести? Что происходит при наведении?

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

Как превратить это в нормальное ТЗ

И так, давайте переделаем размытое "хочу красивый баннер" в конкретное ТЗ, которое действительно поможет разработчику:

Расположение

Расположение: в верхней части главной страницы, под шапкой сайта, на всю ширину контентной области (максимум 1200px).

Размеры и адаптивность

Размеры:
- Десктоп: 1200x400px
- Планшет: 768x300px
- Мобильный: 320x200px

Содержимое должно адаптироваться под все размеры с сохранением читаемости текста и видимости ключевых элементов.

Содержание и дизайн

Содержание:
- Фоновое изображение: фотография нашего бестселлера (товар X) на светлом фоне
- Текст слева: заголовок "Весенняя распродажа" (шрифт как на сайте, размер 32px для десктопа)
- Подзаголовок: "Скидки до 30% на всю коллекцию"
- Кнопка справа: "Купить со скидкой" в фирменных цветах (#FF5500, белый текст)

Дизайн должен соответствовать общему стилю сайта, использовать фирменные цвета и шрифты.

Функциональность

Функциональность:
- При клике на кнопку "Купить со скидкой" пользователь перенаправляется на страницу товара X с автоматически примененным промокодом SPRING2025
- При наведении на кнопку она меняет цвет на #FF7722
- Баннер не должен быть анимирован

Сроки и технические требования

Сроки: баннер должен появиться на сайте с 1 по 15 мая 2025 года
Технические требования: загрузка баннера не должна увеличивать время загрузки страницы более чем на 0.5 секунды

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

Критерии приемки:
- Баннер корректно отображается во всех основных браузерах (Chrome, Firefox, Safari, Edge)
- Дизайн соответствует согласованному макету
- Функциональность работает без ошибок
- Баннер адаптивен и корректно отображается на всех устройствах

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

А теперь я вас шокирую. На создание такого ТЗ уходит примерно 15 минут. А вот на согласование "красивого баннера", сделанного без нормального ТЗ, может уйти недели две и порядка 5-10 итераций правок. Стоит ли экономить эти 15 минут? Думаю, ответ очевиден.

💻

Кейс: интеграция 1С и Битрикс без головной боли

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

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

Почему нельзя просто "сделать интеграцию"

Интеграция 1С с Битриксом — это как покупка машины. Вы же не приходите в автосалон и не говорите: "Дайте мне машину". Вы уточняете:

• Для каких целей (город, трасса, бездорожье)
• Какой бюджет
• Сколько людей/багажа планируете возить
• Какие характеристики важны
• Какое обслуживание планируете

То же самое и с интеграцией. Это не кнопка "сделать интеграцию", а сложный процесс настройки обмена данными между двумя системами. И для этого нужно понимать массу деталей.

Я как-то получил заказ на "интеграцию с 1С", сделал стандартную двустороннюю интеграцию товаров и заказов. А потом выяснилось, что клиенту нужно было ТОЛЬКО выгружать заказы с сайта в 1С, причем с какими-то специфическими полями, о которых он даже не удосужился упомянуть. В итоге — переделка и потерянное время. А ведь можно было просто составить нормальное ТЗ!

Правильное ТЗ для интеграции 1С и Битрикс

Вот как должно выглядеть ТЗ для интеграции 1С и Битрикс:

1. Типы данных для синхронизации

Данные для синхронизации:
- Товары (наименование, артикул, описание, характеристики, цены, изображения, остатки)
- Категории товаров (структура, наименования)
- Заказы (состав, статусы, контактные данные клиента)
- Клиенты (контактные данные, история заказов)

Обратите внимание, что мы четко перечисляем, КАКИЕ именно данные нужно синхронизировать. Не просто "товары", а конкретные атрибуты товаров.

2. Направление синхронизации

Направление обмена:
- Товары: только из 1С на сайт (односторонний обмен)
- Категории: только из 1С на сайт (односторонний обмен)
- Заказы: двусторонний обмен (с сайта в 1С и обновление статусов из 1С на сайт)
- Клиенты: только с сайта в 1С (односторонний обмен)

Здесь мы уточняем, в каком направлении должен идти обмен для каждого типа данных. Это критически важно! Иначе может получиться, что ваш интернет-магазин внезапно перезапишет все данные в 1С, и привет, катастрофа!

3. Периодичность обмена

Частота синхронизации:
- Товары: раз в сутки (в 3:00)
- Категории: раз в сутки (в 3:00)
- Заказы: каждые 30 минут
- Клиенты: в реальном времени (при создании заказа)

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

4. Приоритет данных

Приоритет при конфликте данных:
- Для товаров: данные 1С имеют приоритет
- Для заказов: статусы из 1С имеют приоритет, все остальные данные заказа неизменяемы после создания

Этот пункт особенно важен! Что происходит, если одни и те же данные были изменены и на сайте, и в 1С? Чьи изменения "победят"? Без четкого определения приоритета вы рискуете получить кашу из данных.

5. Особые требования

Особые требования к интеграции:
- Сохранять SEO-URL товаров и категорий при обновлении
- Не обновлять описания товаров из 1С (только цены, остатки и характеристики)
- При синхронизации заказов передавать дополнительные поля: "Комментарий к доставке" и "Предпочтительное время доставки"
- Настроить логирование всех ошибок обмена с уведомлением администратора по email

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

6. Тестирование и внедрение

Процесс внедрения:
- Настройка на тестовой копии сайта и тестовой базе 1С
- Проверка корректности обмена всеми типами данных
- Настройка обработки ошибок и уведомлений
- Перенос настроек на боевую версию после подтверждения работоспособности

Никогда, НИКОГДА не проводите первичную настройку интеграции на рабочих системах! Сначала все тестируется на копиях, и только когда вы убедились, что все работает как надо, настройки переносятся на боевые системы.

Почему детальное ТЗ для интеграции так важно

Я как-то работал с клиентом, который сначала отказывался тратить время на составление подробного ТЗ для интеграции. "Зачем это всё? — говорил он, — Просто настройте стандартный обмен и всё!"

Через неделю после запуска "стандартного обмена" выяснилось, что:

1. В 1С были перезаписаны цены для дилеров (которых не должно было быть на сайте)
2. Описания товаров на сайте, которые специально писали копирайтеры, заменились техническими описаниями из 1С
3. SEO-URL товаров сбросились, и все позиции в поисковиках были потеряны

И это только верхушка айсберга! Клиент потерял несколько недель продаж и кучу денег на восстановление данных. А всё почему? Потому что пожалел пару часов на составление нормального ТЗ.

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

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

Как правильно составить ТЗ для разработчика сайтов: понятный язык вместо сложных терминов

🎨

Макет из Фигмы: от картинки к рабочему функционалу

Сейчас расскажу вам историю, которая случилась со мной пару месяцев назад. Звонит клиент (назовем его Дмитрий), говорит: "У нас готов дизайн макет в Фигме, там все понятно, просто сделайте так же". И скидывает ссылку на макет.

Открываю я этот макет. Да, красиво. Стильно. Модно. Молодежно. Карточки товаров вылизаны до блеска, кнопки идеально расположены, текст ровно уложен. Ну просто загляденье!

И так, звоню Дмитрию: — Слушай, а что происходит, когда пользователь нажимает на эту красивую кнопку "Добавить в избранное"? — Как что? Товар добавляется в избранное... — А где хранится это избранное? В куках? В базе данных? Привязано к аккаунту? — Э-э-э... Не знаю, как обычно делается. — А что если у товара нет в наличии разных размеров, как показано на макете? — Хм... Не подумали... Наверное, нужно как-то по-другому показывать... — А как этот блок выглядит на мобильном? — О, мобильную версию мы забыли нарисовать...

И так продолжалось минут 40. Я задавал вопросы, Дмитрий растерянно отвечал: "Не знаю", "Не подумали", "А как правильно?". В итоге заказчик сам понял, что дизайн-макет — это всего лишь верхушка айсберга, а для нормальной работы нужно техническое задание.

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

Чек-лист для превращения макета в ТЗ

Если у вас уже есть дизайн в Фигме или другом редакторе, то для превращения его в полноценное ТЗ нужно ответить на следующие вопросы:

1. Состояния элементов

   • Как выглядит кнопка при наведении? При нажатии? Когда неактивна?
   • Как отображается форма с ошибкой валидации? А после успешной отправки?
   • Как меняется внешний вид элементов при взаимодействии с ними?

2. Интерактивность

   • Что происходит при клике на каждый интерактивный элемент?
   • Какие анимации должны быть при переходах между страницами или состояниями?
   • Как работают фильтры, сортировки, пагинация?
   • Какие данные отправляются на сервер и какие ответы ожидаются?

3. Адаптивность

   • Как выглядит макет на разных устройствах (десктоп, планшет, мобильный)?
   • При каких размерах экрана происходит перестроение?
   • Какие элементы скрываются или меняют свое поведение на маленьких экранах?

4. Динамика контента

   • Что если текста больше или меньше, чем на макете?
   • Как отображается список с 1, 10, 100 элементами?
   • Что если название товара не помещается в одну строку?
   • Что если картинка товара имеет другие пропорции, чем на макете?

5. Технические требования

   • Какие браузеры должны поддерживаться?
   • Каковы требования к скорости загрузки страницы?
   • Нужна ли поддержка для пользователей с ограниченными возможностями?

На практике получается, что макет — это только 30% информации, необходимой для разработки. Остальные 70% — это как раз эти функциональные требования, которые нужно либо обсудить с заказчиком, либо принять решение на свой страх и риск. И поверьте, второй вариант обычно приводит к множеству переделок.

И опять же, решение простое — детальное ТЗ, которое дополняет макет всей необходимой информацией. Пара часов на его составление сэкономит недели работы над правками.

🤝

ТЗ как основа доверия между заказчиком и разработчиком

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

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

За 15 лет работы в веб-разработке я убедился: проекты с хорошим ТЗ завершаются быстрее, стоят дешевле (да-да, именно дешевле!) и приносят больше удовлетворения всем участникам процесса. Потому что никаких сюрпризов — все знают, что делают и к чему придут в итоге.

Главные выводы

1. ТЗ — это не формальный документ "для галочки", а рабочий инструмент, который определяет успех проекта.

2. Даже если вы не разбираетесь в технических деталях, вы можете составить понятное ТЗ, ориентируясь на результат, а не на процесс.

3. Потратив пару часов на составление ТЗ в начале проекта, вы сэкономите недели на правках и доработках в конце.

4. Хорошее ТЗ — это основа здоровых отношений между заказчиком и разработчиком, где нет места взаимным обвинениям и разочарованиям.

5. Чем сложнее проект, тем важнее деталировка ТЗ. На крупных проектах лучше декомпозировать задачи и составлять отдельное ТЗ для каждой подзадачи.

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

📝

Бонус: Шаблон универсального ТЗ для доработки сайта на Битрикс

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

# Техническое задание на доработку сайта

## 1. Общая информация
- Название проекта: [название вашего сайта]
- URL сайта: [адрес сайта]
- Контактное лицо со стороны заказчика: [ФИО, телефон, email]

## 2. Бизнес-цель доработки
[Опишите, зачем нужна эта доработка с точки зрения бизнеса]

## 3. Текущая ситуация
[Опишите, как это работает сейчас]

## 4. Что конкретно нужно сделать
[Подробное описание того, что должно быть сделано]

## 5. Функциональные требования
[Описание того, как это должно работать]

## 6. Визуальные требования
[Описание того, как это должно выглядеть]

## 7. Требования к адаптивности
[Как это должно выглядеть и работать на разных устройствах]

## 8. Критерии приемки
[Как вы поймете, что задача выполнена качественно]

## 9. Сроки и приоритеты
[Когда это должно быть сделано и насколько это критично]

## 10. Дополнительные материалы
[Ссылки на макеты, примеры, документацию]

Этот шаблон можно использовать как для простых задач ("добавить баннер"), так и для более сложных доработок ("интегрировать платежную систему"). Главное — заполнить все разделы максимально конкретно.

Кстати, если у вас уже есть готовый сайт на Битриксе, и вы хотите его доработать, то этот шаблон — именно то, что вам нужно. Просто скопируйте его, заполните все поля и отправьте разработчику. Увидите, как удивительно гладко пойдет процесс!

И помните: время, потраченное на составление ТЗ, — это не потерянное время. Это инвестиция в успешный результат. Удачи вам в ваших проектах!