HAHpp.com - Форум о SEO продвижении сайтов, оптимизация, раскрутки сайта. Бесплатная СЕО консультация. У нас вы найдете самую интересную и актуальную информацию о SEO продвижении! Форум для тех, кто не стоит на месте, а стремится «жить» и развиваться!

Давайте самосовершенствоваться вместе и менять этот мир в лучшую сторону! Регистрируйтесь!

Есть аккаунт? Войти или Регистрация!

Для рекламы услуг и сервисов, обсуждения работы, отзывы в разделах: Веб-студии и digital-агентства, Частники (не компании), Фрилансеры, Другие услуги и сервисы.


Техническое задание для создание сайта. Как составить?

1 сообщение в этой теме

Опубликовано (изменено) · Жалоба

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

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

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

Обоснование необходимости текстового задания

Прежде чем обосновать важность документального оформления целей и задач, остановимся на еще одном важном моменте. А кто вообще составляет ТЗ? Исходя из опыта, мы рекомендуем отправляться на первую встречу с разработчиком, имея в голове четкий план и видение своего ресурса.

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

Пример

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

Что здесь может быть непонятно? Все стандартно и шаблонно. Разработчик соглашается с клиентом, четко понимает, как должен выглядеть шаблон сайта интернет-магазина одежды:

site-hahpp.thumb.png.19b1178414c7ed1aa9a

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

site-hahpp1.thumb.png.b016b535323e907e65

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

  1. Заказчик признает, что был не прав, бесплатно дорабатывает ресурс. Причем слово бесплатно подобрано не совсем верно, т.к. это будет взгляд только со стороны клиента. Для исполнителя это будут вполне реальные расходы. Необходимо оплатить работу программиста, верстальщика, возможно дизайнера. Ради этого вполне вероятно придется временно отрывать сотрудников от других проектов, либо оплачивать сверхурочную работу. Если подумать, то бесплатно будет весьма условным понятием и со стороны клиента, т.к. к этому моменту он рассчитывал получить готовый проект в соответствии со своими ожиданиями. В результате потрачено время, а этот ресурс вообще бесценен.
  2. Клиент идет на попятную, признает, что подробное текстовое задание решило бы проблему. Соглашается на доработку на платной основе  и проект запускается в доработку. В реальности такая ситуация встречается очень редко, поэтому скорее всего будет конфликт интересов, который закончится потраченными нервами, силами, финансовыми издержками и другими затратами с обеих сторон. Репутация заказчика будет испорчена, независимо от того, по чьей вине была совершена ошибка. Пословица клиент всегда прав работает всегда и везде. Если заказчик настаивает на работе без четкого ТЗ, то необходимо согласовать действующий проект в максимально короткое время, чтобы избежать разногласий в будущем.
  3. Мировая. Это самый простой и действенный метод решения проблем. Обе стороны признают ошибки и договариваются об устранении проблем с минимальными издержками для всех сторон. Но даже в этом случае репутация разработчика может быть испорчена, т.к. профессионализм заключается в том, что не допустить возникновения подобных ситуаций.
  4. Еще одна особенность при разработке ТЗ состоит в правильном подходе к детализации. Обсуждение проекта нужно проводить ровно на том уровне, которого будет достаточно для постановки конкретных задач программисту, дизайнеру и верстальщику. Не стоит углубляться в технические тонкости, выносить в ТЗ особенности кода и другие тонкости. В противном случае время и стоимость технического задания будут сопоставимы с самой разработкой проекта. Доработки будут всегда, но задача ТЗ минимизировать их, свети к минимуму.

Основные пункты создания сайта

Самое важное, что нужно учитывать при составлении документа, сосредоточено в самом названии документа: техническое задание.

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

ТЗ станет документов, на который смогут ссылаться как исполнители, так и заказчики. В каждом конкретном случае, в каждом проекте требования к документу будут отличаться, но в общем виде разделы должны быть следующими:

  • Общие слова. Эта общая информация о проекте, о сайте, о его разделах и назначении. Представьте, что у Вас нет постоянной связи с программистом, а вам нужно просто передать проект человеку, который не выйдет на связь до окончания работы. После прочтения хорошо составленного ТЗ у сотрудника не должно возникать дополнительных вопросов. Первый же вопрос, который заинтересует программиста: «А о чем сайт и что он будет делать?».
  • Эксплуатационное назначение. Многие удивятся и скажут: «Какая еще цель может быть у сайта: привлечь клиентов и принести прибыль». Но мы сделаем вид, что не меркантильные и сформируем в этом пункте основные цели и задача, на более глобальном уровне, который предшествует получению прибыли. Например, для интернет-магазина эксплуатационное назначение – продажа товара, для скидочного ресурса - свести потребителя и покупателя.
  • Функциональное назначение. Здесь уже пора переходить к конкретики и указывать, при помощи какие разделов будет реализовываться эксплуатационное назначение. Проще говоря, в этот блоке нужно указать, при помощи создания какие страниц мы будет продавать товар в интернет-магазине или сводить покупателя и потребителя на скидочном ресурсе.
  • Данные и списки. Самый важный раздел ТЗ. По большому счету, если вычеркнуть из всего документа все пункты и оставить только этот, то можно все равно считать текстовый документ достаточно подробным. Данные и списки сухо перечисляют все задачи, которые должны быть реализованы в проекте.
  • Все остальные пункты будут носить индивидуальный характер. С клиентом стоит заранее обсудить выбранную CMS, хостинг, оговорить требования к контенту и безопасности. Сроки и стоимость обычно указываются не в ТЗ, а в основном договоре на оказание услуг.

 

Изменено пользователем fun

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах


Как заработать на libertex? Подробнее!

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!


Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.


Войти



Как заработать на libertex? Подробнее!