Маркетинг Леонид Царев
2 845

Как правильно писать техническое задание на разработку веб-сайта

Всем привет, мы веб-студия 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 благодарит вас за внимание и желает всем успехов и хорошего настроения!)

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Леонид Царев", "author_type": "self", "tags": [], "comments": 62, "likes": 20, "favorites": 160, "is_advertisement": false, "subsite_label": "marketing", "id": 51971, "is_wide": false, "is_ugc": true, "date": "Wed, 28 Nov 2018 12:24:20 +0300" }
{ "id": 51971, "author_id": 195045, "diff_limit": 1000, "urls": {"diff":"\/comments\/51971\/get","add":"\/comments\/51971\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/51971"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199113, "possessions": [] }

62 комментария 62 комм.

Популярные

По порядку

Написать комментарий...
7

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

Можно написать небольшое ТЗ бесплатно, или написать большое - и не оплачивать его, если с авторами заключается контракт, но тем не менее.

Логичное и емкое обоснование того, что ТЗ также стоит денег, как и любая работа.

Ответить
0

Все верно. Такое часто бывает. ТЗ только после оплаты.

Ответить
4

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

Ответить
9

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

Ответить
–2

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

Ответить
5

Заказчик не должен делать тз, не его работа.

И дополнительно платить не должен.

Это феерическая чушь, Андрей.

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

Если клиент не знает, чего хочет, то итоговый результат контролировать не реально, и всё это может закончится, в лучшем случае, сорванными сроками, а в худшем — судом.

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

Ответить
1

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

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

Он расскажет то, что хочет. Вы ему предложите варианты. После обсуждения придете к единому мнению. Зафиксируете. Продолжите работу.

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

Ответить
1

Во-первых, не «В»ыкай мне :)

Во-вторых, агрегация требований и техническое задание — это синонимы.

В-третьих, под агрегацией требований подразумевается совокупная работа по сбору и фиксации информации по проекту: цели, задачи, портрет ЦА, анализ конкурентов, mind-map структуры, mood-board для концепции дизайна и прочее и прочее.

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

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

В-шестых, контролирование результата — это боль и моя и клиента. Но тут тебя уже куда-то несет не туда :) Ибо, формирования списка требований и набора функций есть частью составление «ТЗ».

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

Ответить
0

Где же я Вам тыкаю-то, уважаемый?)
Предложения, где обращение идет к Вам - на Вы:)

Не синонимы. Одно свободную форму имеет, второе по ГОСТУ.

Логично, все верно.

К чему это? Не ясно. Пришли в фирму - Вы полный спектр услуг оказываете.

Правильно, заплатит в виде проектирования (или агрегации требований по-вашему), но это происходит в процессе работы с Вами. Все верно. Я где-то другое пишу? Я пишу, что заказчик изначально НЕ ДОЛЖЕН приносить никакого ТЗ. Все, именно это в любом предложении.

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

Опять же тыкаете, давайте будем на Ты? Я рад знакомству, реально зовут Андрей, можете обращаться, рад общаться с умными людьми.
Отлично, спасибо за просмотр. Я только пытаюсь побороть свое стеснение, поэтому там ничего интересного, но, надеюсь, со временем смогу что-то полезное донести.
Ну да, закончил универ и сразу на работу. До этого пытался фрилансить)
Кто ж себя убил? Я всегда занимался самообразованием, а на работе я сидел на жопе в техподдержке и выполнял одни и те же задачи. По факту моя работа текущая мало чем отличается, вопрос только в количестве свободного времени и оплате труда.
Не всем суждено или хочется в Москву, я живу тут, есть ипотека:) Мне нужно это оплачивать. На работе в 40к это сделать сложно) И как раз на работе я перестал развиваться. Да, была какая-то сетка развития до условного сеньора, но я понимал, что это не то.
Поэтому выбор на фриланс очевиден. У тебя полно времени, у тебя существенно больше денег, у тебя интересные проекты, общение с людьми.

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

Но буду рад услышать иную точку зрения:)

Ответить
0

В общем, я тебе про мягкое, а ты мне про тёплое.
Поговорим через пять лет :)

Ответить
0

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

Можете мне на почту или в вк написать (или любой месседжер), когда появится желание:) Рад общению с умными людьми.

Ответить
0

