Техническое задание на создание дизайна интернет-магазина

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

Сейчас магазин находится на стадии «перед дизайн». А значит необходимо писать техническое задание на дизайн.

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

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

Собственно, что такое техническое задание?

Согласно Wiki, техническое задание — это исходный документ для разработки информационных систем.

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

На сегодняшний день часто можно услышать вопрос: «какое оно идеальное ТЗ? и где можно взглянуть на образец?».
Я склонен считать, что идеального технического задание не существует. Это крайне индивидуально для каждого проекта. А так же это крайне индивидуально от студии к студии, от менеджера к менеджеру.

Основная проблема в том, как правильно делать техническое задание?

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

Ознакомившись с документом, становится ясно, что составление технического задания на Интернет магазин это задача весьма затратная. Полное и правильное написание разделов технического задания требует наличия специалистов: менеджер проекта, маркетолог и/или PR-менеджер и/или т.д., технолог, финансист. Получается, что штат среднестатистической студии разрастается еще на три специалиста (считаем, что менеджер проекта есть). Это не дешевое удовольствие, потому такие разделы как: основания для разработки, назначение разработки, экономические показатели, оставляют на усмотрение клиента, который этим заниматься никак не будет. Получается «имеем то, что имеем». А после небольшого срока эксплуатации студия получает претензии: «почему у нас не покупают через сайт ничего? Вы нам плохой сайт сделали!», «Сайт не выполняет свои цели! Вы сделали плохой сайт!».

Три методоа работы:

Я знаю о трех методах работы. В некотором виде это эволюционная цепочка.

1. Техническое задание не пишется вообще. Клиент рассказывает на словах чего надо. Менеджер передает на словах/e-mail/ICQ непосредственному исполнителю. Клиент получает результат.

Позитив:

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

Негатив:

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

2. Техническое задание не составляется в явном виде документа (либо носит форму брифа и не содержит всех деталей). Клиент заполняет бриф, менеджер проводит «допрос» и делает заметки. Этот материал и устные дополнения уходят непосредственному исполнителю. Клиент получает результат.

Позитив:

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

Негатив:

  • возрастает цена, т.к. менеджер тратит на Вас больше времени, делая записи;
  • в ходе исполнения, менеджер всегда может отказаться от изменения чего-то, что в брифе написано Вашей рукой;
  • в мелочах Вы можете проиграть, т.к. доказать говорили Вы это или нет — невозможно, есть только бриф. Максимум будет набросок на бумаге. Клиенту: храните у себя копии всех бумажных документов/записок/приписок/набросков и т.д.

3. Техническое задание составляется в полном объеме и является документом, на котором ставится печать.

Позитив:

  • Вы четко представляете все: что будет в конце, сроки, качество, документация и т.д.;
  • Вы получите ровно то, что хотели!

Негатив:

  • это дорого стоит;
  • это занимает больше времени;
  • это скучно и под конец начинает надоедать.

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

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

Скачать «Техническое задание на создание дизайна интернет магазина»

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

Реальные кейсы роста продаж
и повышения конверсии!

Узнайте как другие увеличивают продажи на 10%, 30%, 50% или даже в 2 раза!

