Писал заметки для своей группы, понял, что получается больше, чем я рассчитывал, поэтому решил написать статью и выложить на Хабр целиком. Мне кажется, тут она сможет пригодится. Здесь нет технической информации, просто общее описание оптимального подхода к разработке сайта на заказ, так сказать результат моего опыта работы в веб-студии в течение трёх лет.
Сначала опишу проблему, которую многие узнают в своей жизни. Итак, надо делать сайт, непонятно как, и непонятно где. Есть какие-то знакомые какого-то знакомого, либо по случаю увиденное объявление вею-студии. Назначена встреча. На встрече вам рассказывают, что всё будет хорошо, да вы и сами видите, что ребята хорошие.
Первое время всё идёт замечательно. До тех пор, пока не появляются первые результаты. И вот тогда начинаются проблемы. Скорее всего: вам показывают уже готовый сайт, в котором «надо немного кое-что доделать, и вы посмотрите, может какие нибудь мелочи нужно подправить». Потому что то, что они показывают — ужасно. Вы же договаривались совсем о другом!
C другой стороны, это выглядит совсем по-другому. Проходит встреча с заказчиком, где он хочет обычный сайт. Время от времени он звонит или устраивает встречи и каждый раз меняет свои требования. Когда пришло время сдачи проекта, заказчик устраивает истерику, отказывается платить. Хорошо, что хоть предоплату 50% взяли, а то вообще без денег бы остались.
В результате все друг другом недовольны, иногда договариваются о цене, иногда не договариваются. Заказчик не получает сайт, который он хочет, исполнитель не получает лояльного клиента.
В таких ситуациях существует простое решение, позволяющее свести к минимуму все риски. И о нём я хочу вам рассказать.
Начнём со стороны заказчика.
Самый главный вопрос — зачем вам нужен сайт? Скорее всего, без ответа на этот вопрос вы не получите результат, который вас обрадует. Если у вас до сих пор нет сайта, скорее всего он для вас не является жизненно необходимым. Это надо понимать и не ждать от сайта кардинальных изменений вашего бизнеса. Но не иметь представительства в интернете сейчас тоже не очень хорошо, поэтому сайт делать придётся.
Сайт может быть нужен «для галочки» — никаких целей не преследует, но начальство требует чтобы был. Не важно, какой; не важно, что в нём будет; есть определённый бюджет и в результате должен быть сайт.
Сайт может быть надеждой на экспансию бизнеса в сеть, расширение клиентской базы. Ещё сайт может быть онлайн каталогом, более удобной версии существующих брошюры или прайслистов компании.
В любом случае сайт должен быть предназначен для кого-то. Это могут быть существующие клиенты, или потенциальные клиенты, или менеджеры компании, для которых сайт будет удобным инструментом оформления заказа. Или сайт нужен только для генерального директора, чтобы он не приставал «где мой сайт! ничего сами сделать не можете».
Первым этапом создания сайта является ответы на эти вопросы «Зачем нужен сайт? Для кого он предназначен?». Выполнив этот этап, вы уже получите результат лучший, чем у большинства заказчиков сайтов.
Как выглядит первый этап со стороны исполнителя?
Надо добиться понимания, как заказчик ответит на эти 2 вопроса. Либо прямо поставив перед ним требование объективно ответить на них, либо, задавая наводящие вопросы понять для себя эти ответы. В большинстве веб-студий существует брифинг, или опросник, которые должен заполнить клиент в самом начале сотрудничества. На основании этого документа студия обещает сказать сроки и стоимость работ.
Но!
В этом есть большое «НО».
Во многих студиях опросники создаются как дань моде, «потому что так делают все». В них приведены вопросы, подсмотренные у конкурентов, или вопросы, выглядящие солидно. В продвинутых студиях такие опросники являются дополнительным инструментом продаж, но не более того. В заурядных студиях такие опросники (если есть!!!!) — мало что значащий word-документ, на который не обращают внимание даже сами исполнители. Его даже не всегда включают в итоговый договор. В таких декоративных опросниках обычно приведены общие вопросы (назовите деятельность компании, определите свою целевую аудиторию), хотя по большому счёту ответить на такие вопросы обязанность самих студий, ведь заказчик не обязан иметь в своём штате маркетолога (а это работа именно маркетолога), заказчик просто хочет сайт, в большинстве случаев даже не представляя каким будет итоговый вариант.
Продолжаем обсуждать, как сделать хороший сайт с минимумом рисков. В частности разговариваем про опросник web студий.
Помимо общих вопросов в декоративных опросниках приведены излишне частные вопросы, связанные с технической реализацией сайта. Это могут быть что-то вроде «укажите модули CMS, которые вы хотите на своём сайте». Выбор CMS, даже то, что нужна ли она вообще — это работа, которую должна выполнить веб-студия. Заказчик не обязан знать, какие бывают CMS, а в текущей ситуации заказчик должен не только знать, какие бывают CMS, но и уровень владения программистами студии каждой CMS, ведь глупо поручать разрабатывать сайт в какой-то среде человеку, который хорошо разбирается в другой среде, но плохо в нужной.
Конечно же, если заказчик чётко знает, что он хочет, и какую CMS и какие модули, то он может ответить на эти вопросы, но такое бывает очень редко, а опросники — одинаковые для всех заказчиков.
Другим признаком декоративных опросников является наличие вопросов плана «перечислите пункты меню, которые должны быть на сайте». Во-первых, это означает, что студия в принципе не рассматривает сайты без меню, из чего следует, что работники студии не будут напрягаться, чтобы сделать сайт, который нужен именно вам. Они будут предлагать уже готовые варианты, выдавая их за эксклюзивные. Классическая компоновка, раскрашенная в разные цвета и с разными шрифтами. Весь интернет завален однотипными ничего не выражающими сайтами, сделанными как под копирку. И все ваши предложения по улучшению сайта будут восприниматься в штыки, если для этого придётся чуть больше напрячься, вас будут уговаривать, что «надо сделать попроще, как мы говорим, потому что так никто не делает, как вы хотите, у всех так как мы говорим и вообще это единственно правильное решение». Во-вторых, это опять таки работа студии, определить нужно ли меню, если нужно, то разработать удобную систему навигации в этом меню. Заказчик не обязан в этом разбираться.
Конечно, вопрос «перечислите пункты меню, которые должны быть на сайте» не абсолютный признак, в хороших студиях он для внутреннего употребления может означать, «что заказчик хочет чтобы было на сайте», но может и нет. Лучше размышлять на такие темы до подписания договора и пятидесяти процентной предоплаты.
Продолжаем обсуждать, как сделать хороший сайт с минимумом рисков. В предыдущих постах мы обсуждали брифинг (или опросник) — предварительный документ, существующий во многих веб-студиях. Основная задача опросника — помочь начать заказчику начать понимать, что он хочет. По итогам брифинга невозможно выставить точные сроки или стоимость. Они либо будут завышены, либо нарушены. Такое прокатывает с очень стандартными сайтами, каких студия наштамповала уже немало. В таких случаях можно и без брифинга обойтись. Опять таки, если правильно ответить на 2 самых главных вопроса (обсуждалось в начале), то сам заказчик может понять, что ему нужно что-то совсем простое и сэкономить время и деньги.
Заполняя опросник, заказчик упорядочивает свои мысли, настраивается на нужный лад, решаются некоторые вопросы, про существование которых заказчик может и не подозревать. Самый яркий из которых — кто будет заниматься сайтом. Обязательно нужен человек, который будет отвечать за сайт со стороны заказчика. Это должны понимать обе стороны. Этот человек должен иметь полномочия принимать решения по сайту, которые не будут опротестовываться другими, например, директором. А для этого директор должен чётко обозначить перед таким ответственным человеком (обычно, это секретарша) что должно получиться в итоге. А для этого — тадам! — нужно ответить на 2 самых главных вопроса.
Исполнителям нужен такой человек, потому что они смогут с ним оперативно связываться по текущим вопросам, а они точно будут, если их нет — это повод бить тревогу и смотреть чем они там занимаются. Как знает любая мама, если ребёнок студия затих, значит надо насторожиться.
Обсуждаем как сделать хороший сайт с минимумом рисков. До этого мы обсуждали для чего нужен брифинг (или опросник).
Итак, заказчик заполнил брифинг, сам или с помощью менеджера web студии. На этом этапе по сути произошло знакомство студии и заказчика. Если брифинг — один из инструментов продаж, то заказчик привязался к данной студии и с ним легче будет работать. Кстати, если брифинг используется для продаж, это хороший признак для заказчика — значит исполнители заботятся о своих заказчиках, а следовательно постараются сделать так, чтобы заказчик был доволен результатом студии.
После этого менеджер проекта (а к этому моменту студия должна выделить человека, который будет отвечать за данный проект. Это не обязательно должен быть именно менеджер, может быть программист или дизайнер, если у студии небольшой штат, но именно он должен отвечать за этот проект) должен устроить интервью, по итогам которого должны быть получены ответы на 2 самых главных вопроса — «Зачем нужен сайт?» и " Для кого он предназначен?". Эти вопросы могут быть заданы в лоб, или не озвучены, а выводы сделаны по косвенным вопросам, если заказчик плохо ориентируется в своих предпочтениях, но ответ должен быть чётким и однозначен. И очень желательно где нибудь записан у исполнителя.
Так же по итогам интервью должна быть собрана дополнительная информация (тексты, фоточки, вообщем контент), либо достигнута договорённость когда и кто предоставит эту информацию. То есть как минимум эта тема должна подниматься в разговоре. Если же в разговоре проскальзывают фразы вроде «ну и потом определимся с контентом, там видно будет что конкретно нужно» или «у нас есть копирайтер, он всё напишет когда сайт будем заполнять» — есть вероятность что тексты будут написаны программистом-дизайнером-верстальщиком, который по совместительству и копирайтер, а изображения скачаны с бесплатных фотобанков.
То что мы обсуждали до этого, можно сделать без участия web студии. У заказчика может присутсвовать страх, что он не знает что надо, что у студии большой опыт и они всё сделают правильно. Но если вы вдумчиво прочитаете начало статьи и потратите (или поручите это конкретному сотруднику) день два на разработку требований к результату, то вы уже сделали лучше чем большинство сайтов.
С такой подготовкой гораздо легче работать со студией, контролировать её, а студии соответвенно гораздо легче работать с вами — а это меньшие сроки и качественнее результат. Что обрадует обе стороны.
Как вы заметили, уже видна эффективность данной схемы, а это только начало.
Кстати, друзья, поговорим немного о деньгах. У нас, в России, законодательно запрещено принуждение к бесплатному труду. (не помню статью, но если интересно — пишите в комментариях, поищу).
Всё что мы до этого обсуждали, по-хорошему, студия должна сделать бесплатно, несмотря на законодательный запрет. Потому, что без этого этапа студия не сможет сказать, за сколько, по времени и деньгам, она сделает сайт. Заказчик либо переплачивает, либо недополучает результата, как я уже писал. Либо студия может сказать «предварительный этап стоит столько то тысяч рублей», что будет вполне честно и адекватно, хотя с таким подходом продавать тяжеловато.
Дальше идёт составление технического задания. Тут надо поподробнее всё описать, потому что это очень важно.
Техническое задание это чертёж сайта. Чем оно качественнее, тем предсказуемей результат. Оно не обязательно должно быть большим, качество должно выражаться в освещении ключевых моментов.
Для того, чтобы ты, мой неизвестный друг, разбирался что это за ключевые моменты, я начну издалека, так что приготовься к долгой обороне.
Сайт состоит из нескольких частей, нескольких областей, я бы сказал. Это дизайн, вёрстка и кодинг программного ядра. Они имеют принципиальные различия.
Дизайн это социологическая работа, гуманитарная или техническая, сейчас мнения расходятся, но это неважно.
Вёрсткой должен заниматься верстальщик. Для этого надо знать различия браузеров, их версий, мобильное отображение, всякие такие вещи
Кодингом программного ядра должен заниматься программист. Раньше это должен быть серверный программист, сейчас это может быть и фронт-энд программист.
Эти области не обязательно должны выполняться разными людьми, больше того, их можно вообще не делать, а взять готовые решения, или некоторые области в конкретной реализации могут быть пренебрежимо малы или неотделимо взаимосвязяны с другими, но принципиально это разные вещи и необходимо понимать их наличие, чтобы корректно оперировать диапазоном возможностей.
Сейчас я объясню, как знание этого разделения может помочь вам создать хороший сайт с минимальными усилиями.
Каждый из этих этапов преследует свои цели, которые никак не пересекаются друг с другом. Перед каждым из них стоят свои задачи, и оцениваются эти этапы отдельно.
Эта мысль кажется очевидной, если задуматься над ней, но большинство людей не успевают этого сделать в суете.
И из этой мысли следуют очень практичный принцип — можно и нужно разделять эти этапы.
Они могут выполняться разными студиями или фрилансерами, при правильно составленном техническом задании. Или могут выполняться одним исполнителем, но каждый этап должен контролироваться заказчиком отдельно. И на каждом этапе заказчик будет видеть — сайт получается таким как ему нужно, или надо внести коррективы. Это раз.
И два — приятный бонус — поэтапная оплата внесёт много спокойствия и заказчику и исполнителю.
Вам не обязательно платить за весь сайт, не понимая из чего складывается цена, и не иметь гарантию качественного результата.
Но при таком подходе техническое задание играет фундаментально важную роль и я расскажу, каким оно должно быть.
Техническое задание (ТЗ) должно начинаться с постановки задачи — что должно получиться в итоге. Это самые общие фразы, рисунок большими мазками. Этот пункт нужен для того, чтобы не отклоняться от результата и для более лёгкого восприятия.
Например отличное вступление для ТЗ: «Заказчик ставит перед исполнителем следующие задачи:» и далее список задач. Какие нибудь такие «Создание интернет-магазина, обменивающегося данными с существующей 1с закачика.» или «Разработку автоматизированной системы продаж через интернет». То есть тут должен быть раскрыт первый самый главный вопрос.
Дальше надо рассказать про то, что этот сайт должен делать с точки зрения пользователя. Как вы легко догадались, это ответ на второй самый главный вопрос. Оформить можно так:
«Сайт должен обладать следующим функционалом:
1. Оформлен должен быть таким образом, чтобы пользователи, входящие в группу „пенсионеры“ могли с лёгкостью вызвать представителя компании к себе домой.
2. При однократной авторизации пользователем система не должна требовать повторного ввода пароля никогда».
Потом надо сразу же рассказать условия, при которых работа будет принята. Условия не должны допускать двойного толкования. Не «Сайт должен быть презентабельным», а «Сайт должен соответствовать стилистике эскиза, утверждённого на подготовительном этапе». Хотя второе тоже можно назвать субъективным, но показывая постороннему человеку (например судье) 2 рисунка, гораздо легче доказать что тигр, держащий в зубах слово «Адвокатская контора» не похож на фотографию Нью Йорк Таймс.
Получается, что за первые три пункта, которые могут уместиться на одну страницу, вы получите уменьшение своих будущих проблем на 90%. Исполнитель уже знает что нужно сделать, как, и как ему получить с вас деньги — всё понятно, надо только работать, проблем никаких нет.
Следующим пунктом вашего волшебного документа желательно видеть детали, если они есть. Ссылки на сайт, которые нравятся, все идеи, которые вы придумали пока думали над сайтом, а такие идеи наверняка будут. В общем все ваши хотелки, не такие глобальные, чтобы попасть в первые пункты, но которые тоже нужны.
Тут начинается серьёзный этап, немного посложнее чем предыдущие в техническом плане, но гораздо легче в эмоциональным. Этот этап можно легко перепоручить кому-нибудь, Необходимо составить структуру сайта.
Вот пример простейшего интернет магазина:
Главная страница
--каталог
----страница товара 1
----страница товара 2
— …
----страница товара N
--новости
----новость N
— …
----новость 1
--контакты
корзина
страница заказа
страница покупки
страница помощи
Структура — это иерархический список. Оформить его можно списком, схемой, картинкой, mindmap'ом, как угодно. Но в нём должно быть видно всё, что будет на сайте и как это соотносится друг с другом. Например по этому примеру видно страницы товара лежат в каталоге, а корзина никак к каталогу не относится.
Сложность структуры целиком зависит от вашего сайта, его — модное гос. слово — инновационности. Можно указывать не только вертикальные связи, но и горизонтальные, можно добавлять типы связей. Я уверен, что даже представить не могу того, что вы можете добавить в структуру.
Имея структуру сайта, можно легко сделать список типовых страниц. Типовая страница это то, как будут выглядеть все страницы с одинаковым функционалом. Яркий пример — страница товара. товаров может быть сколько угодно, но для всех одна типовая страница. У неё есть заголовок с названием товара, картинка и описание, например. Всё это выглядит одинаково, подставляются только нужные значения.
Список типовых страниц для приведённого примера:
1. главная страница
2. страница каталога
3. страница товара
4. страница новостей
5. страница новости
6. контакты
7. корзина
8. заказ
9. успешная покупка
10. отмена покупки
11. страница помощи
Список типовых страниц это не иерархический список, как структура. Это простое перечисление. Кстати, то, что есть в структуре не обязательно будет в списке типовых страниц. Например страница одной новости — она не всегда нужна, потому что новости маленькие и незначительные (и их редко кто читает, кроме участников). В большинстве случаев можно обойтись только странице всех новостей, где каждая новость будет подгружаться, а не выводиться на отдельную страницу. А может быть их будет больше, как например страница покупки — она может быть успешной, тогда будет выведено что купил наш дорогой гость и как ему это получить/оплатить и т.п. А что-то может пойти не так, и тогда там будет написано что всё, ничего не получишь, проваливай отсюда. Хотя конечно такие вещи в структуре лучше указывать, чтобы потом не запутаться и не пропустить что-нибудь.
После списка типовых страниц надо их все расписать подробно. Сначала описываете все вещи, которые будут постоянно на вашем сайте, я их называю «унифицированные элементы» в своих тэзэшечках. Там описываются шапка сайта, меню и подвал, всякие хлебные крошки и вылезающие раздражайки вроде «позвоните нам и он-лайн консультант бесплатно заменит половину окна на вашей даче, а потом перезвонит вам».
Кстати, по структуре сайта тут можно написать содержимое меню — посмотрите как список элементов меню легко пишется, глядя на структуру сайта, это же просто сказка! Сравните с ситуацией, когда вам надо писать ответ на вопрос «Какие пункты меню должны присутствовать на вашем сайте», вы сидите в каком то офисе, на вас смотрят, непроизвольно поторапливая, мысли совсем о другом, хочется ничего не забыть, но в голову лезет только слоган, который вы придумали поднимаясь на лифте.
Описание надо давать функциональное, что этот элемент должен делать, а не как он должен выглядеть. Например не «на серебристом фоне золотистые буквы» (дизайнеры, привет!), а «заголовок не должен сливаться с текстом страницы, должен выделяться», ведь заголовок для того и придуман, чтобы выделяться. После таких вот унифицированных элементов вы просто идёте по списку типовых страниц и последовательно описываете каждую. Что там должно быть, списочком, «текст, картинка, цена, ссылка на быструю покупку», потом каждый элемент описываете, если надо.
Итак, посмотрим к чему мы пришли к данному моменту. У нас есть подробное описание того, что нужно сделать, есть ясное понимание того, что получится в итоге. А мы либо вообще не платили web студии, либо платили по минимуму, только за разработку технического задания. Вспомните, я в начале статьи описывал типовой случай. У вас в начале есть больше, чем у большинства по итогам. И денег ушло на это гораздо меньше. Для тех, кто подумает в этом месте «но у них же есть какой то сайт, даже и плохенький, но на него можно ссылаться», скажу, что очень часто итогом такого сотрудничества после оплаты 3-10 тысяч долларов и нервотрёпки в течении 3-18 месяцев заказчик плюёт и обращается к другим «хорошим ребятам», которые говорят «нет, нам проще сделать всё сначала, так будет дешевле и быстрее». По секрету скажу, я был в роли ребят, от которых уходили и ребят, к которым приходили, и это нормально.
Дальше в ТЗ должно идти описание логики работы. В большинстве случаев логика минимальная. Например в интернет магазине это просто схема «товар — корзина — покупка», «скидку считать по формуле скидка=10% если общая сумма покупок за 10 лет больше 23$». Если у вас более интеллектуальная задумка, тот как раз тут место чтобы всё описать.
Далее идёт описание разработки сайта. То есть надо разбить на этапы, например «дизайн, вёрстка, программирование, тестирование, сдача», у каждого этапа написать что будет являться условием принятия работ этого этапа. Для примера для дизайна таким условием может быть «нарисованные и переданные заказчику в формате PSD и JPG все типовые страницы». Легко и просто. Согласитесь, так жизнь выглядит гораздо легче, чем без ТЗ.
В конце (да, а мы уже подошли к концу ТЗ, но статья ещё продолжается), оставайтесь на нашей волне, можно написать сроки, Тут можно вспомнить о том, что некоторые вещи можно делать параллельно, а некоторые только последовательно. Есть такая штука — диаграмма Ганта, по ней очень хорошо планируются такие этапы. В экселе она есть по умолчанию, там надо при создании документа выбрать шаблон документа «планировщик проекта (диаграмма Ганта)».
Составив план работ, вы знаете, что дизайн у вас будет 15, а врёстка, скажем 21, а если исполнители накосячат, то дизайн у вас будет 16 или 17 точно. При другом подходе вам говорят «сайт будет готов в октябре-ноябре, в крайнем случае в декабре», а в феврале только показывают первую версию, потому что «новогодние праздники же». Я считаю что так, как описано в этой статье, намного спокойнее.
Немного отвлекусь на сроки. Для выполнения ТЗ обычного сайта нормально давать 3-5 рабочих дня.
Теперь перейдём к определению качества ТЗ.
1. Всё, что написано в ТЗ должно быть обосновано. Это может быть текст вашей переписки по почте, или тот самый брифинг-опросник, или протокол встречи заказчика и исполнителя (да, в хороших студиях это в обязательном порядке). То есть идёт само ТЗ, а после него приложения, где в приложении 2, например, приведён протокол встречи от такого то числа. И в ТЗ в описании подвала описывается что подвал будет исчезать, если на него не наведена мышка. И тут же в ТЗ написано в скобочках — на основании пункта 3 приложения 2.
2. Все данные должны быть использованы. То есть если вы писали в письме, что хотите светлый сайт, получая ТЗ вы должны открыть раздел с описанием дизайна сайта и найти там, что сайт должен быть светлый. В противоположность этому, бывает что в ТЗ (если оно есть ещё), ничего такого не написано, но исполнители говорят — да мы помним, помним, всё будет хорошо. Так ненадёжно. Они и сами забыть могут, и у них дизайнер может поменяться, а новые не будет знать что вы договаривались о чём-то, ну и много разных других вариантов. всё что вы говорили должно быть записано в ТЗ в соответсвующем разделе.
3. ТЗ это справочник, а не рассказ. Если в нём повторяется одна и та же информация в разных разделах, то это лучше. чем по другому. Например то, что сайт должен быть светлым можно описать и в общих хотелках вначале, и в унифицированных элементах. Работа с ТЗ предполагается такая — исполнитель определённой работы по сайту открывает нужный ему раздел и получает всё, что ему нужно для работы. Ему не нужно помнить всё ТЗ, достаточно 2-3 страниц, которые касаются именно его. Он даже в целом может не знать для чего он это делает, может быть студия попросила внештатного специалиста помочь в трудном месте, но этих пары страниц ему должно хватить.
4. Как и везде, пафосные и бессмысленные слова не очень хорошо. В принципе каждый абзац должен быть для чего-то, и если этот абзац убрать, будет хуже. Например фраза «Сайт представляет собой аппаратно-программный комплекс, подключённый к международной сети Internet» — сегодня не имеет смысла и легко удаляется. Это просто индикатор, что ТЗ не очень хорошее.
5. Ну и само собой, в ТЗ должно быть всё, что понадобится для работы, а если такого нет, то должно быть указано, где это можно взять. Например можно сделать очень короткое ТЗ, где будет указано, что нужен клон другого сайта, но с изменённым логотипом. Всю информацию можно взять с копируемого сайта, понятно что делать и понятно какой должен быть результат. Поэтому такое ТЗ, даже если оно в одну строку, хорошее,
Я упоминал в начале статьи, что можно разные этапы давать разным исполнителям. Сейчас самое время рассказать как это лучше делать. Это очень просто. У вас есть основное ТЗ — берёте и дербаните его. Вот и всё.
Для дизайна копируете описания типовых страниц и общие требования к внешнему виду.
Для вёрстки копируете описания поведения сайта на этих типовых страницах (что где вылезает, что подмигивает, если есть), требования к вёрстке (не должен поддерживать InternetExplorer но должен открываться на айфончиках), прикладываете к этому то, что получили от дизайнера и отправляете верстальщику.
Программисту прикладываете к ТЗ что получили от верстальщика и отправляете.
И у вас есть сайт. Очень просто.
Приведу пример здесь пример ТЗ на дизайн для простого сайта. Начинается со слов «Заказчик работ ставит перед исполнителем следующие задачи:». Никакого ненужного вступления, сразу понятно, что требуется.
В этом ТЗ — задание на создание дизайнерской концепции, то есть общего стиля, и на сам дизайн.
После того, как описано что надо, сразу же идёт описание того, что нужно для начала работы. Предполагается, что это ТЗ будет выставлено на биржах фриланса и разослано знакомым дизайнерам. Они с первых же строк понимают, будут они это делать или нет, и не будет напрасно потраченного времени.
После того, как сказано что надо сделать чтобы начать работать, указано по каким критериям будет приниматься работа. Всё понятно, уже можно начинать делать.
Дальше идёт перечисления в целом, чтобы дизайнер знал, что разрабатывать, и более частные пожелания. Нет излишнего ограничения творческой личности, но в то же время чётко описано что должно быть в итоге.
Дальше идёт описание типовых страниц. Описание очень простое, только перечисление, что там должно быть. Как дизайнер захочет, так и нарисует, но он захочет так, как хочет заказчик, потому что эта работа будет в стилистике, утверждённой заказчиком, и есть требования к дизайну, на каждый не понравившийся элемент заказчик может указать пальцем и спросить — на основании чего вы сделали эту штуку. Если дизайнер ответственно подошёл к делу, то он сможет объяснить почему и зачем он так сделал.
Такое ТЗ занимает 4 страницы, обычном текстом и с нормальными заголовками, меньше одного дня работы. А позволяет сэкономить очень много времени и денег (на момент написания этого ТЗ заказчик ждал оплаченный сайт уже год, получил только одну версию, которая ему категорически не понравилась. Естественно про тех ребят он думает плохо, а они про него).
Вы заметили, что в тексте постоянно используется слова «легко» и всякие такие? Это потому что когда делаешь правильно, всё получается легко.
