Что такое качественное техническое задание?

29.10.2009 17:07

Свой цикл статей о создании веб сайта хочу начать с самого, на мой взгляд, важного – технического задания.

Общение с клиентом оставим за бортом, благо для этого неблагодарного дела есть менеджеры, за что я им бесконечно благодарен. :) Главное, что бы менеджеры знали свое основное задание: выудить из клиента максимум информации до начала разработки.

Итак, давайте разбираться с корня. Что же такое техническое задание? Википедия дает такое определение:

Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).

На мой взгляд, суть передана верно. Для меня же, в первую очередь, как для веб-программиста, техническое задание – это набор текстовых материалов с графическими иллюстрациями, схемами и рисунками, которые полностью и исчерпывающе описывают все программные, графические и концептуальные особенности работы веб-проекта.

Точно так же техническое задание должно служить путеводителем для дизайнера и, в меньшей мере, но в том числе, и для верстальщика. Они также должны на 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 – это плохо, необходимо по возможности обойтись без него

и т.п.




Помните главное – техническое задание является первым звеном в цепи долгого процесса создания сайта, ошибка в котором способна привести к краху всей этой цепи.





Метки: , , , ,


Оставить камент