100% без спама!

  • Почему?

  • Я бы не смог такой заказ выполнить.

  • Согласен с тем, что каждый должен заниматься своим делом.

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

    > Если пригрузил – то…
    Наоборот. Приятно читать мысли основанные на личном опыте ;)

  • Согласен с тем, что каждый должен заниматься своим делом.

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

    > Если пригрузил – то…
    Наоборот. Приятно читать мысли основанные на личном опыте ;)

  • Дима

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

    to Sergey

    > Дело менеджера — управлять, а не писать ТЗ
    — Солидарен с Вами.
    ————————-

    > в ТЗ, в самом конце документа, есть лист изменений
    — На это ответить не могу, так как за период своей работы, нормального ТЗ не видел вообще. Возможно, есть, а вернее, было бы логичнее всего, предусмотреть такой лист.
    ————————-

    >По поводу, сколько я сайтов написал и сколько написал ТЗ — это лишнее. Это же не предмет спора, не так ли?
    — Согласен. Просто я возможно не до конца, либо не совсем правильно выразил свою мысль.

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

    Сейчас я немного отойду в сторону от темы этой статьи.

    Самые страшные сайты получаются у тех, кто приходит с своим заданием, либо «четким виденьем» своего проекта.
    Хуже всего, когда ответственным лицом, с стороны клиента, является бывший программист любитель – это куча несуразных идей, реализация которых требует огромных «трудоресурсов», которые не приносят ни одного улучшения…
    Лучшие сайты из моей практики, получились у тех, кто приходит и говорит:
    «Мы не разбираемся в сайтах, потратить можем приблизительно столько ХХХХ. Создайте сайт, чтоб он принес дополнительных клиентов».
    На таких клиентов можно реализовать весь свой потенциал, им охота помогать, а не выполнять технические действие.

    Основной мыслю всего выше написанного является 2 вещи:
    1. Если Вы в какой-то сфере не профессионал – то будьте профессионалом в какой-то другой сфере.
    Если ты умеешь хорошо копать ямы, но не умеешь садить деревья, хотя много раз видел, как это делается, то копай хорошо! На столько хорошо, чтоб заработать денег столько, чтоб прейти к профессионалу по посадке деревьев и не давать задание, как нужно полить дерево, а дать денег, показать цель (например, засадить весь сад яблонями), И пойти копать яму дальше.

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

    Спасибо за внимание. Если пригрузил – то… Ну что ж, что сделано, то сделано =)

  • Дима

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

    to Sergey

    > Дело менеджера — управлять, а не писать ТЗ
    — Солидарен с Вами.
    ————————-

    > в ТЗ, в самом конце документа, есть лист изменений
    — На это ответить не могу, так как за период своей работы, нормального ТЗ не видел вообще. Возможно, есть, а вернее, было бы логичнее всего, предусмотреть такой лист.
    ————————-

    >По поводу, сколько я сайтов написал и сколько написал ТЗ — это лишнее. Это же не предмет спора, не так ли?
    — Согласен. Просто я возможно не до конца, либо не совсем правильно выразил свою мысль.

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

    Сейчас я немного отойду в сторону от темы этой статьи.

    Самые страшные сайты получаются у тех, кто приходит с своим заданием, либо «четким виденьем» своего проекта.
    Хуже всего, когда ответственным лицом, с стороны клиента, является бывший программист любитель – это куча несуразных идей, реализация которых требует огромных «трудоресурсов», которые не приносят ни одного улучшения…
    Лучшие сайты из моей практики, получились у тех, кто приходит и говорит:
    «Мы не разбираемся в сайтах, потратить можем приблизительно столько ХХХХ. Создайте сайт, чтоб он принес дополнительных клиентов».
    На таких клиентов можно реализовать весь свой потенциал, им охота помогать, а не выполнять технические действие.

    Основной мыслю всего выше написанного является 2 вещи:
    1. Если Вы в какой-то сфере не профессионал – то будьте профессионалом в какой-то другой сфере.
    Если ты умеешь хорошо копать ямы, но не умеешь садить деревья, хотя много раз видел, как это делается, то копай хорошо! На столько хорошо, чтоб заработать денег столько, чтоб прейти к профессионалу по посадке деревьев и не давать задание, как нужно полить дерево, а дать денег, показать цель (например, засадить весь сад яблонями), И пойти копать яму дальше.

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

    Спасибо за внимание. Если пригрузил – то… Ну что ж, что сделано, то сделано =)

  • to Дима: очень приятно, что менеджеры комментируют блог, значит хоть что-то есть интересное :)

    То, что Вы работаете по второму методу, это нормально. Большинство компаний так работают.

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

    > Вы серьезно разбираетесь в сайтах и сходу учтете все нюансы и напишите ТЗ, то это ошибка!

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

    По поводу, сколько я сайтов написал и сколько написал ТЗ — это лишнее. Это же не предмет спора, не так ли?

    Буду рад, если Вы напишете Ваше мнение по поводу моих мыслей о ТЗ в посте: http://openingnewshop.com/2009/01/05/lirika-texnicheskoe-zadanie/

  • to Дима: очень приятно, что менеджеры комментируют блог, значит хоть что-то есть интересное :)

    То, что Вы работаете по второму методу, это нормально. Большинство компаний так работают.

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

    > Вы серьезно разбираетесь в сайтах и сходу учтете все нюансы и напишите ТЗ, то это ошибка!

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

    По поводу, сколько я сайтов написал и сколько написал ТЗ — это лишнее. Это же не предмет спора, не так ли?

    Буду рад, если Вы напишете Ваше мнение по поводу моих мыслей о ТЗ в посте: http://openingnewshop.com/2009/01/05/lirika-texnicheskoe-zadanie/

  • Дима

    Я как человек, который работаю менеджером в одной из компаний, которая занимается разработкой сайтов (названия писать не буду, дабы не было рекламы). Хочу сказать, что лучший из 3-х методов, это №2

    Метод №1 я вообще рассматривать не хочу (он похож на №2, но в облегченной версии, если я правильно понял суть описанного выше).

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

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

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

  • Дима

    Я как человек, который работаю менеджером в одной из компаний, которая занимается разработкой сайтов (названия писать не буду, дабы не было рекламы). Хочу сказать, что лучший из 3-х методов, это №2

    Метод №1 я вообще рассматривать не хочу (он похож на №2, но в облегченной версии, если я правильно понял суть описанного выше).

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

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

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

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

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

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

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

  • Такое есть. Если в ТЗ написано все до последней строчки. Но есть и решение этого. Я в ТЗ часто записываю такие фразы: «чего-то там — на усмотрение дизайнера».

  • Такое есть. Если в ТЗ написано все до последней строчки. Но есть и решение этого. Я в ТЗ часто записываю такие фразы: «чего-то там — на усмотрение дизайнера».

  • Про ТЗ я бы сказал так:

    Позитив:
    Вы получите ровно то, что хотели!
    Негатив:
    Вы получите ровно то, что хотели!

  • Про ТЗ я бы сказал так:

    Позитив:
    Вы получите ровно то, что хотели!
    Негатив:
    Вы получите ровно то, что хотели!