Бизнес сайта техническое задание

Техническое задание – документ, описывающий все страницы и части сайта, их функционал и особенности реализации.

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

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

В статье мы расскажем о том, как по нашему шаблону самостоятельно составить ТЗ и на какие моменты нужно обратить особое внимание.

Кто должен составлять ТЗ

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

Рассмотрим на примерах, чем будут различаться их задания.

Техническое задание от заказчика

Основная миссия ТЗ, которое присылает заказчик исполнителю, – описать все части проекта, дать перечень ожидаемого функционала и указать на важные детали проекта.

Техническое задание на дизайн сайта. Разбор структуры и обзор дизайна на реальных примерах

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

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

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

При наличии ТЗ заказчику проще разговаривать с исполнителем на его языке и конструктивно обсуждать задачу.

Техническое задание от исполнителя

Цель технического задания от исполнителя – сформировать общее единое понимание задачи для всех членов команды и исполнителей, а также получить подтверждение от заказчика, что задача понята верно всеми специалистами. Оно составляется на основе ТЗ от заказчика, готовой структуры сайта и разработанного прототипа (если они есть). Если этих документов пока нет, то можно получить помощь с составлением структуры и прототипов, разместив тендер на проектирование сайта на площадке Workspace.

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

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

ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)

Структура технического задания

При составлении можно опираться на несколько источников информации:

• бриф;
• пожелания заказчика;
• разработанную структуру сайта;
• прототипы.

Составлять ТЗ, когда перед глазами нет ничего, – задача не из легких. Куда проще этим заниматься, если уже проведен анализ, известен перечень необходимых страниц и функционал, указаны цели разработки и ожидания от нее.

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

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

Оформление ТЗ, которое поможет сэкономить время

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

Пример автособираемого оглавления ТЗ

При составлении структуры ТЗ его следует разделить на логические части. В примере шаблона ТЗ использованы следующие:

1. Общая информация о проекте.
2. Структура сайта и ссылки.
3. Описание страниц и их функциональных особенностей.
4. Конверсионные формы.
5. Другие элементы.

Опционально могут добавляться:

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

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

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

Общая информация о проекте

Добавляем самые общие данные о проекте:

1. Название компании.Если проект выполняется не внутри собственной компании, прописанное название поможет специалистам понять, для кого выполняется разработка сайта.
2. Новый и старый URL-адреса компании.Нужны программистам для настройки сайта.
3. Тип сайта.Сайт может быть корпоративным, информационным, сайтом-визиткой, интернет-магазином, порталом. Знание типа может помочь в настройке админ-панели и ее модулей: например, у интернет-магазина должен добавиться модуль работы с заказами.
4. Система управления сайтом.Нужна программистам, чтобы понимать, какую CMS устанавливать или разрабатывать с нуля, если необходимо.
5. Информация о разрешениях верстки.Нужна дизайнерам, верстальщикам и тестировщикам для понимания, какие разрешения должны быть отдельно отрисованы, адаптированы и протестированы.
6. Данные о языковых версиях сайта.Нужны программистам для подключения сайта и настройки вывода данных в админ-панели.

Пример главы с описанием проекта в ТЗ

Структура сайта и ссылки

Чтобы весь сайт имел единообразные понятные URL, необходимо прописать их для каждого типа страниц в отдельной части ТЗ. Это поможет избежать лишних вопросов от программистов и, например, облегчит настройку редиректов со старого сайта (если они нужны и адреса требуется сохранить).

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

Пример инструкции по формированию ссылок для сайта

Сквозные блоки сайта: футер, хедер, всплывающее меню и дополнительные формы

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

• сколько уровней меню будет в хедере/футере;
• нужен ли вывод меню в админ-панель или его можно редактировать только через код;
• если вывод в админку требуется, то в каком формате выводить информацию для редактирования (например, будут ли доступны для редактирования ссылка на страницу, названия пункта меню, сортировка пунктов);
• можно ли менять местами (сортировать) пункты меню в админ-панели;
• можно ли добавлять/удалять пункты меню или нужно задать их фиксированное количество;
• есть ли минимальное и максимальное количество пунктов, которое нужно задать при настройке админ-панели;
• будет ли выводиться меню, если один из параметров меню в админ-панели не заполнить (например, если не добавить ссылку или название пункта меню);
• будут ли выведены в админку email, телефоны и прочие контактные данные или их можно редактировать только из кода;
• что будет происходить при взаимодействии с логотипом;
• есть ли выделение у активного пункта меню;
• как пункты меню выстраиваются в футере;
• как появляется всплывающее меню;
• как будет выделен выбранный пункт при наведении на него;
• требуется ли заверстать почту, номера телефонов, соцсети в специальные теги (url-схемы) или они будут размещены без возможности нажать на них.

Пример хедера

Пример футера

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

Описание страниц и их функциональных особенностей

