Бывает, что человек заказал сайт и на каком-то этапе увидел совсем не то, чего ожидал. В агентстве при этом уверены, что они следуют договоренностям. Проблема в том, что у заказчика и исполнителей были разные представления о проекте. Убедиться, что клиент и разработчик правильно поняли друг друга, и избежать ненужных расходов позволяет техническое задание. Разбираемся, как правильно составить ТЗ на разработку сайта.
Кто должен составлять техническое задание?
Тут нет строгих правил, ТЗ могут составлять как исполнители, так и будущий владелец сайта. Но любой из этих вариантов таит в себе сложности. Плохо представляя себе потребности бизнеса, разработчики нередко воплощают в документе только свое видение. Результат тот же, который описан выше: клиент недоволен результатом и даже готов сменить подрядчика.
Если ТЗ занимается заказчик, минус в том, что у него обычно не хватает технических знаний, чтобы понятно для исполнителей изложить задачу. К тому же, неспециалист просто не в курсе, какие существуют функциональные возможности для воплощения его проекта.
Вывод: ТЗ лучше составлять вместе. Заказчик рассказывает о потребностях компании, целевой аудитории, особенностях продукта или услуги. Разработчик на основе полученной информации делает техническое задание. После этого, документ утверждается обеими сторонами.
Что должно быть в ТЗ на разработку сайта?
Разделы технического задания вызывают больше всего затруднений. Рассказываем, из каких частей обычно состоит грамотное ТЗ. Разумеется, в документе могут быть дополнительные блоки на усмотрение сторон, но есть обязательный джентльменский набор.
1 Вводная часть с общей информацией
Этот раздел вводит в курс дела. Важно, чтобы все члены команды разработчиков понимали, в какой сфере работает заказчик и для кого. Еще в самом начале ТЗ кратко описывают функционал веб-ресурса и указывают его задачи — интернет-магазин это будет, сайт-каталог или, например, визитка.
2 Требования к хостингу и работе сайта, описание главных инструментов
Представьте, что через несколько недель после начала работ окажется, что у клиента и исполнителей разные представления о хорошем хостинге или что заказчик ждал сайта на WordPress, а его делают на Битрикс. Или, например, что клиенту нужно мобильное приложение, а не просто адаптивный сайт, хорошо работающий на разных устройствах.
3 Описание структуры сайта
Структура ресурса — его фундамент, с создания структуры, по сути, начинается разработка. Если сделать эту часть ТЗ плохо, сайт в итоге получится “кривым”. Поэтому важно четко описать страницы и элементы сайта в виде иерархической схемы. Такой подход поможет достичь согласия по поводу главных модулей веб-ресурса и взаимосвязей между ними.
Как правило в структуру включаются и кратко описываются:
- сквозные элементы — те, что будут присутствовать на всех страницах (шапка, подвал, сайдбары, формы и т.д.);
- уникальные веб-страницы — страницы с уникальным дизайном и структурой, на базе которых предполагается “собирать” сайт, желательно зафиксировать в техническом задании;
- прочие страницы — функциональные страницы вроде типовой текстовой, страницы регистрации и результатов поиска тоже надо учесть заранее.
4 Функциональные особенности
Функционал сайта, который четко привязан к определенным страницам, прописывается в описании этих страниц. А не привязанный — в отдельной части технического задания на сайт. Это может быть, например, модуль обратной связи, модуль расшаривания в социальных сетях или комментирования.
5 Текст и дизайн
Во-первых, необходимо указать, кто отвечает за текстовый контент — разработчики или заказчик. Если разработчики, то желательно указать различные требования к тексту — стиль, уникальность и т.д. Что касается дизайна, то к ТЗ надо приложить ссылку на брендбук компании с корпоративными цветами, логотипом, шрифтами. Бывает, что корпоративный стиль как таковой отсутствует. В этом случае при составлении ТЗ заказчик определяется со своими пожеланиями к цветам, шрифтам и прочим элементам.
Чтобы составить ТЗ на разработку сайта правильно, требуется максимальная конкретика и определенность. “Привлекательный дизайн”, “высокая скорость загрузки”, “выведение списка статей на главную страницу” — это неправильно. Лучше написать про цветовую гамму, указать, во сколько баллов должны оцениваться страницы в Google PageSpeed Insights и сколько именно статей должно выводиться на главной странице.
Желаем разработчиком взаимопонимания с заказчиками, а заказчиком — не разочаровываться в выборе подрядчика. Все что для этого нужно — составить подробное и понятное техническое задание и заказать разработку сайта. Как это сделать, вы теперь знаете.
Оставить комментарий