Как составить грамотное техзадание на разработку сайта
Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал желание заказчика — потратил время впустую.
Что такое техзадание и зачем оно нужно
Техническое задание — это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом. Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Польза технического задания:
- Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет — без проблем поменять еще до начала разработки.
- Увидеть компетентность исполнителя. Если техзадание понятное и четкое — доверие к разработчику повышается. Если там написана каша — возможно, стоит бежать от него и не оглядываться.
- Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор — можно даже принудить через суд.
- Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде — она втянется в работу в разы быстрее.
- Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.
Техзадание составляет исполнитель
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: менеджер проекта или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
- Познакомить исполнителя с компанией, продуктами и целевой аудиторией
- Объяснить, зачем ему сайт
- Рассказать, что он хочет, поделиться идеями
- Показать примеры хороших с его точки зрения сайтов
- Ответить на любые другие вопросы исполнителя.
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Пишите однозначно и точно
Этот совет вытекает из главной цели техзадания — «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое — с невнятными формулировками, которые ничего сами по себе не значат:
- Сайт должен понравиться заказчику. А если у него будет плохое настроение?
- Сайт должен быть удобным. Что это значит? Удобным для чего?
- Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
- Качественный экспертный контент. Ну, вы поняли.
Проверяйте, нет ли в тексте неоднозначностей. Если есть — перепишите. Ваши формулировки должны быть четкими и точными:
- Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
- Большие нагрузки → 50 тысяч посетителей одновременно.
- На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
- Минималистичный удобный интерфейс подписки → Поле «Оставьте email» и кнопка «Подписаться» → *нарисованный эскиз*.
Укажите общую информацию
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах — чтобы не получить интернет-магазин вместо блога и наоборот.
Опишите используемые вами инструменты, движки и библиотеки, если вам они известны. Например, сообщите подрядчику, что вы хотели бы использовать WordPress для работы с сайтом. Заодно укажите требования к хостингу, если они у вас имеются.
Перечислите требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать об этом в техзадании, чтобы защититься от недобросовестно выполненной работы.
Также попросите исполнителя указать требования к скорости загрузки страниц, устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Укажите структуру сайта
До начала отрисовки дизайна и верстки вам нужно согласовать структуру сайта.
Решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Структуру вы можете описать в инструментах для проектирования и создания карт, например XMind.
Это один из важнейших этапов работы над сайтом. Структура — это фундамент. Если она неудачная — сайт получится кривой.
Решите, что будет на каждой странице
Необходимо понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать:
- Прототип — более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
- Перечисление элементов — ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Распишите сценарии использования сайта
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей поняла, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
- Действие пользователя
- Ответное действие сайта
- Результат.
Конечно, если вы делаете стандартную визитку или лендинг. Зачастую используется для показа информации пользователям, переходящим по рекламным объявлениям в интернете), писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы — очень желательно.
Определите, кто отвечает за контент
Одни разработчики делают сайт сразу с контентом. Другие ставят «рыбу». Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, — это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Опишите дизайн (если сможете)
Как и в с случае с текстом, объективные критерии оценки дизайна придумать сложно. Если вы с исполнителем договорились о цветовой гамме — напишите ее. Если у вас есть брендбук, в котором прописаны шрифты, — укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Структура техзадания (ТЗ), создаваемого исполнителем
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Если техзадание составляет подрядчик, в нем должны фигурировать такие разделы:
- Информация о компании и целевой аудитории, цели и задачи сайта
- Глоссарий терминов, которые могут быть непонятны клиенту
- Технические требования к верстке и работе сайта
- Описание используемых технологий и список требований к хостингу
- Подробная структура сайта
- Прототипы страниц или описания элементов, которые должны на них быть
- Сценарии использования нестандартного интерфейса (опционально)
- Список контента, который делает разработчик
- Требования к дизайну (опционально).