При описании страниц многие элементы и блоки на них повторяются, для экономии времени на составление ТЗ мы до этого ввели заголовки.

Чтобы добавить гиперссылку в Word, выделите текст, кликните правой кнопкой мыши и выберите в поле «Ссылка» любой из заголовков.

Как сделать гиперссылку на заголовок документа

Описываются вручную поблочно только те элементы, которые присутствуют на конкретной странице или работают иначе на других страницах,

Пример поблочного описания страниц

При описании каждого из блоков обязательно нужно учесть два момента:

• должен ли элемент или блок выводиться в админ-панель (редактируемый он или нет);
• есть ли ограничения по выводу и редактированию элемента/блока, и если да, то какие.

Конверсионные формы

Конверсионные формы – это все формы на сайте, которые всплывают либо размещены на страницах и требуют совершения действия. Например, ввода email для подписки на рассылку.

При описании блока в ТЗ вам нужно учесть:

• где расположена форма и при каких действиях пользователя происходит ее вызов;
• какие данные и поля для ввода данных содержатся в форме;
• что происходит при отправке формы;
• есть ли у нее проверка на корректность введенных данных;
• какие сообщения появляются у каждого из полей, если данные введены неверно;
• редактируются ли / выводятся ли в админ-панель поля и информация с формы;
• можно ли добавить в форму новые поля, менять их местами, удалять существующие;
• как закрывается форма и есть ли затемнение/осветление фона при ее открытии и закрытии;
• куда отправляются данные с формы (на почту, в сервис рассылок);
• какие данные и в каком виде отправляются с формы (например, в каком виде приходит заявка администратору сайта);
• есть ли у полей ввода данных подсказки.

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

Другие элементы

К другим элементам я отношу:

• заголовки страниц;
• хлебные крошки;
• пагинацию;
• блоки для SEO-текста и прочие элементы, которые встречаются во всех проектах.

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

Пример описания типовых элементов

ТЗ защищает обе стороны

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

Чтобы разработка двигалась поэтапно, а обе стороны осознавали наличие единого согласованного видения проекта, нужно себя защитить. Можно прописать в договоре, что техническое задание становится его частью после подписания, а само ТЗ дать подписать представителям с обеих сторон. Даже если юридически техническое задание не всегда спасает, то психологически оно отлично сдерживает обе стороны и позволяет успешно закончить проект в сроки и в полном объеме.

Для выполнения своих задач на площадке Workspace вы можете найти любого квалифицированного специалиста или заказать разработку сайта под ключ.

Workspace.LIVE — мы в Телеграме

Новости в мире диджитал, ответы экспертов на злободневные темы, опросы, статьи и многое другое. Подписывайтесь: https://t.me/workspace

Вакансии

• Копирайтер в блог об интернет-маркетинге
  Webteam Удаленная работа По договоренности
• Переводчик видео с английского на русский язык
  Webteam Удаленная работа По договоренности
