Разработаем техническое задание под Ваш проект

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

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

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

Главное правило при составлении ТЗ - четко понять друг друга. В техническом задании не будут фигурировать слова "качественный, красивый, технологичный". Понятие о красоте у каждого свое. И то, что понравится нам, может совсем не приглянуться заказчику.
Аналогичная ситуация и с формулировками. Они могут быть до того расплывчатыми и неоднозначными, что потребуют от нас тратить свое и ваше время для уточнений. Вот лишь некоторые примеры того, чего указано не будет:

• Удобный сайт. Удобный для чего? Для открытия страницы с контактами? Для заказа товаров онлайн? Для просмотра фотографий вашего портфолио?
• Ресурс будет выдерживать большие нагрузки. У каждого предприятия разный охват аудитории, следовательно и посещаемость у одних будет 100 человек в сутки, а у других - 100 000. Вот и получается, что "большие нагрузки" - совершенно разные понятия;
• Наполним сайт экспертным контентом. У каждой отрасли миллион особенностей и нюансов. Например, для той же металлобазы можно написать текст,в  котором будет приведен химический состав каждого из продаваемых позиций, указать точные размеры до миллиметра для каждого товара;
• Сайт вам понравится. Это - вообще алес! А если у вас будет плохое настроение на момент приема работы?

Вот несколько примеров того, как именно будут выглядеть пункты ТЗ:

• Список статей на главной странице — 6 (7/8/10…) последних новостей будут выводиться на главную страницу;
• Большие нагрузки — 100 (200/500/10 000/100 000) посетителей одновременно;
• Ненавязчивая и минималистичная форма подписки — Тут уже будет эскиз, который поможет клиенту понять, что такое «ненавязчивая и минималистичная» в нашем понимании

Отдельно мы выведем следующую информацию:

• Цель сайта;
• Ожидаемый список функций ресурса;
• Чем вообще занимается предприятие;
• Целевая аудитория.

Если в переписке мы используем сложные или узконаправленные термины, они обязательно поясняются отдельно в глоссарии. Вот простые примеры: база данных на жаргоне веб-разработчиков — это не всегда список данных клиентов. Подвал — это не помещение в доме. А есть и совсем непонятное: Пых, CMS, SQL и т. д.

Безусловно, сайт, который мы предоставим вам по завершении работы, будет прекрасно функционировать в любых браузерах. Мы не можем допустить, чтобы вы теряли клиентов, у которых сайт банально не откроется. Но в списке технологических особенностей мы четко пропишем, в каких браузерах будет открываться сайт.
В этом же блоке указывается и то, с какой скоростью будут открываться страницы и какую нагрузку  будет выдерживать ресурс.
Здесь же будут указаны и инструменты, использующиеся при создании сайта. В частности, это касается CMS. К примеру, мы решим, что для достижения поставленных задач намного эффективнее Wordpress будет Joomla. А ваш администратор не сможет его обслуживать. То же самое касается и требований к хостингу. К примеру, мы напишем сайт на .NET, а ваш хостинг поддерживает исключительно php и MySQL. Ни о каком .NET там и не слышали. Следовательно,  поэтому данный пункт также подробно описывается в ТЗ.

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

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

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

1. Нажали на кнопку «Заказать звонок»;
2. Появилось всплывающее окно с полем для ввода номера телефона и кнопкой «Заказать звонок»;
3. Посетитель вводит номер и нажимает на кнопку;
4. Окно для ввода номера исчезает, вместо него появляется окно с надписью «Мы вам перезвоним в течение 2 часов», которое исчезает само собой через 10 секунд;
5. На электронную почту менеджера приходит письмо с описанием, с какого ресурса пришло письмо и требованием позвонить по номеру, указанному посетителем.

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

Тут тоже могут существовать несколько вариантов:

1. Мы готовим сайт, наполненный «рыбой» - текстом Lorem Ipsum Dolor…, который будет повторяться и который уже вы замените на свой собственный;
2. Мы разрабатываем сайт, который уже заведомо будет наполнен статьями;
3. Мы разрабатываем сайт, а потом, за дополнительную плату, уже наполняем его статьями.

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

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

Безусловно, ТЗ для информационного портала холдингового гиганта и для сайта-визитки булочной будет различаться кардинально. Но, во всех случаях, в предоставленном техническом задании, обязательно указываются следующие пункты: • Глоссарий терминов, которые могут быть непонятны заказчику; • Структура сайта; • Технологии, которые мы будем применять при разработке в зависимости от функционала хостинга; • Прототипы страниц; • Контент, а также способ наполнения им сайта; • Общие данные о целевой аудитории и компании. Это те пункты, которые будут указаны в обязательном порядке. Дополнительно могут появиться и следующие: • Сценарии использования (если интерфейс будет отличаться от стандартного); • Требования к дизайну (если таковые были предоставлены клиентом).