• Главная

ТЗ на создание сайта строительной компании. Пример технического задания на продвижение сайта


Техническое задание на сайт / Хабр

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ
А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

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

И тут выясняется, что первоначальная оценка объема работ (и соответственно, сроков выполнения и стоимости проекта), которую сделал разработчик на основании своих умозаключений и озвучил заказчику, отличается от того, что, собственно, хочет заказчик.

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

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

Так вот, задача технического задания — это свести к минимуму разницу между представлениями двух строн: заказчика и исполнителя. Хорошее ТЗ дает маленький diff, плохое ТЗ — большой.

Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д. Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот.

Если рассматривать две крайности, когда тех. задания просто нет, нет совсем, т.е. вообще, и мы сделали фотохостинг, а заказчик желал интернет-магазин, то diff будет равен всему проекту, и его стоимость будет равна стоимости проекта (придется выкинуть наш фотохостинг и сделать магазин). При этом стоимость ТЗ равна нулю. Другая крайность, это когда техническое задание и есть сам реализованный проект, т.е. оно детализировано полностью, т.е. до строк кода, переменных и стилей css. В этом случае diff равен нулю, а стоимость ТЗ равна стоимости проекта (т.к. ТЗ уже является реализацией). А между этими крайностями находится реальность, которая отражена на этом графике:

Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

Голубой линией отмечена суммарная стоимость ТЗ и переделок, предстоящих по окончании работы. Как видно из графика, у этой суммарной стоимости есть минимальное значение. Т.е. с некоторой точки становится дешевле исправить в конце работы хотелки заказчика, чем доводить до совершенства ТЗ.

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

Описываемый ниже подход, как раз и будет претендовать на ТЗ со степенью детализации близкой к оптимальной.

2. Что в нем должно быть и чего нет. Формулировки

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

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

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

Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!».

Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия. Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).

Тех. задание — это документ, который нам дает заказчик (Не важно, что его пишем мы. По смыслу это задание, техническое задание, а задание дает заказчик исполнителю, т.е. нам). А из этого следует, что в ТЗ должны быть формулировки, которые указывают нам, что делать (типа «сайт должен содержать», «должна быть возможность»). В некоторых ТЗ я видел, формулировки вида «на сайте будет то-то и то-то» — это неверная формулировка, это какое-то уведомление заказчика, что будет сделано, но документ-то называется «задание», а не «уведомление».

3. Разделы ТЗ
3.1 Общие слова
Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.
3.2 Эксплуатационное. назначение
Коротко говоря, эксплуатационное назначение — это выгода, которую должен принести сайт. Вообще, чаще всего, выгода сводится к деньгам (если сайт как-то завязан на коммерции, а таких большинство), и в разделе можно было бы всегда ограничиться написанием того, что эксплуатационное назначение сайта — подзаработать деньжат, но мы не будем столь циничными. Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат». Для интернет магазина это будет продажа товара (с которого мы получим деньги), для скидочного сайта это состыковать клиентов и продавцов или поставщиков услуг (чтоб с этого получить свой процент денег), для сайта визитки — это прорекламироваться в инете (а реклама нужна для получения денег) и т.д.
3.3 Функциональное назначение
Этот пункт уже ближе к делу. Тут краткий перечень того, какими техническими средствами мы хотим получить профит, описанный в предыдущем пункте. Например, для интернет магазина это каталог товаров, корзина заказа, страницы с информацией о доставке, возврате и о компании.

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

3.4 Термины и определения
Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же. Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

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

3.5 Данные и списки

Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.

Данные Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.

Перечисление атрибутов сущности позволяет заметить мелочи, которые, оставшись незамеченными, могли бы привести к осложнениям.

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации
Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

Списки Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей. Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.

3.6 Страницы с описанием

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

Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

