Суть техзадания

Ваша первоначальная задача - донести РґРѕ разработчика суть вашего проекта. Р?менно СЃ этого должно начинаться любое техническое задание РЅР° разработку сайта.

Опишите в свободной форме свой проект, расскажите разработчику, что вы хотите получить от своего нового сайта (или доработки уже существующего) и каким его должен видеть посетитель.

Пример: «Будущий интернет-магазин кондиционеров будет служить основным инструментом для привлечения клиентов Рё увеличения продаж. РћС‚ большинства конкурентов нас отличает наличие собственного сервисного центра Рё технический персонал прошедший обучение РІ РЇРїРѕРЅРёРё. Наш посетитель Рё потенциальный клиент должен СЃ первого взгляда понять, что попал РЅР° сайт серьезной организации, однако серьезность РЅРµ должна „давить“ — РјС‹ хотим произвести впечатление открытой компании СЃ которой легко работать.В».

Подобное описание даст разработчикам возможность прочувствовать что им предстоит сделать, а значит все дальнейшее описание будет восприниматься через призму этих ощущений и избавит от необходимости без видимых причин вдаваться в ненужные и путающие на начальном этапе подробности. Вышеописанное особенно актуально для дизайнеров.

Название, логотип, стиль и дизайн и их значение в техническом задании

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

Например: «Мы видим наш сайт в светлых тонах, без лишних деталей, возможно использование оранжевого цвета для выделения заголовков и других акцентов. Ссылки, кнопки, навигация — на усмотрение дизайнера.»

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

В идеале вам нужно достаточно подробно описать ваше виденье будущего дизайна, так же привести в техническом задании список сайтов (желательно, но не обязательно) тематически близких к вашему. Снабдить список из 5-10 сайтов краткими описаниями, например:

www.site.ru — нравится цветовая гамма и подача товаров, размер шрифтов мелковат.
www.site2.ru — отлично реализован «быстрый заказ», все остальное ужасно.
www.site3.ru — основной конкурент, все хорошо но на него похожим быть нельзя.

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

 

Структура и основная функциональность сайта

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

Например:

1. О компании
          1.1. Руководство
           1.2. Вакансии
2. Каталог товаров
          2.1. Микроволновые печи 
          2.1.1. Panasonic
          2.1.2. Samsung
          2.1.3. Daewoo
2.2. Водонагреватели
          2.2.1. Проточные  
          2.2.1.1. Bosh
          2.2.1.1.1. Проточный водонагреватель Bosh BX5L
          2.2.1.1.2. Проточный водонагреватель Bosh BX10L
          2.2.1.1.3. ...
          2.2.2. Накопительные
          2.2.3. Газовые проточные
3. Контакты
          3.1. Схема проезда

При наличии задач, разделов или функциональных элементов которые нельзя структурно описать в виде дерева, можно нарисовать схему или дать пояснения, например:

• РЈ пользователя должна быть возможность заказать товар, как РёР· СЃРїРёСЃРєР° товаров, так Рё РёР· карточки товара.
• РЈ пользователя должна быть возможность перейти РІ «корзину заказов» СЃ любой страницы сайта.
• РќР° страницах каталога, РІ разделе «пылесосы», Р° так же РІ карточках товаров РїРѕРґ основным СЃРїРёСЃРєРѕРј содержащим модели Рё характеристики должны отображаться мешки для пылесосов.

 

Уточнения

• Обязательно распишите РІСЃРµ что нельзя увидеть РЅР° близких РїРѕ тематике сайтах или может быть истолковано неоднозначно. Любые ваши идеи Рё РЅРѕСѓ-хау — важны.
• Обозначьте примерный размер сайта РІ страницах, например — 10 обычных страниц СЃ информацией Рё 990 страниц СЃ описанием продукции РІ каталоге товаров.
• РќРµ забудьте указать РІ техзадании Рё обсудить СЃ разработчиком стратегию дальнейшего развития, продвижения Рё рекламы вашего проекта.
• Укажите, как именно РІС‹ хотите получить готовый проект, кто будет устанавливать его РЅР° хостинг Рё осуществлять дальнейшую техническую поддержку.
• Продумайте нужна ли РЅР° сайте регистрация для посетителей? Зачем РѕРЅР° нужна вам, Р° чем РѕРЅР° будет полезна посетителю.
• Ваш будущий интернет-магазин РІ перспективе будет доставлять товары почтой РІ любой уголок РјРёСЂР°? РќРµ забудьте предупредить РѕР± этом.
• Договоритесь, кто будет писать Рё подготавливать Рє публикации текстовое наполнение сайта, кто будет заполнять сайт.

 

Сроки и стоимость

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

Со сроками все еще проще - вы знаете когда вы хотите получить проект и когда он будет по-настоящему необходим. Сообщите разработчику, что он вас очень обрадует сдав проект через 6 недель, но через 8 недель у вас «выставка» и к этому сроку проект должен быть готов обязательно.

Ваши контакты

Высылая или другим способом передавая разработчику техническое задание на разработку сайта не забудьте указать ваши контактные данные (как минимум имя, телефон, email) и удобное время связи. Это может выиграть время как при первоначальном ответе разработчика, так и во время дальнейших обсуждений деталей.

 

Жесткое ТЗ

Наверное каждый программист сталкивался в своей работе с неприятностями, вызванными нечеткими договоренностями. Заказчик (или начальник) ставит задачу устно и довольно неподробно. Программист, тем не менее, вполне понимает, о чем идет речь, соглашается сделать за определенные деньги или время, а потом оказывается, что заказчик имел в виду другое (читай: гораздо больше), и вроде как договоренность уже есть, и надо делать, и получается, что программист работает гораздо больше, чем рассчитывал.
После одного-другого таких случаев программист обычно решает, что отныне и навсегда все отношения с заказчиком/начальником обязательно должны регулироваться жестким техническим заданием.

Обратная сторона жесткости

Такой подход действительно логичен и хорошо защищает разработчика и заказчика от неприятностей, но у него есть и другая сторона, которую его приверженцы часто упускают -  спецификация задачи до начала ее реализации чаще всего сильно расходится с тем, что же действительно нужно от системы заказчику.
Р? здесь разработчики часто встают РІ агрессивную защитную позицию: "если этот весь РёР· себя мегабизнесмен сам РЅРµ знает, чего хочет, то сам виноват".

Во-первых, это просто неверная постановка вопроса. Потому что если заказчик действительно не знает, чего хочет, то это не значит, что он не готов платить деньги за то, чтобы ему это объяснили, предложили варианты и оценили каждый вариант во времени/деньгах. А вот это перекладывание ответственности и поиск виноватого в грядущем провале — это как раз то, что отличает разработчика, обиженного на предыдущего заказчика, от разработчика, который хочет решить задачу. Другими словами, не надо заранее планировать провал.

Во-вторых, заказчик не знает, чего хочет, совсем не потому, что он идиот. Просто реальность оказывается куда сложней умозрительных представлений о ней.

Р?так, если РІ РґРІСѓС… словах:

ТЗ с жестко зафиксированными условиями часто приводит к созданию бесполезного продукта.