Свой цикл статей о создании веб сайта хочу начать с самого, на мой взгляд, важного – технического задания.
Общение с клиентом оставим за бортом, благо для этого неблагодарного дела есть менеджеры, за что я им бесконечно благодарен. 
Главное, что бы менеджеры знали свое основное задание: выудить из клиента максимум информации до начала разработки.
Итак, давайте разбираться с корня. Что же такое техническое задание? Википедия дает такое определение:
Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
На мой взгляд, суть передана верно. Для меня же, в первую очередь, как для веб-программиста, техническое задание – это набор текстовых материалов с графическими иллюстрациями, схемами и рисунками, которые полностью и исчерпывающе описывают все программные, графические и концептуальные особенности работы веб-проекта.
Точно так же техническое задание должно служить путеводителем для дизайнера и, в меньшей мере, но в том числе, и для верстальщика. Они также должны на 100% понимать, что требуется получить в результате.
Давайте по порядку.
Текстовые материалы должны, в идеале, содержать максимум подробных описаний всех составляющихся проекта. Под этим я подразумеваю:
- 1. Домен, где будет располагаться сайт. Если он еще не известен, то хотя бы техническое(сокращенное) название сайта. С этим в общем то проблем особо не возникает. Если техническое задание описывает какуй-то новый функционал уже существующего сайта и по тексту нельзя будет понять, куда его прикручивать, то хорошо бы еще указывать раздел, где он будет располагаться или сабдомен, если функционал выносится туда.
- 1. Количество языков интерфейса
- Приблизительное наименование разделов сайта (опционально – на схеме структуры проекта в графических материалах)
- И самое главное – список и подробное описание всех функциональных единиц (обратная связь, события, регистрация, форма заказа и.д.)
Хочу подробнее остановиться на последнем пункте. Подробное описание – это не просто описание, это именно подробное.
Например.
Клиентская сторона. Форма обратной связи.
Поля: имя, e-mail для ответа, тема, текст сообщения, капча.
Обязательными являются: имя, email, текст сообщения.
На первый взгляд, вроде бы вопросов не возникает, но можно то и углубиться.
Например.
Клиентская сторона. Форма обратной связи.
Поля: имя, email для ответа, тема, текст сообщения, капча.
Обязательными являются: имя, email, текст сообщения.
Для авторизированных пользователей поля имя и email не показывать – брать сразу из профиля пользователя при формировании письма.
Отправлять на mail1@domain.com с копией на mail2@domain.com и скрытой копией на boss@domain.com.
Тема письма «Обратная связь сайта domain.com».
Отправлять с ящика no-replay@domain.com.
Указанные выше ящики необходимо зарегистрировать, пароли подобрать по своему усмотрению.
Излишний текст? Возможно. Но зато сразу отпадает множество вопросов, которые определенно будут возникать потом по очереди и тормозить разработку гораздо больше, чем решения этих вопросов сразу одной пачкой. Тем более если фронт задач оглашен весь и сразу, появляется возможность самому регулировать порядок действий, который будет наиболее эффективен и производителен: «почтовые ящики я заведу, когда буду настраивать домен, это лучше всего сделать будет тогда, а вот это тогда».
И это я, в общем-то, привел обратную связь, по сути, как самый мелкий и малоболезненный пример. Все может быть более плачевным, если функционал более широк, развернут и наворочан.
Также не стоит забывать о том, что веб-сайт это не только клиентский и/или администраторский интерфейс – им обоим надо уделять равное количество внимания.
Идем дальше.
Всякие там схемы и наброски внешнего вида страниц послужат отличным подспорьем как для дизайнера, так и для программиста. Дизайнер будет знать, на что ориентироваться, программист будет знать чего ожидать. Лучше потратить 20 минут на простейшую схемку в Визио или том же Экзеле, чем потом программист и/или дизайнер потратят часа полтора на перерисовку и/или переработку логики.
На моем веб-программерском веку я видел не мало технических заданий, от устных (да-да, устное ТЗ для разработки целого сайта не самого простого функционала – лучик поноса в вашу сторону, ВебСИТ ) до самых развернутых, и должен заметить, что при наличии полного письменного технического задания работать намного приятнее и проще, а количество комментариев и доработок в этих 2х случаях несоизмеримы.
Я понимаю, что в компании, где темпы работы шкалят и все надо делать в лучшем случае на вчера, тратить неделю времени на потоки словоблудства тоже не особо правильно и не целеобразно. В таких случаях верным решением будет найти золотую оптимальную середину, обеспечив тем самым максимальную произвоительность. Тем более, что у каждой компании, которая штампует сайты, как конвейер, не может не быть уже готовых базовых наработок. В таком случае вполне корректным будет просто указывать в техническом задании, чем какая-либо логическая единица данного конкретного сайта отличается от стандартной наработки. Например: раздел «обратная связь» стандартный (или, например, «как на проекте Рога и Копыта»), но добавляется не обязательное для заполнения поле «тема».
Еще хочу отметить, что в техническом задании необходимо по максимуму указывать принципиальные моменты, которые относятся к данному проекту. Например:
сайт будет размещаться на сервере клиента.
или
проект только для своих – клиент просит минимизировать попадание сайта в поисковые системы
или еще
клиент уверен, что javascript – это плохо, необходимо по возможности обойтись без него
и т.п.
Помните главное – техническое задание является первым звеном в цепи долгого процесса создания сайта, ошибка в котором способна привести к краху всей этой цепи.
Метки: качественное техническое задание, техническое задание, техническое задание на разработку сайта, ТЗ, что должно быть в техническом задании