Нужно ли тут описывать контент страницы? Нет не нужно. Мы пишем техническое задание. Описывая каталог, мы же не описываем все товары в нем? Наша задача описать функционал, который позволит заказчику самостоятельно заполнить контентом страницу. Если планируется наполнение сайта контентом исполнителем, это лучше вынести в отдельный документ.

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого: Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе. Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.

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

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

3.7 Требования к надежности

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

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

3.8 Требования к хостингу
Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают..., у меня другого хостинга нет, надо переделывать на PHP».

Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом
Этот пункт оговаривает объем наполнения контентом. Как минимум, мы должны создать тот контент, который позволит заказчику начать эксплуатацию сайта. Ну хотя бы создать учетную запись для администратора сайта и сказать заказчику логин и пароль.

Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

3.10 Сдача и приемка

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

Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.

Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно. Хотя, думаю, тут будут и иные взгляды на эту проблему.

Заключение
Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.

Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.

habr.com

ТЗ на создание сайта строительной компании

Цель и предназначение сайта

Сайту предоставляется доменное имя формата www.syte.com, но если домен будет занят, то возможно будет зарегистрировать домен и в других зонах (ru и т. п.). Сайту присваивается название «Сайт строительной компании». Предназначением сайта является представление фирмы заказчика в Интернете. Сайт описывает: информацию о фирме, её историю и режим работы, цены товаров, справочную информацию, сопроводительную графику, юридический адрес с почтовым адресом, схему проезда и контактную информацию. Описывается обеспечение возможностей доступа ко всей информации относительно товаров и услуг фирмы, увеличение объёмов и расширение района сбыта товаров предприятия.

Схема сайта и управление им

Сайт содержит следующие обязательные страницы html: 1 - Главную страницу; 2 - О предприятии; 3-50 - Перечень услуг или товаров, предлагаемых предприятием; 51-60 - Прайс-листы; 61 - схему проезда; 62 – возможность предварительного заказа товаров и услуг; 63 – образец типового договора; 64 - Вопросы с ответами для клиентов; 65 – Новости фирмы; 66-68 - Справочную информацию; 69 - Содержание.

Общее количество страниц определяет веб-дизайнер самостоятельно, исходя при этом из ТЗ, объёмов представленных ему материалов. Из каждой страницы на сайте должен быть переход к главной странице сайта. При этом сайт должен иметь страницу "Содержание". Блок-схема сайта веб-дизайнером определяется самостоятельно, но головная страница должна быть снабжена гиперссылками, обеспечивающими переходы с неё на, как минимум, 95% страниц ресурса.

Оформление графики, браузеры и разрешение сайта

Все рисунки размером более, чем 1 Кб выполняются с замещающим их текстом. Формат графики gif или jpg. Основным диапазоном разрешения мониторов, с помощью которых просматривается сайт, 600х800-1240х1024 пикс. При этом допускается просмотр страниц горизонтальной прокруткой. Основными браузерами, используемыми для просмотра, являются IE, Opera и Firefox.

Общее оформление сайта

Создание сайта должно предусматривать возможности его просмотра и в том случае, когда используется безопасная цветовая палитра (с разрядностью цветов 8).

Общий фон на сайте может иметь следующие варианты:

1. С общим фоном светлым (белым). Допускается использование фонового светлого рисунка.

2. Общий фон на сайте тёмный (с указанием точного, или же примерного цвета).

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

Раскрутка сайта и его порядок передачи

Сайт разрабатывается на протяжении 4 недель со времени оплаты половины всей оговоренной суммы. Продвижение сайта определяется отдельно. Этим ТЗ не оговаривается раскрутка или продвижение сайта.

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

Дополнительные условия

SEO сайта и процесс его раскрутки определено отдельным ТЗ. Настоящее ТЗ раскрутку сайта не оговаривает и в состав работ не входит.

На каждой странице сайта должны содержаться логотип и название фирмы заказчика. Внизу каждой страницы сайта должна указываться контактная информация.

webcomme.ru

Образец тз на разработку сайта

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

 

