Киев
Обратный звонок

Запрос отправлен

Не пропустите звонок от нашего менеджера. Вы получите ответы на все Ваши вопросы через 10 минут.

Есть вопросы? Звоните!
‎050-100-39-90

APEX BUSSINES BLOG

Делимся самым ценым: раскрываем рабочие секреты, рассказываем о новинках и тенденциях, показываем реальные кейсы проектов

 
Создание сайтов

Техническое задание: может ли его написать клиент?

Автор: Владимир Завьялов
Опубликовано: 06.05.2013

Хотел немного поделиться мыслями по этому вопросу. Когда я провожу переговоры с клиентами, с самого начала нашего разговора мне часто приходится слышать о ТЗ (техническое задание). Обычно заказчик уверен, что это его работа и пытается расспросить об этом как можно детальнее...

Техническое задание (тех.задание, ТЗ) - это  документ на проектирование определенного технического объекта. В нашем случае это веб-сайт. В ТЗ устанавливается основное назначение объекта (сайта), определеются технические характеристики, состав и специальные требования к проекту. 
Вопрос, который я хотел поставить в этой небольшой статье звучит примерно так:

Может ли клиент написать ТЗ на свой проект без помощи исполнителя?

Я ни в коем случае не занижаю способностей заказчика, но если я не особо разбираюсь в машинах, то не стану разбирать двигатель:-)
Что же показывает практика? Обычно заказчик получает от исполнителя (веб-студии)  короткий бриф для заполнения с такими графами:
- Структура сайта
- Функциональные элементы
- Интеграции
- Пожелания по использованию CMS
- Платежные системы: какие будут использоваться?
 
Также могут присутствовать и другие пункты, которые предлагают заполнить Заказчику самостоятельно. А ответы на эти пункты-вопросы и становятся тем самым техническим заданием.  Хочу заметить, что так работают определенно не все, но многие. Результат такой работы оставляет желать лучшего. Так почему же так происходит?
 
Давайте немного конкретнее пройдемся по этим пунктам, чтобы понять специфику работ и  их объем.

Структура сайта

Для того, что бы сделать нормальную структуру сайта, необходимо понимать «Проектирование взаимодействий» и «Информационную архитектуру» , но не будем вдаваться в подробные объяснения каждого из них.  Суть в том, что нужно хорошее понимание этих элементов и определенный опыт. Человек, заказывающий  сайт, часто не имеет такого опыта и навыков. Он специалист в своем профиле и ему будет крайне трудно сделать правильную «структуру сайта» без консультаций професссионала. Такой подход приведет к ошибкам на раннем этапе проекта. А такого своему сайту никто не пожелает.
 
 

Функциональные элементы

Хочу поделится случаем из своей практики. Последний бриф-ТЗ, который меня особенно впечатлил исходил от одного клиента,  привыкшего работать по старинке. Задача была создать интернет-магазин. В разговоре с маркетологом фирмы мы разбирали ранее заполенный им бриф сторонней веб-студии. Я спросил: "У вас указано «Возможность заказа». Что вы имели в виду?  Давайте этот пункт расшифруем. Это будет корзина, заявка, телефонный звонок или другие возможности". На  этот вопрос я не получил адекватного ответа, так как маркетолог  только как пользователь мог вспомнить какие бывают «Корзины» и как происходит заказ.
Или, например, когда мы с клиентом говорим о «Геотаргетинге» он часто не понимает, что это такое. И в этом нет ничего страшного, ведь заказчик не обязан разбираться в терминах и возможностях. Исполнитель сам может изложить все предложения и показать все плюсы и минусы использования конкретного функционального решения. Например: нужно определять местоположение пользователя и выдавать ему  информацию для его города. Вот тут то и будет нужен «Геотаргетинг». Функциональность нужно подбирать исходя из требующихся процессов на сайте.
В брифе, один на один с листом бумаги заказчик просто не сможет отобразить все необходимое. О многих технологиях и решениях в сайтостроении он не слышал или  же не понимает, как объяснить, что конкретно ему нужно.

Интеграции

В одном из наших проектов мы начали с того, что клиент хотел только 1С интеграцию. Потом появилась надобность оповещать клиента по телефону о том, что заказ принят и обрабатывается. Так в ТЗ был добавлен «СМС биллинг».  Заказчик к тому же хотел в дальнейшем  делать рассылки  своим подписчикам, и мы остановились на интеграции с американским сервисом «MailChimp». Клиент не знал про него и не подозревал, что  рассылку можно сделать именно так. Просто сначала были задачи, а потом появлялись решения, которые рождались в процессе «Интервью с клиентом».
 
 

Пожелания по использованию CMS

Этот вопрос довольно спорный. И эти споры не умолкают ни на день.  Бесплатные, платные, студийные, профессиональные CMS: какие лучше? Профессиональное сообщество относительно предпочтений в этом вопросе делится на множество лагерей. И каждая лягушка, как говорится, хвалит свое :-) Решение тут довольно простое: CMS должна решать поставленные Вами задачи. Это главный критерий при ее выборе. Также необходимо, чтобы она была удобной в использовании  и давала возможность найти альтернативную тех. поддержку.
 
 

Платежные системы 

У нас есть клиент, которому мы сейчас делаем сайт. Тематика: услуги тренера по фитнесу, профилактика и восстановления после травм. Великолепный профессионал своего дела, но с интернетом на «вы». Клиент хотел просто рассказать про свои способности и опыт,  для нас это означало - «продавать услуги». В  интервью мы совместно пришли к решению о продаже видео-тренингов. Но как? Клиент просто не знал. Как будет происходить покупка  видео-курсов? Какие системы оплаты использовать: Webmoney, Licpay, Интеркасса?.. А теперь подумайте как заказчик смог бы заполнить бриф самостоятельно? И какой сайт по этим ответам получил?
 
В общем, подведу итог:
ТЗ - это достаточно поздний этап проектирования. До него клиент и исполнитель вместе должны подробно разобраться во всех деталях проекта: во всех взаимодействиях, целях, задачах, рубрикаторах, категориях, пользователях, и процессах, которые будут происходить на сайте.
Именно исполнитель, а не заказчик, должен на последующих этапах написать тех. задание программисту и дизайнеру, исходя из согласованного функционала сайта, структуры, дизайнерских задач и других принятых решений. 
Когда Вам как заказчику говорят написать Техническое Задание, хорошо подумайте, правильный ли выбор вы делаете, начиная работу с такой студией. Ведь для этого Вам будет необходимо полное понимание гипотез юзабилити,  проектирования,  поисковой оптимизации и других направлений в сайтостроении. Надеюсь, аргументов о том, что для этого нужны как минимум специальные навыки, я привел достаточно.  
 
P.S.:  Хочу еще раз сделать акцент на том, что ТЗ является результатом СОВМЕСТНОЙ работы заказчика и исполнителя. 
 
 Вы готовы к совмествному творчеству и созданию отличного проекта? 
Вам осталось лишь потратить 30 секунд и заполнить быструю заявку   
 
 

Давайте обсудим?

Есть светлые мысли по теме? Пишите в комментариях, задавайте вопросы!

закрыть

Ваш комментарий успешно отправлен.