• Backend developer (NestJS)
  F`ART Удаленная работа 3 000 – 5 000
• SMM-менеджер (удаленно)
  Отель-усадьба «Времена года» Удаленная работа от 20 000
• Менеджер по продажам CRM Битрикс24
  ANIT Удаленная работа 40 000 – 150 000

Источник: workspace.ru

Как составить грамотное ТЗ на разработку сайта

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

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

Что такое техническое задание

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

Следовательно, результат удовлетворит и заказчика, и исполнителя. Польза от технического задания очевидна:

• Понимает, за что он будет платить деньги и какой ему сделают сайт. Структура сайта видна сразу, и если что-то не устраивает, изменения можно внести еще до начала разработки.
• Оценивает компетентность исполнителя. Грамотно составленное и понятное техзадание повышает доверие к разработчику.
• Защищает себя от недобросовестности исполнителя. Готовый сайт можно проверить на соответствие техническому заданию. Есть неточности? Разработчик их исправит. При наличии официального договора его можно принудить сделать это через суд.
• Упрощает замену исполнителей. Бывает, что заказчик и исполнитель ссорятся и не могут продолжать совместную работу. В такой ситуации с созданием сайта возникают проблемы. Однако при наличии подробного техзадания их можно легко решить: заказчик просто передает ТЗ новой команде, и она сразу же включается в работу.
• Узнает стоимость разработки продукта. Понять, когда будет готов сложный сайт и узнать окончательную стоимость разработки сразу нельзя. Сначала нужно разобраться с функционалом веб-ресурса. Именно для этого нужно составить техническое задание.

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

Техническое задание составляет разработчик

Грамотное ТЗ может составить только исполнитель. Проект-менеджер или разработчик понимают в создании сайтов больше владельцев кафе и стоматологических клиник. Тем не менее заказчик должен принимать в процессе самое непосредственное участие.

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

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

Пишите однозначно и точно

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

Например, этот дизайн кому-то показался красивым, и он использовал его на своем сайте:

То же самое относится и к невнятным формулировкам. Например:

• Сайт должен понравиться заказчику. А если не сможет?
• Сайт должен быть удобным. Для чего и для кого?
• Сайт должен выдерживать большие нагрузки. Сколько конкретно посетителей?
• Качественный экспертный контент. Ну, это понятно.

Обязательно проверьте текст: в нем не должно быть неоднозначных формулировок. В противном случае ТЗ придется переписать. Все мысли следует сформулировать четко и точно. Например:

• не «загрузка сайта должна быть быстрой», а «у каждой страницы должно быть более 80 баллов в Google PageSpeed Insights»;
• не «большая нагрузка», а «50 тысяч пользователей одновременно;
• не «на главной странице размещен список статей», а «на главной странице выведен список последних шести опубликованных статей»;
• не «разработка минималистичного удобного интерфейса подписки», а «поле «Оставьте e-mail» с кнопкой «Подписаться»».

Донесите до коллег общую информацию

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

Разъясните сложные термины

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

Опишите инструменты и требования к хостингу

Допустим, вы в течение двух месяцев разрабатывали сайт. Каждый этап был согласован с заказчиком. И вот работа сделана. Во время показа админки заказчик возмущается: «Это «Модэкс»?! Я рассчитывал, что сайт будет на «Вордпрессе»!»

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

Составьте список требований к работе сайта

Готовый сайт должен работать в любом браузере и на всех устройствах. Это нужно обязательно прописать в ТЗ.

Также нужно указать требования к следующим параметрам:

• скорость загрузки сайта;
• устойчивость к нагрузкам;
• защита от хакерских атак и т.д.

Создайте структуру сайта

До того, как вы начнете отрисовывать дизайн и верстать, согласуйте с заказчиком структуру сайта.

Сначала нужно выяснить, что он хочет. Затем собрать сотрудников (разработчики, SEO-специалисты, маркетологи, главный редактор) и решить, какие именно страницы нужны на сайте и как их связать между собой.

Структуру можно показать списком или нарисовать в виде блок-схемы.

Структура — фундамент сайта. Ее создание — самый важный этап работы. Если она получится неудачной, сайт будет «кривым».

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

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

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

Распишите варианты использования сайта

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

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

Определитесь с контентом

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

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

Опишите дизайн

Объективных критериев оценки дизайна сайта нет. Если заказчик хочет определенную цветовую гамму, пропишите это в ТЗ. Если он имеет брендбук с конкретными шрифтами, напишите и это.

А вот слова «красивый» и «современный» употреблять не нужно.

Вывод: структура ТЗ

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

1. Информацию о компании и целевой аудитории, целях и задачах сайта;

2. Глоссарий терминов, непонятных заказчику;

3. Требования к верстке и работе сайта;

4. Описание применяемых технологий и список требований к хостингу;

5. Подробную структуру сайта;

6. Прототипы страниц и описания содержащихся на сайте элементов;

7. Сценарии использования интерфейса, если он нестандартный;

8. Список контента;

9. Требования к дизайну (в общих чертах).

• разработка сайтов
• маркетинг

Источник: habr.com

Техзадание на разработку сайта: запрещенные слова и выражения

Если заранее обсудить нюансы и удалить сложные термины – это всем понравится.

Дата публикации: 24 декабря 2021
Время чтения: 16 минут

Павел Молянов Редакция «Текстерры»

Обновлено в декабре 2021 года.

Помните закон Мерфи? Если вас могут понять неправильно, вас поймут неправильно. Это справедливо и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика — потратил время впустую.

Рассказываем, что и зачем нужно писать в техзадании. И как писать не надо, чтобы работа не обернулась катастрофой.

Статья будет полезна:

• разработчикам, дизайнерам, верстальщикам;
• менеджерам проектов;
• руководителям диджитал-студий;
• предпринимателям, которые планируют заказать разработку сайта.

Что такое техзадание

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

Главная цель технического задания – убедиться, что клиент и исполнитель правильно поняли друг друга.

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента

• Понять, за что заплачены деньги.Можно сразу увидеть структуру, узнать, что и как будет работать. Пересмотреть идеи еще до начала разработки, чтобы сэкономить время и деньги.
• Проверить компетентность исполнителя.Если техзадание понятное и четкое, доверие к разработчику повышается. Если написана каша, возможно, стоит бежать и не оглядываться.
• Подстраховаться.Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор, можно даже получить компенсацию через суд.
• Упростить замену исполнителей.Если клиент и разработчик повздорили и разбежались, создание сайта может затянуться. Подробное техзадание можно передать новой команде. Так она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта.Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя

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

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

Гарантированно приведем клиентов
на ваш новый лендинг

Техзадание составляет исполнитель

Техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Отлично, одобряю». Он тоже должен участвовать в процессе:

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

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

Техзадание должно быть однозначным

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

Для кого-то красивый и современный сайт может выглядеть так

Аналогично с непонятными формулировками, которые ничего сами по себе не значат:

• сайт должен понравиться заказчику – а если у него будет плохое настроение?
• сайт должен быть удобным – удобным для чего, для кого?
• сайт должен выдерживать большие нагрузки 10 тыс. посетителей? Или 10 млн?
• сайт должен содержать качественный экспертный контент – Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть — перепишите. Ваши формулировки должны быть четкими и точными:

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Техзадание должно содержать общую информацию

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

А еще стоит указать цель сайта и описать его задачи, чтобы не получить интернет-магазин вместо блога.

В техзадании нет сложных терминов

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

• контент – это любой текст, изображения и видео на сайте;
• CMS – система управления сайтом, через которую можно добавлять и редактировать контент, не имея навыков веб-разработки;
• подвал – блок сайта, который отображается внизу каждой страницы.

Техзадание описывает инструменты и требования к хостингу

Представьте, что вы 2 месяца делали сайт. Каждый этап согласовывали с клиентом — он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс? ! Я думал, вы сделаете на “Вордпрессе”!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP, а у клиента сервер на .NET.

Какую CMS выбрать: руководство по выбору «движка» для сайта

Техзадание содержит требования к работе сайта

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

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

Техзадание показывает структуру сайта

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

Можно показать структуру списком, можно нарисовать блок-схему. Второе нагляднее.

Структура простого сайта-визитки

Это один из важнейших этапов работы с сайтом. Структура — это фундамент. Если она неудачная, сайт получится кривым.

Техзадание касается каждой страницы

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

Прототип

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

Сделали прототип главной страницы в Mockplus

Перечисление элементов

Ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице и что они делают.

Такой способ описания страниц экономит немного времени исполнителю, но выглядит сложно и не впечатляет

В техзадании должны быть сценарии использования сайта

Если вы создаете нестандартный интерфейс, показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого подходят сценарии. Схема сценария проста:

действие пользователя – ответное действие сайта – … – результат

Например, таким может быть сценарий оформления заказа. Пользователь нажимает на кнопку «Заказать» – сайт открывает форму заявки – пользователь вводит номер телефона и нажимает «Ок» – сайт принимает заявку и выводит сообщение «Заказ принят» – на e-mail менеджера приходит письмо с номером телефона клиента.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут интерактивные сервисы, прописать сценарии необходимо – это поможет заметить «дыры» в работе ресурса.

Техзадание утверждает обязанности

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

Указываем контент, который должен быть на главных страницах сайта

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «качественный, интересный и продающий, полезный целевой аудитории». Это мусор, он никому не нужен.

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

Техзадание описывает дизайн

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

Пример ТЗ на разработку сайта (контент и дизайн)

Вместо вывода: структура техзадания

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

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

Комментарии разработчиков

• цель сайта;
• требования к серверу;
• описание работы сайта и отдельных его элементов;
• используемые технологии и библиотеки;
• макет дизайна интерфейса;
• структуру и логику внутренних переходов;
• роли и сценарии работы с сайтом для каждой из них;
• архитектуру базы данных (опционально).

• анализируем ТЗ, присланное клиентом;
• изучаем прототип и дизайн-макет сайта;
• на основе полученных данных начинаем подбирать функциональные модули для сайта, которые будут использоваться 100 % и которые, возможно, потребуется использовать;
• прописываем элементы, которые будут нужны при работе с интерфейсом;
• исходя из этих данных и оценки «веса» сайта, вычисляем подходящие системные требования к хостингу сайта;

Валерий Филонов

руководитель отдела frontend- и backend-разработки TexTerra

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

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

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

Аша Саакян

веб-дизайнер, фрилансер

• информацию о компании и цель сайта;
• требования к дизайну, цветовую гамму;
• используемые технологии и CMS;
• кто занимается контентом — мы или клиент;
• структуру сайта вплоть до каждой страницы;
• описания каждой страницы (мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать).

Гурам Сипки

основатель диджитал-студии Udix Media

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

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

Дмитрий Кузьмин

менеджер проектов

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

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

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

Заказчик начинает разбираться, что и как, понимает, что надо было оформлять все на себя или свою фирму, но поменять домен уже сложно: адрес указан на билбордах, визитках, в рекламе, уже проиндексирован поисковиками. Переоформление прав владения доменом – тоже непростая и небыстрая задача. В общем, к выбору исполнителя нужно подходить очень внимательно, внимательно обсуждать и прописывать ТЗ на сайт.

Сохраните эту статью и перечитайте, когда надумаете заказывать сайт. Кстати, сделать это можно в нашем агентстве.

Александр Белов

проект-менеджер TexTerra

Источник: texterra.ru