Надо сказать, что техническое задание в принципе не должно касаться условий о дизайне, так как очень трудно оценить данный результат объективно. «Красота» — понятие исключительно субъективного характера, так же как и «удобство». Посему необходимо отнестись к ТЗ основательно и четко прописать все нюансы, чтобы по окончанию работы избежать спорных ситуаций.

 

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

 

 

Содержание примера технического задания на разработку сайта

 

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

 

Для начала необходимо ввести исполнителя в курс дела — то есть сообщить тематику сайта, его цель и прочие моменты.

 

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

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

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

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

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

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

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

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

 

Ниже расположен типовой образец и бланк примера тз на разработку сайта, вариант которого можно скачать бесплатно. 

uristhome.ru

Техническое задание на разработку сайта

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

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

Написание Технического задания

Написание ТЗ – задача непростая и стоит немалых денег. Ориентировочно цена составляет от 20000 и выше в зависимости от сложности сайта. Хотя при наличии большого количества свободного времени и сильного желания можно это сделать и самостоятельно. Самое главное в составлении ТЗ – это одинаковое понимание исполнителем и заказчиком всех изложенных в нем требований.

Что представляет собой Техническое задание и почему оно так необходимо

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

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

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

Техническое задание на сайт

На что следует ориентироваться при написании Технического задания

Прежде всего, следует в ТЗ указывать следующие пункты:

  1. Тип сайта и цель его создания. Существует несколько разновидностей сайтов (сайт-визитка, блог, форум, видеохостинг и т.д.). Однако все они могут комбинироваться. Именно поэтому следует в ТЗ указывать не только тип сайта, но и цели, которым он должен служить.
  2. Дизайн. Для некоторых организаций дизайн сайта является важной частью, и они предъявляют к нему определенные требования для соблюдения фирменного стиля (цвета, логотип, бренд, шрифты и т.п.). Однако некоторым организациям наоборот может потребоваться его разработка. Такие моменты также согласовываются в ТЗ между разработчиком и заказчиком. Однако за разработку фирменного стиля придется отдельно доплачивать дизайнеру.
  3. Платформа сайта. От неё будет зависеть техническая реализация проекта. Конечно, в тонкости функционирования различных CMS способен вникнуть далеко не каждый. Однако за счет наводящих вопросов и в зависимости от поставленных задач заказчик может сам выяснить, какая платформа будет наиболее точно подходить под необходимые требования.

К данному списку стоит добавить еще один 4-ый пункт, но касаться он будет только интернет-магазинов. Ведь для того, чтобы заказчик мог вести полноценную онлайн-торговлю, необходимо чтобы на сайте отражалось реальное количество товара, его описание и стоимость. А для этого нередко требуется интеграция сайта с остальными программами, используемыми на предприятии, а также проработка других моментов касательно этого. Все это также отдельно прописывается в ТЗ.

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

Что еще следует указать в Техническом задании

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

Что указать в техническом задании

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

Дополнительные функции

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

Важно

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

По ссылке вы можете скачать пример Технического Задания на разработку Веб-сайта: https://yadi.sk/i/2Tr4yAeR3LUb9V

Пример наиболее проработанного Технического Задания на разработку сайта: https://yadi.sk/d/9EnQS1uu3LUcVQ По этому ТЗ был выполнен проект для компании "Двери Велл"

Примеры других, не менее важных документов по проекту: Художественное Задание, договор, смета, план работ, акты и пр. вы можете запросить у нас дополнительно. 

 

www.imagineart.ru

Пример ТЗ копирайтеру при контентном продвижении проекта — Devaka SEO Блог

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

Пример технического задания для одной страницы сайта:

Title: Кого считают изобретателем www и когда это произошло узнай прямо сейчасDescription: Всемирная паутина — World Wide Web (WWW) – система документов, расположенных на разных компьютерах, имеющих доступ к интернетуh2: Кого считают изобретателем www и когда это произошло

