Почему мы делаем сайты без ТЗ, но результат не хз

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

Привет! Это веб-студия Молния. Начнём сразу с того, что мы делаем сайты на Тильде. Ага, скажете вы, вот тут и попались. Да, мы не пишем код и не проектируем мобильные приложения. Мы делаем лендинги, многостраничники и интернет-магазины на конструкторе, и разработка идёт намного быстрее, проще и дешевле, чем при создании самописного сайта.

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

На своём опыте мы столкнулись с тем, что заказчики «техническое задание» трактуют по-разному. В основном делятся на три лагеря.

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

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

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

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

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

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

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

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

Кроме того, некоторые детали практически невозможно зафиксировать на бумаге. Ситуация: для визуала сайта дополнительно нужно нарисовать иллюстрации. Мы также берём на себя эту задачу. С заказчиком обсудили референсы, выбрали формат 2D, нащупали стилевое направление. Пора фиксировать договорённости в ТЗ, только не понятно, как это прописывать. Ок, можно указать формат и количество изображений, прикрепить список референсов, но полностью описать будущую картинку довольно сложно. Не считать же количество пикселей и не расписывать код заливки?

Ответ размещаем сразу в первом предложении — понять и закрепить задачу помогает подготовительный этап здорового человека.

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

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

На брифинг-созвоне копирайтер задаёт уточняющие вопросы, которые помогают глубже понять, как работать со структурой, текстом и Tone of Voice. Происходит обсуждение будущего прототипа: если это многостраничник, то количество и наполнение страниц; если лендинг, то необходимые блоки и содержание. Дизайнер показывает референсы и мудборды, предлагает возможные направления будущей концепции. В живом общении намного проще понять и определить задачу, а также можно сразу обсудить возможные решение. Проджект дословно фиксирует обсуждение для того, чтобы опираться на стенограмму в работе.

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

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

В то же время система защищает и наши интересы. Мы приступаем к работе только после 100% оплаты за этап, а значит нет риска, что сайт полностью сделан, но работу не оплатят. Плюс мы не переходим на следующий этап, пока не будет согласован

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

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

Конечно, мы фиксируем общие правила, порядок оплаты, количество итераций правок, гарантии в договоре. А перед началом каждого этапа работы мы подготавливаем для заказчика дополнительное соглашение на конкретную услугу. Прописываем в нём стоимость, сроки и оставляем мини- ТЗ. Например, прописываем, что дизайн-концепция будет разрабатываться на первых трёх блоках лендинга, и указываем их список. Или перечисляем список интеграций для интернет-магазина. Этого более чем достаточно для закрытия юридических вопросов.

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

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

Больше кейсов и полезной информации по веб-дизайну и маркетингу у нас в Telegram-канале @flash_family