Приложения и дополнительные материалы по проекту

⇐ Назад

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

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

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

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

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

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

Служебная информация

Дата оформления заказа
ФИО оформляющего заказ
Подпись
ФИО представителя Компании
Должность представителя Компании
Координаты представителя Компании
Подпись
Deadline

Приложения

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

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

Информация о Компании

Название
Род деятельности
Конкурентные преимущества
Потребители
Партнеры, поставщики
Конкуренты
Цели и задачи (перспективы развития Компании в обозримом будущем)
Дополнительная информация о Компании (не вошедшая по каким-то причинам в предыдущие пункты)

Информация о продукте (услугах)

Название
Описание
Конкурентные преимущества
— уникальное торговое предложение
Ценовой сегмент рынка
Целевая аудитория
Конкуренты
Дополнительная информация

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

Информация о существующем фирменном стиле

Логотип
— пометка о прилагаемом файле
Фирменные цвета
— в Pantone или CMYK
Фирменные шрифты
— пометка о прилагаемых файлах шрифтов
Графические элементы, образы, персонажи
— пометка о прилагаемых файлах
Модульная сетка
— пометка о прилагаемых файлах
Другие элементы фирменного стиля
— пометка о прилагаемых файлах

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

Информация по дизайну логотипа

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

Ядро ТЗ. Все пункты крайне желательно заполнить. Реально необходим только один — название.

Заключение

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

14 сентября 2004

http://eldesign.ru/write/designer/article02

ехническое задание для дизайнера II. Документ с юридической силой

Следующий момент, которым я плотно занимался: интеграция ТЗ в юридически-правовые взаимоотношения с Заказчиком. Если раньше ТЗ для меня было больше источником информации, то теперь его роль сместилась в сторону вещественных доказательств в случае конфликта. Учитывая сказанное в предыдущей части, это не удивительно. Чем крупнее заказ, тем менее организован Заказчик, тем больше вероятность, что Исполнитель допустит ошибку, которая повлечёт за собой серьёзную финансовую ответственность.

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

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

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

Если в процессе создания Произведения по инициативе Заказчика изменяется Техническое задание, а корректировки Произведения повлекут за собой дополнительные расходы со стороны Исполнителя, то Стороны по взаимному согласию составляют Заказ на дополнительные работы. <…>

Если у Заказчика есть претензии к качеству и/или содержимому Произведения, то Заказчик может:

— Обязать Исполнителя исправить Произведение за счет Исполнителя в соответствии с пожеланиями Заказчика, если эти пожелания не вступают в конфликт с требованиями Технического задания или условиями Заказа. <…>

— Обязать Исполнителя исправить Произведение за дополнительное вознаграждение, если Произведение выполнено в соответствии с Заказом и Техническим заданием. <…>

— Направить Исполнителю отказ от приемки работ в письменном виде. Если работы выполнены в соответствии с Заказом и Техническим заданием, то Исполнитель не возвращает предоплату за выполненный этап, а Заказчик дополнительно оплачивает <…>

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

Безграмотно составленное большое ТЗ ударяет одинаково больно по Заказчику и Исполнителю. Если в одном месте написано, что результат должен быть круглым и тёплым, а в другом — квадратным и синим, то результат работы будет зависеть скорее от субъективных ощущений Исполнителя. Такими же размытыми критериями будет руководствоваться и Заказчик, оценивая работу. Вероятность того, что ощущения Сторон не совпадут, очень высокая.

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

23 января 2008

Техническое задание для дизайнера II. Размер имеет значение Наполнение этого сайта полезной информацией началось с двух статей, которые поднимали важные для меня темы: «Битва за гармонию или как дизайнеру общаться с клиентом» и «Техническое задание для дизайнера». Статьи тут же разлетелись по сети, никому неизвестный до этого сайтик посетили тысячи человек, а я понял, что эти темы важны не только для меня. Прошло 3,5 года, а моё мнение по этим вопросам практически не изменилось. Лишь появились новые интересные нюансы, о которых стоит поговорить. Размер имеет значение Опубликованный в статье пример технического задания практически сразу морально устарел для меня. Я занимался совершенствованием этого документа постоянно. На сайте «Мелехова и Филюрина» я нашёл очень неплохие образцы технического задания, да ещё и заточенные под разные творческие работы. Одно время я пользовался ими практически в неизменном виде, пока не понял, что это не совсем то, что мне надо. После того, как появился «Редбренд», я занялся серьёзным упорядочиванием проектной документации. Потратив несколько дней, я сотворил техническое задание мой мечты (как я тогда думал). Это был документ, который в незаполненном виде занимал 10(!) листов. Там было всё: описание задачи, подробное описание компании, общие сведения, сведение о диверсификации, ценовая политика, национальные симпатии, традиции, подробный портрет потребителя, его объективные и имиджевые потребности, эмоциональная составляющая, ситуация, в которой принимается решение о покупке, ассоциативные ряды, описания дистрибуции и продвижения, точки контакта, обзор рынка, конкуренты и конкурентные преимущества, технологические ограничения, приоритеты и критерии, которыми будут руководствоваться при оценке работы. Каждый пункт был разбит на подпункты, снабжён подробными комментариями и наводящими вопросами. Оформлен документ был таким образом, чтобы клиенту оставалось только вбивать необходимую информацию. Я гордился этой формой техзадания безмерно. Однако, искренне стремясь к идеалу, я упустил некоторые особенности национального бизнеса. Возможно, где-нибудь в педантичной Германии или аккуратной Японии документация на десяти листах считается нормальной частью рабочего процесса, но только не в России. Тут действуют несколько иные законы взаимодействия дизайнера и заказчика, когда дизайнер представляется заказчику этаким тамадой с баяном: я тебе заплатил, а ты меня развлекай. Чем крупнее компания, тем меньше желания у ответственных лиц тратить время на подробное обсуждение причин, по которым заказываются те или иные творческие работы. Почему-то считается, что дизайнер — телепат и сам должен догадаться, что нужно заказчику. При этом никому не придёт в голову обратиться к незнакомому парикмахеру, кинуть на стол деньги и сказать: «Сделайте мне что-нибудь…». Для меня до сих пор остаются непонятными эти ментальные особенности, которые присущи, в том числе, и очень, очень крупным российским компаниям. Ещё несколько интересных особенностей: заказчик готов вести многоэтапные многочасовые переговоры, но не готов потратить час на оформление документа, в котором можно изложить то же самое, но по существу; заказчику удобно обсуждать готовую работу и приходить к неожиданным открытиям, как не надо было делать, но не удобно думать об этом заранее, и ещё сложнее излагать свои мысли на бумаге; заказчик с лёгким сердцем отдает работу на судилище фокус-групп, но при этом скупится провести минимальные исследования рынка и целевой аудитории до начала работы над проектом. Как следствие всего этого, первая реакция на полноценную форму технического задания — неприятие и негатив. Затем появляются два вероятных сценария: либо будут длительные переговоры, на которых Исполнителю предоставляется возможность судорожно заполнять техническое задание под диктовку, либо техническое задание отдадут какому-то менеджеру, и под диктовку будет заполнять он. В первом случае документ будет заполнен мучительно, но с душой, во втором случае будет стандартная отписка в духе «ну придумайте нам что-нибудь». Очень редко я получал подробное техническое задание, в котором меж строк сквозила искренняя заинтересованность в результате и желание помочь. Это, как правило, были небольшие компании. И всегда в этих случаях документ заполнялся руководителем. Продолжение следует... 16 января 2008

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

Хостинг: docker.ru. Программирование: АртВизио

⇐ Назад