Техническое задание для составления эскиза. Порядок разработки технического задания

Вопрос «Нужно ли вообще составлять техническое задание (ТЗ)?» может возникать только у тех, кто никогда в жизни не заказывал разработку сайта, поскольку необходимость в нём возникает после первого же общения заказчика с исполнителем.

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

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

Из чего состоит ТЗ?

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

Общие сведения (описание)

Здесь указываются:

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

Этапы и сроки реализации проекта . Очень важный момент, как правило, календарный план по всем этапам работ составляют в самом конце. Эта часть даёт понимание, что и когда будет делаться. Например (с указанием дат):

• Подготовительный этап;
• Проработка концепции сайта;
• Проектирование;
• Создание дизайн-макета;
• Разработка дизайна страниц;
• Вёрстка;
• Программирование;
• Наполнение контентом;
• SEO-оптимизация;
• Тестирование;
• Запуск.

Каких-то этапов, например, SEO-продвижения может и не быть. Зависит от целей и задач заказчика и компетенций исполнителя.

Назначение и цели

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

Назначение сайта . Каких целей созданием сайта необходимо достичь? Для чего он нужен, какие задачи решает?

• Реклама и привлечение новых клиентов;
• Поддержка заказчиков и партнёров;
• Демонстрация выполненных работ;
• Ознакомление со списком услуг;
• Создание и поддержание имиджа компании.

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

Целевая аудитория . Кто будет пользоваться сайтом, для кого он создаётся?

• Веб-мастера, блогеры;
• Владельцы интернет-магазинов;
• Владельцы информационных порталов;
• Рекламные студии;
• Представители присутствующих в онлайн-пространстве фирм и компаний.

Требования

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

Тип . К какой категории принадлежит веб-ресурс?

• Посадочная страница;
• Сайт-визитка;
• Корпоративный сайт;
• Информационный портал;
• Интернет-магазин.

Требования к оформлению . Они могут быть следующего вида:

• Сайт должен быть минималистичным и при этом отражать род деятельности компании.
• Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
• В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
• Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).

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

Языковые требования . Носители какого языка смогут посещать ресурс? Какие языковые версии сайта должны быть?

• Русский;
• Английский;
• Эсперанто.

Требования к совместимости . С каких устройств и какими браузерами сайт точно будет открываться корректно? В последнее время наметилась тенденция к адаптивной вёрстке, когда страница правильно отображается на любом устройстве с любым соотношением сторон и разрешением экрана. Здесь можно перечислить браузеры, с которыми однозначно должен быть совместим ресурс. Обычно на всех современных браузерах сайты отображаются одинаково, бывают только проблемы со старыми версиями Internet explorer.

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

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

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

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

Структура и навигация . Какие разделы, подразделы и отдельные страницы будет содержать проект?

• Главная страница
• Услуги

• Копирайтинг
• Рерайтинг
• SEO-коперайтинг
• Корректура
• Транскрибация
• Контент-менеджмент
• Контент-маркетинг

• Портфолио
• О нас
• Контакты

Сделайте и краткое описание каждой страницы, дайте определения. Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?

Желательно контент или хотя бы его наброски приготовить еще до начала работ с подрядчиком. Это будет способствовать более эффективной коммуникации.

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

Описание разделов сайта

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

Главная страница . Формулировка задачи может быть в следующем виде.

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

• Шапка - логотип, название фирмы;
• Меню навигации;
• Информация об акциях и скидках;
• Кнопка заказа;
• Рекламный текст;
• Блок с пятью лучшими работами и ссылкой на раздел портфолио;

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из

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

Рекомендуем прочитать:

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

Для чего ТЗ заказчику?

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

Рекомендуем прочитать:

Для чего ТЗ исполнителю?

В первую очередь, это ваш ориентир на то, что нужно сделать. Часто заказчики что-то додумывают в процессе разработки, стараясь навязать Вам выполнение лишних задач. Вы хотите работать бесплатно? Уверен, что нет. Уточняйте, что сумма, оговорена в самом начале, касалась исключительно объема работ указанного в техническом задании. Все что более – оплачивается отдельно. Также при сдаче проекта вы сможете отчитаться по поставленным задачам и их выполнению. Я не раз сталкивался с моментами, когда заказчик не хотел принимать работу, аргументируя неполным ее выполнением. Но поднимания первоначальное ТЗ оказывалось, что тех задач, о которых шла речь, вообще никто не ставил. Еще раз акцентирую внимание – не работайте без ТЗ, ведь мнение заказчика может менять чаще чем погода, и Вам придется все десятки раз переделывать тратя свое время, и не получая за это дополнительную оплату.

С чего начать составление грамотного технического задания

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

• Общие положения технического задания

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

Рекомендуем прочитать:

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

• Цели проекта

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

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

• Функциональные требования

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

Рекомендуем прочитать:

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

• Сроки

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

• Отчетность

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

Также должен быть отчет по факту выполненных работ. Что было сделано, сколько на это потрачено времени, с какими трудностями столкнулся исполнитель и т.д.

• Ответственность

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

Рекомендуем прочитать:

И в конце это статьи, хотелось бы дать несколько советов исходя из собственного опыта составления и получения технических заданий.

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

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

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

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

Правила, применяемые к таким заданиям

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

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

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

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

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

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

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

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

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

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

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

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

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

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