Не серчай, я не хотел тебя чем-то обидеть.
Подъебать, да, чуток ;)

И точно не с позиции «царь».
Мы все были студентами, и многие познавали себя в самообучении. Это заебись, если хватает дисциплины.

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

Ответить
0

Не знаю, в паре сообщений писать про Битрикс-программиста в кавычках с попутным опусканием оного - думаю, положительно это оценить нельзя.
Думаю, тут цель именно зацепить.
Чем меня подепать можно? Я этим деньги зарабатываю в глуши, где моя зп в 3-5 раз больше, чем можно получать.
Я не хочу быть всю жизнь Битриксоидом.
В том же профиле указано, что я и со стандартными web-технологиями работаю, и android изучаю.
А как до дела дошло, чтобы показать плюсы студий - так как-то не очень.
Высмеять, а по аргументам никак - это плохо.

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

Ты сам пишешь, что вы с ним вместе собираете эту инфу, при этом не соглашаешься с моими комментами и минусишь их? Это как понять-то? Если ты сам подтвердил, что говорим одно и тоже.

Ответить
0

Прошу прощения, думал, что на Вы хотите:) Приучили на Вы писать незнакомым.

Ответить
0

Незнакомым людям пишут просто «вы», а не «Вы». С большой буквы пишут только если охуеть-как-уважают собеседника, либо хотят поглубже засунуть язык в порыве лести и учтивости. Ага :)

Ответить
0

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

Ответить
4

В России если не объяснишь подробно, то херню сделают

Ответить
2

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

Ответить
–2

Так я и не спорю) Я о другом. По своему опыту, даже если объяснишь дизайнеру и сценаристу подробно его задачу - с первого раза все равно никто не сделает

Ответить
1

Тут всего 3 варианта:
* вы занимаетесь самодурством и на деле реально плохо объясняете;
* ваши требования не укладываются в бюджет;
* вы работаете со вчерашними студентами, которые считают, что ТЗ не должно оплачиваться :)

По моему же опыту, если четко описать задачу, провести подготовительную работу (прототип, концепция) и приложить референсы, то результат контролируется почти на 100%

Ответить
–1

бред. мы не в идеальном мире живем

Ответить
0

не пиши, пожалуйста, свою ерунду

Ответить
1

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

Ответить
2

Андрей, доля правды есть, но судя по вашему ответу бригада, которя делает ремонт должна делать дизайн-проект квартиры?

Ответить
9

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

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

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

Ответить
4

Георгий, тут речь о другом.
Сайт - это технически сложный продукт. Очень большое кол-во закзачиков вообще не знают чего хотят. Мы советуем, разбираем, предлагаем. Есть очень сложные проекты с личным кабиентом - под такие проекты уже нужно закладывать бюджет на рзарбаотку ТЗ т.к. личный кабинет может стоить в разработке от 50.000 до бескончености, ТЗ может составляться больше 20 рабочих дней - такое ТЗ бесплатно делать никто не будет, мы же все-таки не агенство добрых дел. Сравнивать веб с кухнями и прочим - это не то. Кухни - там все стандартно, есть полки, шкафы ручки - сайт - это техничсеки сложный продукт и под каждый преокт нужно свое решение предложить. Статья для тех, кто хочет просто понять как правильно писать ТЗ и все)

Ответить
0

Согласен. Но для меня как заказчика одинаково "херпойми" что сделать тз для кухни что для сайта.
Ну прикинь расписать какие палки нарезать для того что бы это все собралось в 3х стенную кухню и все мм в мм.
Мне кажется я быстрее для сайта тз накатаю )))

Ответить
0

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

Ответить
0

Ну вот, ты просто не понимаете, о чем говорите :)

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

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

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

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

А если вы ИП, вы знаете, что такое 54-ФЗ, у вас договор с Яндекс.Кассой и ваши деревянные хуи уже не только из ясеня, но и из берёзы, да еще и гравировку нанести можно, и подарочную упаковку, и доставку до квартиры в тёмном пакете. Тогда это уже сайт со сложным функционалом, который так же можно реализовать минимум 5 способами.

Сечете, о чем я?
Сравнивать разработку сайта с заказом кухни — это, мягко говоря, не правильно.

Ответить
–1

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

Ответить
1

