Как написать правильное техническое задание (ТЗ)? Написать тз как


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

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

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

От автора: Как написать техническое задание (тз) на разработку сайта? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

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

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

Давайте проанализируем такой пример:

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

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

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

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

Что мы имеем. Исполнитель пункт тз выполнил, а вы хотели совсем иное. Вроде все в соответствии, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги.

Это пример всего-то банального календаря.

А если придется переделывать что-то серьезнее, на переработку чего времени требуется не полдня, как в случае с календарем? Исполнитель возится с вами, хотя мог бы завершить ваш проект и начать новый.

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

Далее тут указываем:

для кого — целевую аудиторию:

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

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Тип:

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Английский

Русский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

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

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

Для того чтобы перечислить функционал, нужно решить что ему необходимо:

Нужны ли новости

Нужен ли рекламный блок

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

Нужен ли скрипт рассылки

И т.д. и т.п.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

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

Описание функционала

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

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

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

Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.

Далее может идти вкладка «новости». Подпункты могут быть «события», «акции», «новое».

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

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

о компании

история компании

контакты

отзывы

новости

события

акции

новое

продукция

каталог продукции

релизы

отзывы о продукции

сервис

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

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

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

Автор: Бернацкий Андрей

E-mail: contact@webformyself.com

"Киберсант-вебмастер" — самый полный курс по сайтостроению в рунете!

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

Хотите узнать, что необходимо для создания сайта?

Посмотрите 3-х минутное видео и у Вас будет четкий пошаговый план по созданию сайта с нуля!

Смотреть видео

webformyself.com

Как написать правильное техническое задание (ТЗ)?

Правильно поставленная задача — это на половину решенная задача. Другими словами, результат и успех решения задачи на половину зависит от правильной постановки.

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

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

Вот как раз о том как мы пишем ТЗ, тут и поговорим.

Изначальные условия, из которых выросла наша методика:

  1. Мы перестали работать с крупными проектами. Если задача слишком большая, мы просто разбиваем ее на куски и делаем по шагам. Сначала самые важные части, затем докручивая постепенно дополнительные компоненты. Задачи делим на куски по 1-2 недели. Иногда по 2-4 недели. Слишком большие задачи сложнее ставить, легко допустить ошибки в постановке задачи и затем получить проблемы в результате. Пошаговая схема — оптимальна. Еще этот метод называют Agile.
  2. Мерилом прогресса являются итерации или версии продукта. Чем чаще делаются итерации тем лучше.

Таким образом родилась наша методика, которую тезисами можно обозначить так:

Берем чистый лист бумаги (Google Документ лучше всего) и начинаем писать ТЗ, которое состоит из следующих основных разделов:

Задача

Первый раздел ТЗ звучит как Задача.

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

Исходные данные

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

Требования к результату

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

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

Тут есть засада и проблема. Часто новички думают что для написания ТЗ нужно понять задачу. Ошибка в том что все наоборот. Ты не поймешь задачу, пока не напишешь ТЗ. И для этого есть прием из двух шагов: Во-первых надо выключить мозг и составить простой список из идей, условий, историй и любых комментариев и примечаний по задаче. Во-вторых, после того как список будет составлен, надо начать его структурировать по ВИСИ. Выделать общие пункты, подпункты и т д, все по принципу ВИСИ. Вот только после этого начнет приходить понимание. Полное понимание придет только в том случае если удасться структурировать требования и привести список к норме из 3-4 верхних пунктов. До тех пор пока не будет структрирированного списка, вы лишь можете думать что чего то понимаете, но на самом деле это не так. Это иллюзия, в которую вы верите. Структурирование позволяет лишь слегка развеять эту иллюзию и именно это состояние и называется понимание достаточное для исполнения.

Ограничения

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

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