Точное вхождение:— изобретатель интернета— кто изобрел www и когда это произошло— создание всемирной паутины

Неточное вхождение:— кто был первым изобретателем интернета— всемирное хранилище информации— рождения всемирной паутины

Слова которые должны упоминаться в тексте:несколько специалистов, основы веба, искусственного интеллекта, главный упор, тим бернерс-ли, браузер internet explorer, world wide web, тим бернерс-л 1980 год, 1991 году, 1989 году, программное обеспечение, первый браузер, программу «энквайр», сотрудник европейской организации ядерного, разработал концепцию, история создания, стал первым, электронную программу обмена документами

Итого

Написали статью 3425 символов, станица вышла по низко, средне, высоко-частотным запросам.

Статистика за 2 месяца:Страница была создана ранее, но не была оптимизирована под ключевые фразы. После оптимизации ждали апдейта Яндекс + Google.

График роста посещаемости страницы после апдейта

Изменение поискового трафика после апдейта

Фразы, по которым находили страницы

Количество разных поисковых фраз для одной из страниц

Написанная статья отвечает на 91% на все возможные запросы пользователей по данной теме.

Ещё один пример технического задания для одной страницы сайта:

Title: Новая браузерная игра Agar io – пора срочно шпилить!Description: Вы уже слышали о новой игре, в которую уже играет более 1 миллиона человек в формате мультиплеер? Она стала популярна всего за одни сутки после выхода в эфир!h2: Браузерная игра Agar.io

Точное вхождение:— agar.io играть— бесплатная браузерная игра— онлайн игра агар ио— браузерные онлайн игры

Неточное вхождение:— лучшие браузерные игры— новинки браузерных игр— браузерные игры 2015 года новинки бесплатно— браузерные онлайн игры на русском

Слова, которые должны упоминаться в тексте:набирать массу, ваша масса, играть вместе, вместе друзьями, несколько дней, браузерный симулятор, скины agar.io, жизни бактерий, новая браузерная, своей массой, мобильной версии, игры аварии, стала популярной, первый взгляд, названия стран, загнал в угол, размер меньше, популярность, установить скин, выбрать сервер, главное правило, правила управления, поедать пищу, создатель игры, агаровой питательной среды, играть agar io вдвоем друзьями, бактерий, новые скины, разделить бактерию, крупный соперник, нажмите клавишу f12, секреты игре, часть своей массы, маленьк шарик, секреты, тактика

Итого

Написали статью 3600 символов, страница вышла по низко, средне, высоко-частотным запросам.

Статистика за 6 месяцев:Создали страницу, написали и оптимизировали статью, прописали мета-теги. После первого апдейта поисковых систем проиндексировалась статья и некоторые фразы попали в выдачу. Далее, ждали второго апдейта Яндекса и Гугла.

Изменение поискового трафика страницы второго апдейта:

Трафик на другую оптимизированную страницу

Фразы, по которым находили страницу

Количество разных фраз, по которым находили вторую страницу

Написанная статья отвечает на 93% на все возможные запросы пользователей по данной теме.

Выводы по данному кейсу

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

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

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

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

При возникновении вопросов – пишите их в комментарии.

devaka.ru

Техническое задание (ТЗ) на сайт, бриф на продвижение, техническое задание (ТЗ) и бриф на дизайн

На сайте собраны документы по темам: техническое задание (ТЗ) на разработку сайта, логотипа, фирменного стиля , бриф на создание сайта, бриф на продвижение сайта. А так же сопутствующая информация: ГОСТы, как написать ТЗ, программа для создания технического задания. Все ТЗ и брифы можно скачать в формате Word.

47 брифов, 58 ТЗ, 8 договоров и все это за 150 руб. Подробнее

Техническое задание описывает разработку веб-сервиса www.shopoo.ru и его систему администрирования.

Описание:Техническое задание на сайт содержит описание структуры, функционала и внешнего вида веб-сервиса.