Андрей - это статья для тех, кто хочет сам научится псиать ТЗ) Я не писал о том, что именно мы берем за это деньги. Мы всегда лояльны и если проект не сложный - ТЗ делаем БЕСПЛАТНО)

Ответить
0

Я понимаю, но заказчик НЕ МОЖЕТ составить тз. Это не его работа, а разработчика, которая выполняется на этапе проектирования в любом случае.
Мы говорим о граммотном подходе, а не попытке нагреть человека.

Ответить
3

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

Ответить
–1

Я зацепился за первый абзац статьи, где заказчик должен притащить ТЗ, которое он априори не должен составлять сам.
И слово зацепился не очень уместно, я высказал мнение, что данную процедуру делают разработчики, учитывая, что в 90% случаев конечный сайт отличается от начального, если проект действительно большой и сложный.

Ответить
2

Это чушь.

Да, заказчик не должен выбирать за разработчика стек технологий, но должен сказать, что вот эта хуйета должна мигать в такт той хуеты. А вот этот вот раздел должен содержать вот такую вот инфу.

Это и есть ТЗ.
Ну, в широком его смысле, а не ебучуй манускрипт на 990 страниц :)

Ответить
0

У каждого свое мнение. Навязывать одно другому - вот действительно чушь:)

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

ТЗ - это есть ТЗ, Техническое Задание. Есть несколько Гостов, которые описывают его содержание и структуру.
Тогда это нужно не ТЗ называть, все-таки терминология единая.

Ответить
2

Святые печеньки, забудь про ГОСТЫ, друг!
В реальной разработке сайтов ГОСТов нет, лол :)

Под ТЗ подразумевается любая структурированная информация, которая поможет и нам и вам в разработке вашего-нашешл проекта. А не, как я уже писал, 990 страниц мудацкого сухого текста.

Там столько всего, что проще это называть одним словосочетанием «техническое задание». И это не «мнение», а реалии рынка.

PS: если мигающая хуета не к месту, ясен перец клиенту будет максимально доступно это объяснено. Но тут нужен опыт, чтобы сделать это красиво и грамотно.

Ответить
0

Я не понимаю, что все мне дичь какую-то пишут:)

Я написал, что не согласен с тем, что заказчик должен приносить ТЗ.

Я себе не представляю, как какой-то Азат из продуктового приносит мне структуру сайта. Это так-то задача сеошника собрать семантическое ядро, а не Азата. Он тупо не знает, что нужно для его бизнеса на сайте.

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

Ответить
0

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

ТЗ не забота заказчика.

Ответить
0

"Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект."
Ну вон, Лебедев так работает со своими джипегами за 100к, вообще не слушая заказчика, а только убеждая всех (возможно, даже себя) что они выходят ох*енные. Скажем так, результаты весьма неоднозначные.

Ответить
–1

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

Ответить
3

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

Но да, если вы считаете 100к за логотип "бомж-услугой", то тут и в самом деле нет смысла спорить. Желаю вам больше заказчиков, которые разделяют подобное убеждение.

Ответить
0

Именно в студии Артемия - это бомж-услуга. Она даже позиционируется также. Это не к моему мнению.

Ох) При чем тут Битрикс?:) Как раз когда люди приходят и говорят то, что им нужно - то от этого уже и исходит выбор системы управления и набор компонентов. Тебе описывают желание, ты уточняешь определенный перечень вопросов, после чего предлагаешь решение. Это работает именно так.
А вот ВПАРИВАТЬ, как Вы описали - как раз и есть нагревание заказчика.
Ты не заставляешь человека работать с тобою. Он также может пойти и по сравнивать предложения в других местах.
Он знать не знает, что такое функциональные и нефункциональные требования, которые должны быть прописаны в ТЗ.
Назовите тогда это не ТЗ, а список задач. У ТЗ есть четкий ГОСТ - несколько вариаций, которые нужно использовать.

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

Ну и про Битрикс:) Не вижу смысла спорить или еще что-то писать по этому поводу. Люди его используют. Самая активная CMS в России. Заказы есть. Почему бы не работать с этой системой. Мне нужно семью кормить:) Если платформа дает такую возможность - грех ей не воспользоваться.

Ответить
0

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

Извращенный подход к ведению бизнеса?! Ты что, етить тебя за ногу, несешь, щегол? :'D

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