Клиенты разные по характеру — пишут задачи по разному:

  1. Кто то пишет просто задачу в одну строку «Нужен сайт, который будет продавать Угги».
  2. Часть клиентов описывают задачи в Evernote с гиперссылками между требованиями. Где на каждый важный участок есть своя карточка.
  3. А кто то пишет ТЗ в трекерах, где каждый тикет — это часть задачи, а задача определяется как веха (millestone).
  4. Кто то пишем в MindMap.
  5. Есть те кто все еще используют в MS Word.
  6. Самые любимые наши клиенты пишут задачи в  Google Документах. Таким сразу +10 к уровню уважения и любви 🙂

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

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

systemo.biz

Образец технического задания к тендеру 2018

Автор: Черданцева Татьяна 12 июня 2017

Составление технического задания (ТЗ) - важный этап подготовки к закупке. Разберемся в требованиях 44-ФЗ и приведем пример технического задания для тендера.

Понятие технического задания

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

Цель — зафиксировать задачи по осуществлению конкретного заказа и достижению результатов, ожидаемых заказчиком. Это исходный документ, который учитывает основное назначение.

ТЗ — внутренний документ, но оно публикуется вместе со всей документицией о проведении тендера.

Как написать техническое задание на тендер

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

Руководитель заказчика или иное уполномоченное лицо утверждает данный документ.

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

  1. Указать полное наименование объекта с установлением объема закупаемых предметов, услуг.
  2. Конкретизировать описание товаров, указав детально и четко функциональные, качественные и эксплуатационные характеристики.
  3. Обозначить конечную дату или период времени, к которому ожидается достигнуть поставленный результат закупки или установить график оказания услуг.
  4. Установить требования к гарантии, гарантийному обслуживанию и объему предоставления гарантий качества.
  5. Зафиксировать иные существенные условия заказа: место доставки, условия поставки, монтажа, наладки, обучения.

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

Образец технического задания к тендеру

Скачать

Пример технического предложения для тендера

Скачать

goscontract.info

Как создать ТЗ для программиста / Хабр

Рекомендации геймдизайнеру от программиста (архитектора).
Вступление
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

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

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

Самое важное:
  1. Четкое понимание конечного результата. (Контроль качества.)
  2. Сроки исполнения.
Зачем нужна документация:
  1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
  2. Способ увидеть, как будет выглядеть готовый проект.
  3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
  4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
  5. Планирование работ.
Какие бывают документы:
  1. Концепция («Про че игра?»)
  2. Спецификация (Что мы хотим получить?)
  3. Техническое задание (Как это устроено — именно о нем будет идти речь.)
  4. План работ (Как мы это будем делать.)
Кто участвует в обсуждении ТЗ:
Чем раньше будет получена обратная связь от заинтересованных специалистов — тем меньше будет сделано лишней работы.
  1. Геймдизайнер (Написание документации)
  2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
  3. Программист (Оценка объемов работ.)
Требования к оформлению документации:
Чем более неряшливо будет оформление — тем меньше людей вообще начнет это читать. Читатели проявляют невероятную изобретательность, чтобы избежать неприятной для них работы. Поэтому так важно прилагать усилия к тому чтобы чтение документации было легким и приятным настолько, насколько это вообще возможно.
  1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
  2. Выделение ключевых фраз. (Для чтения документа по диагонали)
  3. Составление списков. (Вместо сплошного текста)
  4. Разбиение длинных списков по группам. (По три пункта в группе)
  5. Многократные повторения. (Избегать ссылок по документу)
  6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
  7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)
Требования к содержанию ТЗ
Нет четкого списка требований, которому должна удовлетворять документация. Поэтому разработка ТЗ приостанавливается задолго до приближения к ее полноте. В итоге следующий этап разработки начинается без ТЗ, в надежде, что ТЗ будет дописана по ходу, или даже по итогам разработки.
  1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
  2. Никаких общих слов типа:
    • все возможные варианты
    • карта придумывается компьютером
    • взаимодействие различных объектов
    • после всех действий и т.д.
  3. Все названия видов сущностей(классов) должны иметь:
    • русское название (для игрока)
    • английское (для кода)
    • краткое описание (расшифровка/подсказка/комментарий)
  4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
  5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
  6. Все что можно измерить, должно быть измерено.
    • размеры картинки в пикселях и байтах
    • количество столбцов и клеток в таблице
    • количество символов в текстовом поле
    • количество оружия на уровень
    • время сессии и т.д.