Техническое задание описывает разработку туристического портала.

Описание:Техническое задание на сайт содержит описание дизайна и функционала тур портала.

Техническое задание описывает разработку сайта IT-компании – хостинг, домены, интернет-провайдер, аутсорсинг.

Описание:Техническое задание на сайт содержит описание дизайна и функционала сайта.

Бриф на продвижение сайта представляет из себя анкету с вопросами, ответы на которые определяют задачу SEO-оптимизации сайта.

Описание: Бриф содержит вопросы касаемо ключевых слов, выбора поисковых машин, места в выдаче, общего бюджета и прочих параметров продвижения.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу разработки дизайна сайта.

Описание: Бриф содержит вопросы касаемо компании, концепции сайта, а также требований/пожеланий к дизайну.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу оптимизации сайта.

Описание: Бриф содержит вопросы касаемо торговой марки, коммерческих задач, целевой группы воздействия, а также продвигаемого интернет-ресурса.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу разработки редизайна сайта.

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

Техническое задание описывает разработку интернет-магазина цветов.

Описание:Техническое задание на разработку интернет-магазина содержит описание дизайна и функционала сайта.

Техническое задание описывает разработку интерактивной (flash) карты страны.

Описание: Перемещение по карте, изменение масштаба карты, измерение расстояний на карте, открытие планов городов.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу разработки дизайна сайта.

Описание: Бриф содержит вопросы касаемо исходных материалов, фирменного стиля, назначения и области деятельности сайта, а также посетителей ресурса.

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

Описание: Бриф содержит вопросы касаемо дизайна, CMS, набора функций, портрета покупателей и т.д..

Техническое задание описывает разработку интернет-магазина с корзиной товаров, регистрацией, каталогом и сравнением товаров.

Описание:Техническое задание на интернет-магазин содержит описание функционала стандартного интернет-магазина

Техническое задание описывает разработку flash (флеш) сайта.

Описание: Флеш сайт рекламного агентства в современном стиле с динамично подгружаемым содержимым и программными эффектами.

Техническое задание описывает разработку сайта о недвижимости

Описание: Небольшой сайт с предложениями по недвижимости: главаня страница, каталог с фотографиями, ценами и описанием, страница конкретного предложения с большими фотографиями и описанием.

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

Описание: Бриф содержит вопросы касаемо продукта, целевой аудитории, целей и идеи ролика, оформления рекламного ролика, а также хронометража.

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

Описание: Бриф содержит вопросы касаемо продукта, целевой аудитории, выставки, параметров выставочного стенда, а также способа представления продукции.

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

Описание: Бриф содержит вопросы касаемо продукта, стилистики, проводившихся маркетинговых исследований, а также целевой аудитории.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу разработки дизайна веб-сайта.

Описание: Бриф содержит вопросы касаемо продукции, потребителей, целей проекта, коммерческих задач, а также структуры сайта. Все пункты анкеты с подробными объяснениями.

Бриф представляет из себя анкету с вопросами, ответы на которые определяют задачу разработки дизайна сайта.

Описание: Бриф содержит вопросы касаемо целевой группы, продуктов/услуг компании, технических и графических аспектах сайта.

Первая 2 3 Последняя

www.freetz.ru

Как составить ТЗ на разработку сайта?: публикации CASTCOM