У тебя в профиле «1С-Битрикс (веб-программист)», не удивительно, что ты защищаешь это кусок распила бюджета :) И Битрикс только в РФ и известен, потому что лоббировали его активно.

Ответить
0

Ну да, что тут непонятного? Я вижу, что мне какие-то дурацкие примеры приводят, но ни одного реального аргумента за то, что у заказчика на старте есть готовое ТЗ.

Хорошо, что я вызываю у тебя какие-то эмоции. Жаль, что они негативные.

Да, так и написано, верно.
Я не защищаю, я работаю с этой технологией. Есть люди, которые с ней работают. Есть люди, которые работают на ней. В чем проблема-то?
Я работаю в РФ, поэтому мне не интересно, что там вне, к сожалению.

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

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

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

Ответить
0

Потому что я злой и желчный человек, очевидно же :)

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

Главный посыл, лично мой, что
* классического «ТЗ» — 990 страниц сухого текста — уже много лет нет;
лично я в работе зачастую руководствуюсь вообще только подробным прототипом (Axure RP), этого хватает для покрытия большинства вопросов.

* ГОСТы — говно, забудь про них;

* «ТЗ» может быть и на салфетке, если оно отвечает на ряд ключевых вопросов, типа, че делать будем?;

* словосочетание «техническое задание» лучше заменить на «агрегацию требований» и раскрыть его там максимально широко (исходя из доступных компетенций);

* работа по составлению «ТЗ» должна быть оплачена или уже заложена в стоимость;

Что касается Азата, или как ты там назвал свою условную ЦА, то у него ты все равно спрашиваешь, что надо делать и как это должно выглядеть. Это и есть первый шаг в формировании ТЗ, и его совершает заказчик.

Ответить
0

Так статья о том, что Азат УЖЕ С ТЗ ДОЛЖЕН приходить!
И в ТЗ, как пишут в статье, он приносит СТРУКТУРУ!
Откуда чертов продавец овощей оптом знает, какие разделы ему сделать?
Да он интернет только через ОК.ру видел, а сайт ему сына сказал сделать.
Ну опишет он тебе цвет - белый на оранжевом. Ты это сделаешь? Да кому нужен такой разработчик, который любое г сделает.

Я слишком утрирую пример, но любому человеку, который посмотрит на мир с другой точки зрения это ясно.

При чем тут вообще форма ТЗ, когда мы говорим о конкретном моменте, что заказчик ДОЛЖЕН принести ТЗ (так еще не абы какое, а четкое) РАЗРАБОТЧИКУ.

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

Ответить
0

Не соглашусь.
Мы берем за проектирование деньги, это составляет около 15% от бюджета на разработку. Сюда входит аналитика, написание тз, прототипирование, дизайн концепция.
Если называть "ТЗ" то, что обычно дает заказчик, то да, это не стоит таких денег. Но и пользы от такого документа нет )

Ответить
2

"10 обычных страниц с информацией и 990 страниц с описанием продукции в каталоге товаров."

Что-то я раза 3 перечитал и не могу понять, 990 страниц что? Это в нормальной ситуации 10 страниц + один шаблон страницы товара. Хотя, наверное можно с заказчика брать как за отдельные 🤣

Ответить
0

Это очень абстрактно, пример 10 уникальных страниц и 1000 единиц товара = 1000 внутренних типовых страниц, это имеется ввиду

Ответить
1

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

Ответить
1

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

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

Для сайта важнейшей является нефункциональная сторона. И если заказчик не сформулирует свои бизнес-требования к характеристикам качества, то может жестоко за это поплатиться.

Например:

Производительность - ожидаемая скорость загрузки и отрисовки страниц, ожидаемое количество посетителей среднее и пиковое.

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

Защищённость - как будут защищены данные пользователей и заказчика на разных этапах их обработки.

Ну и далее по списку, например, стандарта ISO 25010.

Очень актуальная на сегодняший день тема - соответствие законодательству. В первую очередь, поддержка требований закона о персональных данных и GDPR. Если на сайте что-то продаётся, то ещё и способы реализации 54-ФЗ.

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

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

Ответить
1

ТЗ уже прошлый век. У меня опыт ведения проектов с трудозатратам в тысячи часов. Под конец большого проекта, сам проект уже не напоминал первоначальное ТЗ. Куча дополнительных документов, уточнений и изменений в проекте. В свете современных технологий удобнее и нагляднее это прототипы, например, в Axure. Клиент видит как ведёт себя интерфейс, можно покликать. А ТЗ выкиньте, старое это все.

