Популярные темы
Копировать ссылку
ВКонтакте
Telegram
WhatsApp
Техническое задание — не просто документ, по которому можно легко разобраться, какие работы должен выполнить разработчик. Это простой способ выяснить, чего хочет заказчик, зафиксировать его требования, найти взаимопонимание, а не угадывать. Отличная страховка для обеих сторон: веб-студия не делает лишней или ненужной работы, а клиент не ждет того, что не прописано в ТЗ.
Зависит от того, какой тип сайта выбрал заказчик, но техническое задание для лендинга будет отличаться от ТЗ для интернет-магазина.
ТЗ составляет тот, кто разрабатывает сайт, а не заказчик! Но без ответов на вопросы и предоставления информации от того, кто его ждет, техзадание получится нерабочим и бесполезным.
Если вы скажете, что нужен сайт-визитка для салона красоты или интернет-магазин для шоурума — это уже будет начало разработки ТЗ.
От этого зависит интерфейс, дизайн, подача контента — вам нужен сайт, который будет удобен и понятен для пользователя. Качественный сайт не вызывает раздражения, что невозможно что-либо найти, а путь с его главной страницы до решения вопроса пользователя занимает всего несколько кликов.
Недостаточно прибыли? Нужно срочно выйти в онлайн, так как в офлайне дела идут не очень? Или наоборот: все хорошо, но надо еще лучше? Причины разные, и они тоже влияют на разаработку сайта.
Процесс разработки техзадания ускорится, если заказчик принимает активное участие: накидает свои “хотелки”, референсы сайтов, которые ему нравятся, расскажет, в каком стиле комфортнее его аудитории воспринимать информацию.
Заказчик и разработчик должны правильно понять друг друга. Не приукрашивайте ТЗ качественными прилагательными, такими, как “красивый”, “современный”, так как это слишком субъективно. У каждого свое понимание того, что сейчас называть красивым или современным.
Например, если вы пишите, что сайт выдерживает большие нагрузки, то добавьте конкретную деталь: на сайте может находиться 100 тысяч посетителей одновременно.
Самое важное в техзадании — сделать его понятным абсолютно для всех, кому придется его читать и брать во внимание. Объясните, что такое CMS так, чтобы понял школьник младших классов.
Отдельным пунктом вынесите требования к хостингу (уточните, где у клиента сервер). Все это необходимо, чтобы потом у заказчика не возникало, например, вопроса “Почему сайт не на Битрикс, а на Вордпресс?”.
Здесь пишем, в каких браузерах должен работать сайт, типы мобильных устройств, в которых он должен отображаться корректно, скорость загрузки, которая в идеале должна составлять не более 3 секунд, защита от хакеров и т.п.
Это лучше сделать еще до того, как отрисован дизайн и начата верстка. Все страницы сайта должны быть полностью описаны: элементы и их расположение, контент, как одна страница взаимосвязана с другой. Удобный способ показать структуру клиенту — прототип. Заказчик увидит интерфейс будущего сайта и даст обратную связь: поймет, что ему нравится, а что нужно изменить.
Нужно прописать схемы взаимодействия пользователя с сайтом, чтобы на начальном этапе разработки не потерять какое-либо важное звено: описание действия пользователя, ответ со стороны сайта и результат.
Определитесь, кто будет предоставлять контент: одни разработчики делают сайт сразу с ним, а для других его нужно подготовить самостоятельно. Третьи подготовят контент за дополнительную плату. Договоритесь заранее и о том, какой дизайн одобрил заказчик, включая шрифты.
Каждый этап разработки должен быть ограничен временем — сроки выполнения тоже указываются в ТЗ.
Есть прецеденты, когда даже без технического задания заказчикам и разработчикам удавалось понять другу друга так, что результат радовал всех, но это, скорее, исключение, нежели правило. Поэтому разумнее всего начинать разработку сайта с составления грамотного ТЗ.
