Всем привет, мы веб-студия Mad Design - специализируемся на разработке веб-проектов. Около 75% наших клиентов, при обращении к нам, не предоставляют вообще никакого ТЗ на разработку веб-сайта, около 20% пишут как могут, и оставшиеся 5% приходят к нам с подробным ТЗ (спасибо вам большое!). Эта статья для тех, кто хочет самостоятельно написать ТЗ для разработки своего проекта! Лично мы в 99% случаев ТЗ разрабатываем бесплатно.
Давайте разберемся, как все-таки правильно писать техническое задание на разработку веб-сайта?
Есть 2 варианта:
1. Описать все очень подробно в свободной форме и отдать это подрядчику, подрядчик на основании этого составит для вас профессиональное ТЗ. Минус - за это нужно заплатить дополнительно.
2. Если средства ограничены, то можно попробовать это сделать самому, давайте разберемся пошагово как что и к чему?
Суть техзадания:
Ваша первоначальная задача донести до разработчика суть вашего проекта. Именно с этого должно начинаться любое техническое задание на разработку сайта.
Опишите в свободной форме свой проект, расскажите разработчику, что вы хотите получить от своего нового сайта (или доработки уже существующего) и каким его должен видеть посетитель.
Пример: «Будущий интернет-магазин кондиционеров будет служить основным инструментом для привлечения клиентов и увеличения продаж. От большинства конкурентов нас отличает наличие собственного сервисного центра и технический персонал прошедший обучение в Японии. Наш посетитель и потенциальный клиент должен с первого взгляда понять, что попал на сайт серьезной организации, однако серьезность не должна „давить“ — мы хотим произвести впечатление открытой компании с которой легко работать.».
Подобное описание даст разработчикам возможность прочувствовать что им предстоит сделать, а значит все дальнейшее описание будет восприниматься через призму этих ощущений и избавит от необходимости без видимых причин вдаваться в ненужные и путающие на начальном этапе подробности. Вышеописанное особенно актуально для дизайнеров.
Название, логотип, стиль и дизайн и их значение в техническом задании
Сообщите разработчику название вашего сайта, пришлите логотип и руководство по использованию фирменного стиля. Если логотипа и стиля нет, вполне возможно вам может помочь разработчик, или порекомендуют нужных специалистов. Как минимум, вы должны сообщить свои предпочтения по стилистике будущего проекта. Даже если у вас пока нет четкой определенности — вы сэкономите массу времени и себе и разработчику просто в свободной форме изложив свои соображения о том, как должен выглядеть ваш сайт.
Например: «Мы видим наш сайт в светлых тонах, без лишних деталей, возможно использование оранжевого цвета для выделения заголовков и других акцентов. Ссылки, кнопки, навигация — на усмотрение дизайнера.»
Постарайтесь объяснить разработчику в каких аспектах вы хотите точного выполнения описанного, а в каких даете творческую свободу. Это необходимо для того, что бы исполнитель знал, как вы отреагируете на то или иное решение. Будьте готовы, что не все из того что вы хотите получить при написании ТЗ в итоге будет гармонично выглядеть. В этом нет ничего страшного и опытный разработчик, как правило, еще на этапе согласования ТЗ или первых эскизов укажет на ошибку и предложит пути ее решения.
В идеале вам нужно достаточно подробно описать ваше виденье будущего дизайна, так же привести в техническом задании список сайтов (желательно, но не обязательно) тематически близких к вашему. Снабдить список из 5-10 сайтов краткими описаниями, например:
- www.site1 — нравится цветовая гамма и подача товаров, размер шрифтов мелковат.
- www.site2 — отлично реализован «быстрый заказ», все остальное ужасно.
- www.site3 — основной конкурент, все хорошо, но на него похожим быть нельзя.
Не перегружайте дизайнера информацией, хороший дизайнер уже «видит» ваш проект, постарайтесь не менять свои пожелания, в противном случае есть вероятность запутаться самому и запутать дизайнера, это приведет к потере времени. Вышеописанный минимум даст разработчику возможность проявить свой творческий потенциал и задать вам интересующие его уточняющие вопросы.
Структура и основная функциональность сайта или интернет-магазина
Опишите предполагаемую структуру будущего ресурса. Структура один из самых информативных и важных разделов в будущем техническом задании на разработку сайта или интернет магазина. Структуру проще всего описывать в древовидной форме, кроме того это достаточно наглядно и даст техническому специалисту основную информацию о предстоящей работе. Например:
1. О компании
1.1. Руководство 1.2. Вакансии
2. Каталог товаров
2.1. Микроволновые печи
2.1.1. Panasonic 2.1.2. Samsung 2.1.3. Daewoo
2.2. Водонагреватели
2.2.1. Проточные
2.2.1.1. Bosh
2.2.1.1.1. Проточный водонагреватель Bosh BX5L 2.2.1.1.2. Проточный водонагреватель Bosh BX10L 2.2.1.1.3. ...
2.2.2. Накопительные
2.2.3. Газовые проточные
3. Контакты
3.1. Схема проезда
Схематическая структура:
При наличии задач, разделов или функциональных элементов которые нельзя структурно описать в виде дерева, можно нарисовать схему (главное не перестарайтесь как в примере выше) или дать пояснения, например:
- У пользователя должна быть возможность заказать товар, как из списка товаров, так и из карточки товара.
- У пользователя должна быть возможность перейти в «корзину заказов» с любой страницы сайта.
- На страницах каталога, в разделе «пылесосы», а так же в карточках товаров под основным списком содержащим модели и характеристики должны отображаться мешки для пылесосов.
Уточнения
- Обязательно распишите все что нельзя увидеть на близких по тематике сайтах или может быть истолковано неоднозначно. Любые ваши идеи и ноу-хау — важны.
- Обозначьте примерный размер сайта в страницах, например — 10 обычных страниц с информацией и 990 страниц с описанием продукции в каталоге товаров.
- Не забудьте указать в техзадании и обсудить с разработчиком стратегию дальнейшего развития, продвижения и рекламы вашего проекта.
- Укажите, как именно вы хотите получить готовый проект, кто будет устанавливать его на хостинг и осуществлять дальнейшую техническую поддержку.
- Продумайте нужна ли на сайте регистрация для посетителей? Зачем она нужна вам, а чем она будет полезна посетителю.
- Ваш будущий интернет-магазин в перспективе будет доставлять товары почтой в любой уголок мира? Не забудьте предупредить об этом.
- Договоритесь, кто будет писать и подготавливать к публикации текстовое наполнение сайта, кто будет заполнять сайт.
Сроки и стоимость
Указывать или нет вилку цен, в которой вы готовы работать с выбранным исполнителем — ваше дело, не указав ее в техзадании вы можете выиграть в том случае, если разработчик назовет стоимость ниже, но рискуете недополучить то, что разработчик готов предложить за те деньги которые вы в действительности готовы заплатить. Указав примерную стоимость — даете разработчику возможность сразу не гадая предлагать вам решения в указанных ценовых рамках, экономя время обеих сторон. Кроме того, указание вилки цены не отменяет необходимость разработчика обосновать ту сумму которую он просит за свою работу.
Со сроками все еще проще — вы знаете, когда вы хотите получить проект и когда он будет по-настоящему необходим. Сообщите разработчику, что он вас очень обрадует сдав проект через 6 недель, но через 8 недель у вас «выставка» и к этому сроку проект должен быть готов обязательно.
Ваши контакты
Высылая или другим способом передавая разработчику техническое задание на разработку сайта не забудьте указать ваши контактные данные (как минимум имя, телефон, email) и удобное время связи. Это может выиграть время как при первоначальном ответе разработчика, так и во время дальнейших обсуждений деталей.
Заключение
Надеемся, что данным руководством по созданию предварительного технического задания мы не только поможем вам без лишних затрат времени и сил объяснить исполнителю суть и цели будущего проекта, но и на шаг приблизим к успешной реализации вашей задумки.
Если все же у вас планируется технически сложный проект, в этом случае рекомендуем вам все же потратиться и заказать разработку технического задания у исполнителя вашего проекта.
Команда веб-студии Mad Design благодарит вас за внимание и желает всем успехов и хорошего настроения!)
Заказчик не должен делать тз, не его работа.
И дополнительно платить не должен.
Вы ему сайт делаете нормальный или херню по его желанию? Тогда вы фиговая фирма. Человек может не смыслить ничего. Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект.
А инфо по сайту на этапе проектирования и анализа конкурентов собирается, это обычная практика.
"Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект."
Ну вон, Лебедев так работает со своими джипегами за 100к, вообще не слушая заказчика, а только убеждая всех (возможно, даже себя) что они выходят ох*енные. Скажем так, результаты весьма неоднозначные.
К сожалению, не вижу уже смысла спорить. Я уже понял, что у многих тут извращенный подход к ведению бизнеса, где главное нагреть заказчика, а не выполнить качественный проект, который будет выполнять свою роль.
Что ж Вы мне предлагаете сравнивать бомж-услугу от Лебедева, а не основные заказы? Я уверен, что там все тоже самое, только подход другой к первому этапу.
Я высказал свое мнение, что мороженщик, который пришел ко мне сделать сайт НЕ ДОЛЖЕН мне никакого ТЗ приносить. Это моя задача сделать сайт. Я соберу нужную мне информацию, продумаю компоненты необходимые, мы зафиксируем их набор и приступим к работе.
Ни в одной профессии нормальной заказчик не рассказывает, что нужно сделать детально, а только свои пожелания.
Так в том то и дело, что нагреть заказчика - это когда приходит к тебе мороженщик, а ты ему "объясняешь", что ему обязательно нужен Битрикс, чат-бот, "продающие тексты" и студийные фото на сайт. Потому что тебе, мол, лучше знать, как выглядит реально качественный продукт. А то, что это всё не окупится, а Битрикс вообще ущербен, это уже будут его проблемы.
И вот чтобы этого избежать, заказчику и приходится оформлять свои пожелания в виде чёткого ТЗ, которое можно разослать в несколько студий и сравнить цены и подходы.
Но да, если вы считаете 100к за логотип "бомж-услугой", то тут и в самом деле нет смысла спорить. Желаю вам больше заказчиков, которые разделяют подобное убеждение.
Именно в студии Артемия - это бомж-услуга. Она даже позиционируется также. Это не к моему мнению.
Ох) При чем тут Битрикс?:) Как раз когда люди приходят и говорят то, что им нужно - то от этого уже и исходит выбор системы управления и набор компонентов. Тебе описывают желание, ты уточняешь определенный перечень вопросов, после чего предлагаешь решение. Это работает именно так.
А вот ВПАРИВАТЬ, как Вы описали - как раз и есть нагревание заказчика.
Ты не заставляешь человека работать с тобою. Он также может пойти и по сравнивать предложения в других местах.
Он знать не знает, что такое функциональные и нефункциональные требования, которые должны быть прописаны в ТЗ.
Назовите тогда это не ТЗ, а список задач. У ТЗ есть четкий ГОСТ - несколько вариаций, которые нужно использовать.
Видите, Вы описываете, видимо, со своей позиции - впарить услугу, получить заказ.
Я работаю по-другому, если Вы чекать бегали мои соцсети:)
Я откажусь от заказа, если человеку проще его на WP сделать, о чем ему сразу и скажу.
В этом и есть смысл качественной услуги, когда ты ставишь себя на место заказчика и печешься о его бизнесе.
Ну и про Битрикс:) Не вижу смысла спорить или еще что-то писать по этому поводу. Люди его используют. Самая активная CMS в России. Заказы есть. Почему бы не работать с этой системой. Мне нужно семью кормить:) Если платформа дает такую возможность - грех ей не воспользоваться.
Извращенный подход к ведению бизнеса?! Ты что, етить тебя за ногу, несешь, щегол? :'D
У меня от тебя лицо краской заливается, каждый новый перл лучше предыдущих двух.
У тебя в профиле «1С-Битрикс (веб-программист)», не удивительно, что ты защищаешь это кусок распила бюджета :) И Битрикс только в РФ и известен, потому что лоббировали его активно.
Ну да, что тут непонятного? Я вижу, что мне какие-то дурацкие примеры приводят, но ни одного реального аргумента за то, что у заказчика на старте есть готовое ТЗ.
Хорошо, что я вызываю у тебя какие-то эмоции. Жаль, что они негативные.
Да, так и написано, верно.
Я не защищаю, я работаю с этой технологией. Есть люди, которые с ней работают. Есть люди, которые работают на ней. В чем проблема-то?
Я работаю в РФ, поэтому мне не интересно, что там вне, к сожалению.
Как этот комментарий соотносится с изначальной темой обсуждения, я не понимаю.
Почему такая желчь? Зачем переходить на личности?
Ну посмотрел мой профиль, ок. Ну не любишь битрикс, ок. Зачем об этом писать, аки черт? Люди им пользуются, платят за это. Мне нужно зарабатывать. Не вижу тут каких-то проблем.
Умный человек бы помог другому, если бы считал, что тот неправ, а не старался его обосрать.
Потому что я злой и желчный человек, очевидно же :)
Сейчас уже все мысли, доводы и выводы смешались в кучу, вместе с конями.
Главный посыл, лично мой, что
* классического «ТЗ» — 990 страниц сухого текста — уже много лет нет;
лично я в работе зачастую руководствуюсь вообще только подробным прототипом (Axure RP), этого хватает для покрытия большинства вопросов.
* ГОСТы — говно, забудь про них;
* «ТЗ» может быть и на салфетке, если оно отвечает на ряд ключевых вопросов, типа, че делать будем?;
* словосочетание «техническое задание» лучше заменить на «агрегацию требований» и раскрыть его там максимально широко (исходя из доступных компетенций);
* работа по составлению «ТЗ» должна быть оплачена или уже заложена в стоимость;
Что касается Азата, или как ты там назвал свою условную ЦА, то у него ты все равно спрашиваешь, что надо делать и как это должно выглядеть. Это и есть первый шаг в формировании ТЗ, и его совершает заказчик.
Так статья о том, что Азат УЖЕ С ТЗ ДОЛЖЕН приходить!
И в ТЗ, как пишут в статье, он приносит СТРУКТУРУ!
Откуда чертов продавец овощей оптом знает, какие разделы ему сделать?
Да он интернет только через ОК.ру видел, а сайт ему сына сказал сделать.
Ну опишет он тебе цвет - белый на оранжевом. Ты это сделаешь? Да кому нужен такой разработчик, который любое г сделает.
Я слишком утрирую пример, но любому человеку, который посмотрит на мир с другой точки зрения это ясно.
При чем тут вообще форма ТЗ, когда мы говорим о конкретном моменте, что заказчик ДОЛЖЕН принести ТЗ (так еще не абы какое, а четкое) РАЗРАБОТЧИКУ.
Не вместе составить, а уже с готовым приходить.
Это первый же абзац статьи, где владелец студии сетует, какие заказчики нехорошие, что не тащат ТЗ.
В моем первом же комментарии написано, что сбор информации - это стандартный процесс, но никак не заказчик приходит с ТЗ.