Ответить
1

Все в кучу свалили.
1.Заказчик приходит с запросам сделать сайт, в идеальном мире каждый занимается своим делом заказчик вообще не должен ничего понимать в сайтах.
2.Включается pre-sale. Вы направляете ему ему бриф, где с помощью отточенных вопросов собираете с заказчика информацию о концепции
3. Pre-sale агрегирует данные, на основании этого составляет карту функциональных и нефункциональных требований к продукту, делает первоначальную грубую оценку стоимости (обычно вилкой) и сроков. Апрувит с заказчиком данные параметры, если все хорошо делаем точную оценку
4. Pre-sale / sale делает точную оценку проекта, составляет красивое КП с разбивкой по этапам (проектирование и дизайн, разработка, интеграции, внедрение), описывает работы в рамках этапа, возможно узнает у разработки загруженность, и информирует клиента о том когда готовы приступить. Апрувит это все у заказчика, если все круто, получаем предоплату и переходим к аккаунту.
5. Аккаунт принимает клиента, дополнительно апрувит функциональные требования, передает коллегам для разработки высокуровнего и низкоуровнего технического задания на сайт и на интеграции, параллельно дизайнеры брифуют клиента.
6. И дальше в разработку.

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

Ответить
1

Довольно спорная статья в которой описан устаревший подход.

Из своего опыта могу сказать, что этап проектирования сайта всегда должен быть платным и за него нельзя брать меньше 50 000 руб (даже за лендинг) За крупный проект от 100-150к. Хотя бы для того, чтобы обезопасить себя от времени, потраченного на обсуждение проекта и составление сметы.

Кроме того, на этапе проектирования надо сделать структуру сайта в Mind Map и сделать прототип будущего сайта. Без этого невозможно поставить ТЗ на дизайн и дальнейшие этапы работы.

А сроки лучше всегда говорить финальные после завершения этапа "проектирование", а до этого обсуждать только вилку "от ххх и до ххх".

И за любую работу надо платить)

Ответить
0

Вот это веселая паутина)

Ответить
0

Должно же быть хоть что-то позитивное в статье и в жизни)

Ответить
0

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

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

Мы всегда фиксируем в договоре:
- всю структуру сайта (с припиской что наименования могут быть изменены)
- общий перечень и подробное описание каждого модуля, какие поля, условия обработки полей, связь с другими модулями, доп. условия обработки данных из каждого поля (это примерно 80% всего ТЗ)
- список прототипов и макетов сайта, которые мы обязаны сделать + кол-во правок к макетам
- список индивидуальных страниц без связи с модулями
- объем наполняемых страниц, и наполняемого каталога (если он есть) в кол-ве страниц.

Этого нам ВСЕГДА хватает, что бы очертить наш объем работ и результат для заказчика.
Единственный нюанс - дизайн. В 90% случаев приходится договариваться на словах до заключения договора.
Иногда в ТЗ кладем скрины сайта-примера, с указанием, что будем использовать модальную сетку, цвета, шрифты вот такого сайта, и прикрепляем скрин.

Отдельный допник к договору - порядок и сроки работ. Но это совсем другая тема)

Ответить
0

>> Мы видим наш сайт в светлых тонах, без лишних деталей, возможно использование оранжевого цвета

Дальше читать не стал. Фраза говорит о том, что дизайн уже сделал сам заказчик. В голове. Умозрительно.

Ответить
0

Клиент должен дать оринтир по цветам, иначе это будет работа на угад. Дизайн - это вообще отдельная тема, на вкус и цвет. Переделывать макет по 150 раз или прсото попросить заказчика дать ориентир по цветам - что продуктивнее?

Ответить
0

В случае, если есть styleguide бренда, где есть разработанная палитра, да. А так — это непонятно как обоснованные пожелания. Цветовые решения должны выполнять функцию айдентики, выделять среди конкурентов и делать продукт узнаваемым. Для этого делаются исследования конкурентной среды. Заказчик, конечно, может эти исследования сам провести, но фраза «Мы видим наш сайт в светлых тонах» вызывает у дизайнера вопрос — почему?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления
{ "page_type": "default" }