Всем привет, мы веб-студия 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 благодарит вас за внимание и желает всем успехов и хорошего настроения!)
Заказчик не должен делать тз, не его работа.
И дополнительно платить не должен.
Вы ему сайт делаете нормальный или херню по его желанию? Тогда вы фиговая фирма. Человек может не смыслить ничего. Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект.
А инфо по сайту на этапе проектирования и анализа конкурентов собирается, это обычная практика.
Вы же понимаете, что бесплатной работы не бывает? Любой относительно большой бизнес или пишет ТЗ сам, или платит за него. То, что студия должна бесплатно написать ТЗ - это забавно, ибо за эту работу все равно кто-то заплатит, пусть и неявно.
Андрей, доля правды есть, но судя по вашему ответу бригада, которя делает ремонт должна делать дизайн-проект квартиры?
И дополнительно платить не должен.
Это феерическая чушь, Андрей.
Техническое задание, помимо того, что в своём классическом виде — 990 страниц текста — уже мертво, это ключевая часть процесса разработки.
Если клиент не знает, чего хочет, то итоговый результат контролировать не реально, и всё это может закончится, в лучшем случае, сорванными сроками, а в худшем — судом.
Любая работа должна быть оплачена, предоплачена и закрыта актом.
И составление ТЗ — а лучше называть это «агрегацией требований» — это такая же работа.
В России если не объяснишь подробно, то херню сделают
"Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект."
Ну вон, Лебедев так работает со своими джипегами за 100к, вообще не слушая заказчика, а только убеждая всех (возможно, даже себя) что они выходят ох*енные. Скажем так, результаты весьма неоднозначные.
Не соглашусь.
Мы берем за проектирование деньги, это составляет около 15% от бюджета на разработку. Сюда входит аналитика, написание тз, прототипирование, дизайн концепция.
Если называть "ТЗ" то, что обычно дает заказчик, то да, это не стоит таких денег. Но и пользы от такого документа нет )
ТЗ уже прошлый век. У меня опыт ведения проектов с трудозатратам в тысячи часов. Под конец большого проекта, сам проект уже не напоминал первоначальное ТЗ. Куча дополнительных документов, уточнений и изменений в проекте. В свете современных технологий удобнее и нагляднее это прототипы, например, в Axure. Клиент видит как ведёт себя интерфейс, можно покликать. А ТЗ выкиньте, старое это все.
На деле все просто: ТЗ - результат интеллектуального труда, весьма определенный и конечный. Клиент может взять написанное ТЗ и идти по студиям - поэтому эти результаты, как правило, оплачиваются.
Можно написать небольшое ТЗ бесплатно, или написать большое - и не оплачивать его, если с авторами заключается контракт, но тем не менее.
Логичное и емкое обоснование того, что ТЗ также стоит денег, как и любая работа.
Все верно. Такое часто бывает. ТЗ только после оплаты.
"10 обычных страниц с информацией и 990 страниц с описанием продукции в каталоге товаров."
Что-то я раза 3 перечитал и не могу понять, 990 страниц что? Это в нормальной ситуации 10 страниц + один шаблон страницы товара. Хотя, наверное можно с заказчика брать как за отдельные 🤣
Это очень абстрактно, пример 10 уникальных страниц и 1000 единиц товара = 1000 внутренних типовых страниц, это имеется ввиду
Мы всегда идем на встречу и простые ТЗ разрабатываем бесплатно. Но есть технически сложные проекты, которые требуют очень тщательной прораьотки функционала. Стоимость разработки одного ТЗ может быть от 2000 до 40000, в данном случае оплатить работу - это нормальная практика
Практически всё предложенное ТЗ сосредоточено на функциональных требованиях и выглядит "заточенным" под интересы разработчика.
Иерархическая структура, логотип и цветовая гамма, продвижение и реклама - то, что мы умеем и любим при натягивании сайта на готовые шаблоны и CMS. А вот что мы не любим (и часто не умеем) - это бизнес-требования, особенно нефункциональные.
Для сайта важнейшей является нефункциональная сторона. И если заказчик не сформулирует свои бизнес-требования к характеристикам качества, то может жестоко за это поплатиться.
Например:
Производительность - ожидаемая скорость загрузки и отрисовки страниц, ожидаемое количество посетителей среднее и пиковое.
Надёжность - процент отказов, способы восстановления при сбоях, допустимый процент времени вынужденных простоев, а также какими средствами надёжность будет контролироваться.
Защищённость - как будут защищены данные пользователей и заказчика на разных этапах их обработки.
Ну и далее по списку, например, стандарта ISO 25010.
Очень актуальная на сегодняший день тема - соответствие законодательству. В первую очередь, поддержка требований закона о персональных данных и GDPR. Если на сайте что-то продаётся, то ещё и способы реализации 54-ФЗ.
Отдельно нужно сказать о юзабилити, которое в зависимости от назначения сайта, может быть важнейшим конкурентным преимуществом (или, наоборот, причиной провала). Если оно важно, то в ТЗ должно быть расписано, в каких сценариях ему нужно уделять особое внимание, какие показатели предполагается использовать для его оценки, и как они будут проверяться.
Разработчику, понятно, фиксация таких нефункциональных требований обычно не очень выгодна, потому что может в разы увеличить стоимость разработки и сопровождения.
Все в кучу свалили.
1.Заказчик приходит с запросам сделать сайт, в идеальном мире каждый занимается своим делом заказчик вообще не должен ничего понимать в сайтах.
2.Включается pre-sale. Вы направляете ему ему бриф, где с помощью отточенных вопросов собираете с заказчика информацию о концепции
3. Pre-sale агрегирует данные, на основании этого составляет карту функциональных и нефункциональных требований к продукту, делает первоначальную грубую оценку стоимости (обычно вилкой) и сроков. Апрувит с заказчиком данные параметры, если все хорошо делаем точную оценку
4. Pre-sale / sale делает точную оценку проекта, составляет красивое КП с разбивкой по этапам (проектирование и дизайн, разработка, интеграции, внедрение), описывает работы в рамках этапа, возможно узнает у разработки загруженность, и информирует клиента о том когда готовы приступить. Апрувит это все у заказчика, если все круто, получаем предоплату и переходим к аккаунту.
5. Аккаунт принимает клиента, дополнительно апрувит функциональные требования, передает коллегам для разработки высокуровнего и низкоуровнего технического задания на сайт и на интеграции, параллельно дизайнеры брифуют клиента.
6. И дальше в разработку.
Естественно в больших проектах сначала так делает mvp, все остальные фичи уже просто приложения к спеке,. с описанием функционала, структур данных, апи и тд если все это есть.
Довольно спорная статья в которой описан устаревший подход.
Из своего опыта могу сказать, что этап проектирования сайта всегда должен быть платным и за него нельзя брать меньше 50 000 руб (даже за лендинг) За крупный проект от 100-150к. Хотя бы для того, чтобы обезопасить себя от времени, потраченного на обсуждение проекта и составление сметы.
Кроме того, на этапе проектирования надо сделать структуру сайта в Mind Map и сделать прототип будущего сайта. Без этого невозможно поставить ТЗ на дизайн и дальнейшие этапы работы.
А сроки лучше всегда говорить финальные после завершения этапа "проектирование", а до этого обсуждать только вилку "от ххх и до ххх".
И за любую работу надо платить)
Вот это веселая паутина)
Должно же быть хоть что-то позитивное в статье и в жизни)
Техническое задание - это документ, который очерчивает объем работ для исполнителя, и результат для Заказчика.
Если в ТЗ поместить сайты которые нравятся заказчику, он пойдет в суд с этим документом и всегда докажет, что вы не выполнили договор. Т.к. итоговый сайт не может быть похож на все три сайта.
Мы всегда фиксируем в договоре:
- всю структуру сайта (с припиской что наименования могут быть изменены)
- общий перечень и подробное описание каждого модуля, какие поля, условия обработки полей, связь с другими модулями, доп. условия обработки данных из каждого поля (это примерно 80% всего ТЗ)
- список прототипов и макетов сайта, которые мы обязаны сделать + кол-во правок к макетам
- список индивидуальных страниц без связи с модулями
- объем наполняемых страниц, и наполняемого каталога (если он есть) в кол-ве страниц.
Этого нам ВСЕГДА хватает, что бы очертить наш объем работ и результат для заказчика.
Единственный нюанс - дизайн. В 90% случаев приходится договариваться на словах до заключения договора.
Иногда в ТЗ кладем скрины сайта-примера, с указанием, что будем использовать модальную сетку, цвета, шрифты вот такого сайта, и прикрепляем скрин.
Отдельный допник к договору - порядок и сроки работ. Но это совсем другая тема)
Комментарий удален модератором
Клиент должен дать оринтир по цветам, иначе это будет работа на угад. Дизайн - это вообще отдельная тема, на вкус и цвет. Переделывать макет по 150 раз или прсото попросить заказчика дать ориентир по цветам - что продуктивнее?