Мы составляем рабочую документацию не ради стопки файлов. Пакет нужен, чтобы любой следующий специалист понял, что уже решено, а заказчик мог принять этап по чек-листу, а не по настроению после показа.
Устная постановка живёт до следующей встречи. На следующей встрече память у сторон уже разная. Это не злой умысел, а обычная работа памяти. Бумага фиксирует выбор, который в разговоре казался очевидным.
Что именно фиксируем
- цели сайта и кто принимает решения со стороны заказчика;
- структура, типы страниц, состав каталога и форм;
- требования к кабинету, обменам, ролям;
- макеты и комментарии к ним, а не «вам же отправили в мессенджер»;
- сценарии приёмки: что считается готовым на этапе.
Техническое задание не заменяет здравый смысл. Оно снимает споры вида «мы это подразумевали». Если требование появилось позже, его оформляют как изменение, с сроком и стоимостью. Иначе проект бесконечно «чуть доделывают».
Зачем это команде
В работе участвуют разные роли: менеджер, дизайнер, верстальщик, программист, тестировщик, контент. Каждый читает свой срез. Если срез только в голове менеджера, дизайнер слышит одно, программист другое, на приёмке выясняется третье.
Документ экономит часы созвонов. Вопросы всплывают в момент описания, когда ещё дешево поменять решение. На готовой вёрстке то же самое уже ломает сроки.
Зачем это заказчику
Вы получаете возможность вернуться к формулировке через полгода, сменить сотрудника на своей стороне и не потерять логику проекта. Приёмка идёт по пунктам. Претензия «не то чувство от главной» без критерия непроверяема; «в шапке телефон и заявка, в каталоге фильтр по бренду» — проверяема.
Документация помогает и после запуска: инструкция редактора, список интеграций, доступы, что не входит в поддержку. Иначе сайт «сдан», а знания остались у одного человека.
Как мы этим пользуемся в процессе
Сначала цели и ограничения. Затем структура и прототип или перечень экранов. Затем макет. Затем вёрстка на 1С-Битрикс и функционал. На каждом шаге сверка с предыдущим документом. Тестирование сверяет не «красоту», а описанные сценарии: форма, письмо, цена, роль пользователя.
Качество результата упирается в качество постановки. Мы настаиваем на документах, потому что иначе нельзя честно назвать срок и отвечать за объём. Если готовы описывать желаемое один раз и править осознанно — проект идёт ровнее для обеих сторон.
Что не является документацией
Чат на сорок экранов без выводов — не пакет документов. Скриншот макета без номера версии — не утверждение. Устное «делаем как у них, только спокойнее» нельзя тестировать. Мы переносим такие фразы в формулировку с критерием или откладываем.
Документ живой: изменение вносят явно, со датой. Тихая правка ТЗ после утверждения макета порождает конфликт на приёмке. Лучше лишний абзац в приложении, чем обида «вы же знали».
Заказчик вправе писать коротко. Наша работа — превратить короткий сигнал в проверяемый пункт и вернуть на согласование. Молча делать догадку дешевле на день и дороже на месяц переделок.
После запуска документация не выбрасывается. На ней учат нового редактора и считают, входит ли задача в поддержку. Без этого каждый тикет превращается в археологию переписки.
