Техническое задание на разработку сайта, и почему оно короче, чем принято думать

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

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

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

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

Второй признак это цена ошибки. Обычный сайт услуг переделывается быстро, поэтому подробное описание каждой мелочи не окупается. Магазин с оплатой, складом и выгрузкой в учётную систему переделывается тяжело, и там каждый непрописанный сценарий всплывает уже после запуска, вместе с потерянными заказами.

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

Рабочее задание отвечает на три вопроса и на этом заканчивается. Из чего сайт состоит. Что на нём должно происходить. Как мы оба поймём, что работа сделана.

Всё остальное это украшения. Раздел с определениями терминов, преамбула про цели и задачи предприятия, ссылки на стандарты, таблица версий документа. Эти разделы никто не читает после первого раза, а пишутся они долго.

Проверка на полезность у каждого пункта простая: можно ли по нему поспорить на приёмке. «Современный дизайн» это не пункт, спорить по нему невозможно, потому что современный у каждого свой. «Меню закреплено при прокрутке на телефоне» это пункт: либо закреплено, либо нет.

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

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

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

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

Рядом с каждой строкой пишем, зачем страница существует и что на ней делает посетитель. Строка выглядит так: «Услуга: человек понимает, что входит в работу, и оставляет заявку». Три слова, но они снимают половину будущих вопросов, потому что задают приоритет содержания.

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

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

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

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

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

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

Правильная формулировка описывает поведение. Не «интеграция с мессенджером», а «заявка с формы приходит в Telegram владельцу за минуту, дубль падает на почту». Не «личный кабинет», а «клиент видит свои прошлые заказы после входа по номеру телефона». Из такой формулировки подрядчик сам выберет способ, а вы получите проверяемый результат.

Каждую функцию полезно дописать до конца, включая неприятные случаи. Форма отправлена, но почта недоступна: что происходит. Человек ввёл телефон с буквами: что он видит. Товар кончился, пока лежал в корзине: как об этом сообщают. Эти сценарии занимают по строке, а находят их обычно в день запуска, когда исправлять некогда.

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

И про счётчики. Метрика, цели на отправку формы и на клик по номеру телефона это тоже функция, и её тоже надо записать. Иначе через месяц выяснится, что заявки идут, а посчитать их источник нечем, и вся реклама крутится вслепую.

Ещё один пункт, который вспоминают поздно: что происходит со старым сайтом, если он есть. Адреса страниц меняются почти всегда, и без переадресации со старых на новые поисковый трафик обнуляется в день переезда. Одна строка в задании про то, что старые адреса переносятся, спасает накопленные за годы позиции.

Самая частая дыра в задании выглядит невинно: про содержание не написано ничего. Подразумевается, что тексты как-нибудь появятся. Не появляются. Через две недели работа стоит, а виноватого нет, потому что договорённости не было.

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

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

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

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

Приёмка без списка проверок превращается в обмен впечатлениями. Заказчик говорит «как-то не то», подрядчик говорит «всё по договорённости», и оба правы, потому что договорённость была устной и каждый помнит свою версию.

Список проверок пишется заранее, вместе с заданием, и состоит из проверяемых утверждений. Все страницы из списка существуют и открываются. Форма отправляется, письмо приходит на указанный адрес. Меню и кнопки работают на телефоне. Счётчик установлен, цель на заявку срабатывает. Страница ошибки существует. Адреса страниц человекочитаемые.

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

Правки на приёмке делятся на два вида, и их полезно разделять вслух. Первое: расхождение с заданием, это исправляет подрядчик в рамках работы. Второе: новое пожелание, которого в задании не было, это отдельная задача. Смешивать их вредно обеим сторонам, потому что тогда работа не заканчивается никогда.

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

Не надо описывать дизайн словами. «Строгий, но дружелюбный, с акцентом на доверие» это описание настроения, по нему невозможно ни сделать, ни проверить. Работает другое: два-три ссылки на чужие сайты с пояснением, что именно там нравится, и одна ссылка на то, что не нравится категорически.

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

Не надо переписывать в задание общие требования вроде «сайт должен быть удобным и современным». Они ничего не добавляют и создают ложное ощущение проработанности. Все проверяемые требования уже сидят в списке приёмки, остальное это вода.

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

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

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

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

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

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

Признак, по которому видно нормального подрядчика: он задаёт неудобные вопросы. Кто разбирает заявки. Что происходит, если клиент пишет ночью. Почему выбирают вас, а не соседа. Кто утверждает макет. Подрядчик, который на всё отвечает «хорошо, сделаем», задание не напишет и на приёмке будет спорить.

И последнее. Задание это не гарантия результата, это способ синхронизировать понимание. Хороший сайт получается из работы и обратной связи, а документ лишь убирает разночтения на старте. Поэтому пишем коротко, по делу, и идём делать.