Главные требования к результату работы программиста:
Эти важные требования подразумеваются, но никогда никем не озвучиваются.
  1. Гибкость системы к изменениям. (Динамические требования.)
  2. Автоматический сбор данных об ошибках. (Обратная связь.)
  3. Простота запуска и настройки заказчиком. (Демонстрация результата.)
Первый этап написания ТЗ:
Описание предметной области, ее формализация в понятных программистам терминах.
  1. База данных (метаданные)
    • список типов объектов
    • характеристики объектов
    • связь/зависимость между объектами
  2. Бизнес-процессы (полный игровой цикл)
    • список процессов (сценарии работы)
    • список функционала (что должен уметь)
    • список ожидаемых изменений (что вообще может быть)
Второй этап написания ТЗ:
Как должен выглядеть/работать продукт для всех типов пользователей (игроки и администраторы).
  1. Интерфейс (визуальная часть)
    • список экранов игры с названиями (или группы элементов)
    • список элементов на каждом экране с названиями и текстом подсказок
    • описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
  2. Админка (управление)
    • сервер (жизненные/системные показатели )
    • игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
    • игровые данные(контент генерируемый игроками)
    • статистика и отчеты (какую статистику нужно собирать?)
Третий этап написания ТЗ:
Как мы собираемся это все делать.
  1. Исследование необходимых технологий
    • Список требований к каждой технологии
    • Описание тестов/демонстрации работы каждой технологии
    • Список будущих требований/возможных проблем (что дальше?)
  2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
  3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
  4. Расстановка приоритетов по задачам.
  5. Требования к первой работающей сборке (что должен уметь первый прототип).
  6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)
Сопровождение документации
  1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
  2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
  3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
  4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
  5. После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
  6. Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
  7. Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
  8. Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.
Срезание углов
Любая технология будет упрощена до абсурда, чтобы уменьшить количество работы и расходов. Хлеб из химических дрожжей, вино из спирта, разработка без документации. Многие считают что документация не нужна, если:
  1. Проект в 2-3 месяца.
  2. Команда из 2-3 человек.
  3. Ограниченный бюджет. (Он всегда ограничен)
  4. Нет требований к документации. (Никто не знает как надо делать)
  5. От нее нет никакой пользы. (Никогда не использовали документацию)
Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.
Первые шаги
Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша. Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.

habr.com

Как написать ТЗ?

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

Зачем нужно техническое задание (ТЗ)?

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

Как писать техническое задание на сайт?

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

Общая концепция проекта

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

Функционал сайта

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

Дизайн сайта

Дизайн сайта часто становится предметом наибольших разногласий между заказчиком и веб-студией. И это неудивительно - в отличие от функциональной части, которая имеет объективные критерии оценки (работает/не работает), дизайн оценивается субъективно (нравится/не нравится). Многие компании уже имеют фирменный стиль (логотип, буклеты, представительскую полиграфическую продукцию), который разработан профессиональными дизайнерами. В этом случае дизайн сайта должен соответствовать фирменному стилю компании. Если фирменного стиля нет,то самый простой способ - привести примеры сайтов, дизайн которых нравится, и в общих чертах описать свои пожелания относительно цветовой гаммы сайта, шаблона, размещения элементов навигации. При наличии логотипа его также необходимо передать веб-студии, так как обычно именно логотип определяет стилистику сайта. Подводя итог статьи, можно сказать, что наличие технического задания значительно облегчает взаимодействие заказчика с веб-студией и позволяет избежать многих спорных моментов, неизбежных при обсуждении проекта "на словах".   Обратный звонок

top10-studio.ru

ТЗ для копирайтера: пример хорошо поставленной задачи

Отдайте свои заботы о хорошем контенте на сайте в наши руки

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

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

И дело не в том, что у нас нет денег на хорошего копирайтера.