Функциональность современного интернет-ресурса оптимизируется под задачи клиента, а дизайн и наполнение — под особенности целевой аудитории. Все эти неотъемлемые части процесса разработки регламентируются единым документом — техническим заданием или ТЗ.  Зачем нужно техническое задание?   ТЗ — обязательное приложение к любому договору на разработку программного продукта. Это документ, который формализует требования и пожелания клиента, предоставляет понятные критерии для совершения сдачи-приёма работ, а также защищает права сторон.   Заказчику гарантируется выполнение всех указанных в ТЗ требований за обозначенную стоимость, исполнителю — отсутствие кардинальных изменений на поздних этапах. Всё это позволяет избежать спорных ситуаций, конфликтов и недопонимания.  Постановка задачи исполнителю  Написание технического задания на разработку какого-либо программного продукта помогает понять, что должно получиться в результате работы.  Это особенно важно для исполнителя, который, изучив документ, сможет предоставить заказчику точную стоимость работ, спрогнозировать сроки их завершения.   ТЗ обычно составляется самим заказчиком для исполнителя. Однако иногда над этим документом работают обе стороны, если формализация требований вызывает какие-либо трудности.  Из чего состоит ТЗ?   Техническое задание состоит из нескольких блоков. Несмотря на то что ТЗ является частью договора и имеет юридическую силу, их порядок и наименования могут несколько отличаться:

  1. Глоссарий. В этом разделе приводится разъяснение всех понятий и терминов, которые будут далее использоваться в документе.
  2. Общие сведения. Это один из наиболее важных разделов. Здесь необходимо указать адрес будущего сайта, его наименование, определить порядок согласования различных вопросов. Не менее важно формализовать в этом разделе и поэтапный график выполнения работ, указать порядок согласования результатов. Однако эта информация становится известной уже после завершения написания ТЗ, так что её можно вынести и в отдельный блок, который размещают в конце документа.
  3. Цели и задачи. В данном разделе указываются способы дальнейшего использования ресурса, описывается его целевая аудитория.
  4. Программное обеспечение. Необходимо обозначить, с какими браузерами должен быть совместим новый сайт, а также какие технологии будут использоваться для его реализации.
  5. Требования к дизайну. Это довольно свободный блок, в котором заказчик формулирует свои требования к облику будущего сайта. Можно указать стилистику, используемые гарнитуры шрифтов, определить цветовую гамму и не только. Также стоит обозначить здесь необходимость использования анимированных элементов, баннеров и т. д.
  6. Требования к структуре. Данный блок обычно является самым объёмным. Здесь указываются все необходимые страницы сайта, их структура, связи между ними. Также кратко описывается предназначение и содержимое каждого раздела.
  7. CMS. Система управления контентом сайта позволяет упростить его дальнейшее наполнение и использование. Использование такого программного продукта также даёт возможность снизить стоимость и сроки разработки.
  8. Требования к контенту. Этот раздел подробно расписывается в ТЗ на создание сайтов под ключ, где разработчик должен подготовить и все необходимое наполнение. В таком случае следует определить количество, объём и формат статей, новостей, различных медиаматериалов и не только.
  9. Порядок передачи результата работы. Необходимо согласовать, в каком именно виде заказчик получит сайт. Он может быть размещен в сети, на хостинге или, например, передан на каком-либо носителе для дальнейшей работы.
  Этот перечень нельзя назвать исчерпывающим. Однако он описывает все основные блоки, без которых ТЗ не может считаться завершенным. Далее мы подробнее рассмотрим наиболее важные разделы этого документа и приведем рекомендации по их составлению.  Как составить и образец   Перед рассмотрением основополагающих вопросов, предлагаем две важные рекомендации, которые помогут сделать ТЗ более исчерпывающим и понятным.   Первое — используйте объективные или измеримые критерии. Например, если вы хотите, чтобы заголовки на сайте были зеленого цвета, лучше указать точный RGB или HEX-код. То же самое касается и CMS: лучше потратить какое-то время на поиск подходящей системы (для этого, например, можно проконсультироваться с исполнителем), чем указывать размытые термины вроде «удобная», «простая в освоении» и т. д.   Второе — максимально подробно описывайте все элементы сайта. Это поможет избежать двояких трактовок, дополнительного времени на согласование ТЗ, уточнение требований и т. д. В данном случае избыточное описание лучше недостаточного.

ТЗ как основа основ.

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

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

www.castcom.ru


Смотрите также