Техническое задание на сайт / Habr
UPD: Продолжение статьи с примером техзаданияНе так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.
То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.
Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта).
Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.
1. Обоснование необходимости ТЗ
А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.
Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:
Под конец работы приходит дизайн от заказчика, и при его просмотре становится ясно, что заказчик понимает задачу несколько иначе. А именно так:
И тут выясняется, что первоначальная оценка объема работ (и соответственно, сроков выполнения и стоимости проекта), которую сделал разработчик на основании своих умозаключений и озвучил заказчику, отличается от того, что, собственно, хочет заказчик.
Если «вычесть» одну картинку из другой, сделать, так сказать, diff, то мы получим разницу в ожиданиях заказчика и планах разработчика. И разница эта может быть весьма существенной:
И вот здесь возникает конфликт, где каждая из сторон права: заказчик не получил то, что ожидал за оговоренную цену, его пытаются «прокидать»; исполнитель же считает, что сделал все в точности с заказом, а остальные «хотелки» — это попытка «прокидать» его. Этот конфликт может решиться по-разному: либо заказчик примет, то что есть, либо разработчик доделает все бесплатно, либо обе стороны пойдут на взаимные уступки. Но в любом случае, будут пострадавшие.
Так вот, задача технического задания — это свести к минимуму разницу между представлениями двух строн: заказчика и исполнителя. Хорошее ТЗ дает маленький diff, плохое ТЗ — большой.
Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.
И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги.
Это деньги, время, потраченные нервы, испорченные отношения и т.д.
Если рассматривать две крайности, когда тех. задания просто нет, нет совсем, т.е. вообще, и мы сделали фотохостинг, а заказчик желал интернет-магазин, то diff будет равен всему проекту, и его стоимость будет равна стоимости проекта (придется выкинуть наш фотохостинг и сделать магазин). При этом стоимость ТЗ равна нулю. Другая крайность, это когда техническое задание и есть сам реализованный проект, т.е. оно детализировано полностью, т.е. до строк кода, переменных и стилей css. В этом случае diff равен нулю, а стоимость ТЗ равна стоимости проекта (т.к. ТЗ уже является реализацией). А между этими крайностями находится реальность, которая отражена на этом графике:
Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.
Голубой линией отмечена суммарная стоимость ТЗ и переделок, предстоящих по окончании работы. Как видно из графика, у этой суммарной стоимости есть минимальное значение. Т.е. с некоторой точки становится дешевле исправить в конце работы хотелки заказчика, чем доводить до совершенства ТЗ.
Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.
Описываемый ниже подход, как раз и будет претендовать на ТЗ со степенью детализации близкой к оптимальной.
2. Что в нем должно быть и чего нет. Формулировки
Техническое задание — это документ, часть договора (не важно это договор с печатями и подписями или же только устная договоренность), которая регламентирует, какие работы должны быть выполнены. Всё что описано в ТЗ должно допускать возможность объективной оценки. Т.е. должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет.
Исходя из этого получается, что в техническом задании не должно быть речи о дизайне.
Да и вообще, задание техническое, а не художественное. Дизайн не поддается объективной оценке, что одному нравится, другому — нет, и не существует объективных критериев, по которым можно сказать, хороший дизайн или нет.
Реализация дизайна с формулировкой задачи «в зеленых тонах, и что бы дерево», может быть как плохой работой, так и шедевром (и что особо печально, оба варианта могут не нравиться заказчику). Короче говоря, выполнение объективных критериев описывающих дизайн может приводить к плохому результату.
Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!».
Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы.
В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».
«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия.
Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).
Тех. задание — это документ, который нам дает заказчик (Не важно, что его пишем мы. По смыслу это задание, техническое задание, а задание дает заказчик исполнителю, т.е. нам). А из этого следует, что в ТЗ должны быть формулировки, которые указывают нам, что делать (типа «сайт должен содержать», «должна быть возможность»). В некоторых ТЗ я видел, формулировки вида «на сайте будет то-то и то-то» — это неверная формулировка, это какое-то уведомление заказчика, что будет сделано, но документ-то называется «задание», а не «уведомление».
3. Разделы ТЗ
3.1 Общие слова
Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи.
Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.3.2 Эксплуатационное. назначение
Коротко говоря, эксплуатационное назначение — это выгода, которую должен принести сайт. Вообще, чаще всего, выгода сводится к деньгам (если сайт как-то завязан на коммерции, а таких большинство), и в разделе можно было бы всегда ограничиться написанием того, что эксплуатационное назначение сайта — подзаработать деньжат, но мы не будем столь циничными. Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат». Для интернет магазина это будет продажа товара (с которого мы получим деньги), для скидочного сайта это состыковать клиентов и продавцов или поставщиков услуг (чтоб с этого получить свой процент денег), для сайта визитки — это прорекламироваться в инете (а реклама нужна для получения денег) и т.д.
3.
3 Функциональное назначение
3 Функциональное назначениеЭтот пункт уже ближе к делу. Тут краткий перечень того, какими техническими средствами мы хотим получить профит, описанный в предыдущем пункте. Например, для интернет магазина это каталог товаров, корзина заказа, страницы с информацией о доставке, возврате и о компании.
3.4 Термины и определения
Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.
Во втором случае, как правило, не нужно описывать термины специфичные для предметной области, но не имеющие отношения к реализации проекта. Например, для магазина торгующего запчастями для парусных судов, не стоит выносить в термины такое, как стаксель и ванты.
Здесь нужны расшифровки терминов, которыми оперирует заказчик и вкладывает в них некий смысл, который может быть нами истолкован неверно. Какие-то простые слова, но в данном контексте, принимающие особое значение. Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы». Ошибочное понимание такого простого термина может создать реальную проблему.
3.5 Данные и списки
Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.
Данные
Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.
Для примера, та же самая новость:
- Заголовок
- Текст
- Дата публикации
Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости.
Доработка несложная.А теперь, допустим, выясняется, что забыли добавить атрибут «Категория новости». Просто добавить одно поле в таблицу базы данных, как это было с анонсом, уже недостаточно. Придется добавлять еще одну сущность, таблицу категорий и соответствующий раздел в админке по управлению категориями новостей. Вот такого рода пункты, оставаясь незамеченными при оценке проекта, приводят к неверным результатам и, как следствие, к срыву сроков. И именно этот пункт ТЗ позволяет выявлять подобные проблемы. Т.е. лучше заметить нехватку «Категорий» на этапе написания ТЗ, чем в процессе работы.
Списки
Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта.
Но есть более тяжелые случаи.Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.
3.6 Страницы с описанием
Раздел с описанием всех страничек и того, что на них должно быть. В большинстве случаев это достаточно короткое описание, т.к. мы можем использовать отсылки к данным и спискам. Например, «на странице отображается список последних новостей». Что такое новость, мы уже описали, что такое последние новости — тоже. Если нужно, можем уточнить, что отображаются не все данные новости, а только название и анонс.
Тут будет уместно описать не только, что отображается, но и как.
Нужно ли тут описывать контент страницы? Нет не нужно. Мы пишем техническое задание. Описывая каталог, мы же не описываем все товары в нем? Наша задача описать функционал, который позволит заказчику самостоятельно заполнить контентом страницу. Если планируется наполнение сайта контентом исполнителем, это лучше вынести в отдельный документ.
Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:
Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.Возможно, стоит в тексте документа прямо указать, что первичен текст, а иллюстрации просто для облегчения понимания. Хотя этот вопрос спорный.
Для сайтов с четко выраженным разделением на админку и публичную часть, имеет смысл сгруппировать все страницы в две большие категории: публичная часть и админка. Если четкого разделения нет, нужно указать права доступа для каждой страницы.
3.7 Требования к надежности
Если планируется сайт с высокой нагрузкой, об этом стоит сказать заранее, чтоб не было конфуза. Высоконагруженный сайт вполне может потребовать специфические действия по настройке серверов или написанию кода. И выяснить, что сайт должен держать огромную нагрузку в момент сдачи проекта, не лучшее развитие ситуации.
Стоит отдельно сказать, что для надежности, необходимо настроить бэкапы, т.
к. «случаи разные бывают» и никто не застрахован от злобных хакеров которые могут попортить базу данных или хостеров, которые могут сгореть синим пламенем, как это уже бывало.
3.8 Требования к хостингу
Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают…, у меня другого хостинга нет, надо переделывать на PHP».
Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.
Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.
3.9 Наполнение контентом
Этот пункт оговаривает объем наполнения контентом. Как минимум, мы должны создать тот контент, который позволит заказчику начать эксплуатацию сайта. Ну хотя бы создать учетную запись для администратора сайта и сказать заказчику логин и пароль.
Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.
Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.
3.10 Сдача и приемка
Описание тех условий, при наступлении которых должен состояться расчет за работу.
Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.
Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно.
Хотя, думаю, тут будут и иные взгляды на эту проблему.
Заключение
Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.
Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.
Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.
Как создать правильное ТЗ на разработку сайта
Техническое задание — не просто документ, по которому можно легко разобраться, какие работы должен выполнить разработчик. Это простой способ выяснить, чего хочет заказчик, зафиксировать его требования, найти взаимопонимание, а не угадывать. Отличная страховка для обеих сторон: веб-студия не делает лишней или ненужной работы, а клиент не ждет того, что не прописано в ТЗ.
Кому требуется составлять техническое задание?
- разработчикам сайтов
- верстальщикам
- веб-дизайнерам
- проект-менеджерам
- бизнесменам, планирующим разработку сайта
Что входит в техническое задание
Зависит от того, какой тип сайта выбрал заказчик, но техническое задание для лендинга будет отличаться от ТЗ для интернет-магазина.
ТЗ составляет тот, кто разрабатывает сайт, а не заказчик! Но без ответов на вопросы и предоставления информации от того, кто его ждет, техзадание получится нерабочим и бесполезным.
Тип сайта и задачи, которые он решает
Если вы скажете, что нужен сайт-визитка для салона красоты или интернет-магазин для шоурума — это уже будет начало разработки ТЗ.
Рассказ о компании, товаре или услугах, описание целевой аудитории
От этого зависит интерфейс, дизайн, подача контента — вам нужен сайт, который будет удобен и понятен для пользователя. Качественный сайт не вызывает раздражения, что невозможно что-либо найти, а путь с его главной страницы до решения вопроса пользователя занимает всего несколько кликов.
Объяснение, почему на этом этапе развития бизнеса было принято решение разработать сайт
Недостаточно прибыли? Нужно срочно выйти в онлайн, так как в офлайне дела идут не очень? Или наоборот: все хорошо, но надо еще лучше? Причины разные, и они тоже влияют на разаработку сайта.
Идеи и примеры хороших (с точки зрения заказчика) сайтов
Процесс разработки техзадания ускорится, если заказчик принимает активное участие: накидает свои “хотелки”, референсы сайтов, которые ему нравятся, расскажет, в каком стиле комфортнее его аудитории воспринимать информацию.
Рекомендации исполнителю. Идеальное ТЗ не обойдется без:
- понятных однозначных формулировок;
Заказчик и разработчик должны правильно понять друг друга. Не приукрашивайте ТЗ качественными прилагательными, такими, как “красивый”, “современный”, так как это слишком субъективно. У каждого свое понимание того, что сейчас называть красивым или современным.
- точного контента, без размытых фраз;
Например, если вы пишите, что сайт выдерживает большие нагрузки, то добавьте конкретную деталь: на сайте может находиться 100 тысяч посетителей одновременно.
- расшифровки профессиональных терминов;
Самое важное в техзадании — сделать его понятным абсолютно для всех, кому придется его читать и брать во внимание.
Объясните, что такое CMS так, чтобы понял школьник младших классов.
- подробного описания, какие инструменты и библиотеки будут использоваться для разработки, какую админку одобрил заказчик;
Отдельным пунктом вынесите требования к хостингу (уточните, где у клиента сервер). Все это необходимо, чтобы потом у заказчика не возникало, например, вопроса “Почему сайт не на Битрикс, а на Вордпресс?”.
- описания требований к работе сайта;
Здесь пишем, в каких браузерах должен работать сайт, типы мобильных устройств, в которых он должен отображаться корректно, скорость загрузки, которая в идеале должна составлять не более 3 секунд, защита от хакеров и т.п.
- подробного описания структуры сайта;
Это лучше сделать еще до того, как отрисован дизайн и начата верстка. Все страницы сайта должны быть полностью описаны: элементы и их расположение, контент, как одна страница взаимосвязана с другой. Удобный способ показать структуру клиенту — прототип.
Заказчик увидит интерфейс будущего сайта и даст обратную связь: поймет, что ему нравится, а что нужно изменить.
- сценариев использования будущего сайта;
Нужно прописать схемы взаимодействия пользователя с сайтом, чтобы на начальном этапе разработки не потерять какое-либо важное звено: описание действия пользователя, ответ со стороны сайта и результат.
- контента и дизайна;
Определитесь, кто будет предоставлять контент: одни разработчики делают сайт сразу с ним, а для других его нужно подготовить самостоятельно. Третьи подготовят контент за дополнительную плату. Договоритесь заранее и о том, какой дизайн одобрил заказчик, включая шрифты.
Каждый этап разработки должен быть ограничен временем — сроки выполнения тоже указываются в ТЗ.
Есть прецеденты, когда даже без технического задания заказчикам и разработчикам удавалось понять другу друга так, что результат радовал всех, но это, скорее, исключение, нежели правило.
Поэтому разумнее всего начинать разработку сайта с составления грамотного ТЗ.
ТЗ на разработку сайта. Коротко о главном
Несмотря на то, что обычно идея создать сайт приходит одному человеку, на деле создание сайта — это коллективное творчество. В данной статье рассмотрим принципы создания технического задания на разработку сайта, что этому процессу предшествует и кто в нем задействован.
Не будем ходить вокруг да около: вы решили создать сайт, что делать в первую очередь?
1. Выбрать название сайта.
2. Определить и описать его назначение (он же вид сайта, сайт-визитка, информационный сайт, интернет-магазин, каталог, блог, форум). Обычно с этим пунктом человек, который готов заказать сайт, уже определился.
3. Структура сайта.
Как минимум шапка, контент, футер, дальше 1 и более сайдбаров (боковые области, в которых обычно располагается меню, блоки типа «последние комментарии/отзывы/новости», блоки «подписка», «поиск» и т.
п.).
Также может быть несколько футеров и шапок. Вот на этом этапе обычно требуется помощь специалистов. Можно, конечно, пуститься в мир фантазии с дизайнером и «забабахать» шапку на весь первый экран, с красивыми картинками, слайдшоу и даже видео… И программист(ы) воплотят в жизнь этот ваш каприз… А потом подключатся юзабилитисты и скажут все «снести».
Также, продумывая структуру сайта, нужно определиться, будет сайт статическим, резиновым либо адаптивным (адаптироваться под разные устройства).
4. Дизайн.
К дизайнеру прихватите наброски из предыдущего пункта. А лучше даже не наброски, а сформированные прототипы. О программах, с помощью которых можно создать прототип, можно почитать тут.
Со стилем дизайна можно определиться самому, а можно попросить дизайнера сделать несколько вариантов одной страницы (обычно это главная страница сайта). После этого выбрать наиболее подходящий и дальше добавлять определенные элементы, согласно структуре и вашим пожеланиям (модальные окна, карусели, слайдеры, баннеры, формы, поведение ссылок, элементов навигации и т.
д.).
В процессе создания дизайна или когда вы уже имеете на руках макеты 1-2 страниц, можно показать их программисту, чтобы он мог при необходимости задать вопросы дизайнеру, особенно когда дело касается динамических элементов. Дальше готовые макеты можно передавать верстальщику.
Вот теперь, собственно, пора составлять ТЗ, используя всю информацию и наработки по описанным выше пунктам.
С ним мы идем к программисту и описываем все этапы разработки сайта, сроки их реализации и стоимость — это и будет ТЗ.
Структура ТЗ может быть следующей:
(«может быть», т. к. это не правила составления ТЗ, а рекомендации, значит, в зависимости от ситуации могут быть дополнительные пункты, а некоторых может не быть)
1. Общая информация о сайте. Согласно выбранному имени мы выбираем доменное имя. Описываем в свободной форме назначение сайта.
2. Покупка и настройка хостинга. Стоить отметить, что часто хостинговые компании предлагают в подарок доменные имена и возможность приобрести у них платные CMS на выгодных условиях..png)
Либо у них доступна установка большинства бесплатных CMS с простой установкой, обновлением, системой резервного копирования и т.д. Поэтому иногда есть смысл заняться покупкой хостинга на первых порах разработки сайта.
Еще возможен вариант, когда сайт на время разработки находится на тестовом сервере, принадлежащем компании, которая занимается разработкой вашего сайта, а на хостинг переносится, когда уже полностью или частично готов. Это обсуждается на этапе написания ТЗ.
3. Список терминов, используемых при разработке сайта. Для взаимопонимания, чтобы не называть потом элементы дизайна «штучками» 🙂
4. Описываем структуру сайта. В данном пункте перечисляются и расписываются разделы и подразделы сайта, статические и динамические страницы, навигация по сайту.
5. Верстка. Лучше всего, когда версткой дизайна занимается верстальщик, которому пишут свое ТЗ (ТЗ на верстку). А затем, когда верстка готова, программисту передают макет с элементами дизайна и сверстанные страницы.
6. Функциональные характеристики сайта. Определяемся вместе с программистом, какую CMS используем, либо ее разрабатывает программист (группа программистов). Возможно, для ваших нужд хватит и html+css+javascript. Описываем подробно, какой функционал должен быть на сайте, согласно назначению и структуре сайта. Это могут быть как обычные формы и фильтры, постраничная навигация, так и более серьезные инструменты и функционал, вроде системы резервного копирования, модуля массовой загрузки файлов, если на сайте, например, предусмотрена фотогалерея.
Также в этом разделе необходимо описать количество пользователей и разграничения их прав, если это необходимо для вашего вида сайта, описать, будет ли сайт мультиязычным, и если да, то какие языковые версии он будет поддерживать. Т.е. в данном пункте расписывается вся основная работа программиста.
Еще стоит отметить, что лучше не придумывать ничего «сверху» того дизайна, который у вас уже разработан.
7.
Описание страниц сайта, всех элементов, которые на них должны быть, их поведение. Описывают обычно все типы страниц. Т.е. если у вас сайт-каталог, то описать необходимо главную страницу, страницу раздела каталога, страницу карточки товара, а также информационные страницы: условия доставки, оплаты, контакты и т.д. Чем подробнее, тем лучше, и желательно со скриншотами и ссылками на другие ресурсы, где вы подобное видели.
8. Наполнение сайта: тексты, статьи, фотографии в хорошем качестве (чем выше качество, тем лучше). Тоже важный момент. Некачественные фото, так же, как и наполнение сайта плохо сверстанными статьями, могут вызвать неприятное впечатление у ваших будущих посетителей. Притом, что движок может быть идеальным и хостинг быстрым.
Но, вообще, это опциональный пункт ТЗ, т.е. его может и не быть в случае, если наполнять сайт вы планируете в дальнейшем сами. Тогда необходимо позаботиться о том, чтобы было удобно наполнять сайт — обсудить установку и настройку визуального редактора.
9. Тестирование и проверка сайта на соответствие ТЗ заказчиком. На данный пункт выделяется определенное время, обычно несколько дней, за которые заказчик может изучить систему: соответствие и наличие всех инструментов, их работу.
Сообщите о возможных несоответствиях. После программистом вносятся правки, если несоответствия были выявлены.
10. Перенос сайта на хостинг.
Случается, что после переноса на хостинг, когда клиент более плотно начинает работать с сайтом, он находит какие-то недоработки либо какие-то инструменты могут оказаться нерабочими/неудобными. В таком случае в ТЗ необходимо оговорить возможность поддержки сайта компанией-разработчиком. Нужно четко описать, какие виды доработок входят в эту поддержку, какие нет. Например, установка/настройка дополнительного функционала, естественно, будет оплачиваемой. Если же это действительно ошибка программиста и какой-то функционал не работает либо работает некорректно, такого вида доработки могут выполняться программистом без дополнительной платы.
Примерно так выглядит основной набор разделов ТЗ на создание сайта.
Составление ТЗ на разработку сайта – не быстрая и достаточно трудоемкая задача, но от того, насколько подробным будет ТЗ и как серьезно вы подойдете к его составлению, зависит результат.
Подписаться на рассылкуЕще по теме:
Анна Себова
Web-разработчик
Пришла с небольшими знаниями в настройке, установке и принципах работы нескольких CMS. С тех пор «обросла» знаниями и опытом в разработке сайтов на следующих CMS, PHP и JS/CSS-фреймворках: WordPress, Joomla, Bitrix, MODx, Drupal, Codeigniter, Laravel, Bootstrap.
Разрабатывает, дорабатывает, перерабатывает и адаптирует сайты.
Девиз: если очень захотеть, можно в космос полететь
Оцените мою статью:
Есть вопросы?
Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.
ТЗ на разработку сайта — что важно знать Заказчику
Грамотно составленное ТЗ бережет время и нервы.
Оно позволяет максимально эффективно перевести желания Заказчика и рекомендации маркетологов в беспристрастные технические формулировки.
1. Что такое ТЗ на разработку сайта: определение, факты
Техническое задание на разработку сайта (ТЗ) — это документ, который конкретизирует многочисленные требования к будущему веб-ресурсу. В нем указываются пожелания к маркетинговой составляющей сайта, технической функциональности и особенностям дизайна.
Очень важно подойти к его составлению предельно тщательно, сформулировав свои требования и предпочтения:
- предельно конкретно;
- подробно;
- в окончательной форме.
Помните: просить переделать ТЗ на других этапах — то же самое, что предлагать заменить фундамент уже построенного дома. Несвоевременная «смена курса» в веб-разработке всегда заканчивается недопониманиями, удорожанием проекта и жестким срывом сроков.
Какого-либо обязательного ГОСТа для составления ТЗ на разработку сайта нет.
Однако, по глубине и строгости структуры техзадания нередко напоминают описания государственных стандартов.
Объем ТЗ зависит от сложности вашего веб-ресурса — богатства функционала и количества контента. Если ТЗ для сайта-визитки может ограничиваться 20 страницами, то техническое задание для какого-нибудь сложного интернет-магазина с личным кабинетом и обширным «внутряком» занимает более 100 страниц.
При этом, важно помнить: техзадание — полноценный документ. ТЗ подписывается обеими сторонами и служит дополнением к договору оказания услуг.
2. Состав технического задания
Далее мы разберем некоторые аспекты, которые должны найти отражение в техническом задании на разработку сайта. Вот оглавление ТЗ одного из разработанных нами веб-ресурсов:
Задачи
В техническом задании обязательно должна быть указана цель создания сайта.
Структура
В ТЗ следует отразить иерархическую структуру будущего веб-ресурса: ожидаемые разделы и взаимосвязь между ними.
Дизайн
Если дизайн сайта должен быть выполнен, основываясь на предписания вашего брендбука, указываем это. Если же у вас имеются определенные пожелания, касающиеся цветовой гаммы или следования определенному тренду, важно также это своевременно сообщить и зафиксировать.
Например: «в оформлении сайта предпочтительно использовать светлые тона, придерживаться минимализма, кнопки должны быть с закругленными краями и т. д.»
Описание конкретных страниц и блоков.
В техзадании также следует отразить, какой функционал и особенности компоновки ожидаются от каждой конкретной страницы.
Причем нужно не просто написать формулировку наподобие: «задача главной страницы — донести по пользователя основную информацию о нашем предложении и, по возможности тут же его сконвертить», а детально описать функции и особенности каждого блока.
Давайте рассмотрим это на примере блока «Подвал» (футер):
Вот описание этого блока из технического задания:
В «Подвале» с левой стороны размещен: логотип компании со слоганом, под слоганом выведены: копирайт, с годом и названием компании, ИНН/КПП компании.
Правее выведены ссылки: «Карта сайта», «Политика конфиденциальности», ниже текстовое поле, с текстом и ссылкой «Напишите нам», при нажатии пользователем на ссылку «Напишите нам» всплывает форма обратной связи:
После успешного заполнения обязательных полей и нажатия на кнопку «Отправить», всплывает сообщение с текстовым описанием: «Спасибо за обращение! Наши специалисты свяжутся с вами в ближайшее время». Данные из формы должны отправляться на e-mail администратора и сохраняться в базе данных сайта в табличном виде, для дальнейшего экспорта в Excel.
Правее выведены номера телефонов компании, адрес электронной почты, и ссылки на социальные сети, с правой стороны выведены адреса компании, при клике пользователь перенаправляется на страницу «Контакты».
Как видите, техзадание не только определяет внешний вид сайта, но и сообщает:
- что последует после взаимодействия пользователя с каким-либо интерактивным элементом;
- что увидит пользователь;
- куда будут переданы высланные им данные и т. д.
Типичный сайт состоит из десятков различных блоков и каждый из них настолько же подробно разбирается в ТЗ.
Технические требования к сайту.
Есть множество чисто технических «недоделок», которые могут понизить эффективность работы сайта.
Из-за пары неправильно прописанных тегов верстка сайта может расползтись на каком-нибудь устройстве или экране.
Из-за неправильных настроек на хостинге ваш сайт оказывается недоступен.
Из-за дублирования информации в метатегах осложняется дальнейшее SEO-продвижение веб-ресурса и т. д.
Поэтому обязательства веб-разработчика в этом плане очень жестко прописываются.
То есть, ТЗ это сложный и многосторонний документ, требующий вдумчивого подхода и активного сотрудничества проект-менеджера с Заказчиком.
3. Ошибки при составлении технического задания
За 7 лет практики веб-разработки мы выделили три распространенные ошибки Заказчиков, связанные с их отношением к техническому заданию:
1. Неоправданная спешка
Некоторые Заказчики ни к месту проявляют нетерпение: «мне бы сайт побыстрее, а эти маркетологи такие маркетологи — целую книжку написали вместо того, чтобы дело уже делать!». Это роковая ошибка, без преувеличения. ТЗ как раз и делается для того, чтобы сэкономить время, сделать сайт быстрее и дешевле.
Когда ТЗ отсутствует, возникает множество хаотичных правок на разрабатываемом сайте. Заказчик и агентство бомбят друг друга сотнями писем и сообщений в мессенджерах. Время, заложенное в изначальную стоимость проекта, распыляется на множество дополнительных коммуникаций и переделок уже сделанного.
В результате возникает ситуация: оплаченное время закончилось, веб-студия работает в ноль. Тут уже два варианта дальше: либо у Заказчика попросят дополнительной оплаты, либо сделают все кое-как, на скорую руку.
Поэтому вы, как Заказчик, очень заинтересованы в подробном, грамотно составленном ТЗ.
2. Правки сверх ТЗ
Некоторые Заказчики относятся к ТЗ, как некоей условности. Когда сайт уже готов, они просят внести какие-либо изменения в проект. Например: «ребята, поменяйте функционал каталога на функционал интернет-магазина, я передумал». Вот тут и заключается один из главных камней преткновения между студией и Заказчиком. Очень часто изменения, которые визуально кажутся не столь существенными, означают дополнительные часы работы дизайнера, верстальщика, программиста и т. д. Эти часы работы нужно оплачивать…
3. Несерьезное отношение
ТЗ — это дополнение к договору, защищающее ваши права. Соответственно, до тех пор, пока сайт не соответствует указанным в ТЗ параметрам, у вас имеется рычаг давления на веб-разработчика. Глупо от него отказываться, не так ли?
Мы надеемся, что вы избежите вышеописанных заблуждений. В конце концов, раз вы дочитали эту сухую статью до этого места, скорее всего вы — вдумчивый и внимательный человек. А значит, вы оцените по достоинству системный, скрупулезный подход к делу, характерный для нашей компании.
4. Особенности нашего подхода к составлению ТЗ
Для технических заданий создаваемых в нашем агентстве сайтов характерен мощный маркетинговый бэкграунд. Когда у нас заказывают разработку сайта, мы учитываем, в рамках какой маркетинговой стратегии будет использоваться этот веб-ресурс, каковы дальнейшие возможности его развития. Так, например, при разработке интернет-магазинов мы стараемся думать на несколько шагов вперед — нам важно не только вовремя сдать вам сам сайт, но и заложить фундамент для его:
- дальнейшего seo-продвижения;
- автоматизации;
- различных интеграций с системами учета товаров и т. д.
Именно поэтому этапу составления технического задания у нас уделяется особое внимания. Независимо от того, будете ли вы сотрудничать с нами дальше или нет, мы подходим к разработке сайта таким образом, будто уверены, что мы потом будем отвечать за вашу конечную прибыль. А тут уж без жесткого планирования никуда.
Обращайтесь в агентство комплексного интернет-маркетинга Marketing Up. Как и вы, мы играем «в долгую»!
Техническое задание на разработку сайта: техническая оптимизация для SEO-продвижения
Система администрирования сайта (CMS, ЦМС, админка): важный момент при создании. Систем существует большое количество, есть даже «самописные», то есть программисты могут создать что-то свое. Но нужно понимать, что не все админки могут быть хорошо, удобно и понятно редактируемыми. Какие-то могут иметь ограниченный функционал: если вдруг мы захотим что-то добавить на сайте, система может не поддерживать такую возможно. В этом случае могут быть два варианта:
- либо делать «костыль» на сайте, то есть программист дописывает и внедряет дополнительный программный код, что может быть дорого и сложно,
- либо сайт переносится на другую систему администрирования, которая поддерживает те функции, которые вам нужны. А это опять затраты сил и денег.
Поэтому на этапе проектирования нужно проанализировать и решить, какую систему админки выбрать, чтобы она могла делать все, что вам потребуется.
CMS ориентируются на определенные задачи. Для интернет-магазинов они свои, для блогов и корпоративных сайтов тоже есть определенные системы. Есть универсальные, которые подойдут под любую тематику. С такими платформами можно решить множество задач, благодаря большому набору плагинов. Поэтому так важно выбрать правильную.
Обзор хороших систем администрирования сайта, которые мы рекомендуем:
- 1С-Битрикс. Платная CMS. Многофункциональная система, подходит для больших сайтов, в частности для интернет-магазинов с большим каталогом товаров и интеграцией с 1С. Высокая надежность, безопасность, стабильное обновление.
- MODx (МОДикс). Бесплатная система администрирования сайта. Хорошо подходит для сайтов услуг и небольших интернет-магазинов.
- UMI.CMS. Удобный конструктор сайтов. На этой системе можно делать сайты любого направления: от небольших сайтов услуг до огромных интернет магазинов. Очень удобна в администрировании.
- WordPress (Вордпресс). Бесплатная CMS, популярна в рунете. Русифицированная система, легко устанавливается. Наполнение сайта информацией не требует дополнительных знаний. Часто используется как движок для блогов. Не рекомендуем для коммерческих сайтов, особенно интернет-магазинов.
Особняком стоят фреймоворки, например Yii, Laravel и другие — это гибкие системы, на которых можно реализовать что угодно под нужды бизнеса. Успешность функционирования зависит от квалификации разработчиков, как программистов, так и проектировщиков.
Техническое задание на разработку сайта, как составть ТЗ для создания, примеры, образцы и шаблоны написания
Когда клиент получает готовый результат, еще не значит, что он остается им доволен. Многих заказчиков при виде итоговой работы не устраивает дизайнерская мысль, текстовое наполнение, расположение элементов или обилие совершенно ненужной информации. Чтобы избежать подобных несоответствий ожиданиям, необходимо правильно составить техническое задание на разработку сайта.
Если техническое задания для разработки сайта было сформулировано неверно, а программисты не хотят переделывать выполненные работы, то специалисты “Студия 17” придут вам на помощь! “Студия 17” занимается разработкой сайтов в нуля и оказывает оперативную и качественную поддержку проектов.
Что собой представляет техзадание
Не имеет значения, кто именно возьмется за создание проекта: сам пользователь, его знакомый, сторонний фрилансер, профильная компания — ТЗ должно быть. Это своего рода документ, подтверждающий выполнение строго определенных условий. При любом даже незначительном несоответствии разработчику можно будет указать на ошибки и потребовать их исправления.
Для чего оно необходимо
На базе таких прописанных установок и создают сетевые ресурсы. От того, насколько подробно и грамотно клиент изложит свои пожелания и требования, напрямую зависит конечный результат. Если заказчик не подходит серьезно к его формированию, то и на успешное разрешение своего вопроса может особо не рассчитывать.
Техзадание — закон, который не допускает пространных трактовок и неоднозначности. Ведь все, что в нем не задано, исполнитель вправе сделать, отталкиваясь от собственных измышлений.
Кто должен заниматься составлением ТЗ, написанием технического задания для сайта
Составлять его может как сам клиент, так и тот, кто берется выполнить работу. При этом вкладывает свое понимание в данный процесс. Вполне естественно, ведь и требования, и подход к реализации задуманного для каждого из них свои.
Так, заказчик в первую очередь пытается сделать следующее:
- определить, каким он хочет видеть готовый веб-ресурс;
- зафиксировать размер предстоящих затрат;
- установить контроль над выполнением задачи.
Разработчик стремится:
- понять его пожелания и выполнить поручение в точности с установками;
- по возможности избежать последующих корректировочных действий.
По существу, они оба нацелены получить хороший результат, предельно ясно поняв друг друга в самом начале.
Бриф на разработку ресурса
Выясняя, как написать техническое задание, ТЗ для сайта по примерам и образцам тех заданий, помните — ответственный исполнитель не заинтересован в возникновении недопониманий. Скорее всего, он сам предложит составить нужный документ для работы. Не исключено, что и сделает все самостоятельно. При этом — будьте внимательны. Не утверждайте, не ознакомившись детально с содержимым. В противном случае рискуете получить в итоге совсем не то что нужно.
Составление возможно исключительно с учетом пожеланий заказчика. Иначе взаимовыгодное сотрудничество так и окажется недосягаемой высотой для обеих сторон. В этом деле может ощутимо посодействовать бриф. Он представляет собой специальную анкету, содержащую максимально подробные вопросы о предстоящем проекте. Отвечая на них предельно развернуто, клиент предоставляет разработчику своего рода техзадачу, только в ином виде.
Если какие-либо пункты в анкетировании окажутся непонятными — смело спрашивайте и уточняйте. Только так удастся избежать недопонимания. Лучше лишний раз переспросить, заострить внимание на деталях, чем впоследствии получить разочарование.
Четкость формулировок
Рассматривая примеры технических заданий, образцы ТЗ на создание сайта, помните — качественное техзадание всегда сформулировано максимально четко. Только конкретика и подробное расписывание каждого пункта может гарантировать достойный результат при выполнении работы.
Обговаривайте все до мелочей. Обсудите, какие инструменты будут задействоваться в процессе, рассмотрите требования к хостингу и т.д. Сразу укажите, что создаваемый веб-ресурс должен будет эффективно функционировать во всех известных браузерах, быть адаптированным к различным устройствам, устойчивым к перегрузкам и хакерским атакам.
Структура техзадачи
Хорошенько подумайте, какие веб-страницы предстоит сделать и решите вопрос с навигацией. Для многих наиболее удобными и простыми в восприятии являются блок-схемы, выполненные в XMind. Если же считаете, что это только затянет время составления — просто сформируйте перечень в Word.
Верным решением окажется предварительный сбор семантического ядра. Именно оно в перспективе поспособствует правильному формированию структуры и подразделов на базе настоящих запросов пользователей, выделенных согласно сегментации.
Из чего состоит техническое задание на разработку сайта: образец
Ниже можно рассмотреть пример правильно составленного техзадания:
| Пункты ТЗ | О чем писать | Варианты заполнения |
| БИЗНЕС-ТРЕБОВАНИЯ | ||
| Сведения об организации | Наименование, изделия, услуги, вид деятельности, конкуренты, достижения, дата регистрации. | Компания «Молтехникс». Производство оборудования по переработке молока. Основана в 2012 г. Обладатель премии «Товар года». Конкуренцию составляют: «Млечный путь», «Ферм Строй». |
| Целевая аудитория | Как можно подробнее опишите контингент, который планируете видеть на страницах. Укажите их предполагаемое место жительства, уровень дохода, возрастные характеристики. | Индивидуальные предприниматели, выпускающие молочную продукцию. Фермерские хозяйства. Мужчины и женщины в возрасте от 30 до 55 лет. Занимаются сельскохозяйственной деятельностью, проживают на территории Российской Федерации. Имеют средний доход и выше. |
| Цели веб-ресурса | Что Вы хотите получить от посетителей своей страницы? Оформить заказ, связаться с сотрудником компании по внутренней связи, подписаться на рассылку. Когда цель не одна, лучше обозначить все сразу. Данный пункт можно смело назвать основным. Именно на базе него строится формирование дизайна, функциональных возможностей и осуществляется наполнение контентом. |
|
| Анализ имеющегося сайта | Предоставьте на него ссылку и расскажите о плюсах и минусах по вашему мнению. | Имеющиеся сведения на ресурсе нельзя обновлять или редактировать. Интерфейс слишком сложен для пользователей. |
| НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ | ||
| Начальная структура | Что из основного обязано быть в наличии. | Домашняя (сведения об организации, место деятельности, проводимые акции). Каталог; Блог; Новости; Контакты. |
| Структурирование страниц | Какие детали должны быть и примерное место их размещения. | Поисковая строка, Телефон для связи, окно диалога с оператором компании, перечень проводимых акционных мероприятий. Сбоку список подразделов каталога, форма для подписки. |
| Пожелания по оформлению и дизайну | Предпочтительный цвет, стилистика, шрифты. | Веб-сайт больше в дружеском стиле. Основная палитра: синий, голубой, бирюзовый, белый. Верх и низ темнее, центр светлый. В качестве изображений фотографии, иллюстрирующие деятельность. |
| Прилагающиеся наработки | Ссылки на образцовые ресурсы, фото, буклеты, журналы. | Выделено архивом. |
| Разрешение и изображение | Обозначьте, с какого устройства должны просматриваться страницы. | Мониторы ПК от 19 до 27 дюймов; Ноутбуки от 15,6 до 17,3; Смартфоны от 3,5 до 6; Планшеты от 7 до 12. |
| Целесообразность мобильной версии | Нужна. | |
| Приблизительные перечень модулей | Укажите, что хотите видеть на своей странице. Фильтры каталога, возможность сделать онлайн-заказ и т.д. | Распределение товарных позиций по стоимости, в алфавитном порядке. Консультация предполагаемым покупателям. |
| Администрирование | Опишите, какие корректировки Вы должны вносить самостоятельно. Выясните как именно это делается. | Доступны все действия с товарными карточками, возможность публикации новостей, акционных предложений. |
| Подключение платежных систем | Укажите предпочтительные. | Необходима консультация разработчика. |
| Возможности интеграции | Интегрирование с Мегапланом и 1С. | |
| ИНТЕРНЕТ-РЕСУРСЫ | ||
| Обзор | Оптимально будет привести примеры в виде ссылок, что нравится, а что категорически нет. | adme.ru— меню tobiafran.com — анимация загрузки anotherstate.co — шрифты. |
| ДОПОЛНЕНИЯ | ||
| Вопросы к исполнителю | Если что-то непонятно, сразу спрашивайте в письменной форме. Так удастся избежать недопонимания. | |
| Пожелания | В эту графу следует внести все, что не было затронуто в предыдущих позициях. |
Предпроектное проектирование
Рассмотрев шаблон технического задания, ТЗ на разработку сайта как пример, следует перейти к следующему пункту. По факту к техзаданию он не относится, но ничем не уступает в значимости. После того, как сформирован бриф, утверждена техзадача и изучены дополнительные материалы (исполнителем), он приступает к предварительному построению. Создает базу-скелет будущего ресурса.
Осуществляется данная операция после соглашения, так как разработчику необходимо должным образом изучить сведения о компании, ее конкурентах и ситуации на рынке. Процесс трудоемкий, требующий немало времени.
Примерное составление (структура)
Чтобы наглядно представить, как выглядит оптимальное техзадание, стоит рассмотреть пример технического задания на разработку и изготовление интернет сайта.
«Домашняя» (главная) страница
- Отдел «Меню» с основными разделами и всплывающим перечнем подразделов.
- Логотип и рекламный лозунг (слоган).
- «Главная».
- «Проекты».
- «Каталог изделий» с выдаваемым списком составляющих.
- «Деятельность».
- «Об организации».
- «Клиентам».
- «Информация».
- «Контактные данные».
- Ссылка на скачивание в формате pdf.
- Телефонный номер компании.
- Клавиша «Заказ звонка».
- Отдел «Слайдер» с фото в ширину дисплея и кнопкой обратной связи.
- Блок «Преимущества».
- «Товары» с обязательным описанием плюсов.
- «Организация в цифрах» с указанием достижений, продаваемых объемов и т.д.
- «Видеоруководства».
- «Подвал».
- Контактная информация.
- Ссылки на соцсети компании.
Лайфхаки как написать, составить тз для сайта
Эти полезные советы окажутся кстати при составлении техзадания и брифа. Пользуясь ими, можно существенно облегчить процесс разработки ресурса.
Где взять образцовые варианты
Неплохим подспорьем станут демонстрируемые на сетевых площадках рейтинги и ТОП сборники. Так, отлично подойдет allawards.ru. На его страницах собраны лучшие по части дизайнерского воплощения, неординарности и эффективности платформы.
Параллельно стоит сформировать собственные подборки с понравившимися референсами. Будет очень удобно пользоваться ими в перспективе.
Не менее полезная идея — посмотреть на иностранные веб-ресурсы с соответствующей тематикой. Наши заграничные друзья используют более продвинутые технологии. Из их работ можно почерпнуть немало интересного.
Как определить цветовую гамму
Исследуя примеры техзаданий на разработку сайтов и образцы ТЗ, уделите данному вопросу не меньшее внимание. Очень хорошо, когда у Вас на руках есть подготовленный ранее бренд-бук. Если его нет, то опираться исключительно на собственный вкус в отношении цвета — большая ошибка. Такими темпами Вы рискуете стать единственным посетителем своего ресурса.
Не поленитесь изучить позиции восприятия людьми различных оттенков в рекламе.
Как подобрать шрифты
Немаловажный аспект. От их качества (читаемости) и соответствия общему дизайну во многом зависит понимание информации пользователями. Обязательно пропишите в техзадании конкретные пожелания. Коллекцию Word можете смело не рассматривать. Все, что в ней имеется, уже многократно использовано до Вас. Лучше обратите внимание на сетевую библиотеку allfont.ru.
Как писать шаблон ТЗ, составлять техзадание для сайта правильно: основные ошибки
Даже имея перед собой приличные образцы, можно допустить ряд досадных оплошностей. Чтобы этого не произошло, следует о некоторых из них (которые чаще всего встречаются в работе) просто знать.
Не указано отведенное время
Нередко бывает так, что проект составлен очень подробно, с учетом всех нюансов и тонкостей, а период, отведенный на реализацию вашей идеи, не проставлен. Такое положение может привести к существенному затягиванию сроков выполнения задачи. О временных рамках дедлайна лучше написать в техзадаче или прямо в шапке заполняемой формы.
Потеряны данные доступа
Пожалуй, это самая досадная оплошность, которую можно допустить в решении вопроса: как составить ТЗ задание на разработку сайта. Как правило, регистрацией домена и хостинга ресурса занимается исполнитель. Как только он выполняет свою работу, о кодах и ключах попросту забывает. Полезная привычка фиксировать сведения, к сожалению, имеется не у всех.
В определенный момент площадка может перестать функционировать (из-за сбоев в продлении или по другим техническим проблемам). В момент восстановления деятельности обязательно потребуются данные, которые задавались изначально. Не имея их на руках, можно лишиться собственного ресурса. Не забывайте взять их у разработчика сразу после выполнения заказа и спрятать в надежном месте. Не лишено смысла сменить их на другие, человеческий фактор еще никто не отменял.
Отсутствие наглядности
Проблема обычно заключается в разнице понимания. Клиент вкладывает в определенные слова собственный смысл, а исполнитель представляет сказанное им совершенно иначе. Продемонстрировать это можно на примере техзадания на создание сайта, в котором заказчик попросил изобразить абстракцию. Для одного она выступает в роли полупрозрачных бесформенных фигур, другому представляется в виде радужных волн или кругов (и так до бесконечности). У каждого свое видение — так устроен наш мир. Гораздо правильнее сразу предоставить веб-специалисту образцы конкретно вашей абстрактной мысли. От того, насколько верно он ее увидит, зависит конечный результат.
Качественные прилагательные
При составлении техзадачи старайтесь избегать использования слов, обозначающих неточные характеристики предметов. Например: красивый, умный, сильный, современный и т.д. Помните — только конкретика: «На два оттенка темнее», «Укоротить на 4 см», «Округлые края у кнопки». Опять же, у каждого человека собственное представление о красоте, силе, современности и иных сравнительных параметрах.
«На усмотрение исполнителя»
Особо опасный момент, о котором нельзя забывать. Не оставляйте незаполненных пунктов в ТЗ, не стоит полагаться на телепатические способности разработчика. Если ему не предоставлены четкие требования, а дана возможность сделать работу по своему разумению — приготовьтесь ловить результат, в корне отличный от того, на что вы рассчитывали. Даже когда веб-специалист выполнит все идеально с технической стороны, итог может не понравится просто субъективно.
Заключение
Стоит еще раз напомнить, что каждому, кто собирается заказывать разработку веб-ресурса, следует знать, как написать техзадание на создание сайта правильно. Ведь грамотно составленное ТЗ — это гарантия хорошего взаимопонимания и качественной реализации идеи.
|
▷ 3Tz.сайт Статистика веб-сайта и анализ трафика
Сводка по домену
| Глобальный рейтинг трафика | нет данных |
|---|---|
| Предполагаемые посетители | нет данных |
| Предполагаемые просмотры страниц | нет |
| нет данных | |
| Возраст домена | нет |
| IP-адрес | |
| Расположение веб-сервера | США |
Часто задаваемые вопросы (FAQ)
Что такое 3Tz.серверы имён сайта? |
Какой IP-адрес разрешает 3Tz.site? |
В какой стране расположены серверы 3Tz.site?3Tz.site имеет серверы, расположенные в США . |
Какое программное обеспечение веб-сервера использует 3Tz.site?3Tz.site работает на веб-сервере « nginx / 1.11.5 «. |
Запись домена WHOIS
| Доменное имя | 3tz.site |
|---|---|
| Расширение домена | site |
| Домен верхнего уровня (TLD) | .site |
| TLD Тип | Общий домен верхнего уровня (gTLD) | DotSite Inc. |
| .site WHOIS Server | whois.nic.site |
| URL-адрес реестра .site | http://www.radixregistry.com |
IP-адрес и расположение сервера
Лос-Анджелес, Калифорния, США
| Местоположение | Лос-Анджелес, Калифорния, , США |
|---|---|
| Latitude | 34.0549/34 ° 3′17 ″ с.ш. |
| Долгота | -118,2578 / 118 ° 15′28 ″ з.д. |
| Часовой пояс | Америка / Лос-Анджелес |
| Местное время | 2021-01-14|
| IPv4-адреса |
Информация о веб-сайте и веб-сервере
| Хост веб-сайта | http://3tz.site |
|---|---|
| Серверное программное обеспечение | nginx / 1.11,5 |
Записи ресурсов DNS
@ представляет источник 3tz.site зоны DNS, который часто встречается в файлах зоны BINDОбратный IP — Веб-сайты на том же IP-адресе
Веб-сайты с похожими именами
См. Также: Домен Список — страница 574,951
Популярные сайты
Популярные сайты
Последние поисковые запросы
Галерея TZ Plus — плагин для WordPress
TZ Plus Gallery отображает все ваши альбомы из социальных сетей Facebook, Flickr, Instagram, Google+ и WordPress на вашем сайте.
Вы можете публиковать свои фотографии где угодно, каждый раз со своего мобильного устройства в Facebook, Flickr, Instagram и Google+. он будет автоматически добавлен на ваш сайт.
Характеристики
- Разместите свои альбомы из онлайн-источников, таких как Facebook, Instagram, Google + или Flickr, в галерее вашего сайта.
- Поддерживаемые альбомы WordPress.
- Управляйте галереей, включая / исключая альбомы, ограничивайте количество изображений, отображаемых в каждом альбоме.
- Неограниченное отображение галереи на вашем сайте.
- Отображение нескольких альбомов на одной странице или в сообщении.
- Совместимость с планшетом, смартфоном.
- Совместим с плагином Visual Composer.
- Опции выбирают количество столбцов.
- Варианты выбора цветового стиля.
- Опции заполнения альбомов или фотографий.
Демо
Альбомы на фан-странице Facebook
Альбомы Google+
Альбомы Instagram
Альбомы Flickr
Pro версия
1.Автоматическая установка:
Самый простой способ установки — нажать «Плагины», затем «Добавить» и ввести «TZ Plus Gallery» в поле поиска.
2. Ручная установка 1:
- Войдите на свой сайт и перейдите к плагинам.
- Нажмите кнопку «Добавить».
- В разделе «Установить подключаемые модули» щелкните «Загрузить подключаемый модуль».
- Выберите zip-файл плагина (tz-plus-gallery.zip) на своем компьютере и нажмите кнопку «Установить сейчас».
- Вы должны увидеть сообщение об успешной установке подключаемого модуля.
- Щелкните Активировать подключаемый модуль.
2. Ручная установка 2:
- У вас должен быть доступ к серверу, на котором установлен WordPress.
- Загрузите zip-файл плагина (tz-plus-gallery.zip) до пути к вашему серверу (/ wp-content / plugins /) и распакуйте его сюда.
- Войдите на свой сайт и перейдите в раздел «Плагины» на панели администратора.
- Найдите «TZ PlusGallery» и нажмите «Активировать».
Галерея Facebook: иногда работает, иногда не работает.Поддержка: совсем не работает.
Отличный альбом для WordPress. К сожалению отсутствует возможность установить количество альбомов / фотографий на странице.
Отличный плагин, очень простой в использовании и очень эффективный! Одна небольшая проблема — количество изображений, установленное на «0» для отображения всех изображений. В моем случае это не сработало, я ждал бесконечно, когда щелкал альбом, поэтому я изменил его на 9999 и решил проблему! По-прежнему заслуживает 5 *.
Я протестировал полдюжины связанных плагинов, которые не работают, или запрашивал api. Этот плагин без большого количества кругов заработал с первого раза. Поздравляем разработчика!
Самый большой плагин для категории!
Отличная работа, заслуживает 5 звезд
Посмотреть все 10 отзывов«TZ Plus Gallery» — программное обеспечение с открытым исходным кодом. Следующие люди внесли свой вклад в этот плагин.
Авторы1,5,5
- Альбом с фиксированным отображением в facebook
1.5.3
- Добавьте видео, чтобы помочь получить идентификатор альбома Google и Instagram получить токен доступа
1.5.2
- Исправлено дублирование описания поста.
1.5.1
- Исправлено отображение фотографий в Facebook.
1,5
- Фиксированный токен доступа к Instagram.
- Фиксированный ключ API данных Flickr.
1.1,3
- Альбомы с фиксированным лимитом отображают только 16 альбомов.
1.1.2
- Поддерживаемые альбомы WordPress.
- Исправлен конфликт с меню Bootstrap в мобильной версии.
- Добавить файл css в голову.
1.1.1
- Fix Ограничить количество фотографий в альбомах. В версии
- Pro добавлен новый макет «Кофе».
1.1.0
- Улучшить качество миниатюры для бесплатной версии. Версия
- Pro поддерживает 14 потрясающих макетов.
1.0.2
- Фотографии с фиксированным пределом отображаются в нескольких альбомах.
1.0.1
- Фиксированное имя папки плагина.
- Исправлено добавление нескольких альбомов в альбомы включения и исключения.
1.0.0
Техническое задание
Итак, вы хотите заказать сайт и для этого вам необходимо составить ТЗ (техническое задание). Не принимайте это формально и сделайте это в первую очередь. Потому что нужно выбрать веб-студию. И пока нет хорошего описания заказа (ТЗ), ни одна веб-студия не может сказать вам точную стоимость.Ну и не выбрать наиболее удачный вариант. Более того, вам еще нужно описать, что вы хотите иметь. Обычная веб-студия ожидает, что заказчик мало разбирается в создании сайтов и не ожидает приличных ТЗ. Да и двух похожих ТЗ я еще не встречал. Это продукт творчества, как и сам сайт. Прежде всего, давайте определимся, зачем он нужен и какую роль он играет.Это описание заказа. В будущем вы можете требовать все, что есть в ТЗ, и не можете требовать того, чего там нет.Для вебмастера ТЗ определяет стоимость проекта.
Понятно, что в процессе создания сайта вам может понадобиться что-то еще, или вы вспомните что-то еще.
Ничего страшного, можно все это добавить и изменить в процессе. Однако, как правило, добавляет и меняет стоимость проекта. При написании ТЗ я бы назвал 2 крайности: туманное, неконкретное описание проблемы.
Очень сложное описание, основанное на его логике. Не бойтесь, просто опишите идею вашего сайта, укажите важные для вас детали.
Если веб-мастер чего-то не понимает, он у вас это уточнит.
Пример процедуры сотрудничества
- вы отправляете ТЗ на согласование,
- получите наводящие вопросы,
- делать обновления,
- получить договор сверки,
- внесение исправлений, при необходимости подписание договора,
- Внести предоплату,
- предоставить материалы для сайта,
- Начинается процесс создания сайта.
Итак, если вы отдадите весь материал сразу, то вы упростите работу веб-мастеру, что скажется на цене и скорости.