Представьте, для продвижения вам нужен текст про обои. Предполагается, что в нем будут ключи, размещаться статья  будет перед таблицей с ассортиментом. Обычно такие тексты никто не читает… А вдруг? Поэтому на всякий случай текст должен быть читабельным и приятным. Но не заказывать же его у Димы Кота?

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

 

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

  1. У вас ограничен бюджет (хорошие контент-агентства и студии вам не по карману).
  2. Вы считаете, что все копирайтеры плохие и незачем переплачивать за пиар.
  3. Вам не нужно нечто особенное и прекрасное. Ваша цель — простенький, но миленький текст для продвижения.
  4. Текст вам нужен срочно и нет времени ждать пока “профессионал” взвесит плюсы и минусы, придумает гениальный заголовок, дождется растущей луны и, принеся жертву богу “действительно продающих текстов”, сядет писать.

 

ТЗ на продающий текст

Зарегистрироваться. Заказать. Купить. Забронировать. Проголосовать. Что-нибудь из этого вам обязательно нужно. Один из способов получить лид — разместить хороший текст. Как донести это для копирайтера?

  1. Сначала обратитесь к вашему менеджеру по продажам или маркетологу. Получите от него список преимуществ вашего продукта/услуги/компании. Этот список поможет копирайтеру сориентироваться и он, возможно, не станет тупо рерайтить тексты ваших конкурентов.
  2. Обозначьте цель текста.
  3. Расскажите об аудитории: кто ваш клиент? Для кого пишется текст? Эта информация влияет как на стилистику, так и основные рычаги.
  4. Составьте план текста: выявите смысловые блоки.
  5. Обозначьте вопросы, на которые должна отвечать статья.
  6. Поставьте запреты: чего ни в коем случае не должно быть в тексте.
  7. Укажите, чем текст должен отличаться от статей на первых двух сайтах, которые можно обнаружить в выдаче по тематическому поисковому запросу.
  8. Определитесь с базовыми требованиями (см. ниже).

Тз для копирайтера: пример

Заказываем текст для языковой школы. Начну сразу со второго пункта, пропустив базовые требования.

Цель текста: замотивировать пользователя на проверку своих знаний языка путем регистрации на бесплатный тест, который можно пройти в школе.

Целевая аудитория: мужчины из женщины от 22 - до 40. Люди, которые когда-то изучали иностранный язык в школе или университете, но забыли его и могут заинтересоваться интенсивным курсом для работы или путешествия.

План текста:

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

Вопросник:

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

В тексте не должно быть:

  • общих вводных фраз типа “известно, что...”;
  • длинных предложений с кучей различных оборотов;
  • лишней информации, не относящейся к делу (типа истории Англии).

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

 

Другие типы текстов

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

 

Главная страница / текст “о компании”

  1. Еще раз повторюсь: не ждите хороших текстов. Никто не будет ради трех соток весь день думать над преимуществами вашей компании, поэтому распишите их самостоятельно в виде списка тезисов.
  2. Предоставьте копирайтеру основную информацию о вас: всевозможные цифры, даты, названия компаний-партнеров, отзывы и т.д.
  3. Опишите целевую аудиторию.
  4. Предоставьте перечень своих услуг.
  5. Обозначьте главных конкурентов и поясните, что вам нравится в их текстах, а что нет.
  6. Обозначьте вопросы, которые может задать ваш клиент. Пусть копирайтер попробует ответить на них, используя предоставленную вами информацию о компании.
  7. Также поставьте запреты.

 

Совет: Главная — очень важная страница, поэтому советую раскошелится и заказать ее в студии, которая вызывает доверие.

 

SEO текст

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

 

Как составить ТЗ для копирайтера: стандартный набор требований

Если копирайтер, с которым вы сотрудничаете не задает вопросы, это не значит, что вы супер-четко поставили задачу, и он все понял. Нет. Ему просто плевать. Он не парится о том, будет ли какой-то толк от его писанины или же нет. Главная его цель — получить оплату и желательно быстро.

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

semantica.in