Для чего нужно техзадание
ЗАЧЕМ ВАМ НУЖНО ТЕХНИЧЕСКОЕ ЗАДАНИЕ?
Часто ли у Вас перед началом работы просят показать техническое задание или заполнить бриф?
Думаю, часто. Возможно, иногда Вас это может раздражать, ведь и так всё понятно – бери и делай, но, увы, всё не так просто.
Люди порой субъективны в вопросах подобным: “нравится –не нравится”, “красиво – не красиво”.
По-большому счёту это “субъективизм”, в любом проекте (и дизайн тут не исключение) есть задачи, которые проект решает (или цели, которые должен достичь). Да, от субъективности порой невозможно отказаться полностью, но есть способ снизить недопонимание, а в идеале исключить его полностью.
И этот способ – Техническое задание или бриф.
Что такое техническое задание (ТЗ)?
Техническое задание или бриф нужны специалистам для максимального понимания сути проекта и задач, стоящих перед ним:
Эти и ряд других вопросов не прихоть дизайнера или менеджера, а необходимая для работы информация.
Для чего нужно техническое задание (ТЗ)?
Техническое задание прежде всего необходимо дизайнеру для формирования общего видения проекта, целей и задач, которые необходимо решить.
По данному заданию дизайнер должен понять, какой результат нужен заказчику. Также следует понимать, что подробное составление ТЗ, позволит Вам сэкономить свои время и деньги.
Как ТЗ экономит Ваши время и деньги?
Чем подробнее вы опишите свои пожелания, тем больше вероятность того, что в результате вы получите «тот самый» дизайн-макет, который представляли у себя в голове.
Чтобы такого не случилось, необходимо предоставлять специалистам как можно более подробное описание проекта, чтобы при прочтении, сразу сложилось представление о желаемом результате.
Если в начале работы нет подробного технического задания, то на дополнительные правки уходит больше времени, чем планировалось, это, в свою очередь, приводит к изменению сроков и стоимости проекта.
Какие пункты при составлении ТЗ являются ключевыми?
Чтобы составить качественное ТЗ, необходимо придерживаться основных моментов.
1) Указать вид и сферу деятельности компании. Для этого достаточно ответить на следующие вопросы:- в чем уникальность вашего бренда?- в чем преимущество перед конкурентами?- для какой аудитории предназначен ваш продукт?
2) Предоставить технические параметры. Для каждого проекта свои технические требования. Если вам неизвестно, какие именно, обратитесь за помощью к нашему дизайнеру или компании, где будете производить продукцию.
3) Прислать примеры, которые нравятся или не нравятся Вам. Напишите, что именно Вас привлекает / не привлекает в них.
4) Укажите пожелания по цветовой гамме. Здесь следует описать цвета, которые можно применять и те, которые не желательны в использовании. Возможно, есть задача придерживаться общего фирменного стиля или стиля продуктовой линейки.
5) При наличии, предоставить дизайнеру материалы фирменного стиля компании (логотип, брендбук, прошлые дизайн-макеты).
Как быть, если у Вас нет времени составлять ТЗ?
В таком случае нужно быть готовым к тому, что на правки возможно придется затратить в 2 раза больше времени и средств.
Желательно уделить хотя бы немного времени, чтобы описать свои пожелания по проекту. Сделать это можно как самостоятельно, так и при консультации наших специалистов.
Для определения стилевых решений, эффективнее всего будет поискать схожие примеры в нашем портфолио или в интернете. После чего, приложить их к описанию проекта. Так специалисты поймут, какой результат Вы хотите получить.
Составление технического задания по 44‑ФЗ: особенности и правила
Техническое задание — важнейшая часть документации, и это одно из условий успешной закупки. Чем четче вы пропишите техническое задание и чем больше требований предъявите к поставщику и товару, тем более качественный товар получите.
Вопрос правильного составления технического задания важен не только для заказчиков, но и для поставщиков поскольку техническое задание является тем документом, на основании которого они делают выводы, стоит ли им участвовать в тендере или нет.
Что такое техническое задание и где оно используется
Техническое задание — это документ, в котором заказчик описывает объект закупки, то есть требования, которые он предъявляет к закупаемым товарам, работам или услугам. Как правило, техническое задание — это либо приложение к контракту или договору, либо часть документации, в которой изложено, что конкретно приобретается по договору.
Важно!
Термин «техническое задание» — не единственно возможный, а лишь наиболее часто используемый. Другие допустимые названия: «техническая часть», «спецификация», «проектно-сметная документация» и т.п. Федеральный закон от 5.04.2013 № 44-ФЗ раздел документации о закупке, в котором заказчик описывает объект закупки, определяет как «описание объекта закупки».
Независимо от употребляемого термина, важно, чтобы требования к закупаемым товарам, работам и услугам были конкретными, понятными и не противоречили законодательству — 44-ФЗ, 223-ФЗ и 135-ФЗ.
Техническое задание используется:
В соответствии с ч. 2 ст. 33 Федерального закона от 05.04.2013 № 44-ФЗ в техническом задании должны быть указаны показатели, позволяющие определить соответствие закупаемых товаров, работ, услуг установленным заказчиком требованиям. При этом указываются максимальные и (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться. Это необходимо для того, чтобы не ограничивалась конкуренция. К товару нельзя определить определенный вес, размер, габариты, мощность. Должны быть максимальные и минимальные значения. А уже потенциальный участник попытается поставить товар, характеристики которого входят в этот диапазон. При этом в ст. 33 также сказано, что есть показатели, которые не могут изменятся.
Правила формирования технического задания
Эксперт по тендерам и ведущий вебинара «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию» Олег Бируля рассказывает, на что заказчику следует обратить внимание при составлении технического задания:
Особенности подготовки технического задания
В описание объекта закупки не должны включаться требования или указания:
Нельзя в рамках описания объекта закупки предъявлять требования к товарам, информации, работам и услугам при условии, что такие требования влекут за собой ограничение количества участников закупки. Законодатель не расписывает, какие условия и какие требования влекут за собой ограничения, он просто обращает внимание на то, что нельзя предъявлять требования, которые ведут за собой ограничение количества участников закупки, то есть нарушают конкуренцию. Исключение составляют лишь случаи, когда нет другого способа, обеспечивающего более точное и четкое описание характеристик объекта закупки.
Найдите все закупки благодаря умному поиску
В определенных случаях 44-ФЗ допускает указание в конкурсной документации товарных знаков — в случае если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». Допустим, предметом контракта является строительство. Разумеется, в рамках строительства используются строительные материалы — например, цемент, клей, кирпич определенных марок. Но поскольку цемент, клей, кирпич не являются предметом контракта, то заказчик, закупая, по сути, работу с использование материалов, может предъявить требования к материалам, то есть указать, что ему нужен цемент, клей, кирпич определенной торговой марки. Но со словами «или эквивалент».
Есть ряд исключений, когда слова «или эквивалент» не пишутся:
В описании объекта закупки должны использоваться, если это возможно, стандартные показатели, требования, условные обозначения, терминология, касающаяся технических и качественных характеристик объекта закупки, которые установлены в соответствии с техническими регламентами, стандартами и иными требованиями.
Ст. 33 44-ФЗ разрешает в описание объекта закупки включать спецификации, планы, чертежи, эскизы, фотографии, результаты работ, тестирования, требования в отношении проведения испытаний, методов испытаний, упаковки в соответствии с требованиями гражданского кодекса РФ, маркировки, этикеток, подтверждения соответствия (стандарту, ТУ или др.), процессов и методов производства и др.
Документация должна содержать изображение поставляемого товара (если есть требование о соответствии поставляемого товара изображению).
Документация должна содержать информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт (при наличии требования о соответствии поставляемого товара образцу или макету товара). Например, если госзаказчик пишет в документации, что поставляемый товар должен соответствовать определенному макету, то он должен указать, по какому адресу расположен макет, чтобы все потенциальные участники закупки могли в определенное время ознакомиться с ним.
Поставляемый товар должен быть новым. То есть речь идет о товаре, который не был в употреблении, в ремонте, не был восстановлен, у которого не была осуществлена замена составных частей и не были восстановлены потребительские свойства. Однако законодатель делает важную оговорку: «в случае если иное не предусмотрено описанием объекта закупки». То есть если заказчик указывает в техническом задании, что ему нужен товар не новый, то он может его получить.
Документация о закупке должна содержать показатели, позволяющие определить соответствие закупаемых товара, работы, услуги потребностям заказчика (указываются максимальные (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться. Но если будет указан конкретный показатель, под который попадает только одна марка, значит, будет нарушена конкуренция.
При необходимости в техническом задании устанавливаются требования к гарантийному сроку товара, работы или услуги и объему предоставления гарантий их качества; к гарантийному обслуживанию товара; к расходам на эксплуатацию товара; к обязательности осуществления монтажа и наладки товара; к обучению лиц, осуществляющих использование и обслуживание товара.
В случае определения поставщика новых машин и оборудования заказчик устанавливает в документации о закупке требования к предоставлению гарантии производителя и (или) поставщика данного товара и к сроку действия такой гарантии. Предоставление такой гарантии осуществляется вместе с данным товаром.
В документацию о закупке нельзя включать следующие требования:
Исключения составляют случаи, когда возможность установления таких требований к участнику закупки предусмотрена настоящим законом.
Закон ввел новые инструменты регламентации качества: техническое регулирование, технический регламент, международный стандарт, национальный стандарт, оценка соответствия, декларирование соответствия, знак обращения на рынке и др. Их заказчик тоже может использовать при формировании описания объекта закупки.
Специфические вопросы регулируют другие законы. Так, например, при закупке пищевых продуктов госзаказчик должен ориентироваться на Федеральный закон от 02.01.2000 №29-ФЗ. Особенности описания объектов закупок по государственному оборонному заказу могут устанавливаться Федеральным законом от 29.12.2012 № 275-ФЗ.
Антимонопольное законодательство
В ст. 17 Федерального закона от 26.07.2006 № 135-ФЗ говорится, что при проведении торгов, запроса котировок цен на товары, запроса предложений запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции. Это следующие действия:
Не пропустите новые публикации
Подпишитесь на рассылку, и мы поможем вам разобраться в требованиях законодательства, подскажем, что делать в спорных ситуациях, и научим больше зарабатывать.
Техзадание на разработку сайта: запрещенные слова и выражения
Если заранее обсудить нюансы и удалить сложные термины – это всем понравится.
Обновлено в декабре 2021 года.
Помните закон Мерфи? Если вас могут понять неправильно, вас поймут неправильно. Это справедливо и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика — потратил время впустую.
Рассказываем, что и зачем нужно писать в техзадании. И как писать не надо, чтобы работа не обернулась катастрофой.
Статья будет полезна:
Что такое техзадание
Техническое задание — документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше участники процесса понимают, что должны делать. А значит, вероятность, что все останутся довольны результатом, выше.
Главная цель технического задания – убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента
Польза для исполнителя
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Быстро и эффективно
Техзадание составляет исполнитель
Техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель – проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец бизнеса, поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Отлично, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Техзадание должно быть однозначным
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять.
Для кого-то красивый и современный сайт может выглядеть так
Аналогично с непонятными формулировками, которые ничего сами по себе не значат:
Проверяйте, нет ли в тексте неоднозначностей. Если есть — перепишите. Ваши формулировки должны быть четкими и точными:
С формулировками разобрались, давайте пробежимся по структуре.
Техзадание должно содержать общую информацию
Все члены команды должны правильно понимать, чем занимается компания, кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать.
А еще стоит указать цель сайта и описать его задачи, чтобы не получить интернет-магазин вместо блога.
В техзадании нет сложных терминов
Техзадание должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка, условная владелица магазина детских игрушек, обязательно поясните их. Например:
Техзадание описывает инструменты и требования к хостингу
Какую CMS выбрать: руководство по выбору «движка» для сайта
Техзадание содержит требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же добавьте требования к скорости загрузки сайта, устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Техзадание показывает структуру сайта
До отрисовки сайта и его верстки вам нужно согласовать с клиентом структуру. Соберите разработчиков, сеошников, маркетологов, главреда — и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Второе нагляднее.
Структура простого сайта-визитки
Это один из важнейших этапов работы с сайтом. Структура — это фундамент. Если она неудачная, сайт получится кривым.
Техзадание касается каждой страницы
Клиент должен понять, зачем нужна каждая страница сайта, какие элементы на ней будут. Есть два способа это показать.
Прототип
Более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс будущего сайта и говорит, что ему нравится, а что стоит изменить.
Сделали прототип главной страницы в Mockplus
Перечисление элементов
Ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице и что они делают.
Такой способ описания страниц экономит немного времени исполнителю, но выглядит сложно и не впечатляет
В техзадании должны быть сценарии использования сайта
Если вы создаете нестандартный интерфейс, показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого подходят сценарии. Схема сценария проста:
действие пользователя – ответное действие сайта – … – результат
Например, таким может быть сценарий оформления заказа. Пользователь нажимает на кнопку «Заказать» – сайт открывает форму заявки – пользователь вводит номер телефона и нажимает «Ок» – сайт принимает заявку и выводит сообщение «Заказ принят» – на e-mail менеджера приходит письмо с номером телефона клиента.
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут интерактивные сервисы, прописать сценарии необходимо – это поможет заметить «дыры» в работе ресурса.
Техзадание утверждает обязанности
Одни разработчики делают сайт сразу с контентом, другие ставят рыбу, третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Указываем контент, который должен быть на главных страницах сайта
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «качественный, интересный и продающий, полезный целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальным — это полезно. Причем в идеале нужно указать конкретные показатели уникальности в процентах, а также сервисы для проверки текста, которые исполнителю стоит использовать.
Техзадание описывает дизайн
Как и в случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме, опишите ее. Если у него есть брендбук, в котором прописаны шрифты, укажите и их.
Пример ТЗ на разработку сайта (контент и дизайн)
Вместо вывода: структура техзадания
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
Комментарии разработчиков
Техзадание есть всегда, без него не бывает работы. «Мне нужен интернет-магазин» — это уже техзадание. Проблема в том, что это очень расплывчатое ТЗ, оно не дает никакого понимания. Задача проект-менеджера — собрать необходимую информацию, продумать решение, создать сайт у себя в голове. А потом описать его в документе.
В каждом ТЗ обязательно должны быть указаны:
Клиент должен четко представлять свой сайт в законченном варианте, его внешний вид и дальнейшую стратегию развития. Техническое задание не должно указывать разработчикам «как им делать, что делать и какой код вставить» — это в корне неправильно. В общих чертах нужно описывать, какой сайт должен быть, а не как его делать. Как минимум потому что заказчик чаще всего не обладает должной экспертизой.
Что касается подхода, мы всегда прислушиваемся к мнению клиента, но бывают моменты, когда понимаем, что так делать не стоит. В этом случае стараемся переубедить заказчика, опираясь на экспертные данные. В целом, мы приветствуем любое видение клиентов.
Как мы готовим техзадание:
после этих базовых пунктов начинаем расписывать ТЗ более детально по каждой странице.
руководитель отдела frontend- и backend-разработки TexTerra
Техзадание должен писать менеджер проекта, тимлид или сам разработчик (если он фрилансер и работает один). Клиент не разбирается в сайтах — он не сможет учесть все важное. Я пишу ТЗ, чтобы оно было понятным для заказчика. Поясняю термины, описываю структуру, дизайн, функционал, используемые технологии. Часто прикладываю прототипы страниц, чтобы клиент понял, как будет выглядеть его сайт. Потом составляю отдельное задание для верстальщика — с техническими деталями и пояснениями, которые помогут в его работе.
Чем сложнее задача, тем подробнее должно быть ТЗ. Когда я участвовала в больших проектах, я видела техзадания на 30 страниц.
В первую очередь ТЗ нужно клиенту, чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так, он может сослаться на ТЗ и попросить переделать. ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером. Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Последние 2 раздела — самые важные. Именно они обеспечивают понимание, каким будет сайт, как он будет работать.
Очень важный момент — нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ — это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно — надо объяснить, обсудить, дать подробные комментарии.
основатель диджитал-студии Udix Media
Писать техзадание должен должен разработчик или менеджер проекта. Нужно указывать только конкретные завершенные формулировки, которые невозможно оспорить. Избегать оценочных прилагательных: красивый, эффективный и прочее.
Если что-то не указано в ТЗ — надо или уточнить у клиента, или реализовать на усмотрение разработчика, но отдельно сообщить об этом моменте клиенту. Это нужно обсудить заранее, а еще лучше прописать в конце техзадания.
Благодаря подробным ТЗ, которые приходят к нам от проект-менеджеров, клиент на выходе получает сайт, который хотел. Без сюрпризов вроде того, что заказчик просил сделать форму обратной связи, и она сделана, но без привлечения программиста в ней невозможно поменять адрес, на который отсылаются письма. Если вы как владелец сайта хотите самостоятельно менять контент на нем, это стоит указать в ТЗ – тогда разработчики выведут возможность таких изменений в панель администрирования. Если вы хотите, чтобы сайт был сделан не на готовом графическом шаблоне, а обладал уникальным дизайном, это также необходимо прописать и обговорить заранее.
Есть еще один момент, и он относится скорее к договору, чем к ТЗ, но тоже очень важен. Недобросовестные исполнители иногда регистрируют домен не на заказчика, а на себя. Потом, когда приходит момент продления доменного имени, звонят заказчику и просят сумму в несколько раз больше, говоря, что это обсуждалось, но, опять же, нигде не задокументировано. Заказчик начинает разбираться, что и как, понимает, что надо было оформлять все на себя или свою фирму, но поменять домен уже сложно: адрес указан на билбордах, визитках, в рекламе, уже проиндексирован поисковиками. Переоформление прав владения доменом – тоже непростая и небыстрая задача. В общем, к выбору исполнителя нужно подходить очень внимательно, внимательно обсуждать и прописывать ТЗ на сайт.
Сохраните эту статью и перечитайте, когда надумаете заказывать сайт. Кстати, сделать это можно в нашем агентстве.