что такое техническое задание на проектирование
Приложение N 2. Требования к подготовке задания на проектирование объекта капитального строительства
УТВЕРЖДЕНЫ
приказом Министерства строительства
и жилищно-коммунального хозяйства
Российской Федерации
от 1 марта 2018 г. N 125/пр
Требования
к подготовке задания на проектирование объекта капитального строительства
3. Задание на проектирование утверждается застройщиком (техническим заказчиком) после проведения технологического и ценового аудита обоснования инвестиций.
4. Задание на проектирование должно содержать исходные данные, достаточные для разработки проектной документации объекта капитального строительства в соответствии с требованиями Положения о составе разделов проектной документации и требованиях к их содержанию, утвержденного постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87 (Собрание законодательства Российской Федерации, 2008, N 8, ст. 744; 2009, N 21, ст. 2576, N 52, ст. 6574; 2010, N 16, ст. 1920, N 51, ст. 6937; 2011, N 8, ст. 1118; 2012, N 27, ст. 3738, N 32, ст. 4571; 2013, N 17, ст. 2174, N 20, ст. 2478, N 32, ст. 4328; 2014, N 14, ст. 1627, N 50, ст. 7125; 2015, N 31, ст. 4700, N 45, ст. 6245; 2016, N 5, ст. 698, N 48, ст. 6764; 2017, N 6, ст. 942, N 19, ст. 2843 N 21, ст. 3015, N 29, ст. 4368, N 38, ст. 5619, N 51, ст. 7839).
5. Задание на проектирование подготавливается в электронной форме, за исключением случая, указанного в пункте 9 настоящих Требований, и утверждается путем подписания застройщиком (техническим заказчиком) с использованием усиленной квалифицированной электронной подписи.
6. Задание на проектирование в форме электронного документа подготавливается в следующих форматах:
7. Электронный документ, выданный органом государственной власти, органом местного самоуправления, организацией, физическим лицом в соответствии с требованиями, установленными законодательством Российской Федерации о градостроительной деятельности, прилагается к заданию на проектирование в исходном формате.
8. В случае, когда оригинал документа, прилагаемый к заданию на проектирование, выдан и подписан уполномоченным органом государственной власти, органом местного самоуправления или организацией на бумажном носителе, допускается формирование электронного документа путем сканирования непосредственно с оригинала документа (использование копий не допускается), которое осуществляется с сохранением ориентации оригинала документа в разрешении 300 dpi (масштаб 1:1) с использованием следующих режимов:
а) «черно-белый» (при отсутствии в документе графических изображений и (или) цветного текста);
б) «оттенки серого» (при наличии в документе графических изображений, отличных от цветного графического изображения);
в) «цветной» или «режим полной цветопередачи» (при наличии в документе цветных графических изображений либо цветного текста).
Если бумажный документ состоит из двух и более листов, электронный образ такого бумажного документа формируется в виде одного файла.
Сформированный электронный документ подписывается усиленной квалифицированной электронной подписью лица, осуществляющего подготовку задания на проектирование.
9. Задание на проектирование, содержащее сведения, составляющие государственную тайну, подготавливается на бумажном носителе.
1 В соответствии с пунктом 21 Требований к составу и содержанию обоснования инвестиций, осуществляемых в инвестиционный проект по созданию объекта капитального строительства, в отношении которого планируется заключение контракта, предметом которого является одновременно выполнение работ по проектированию, строительству и вводу в эксплуатацию объекта капитального строительства, утвержденных постановлением Правительства Российской Федерации от 12 мая 2017 г. N 563 «О порядке и об основаниях заключения контрактов, предметом которых является одновременно выполнение работ по проектированию, строительству и вводу в эксплуатацию объектов капитального строительства, и о внесении изменений в некоторые акты Правительства Российской Федерации» (Собрание законодательства Российской Федерации, 2017, N 21, ст. 3015).
Что такое техническое задание на проектирование
Система разработки и постановки продукции на производство
Требования к содержанию и оформлению
System of products development and launching into manufacture. Technical assignment. Requirements to contents and form of presentation
Дата введения 2017-09-01
Предисловие
Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»
Сведения о стандарте
1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)
2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии
3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)
За принятие проголосовали:
Краткое наименование страны по МК (ИСО 3166) 004-97
Сокращенное наименование национального органа по стандартизации
Минэкономики Республики Армения
4 Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. N 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.
6 ПЕРЕИЗДАНИЕ. Июль 2020 г.
Информация о введении в действие (прекращении действия) настоящего стандарта и изменений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.
В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»
1 Область применения
Настоящий стандарт устанавливает требования к построению, содержанию, изложению, оформлению, порядку согласования и утверждения технического задания на выполнение научно-исследовательских и опытно-конструкторских работ в области изделий машиностроения и приборостроения.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:
ГОСТ 2.001 Единая система конструкторской документации. Общие положения
ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов
ГОСТ 2.103 Единая система конструкторской документации. Стадии разработки
ГОСТ 2.105 Единая система конструкторской документации. Общие требования к текстовым документам
ГОСТ 2.116 Карта технического уровня и качества продукции
ГОСТ 2.118 Единая система конструкторской документации. Техническое предложение
ГОСТ 2.119 Единая система конструкторской документации. Эскизный проект
ГОСТ 2.120 Единая система конструкторской документации. Технический проект
ГОСТ 2.301 Единая система конструкторской документации. Форматы
ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы*
* В Российской Федерации действует ГОСТ Р 2.601-2019.
ГОСТ 3.1001 Единая система технологической документации. Общие положения
ГОСТ 3.1102 Единая система технологической документации. Стадии разработки и виды документов. Общие положения
ГОСТ 14.201 Обеспечение технологичности конструкции изделий. Общие требования
ГОСТ 15.012 Система разработки и постановки продукции на производство. Патентный формуляр
ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 27.003 Надежность в технике. Состав и общие правила задания требований по надежности
ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ 16504 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения
ГОСТ 19433 Грузы опасные. Классификация и маркировка
ГОСТ 21964 Внешние воздействующие факторы. Номенклатура и характеристики
ГОСТ 28934 Совместимость технических средств электромагнитная. Содержание раздела технического задания в части электромагнитной совместимости
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 техническое задание (ТЗ): Исходный технический документ для проведения работы, устанавливающий требования к создаваемому изделию (его СЧ или КИМП) и технической документации на него, а также требования к объему, срокам проведения работы и форме представления результатов.
3.2 заказчик: Предприятие (организация, объединение или другой субъект хозяйственной деятельности), по заявке или договору с которым производится разработка (модернизация), производство и (или) поставка продукции, в том числе научно-технической.
3.3 разработчик: Предприятие (организация, объединение, юридическое или физическое лицо), осуществляющее разработку продукции в установленном порядке.
3.4 изделие: Любой предмет или набор предметов производства, подлежащих изготовлению на предприятии, количество которых может исчисляться в штуках или экземплярах.
3.5 радиоэлектронные средства: Технические средства, предназначенные для передачи и (или) приема радиоволн, состоящие из одного или нескольких передающих и (или) приемных устройств либо комбинации таких устройств и включающие в себя вспомогательное оборудование.
живучесть: Свойство объекта, состоящее в его способности противостоять развитию критических отказов из дефектов и повреждений при установленной системе технического обслуживания и ремонта, или свойство объекта сохранять ограниченную работоспособность при воздействиях, не предусмотренных условиями эксплуатации, или свойство объекта сохранять ограниченную работоспособность при наличии дефектов или повреждений определенного вида, а также при отказе некоторых компонентов.
[ГОСТ 27.002-89, пояснение к термину «Надежность»]
3.7 эскизный проект (ЭП): Вид проектной конструкторской документации на изделие, содержащей принципиальные конструкторские решения, дающие общее представление о конструкции и принципе работы изделия, а также данные, определяющие его соответствие назначению.
3.8 технический проект (ТП): Вид проектной конструкторской документации на изделие, содержащей окончательные технические решения, дающие полное представление о конструкции разрабатываемого изделия и включающей данные, необходимые и достаточные для разработки рабочей конструкторской документации.
техническое предложение: Совокупность проектных КД, которые должны содержать технические и технико-экономические обоснования целесообразности разработки документации изделия на основании анализа ТЗ и различных вариантов возможных решений изделий, сравнительной оценки решений с учетом конструктивных и эксплуатационных особенностей разрабатываемого и существующих изделий, а также патентные исследования.
3.10 рабочая конструкторская документация (РКД): Совокупность конструкторских документов, предназначенных для изготовления, контроля, приемки, поставки, эксплуатации и ремонта изделия.
3.11 головной исполнитель: Предприятие (организация, объединение), выполняющее работу по созданию изделия (комплекса, системы), координирующее деятельность исполнителей составных частей этой работы и отвечающее за выполнение работы в целом.
4 Сокращения
В настоящем стандарте применены следующие сокращения:
Приложение N 1. Задание на проектирование объекта капитального строительства
ГАРАНТ:
См. данную форму в редакторе MS-Word
УТВЕРЖДЕНО
приказом Министерства строительства
и жилищно-коммунального хозяйства
Российской Федерации
от 1 марта 2018 г. N 125/пр
(должность уполномоченного лица
застройщика (технического заказчика), осуществляющего подготовку задания на проектирование)
«__» ________________ 20 г.
1 В соответствии с частью 5 статьи 47 Градостроительного кодекса Российской Федерации (Собрание законодательства Российской Федерации, 2005, N 1, ст. 16; N 30, ст. 3128; 2006, N 1, ст. 10, 21; N 23, ст. 2380; N 31, ст. 3442; N 50, ст. 5279; N 52, ст. 5498; 2007, N 1, ст. 21; N 21, ст. 2455; N 31, ст. 4012; N 45, ст. 5417; N 46, ст. 5553; N 50, ст. 6237; 2008, N 20, ст. 2251, 2260; N 29, ст. 3418; N 30, ст. 3604, 3616; N 52, ст. 6236; 2009, N 1, ст. 17; N 29, ст. 3601; N 48, ст. 5711; N 52, ст. 6419; 2010, N 31, ст. 4195, 4209; N 48, ст. 6246; N 49, ст. 6410; 2011, N 13, ст. 1688; N 17, ст. 2310; N 27, ст. 3880; N 29, ст. 4281, 4291; N 30, ст. 4563, 4572, 4590, 4591, 4594, 4605; N 49, ст. 7015, 7042; N 50, ст. 7343; 2012, N 26, ст. 3446; N 30, ст. 4171; N 31, ст. 4322; N 47, ст. 6390; N 53, ст. 7614, 7619, 7643; 2013, N 9, ст. 873, 874; N 14, ст. 1651; N 23, ст. 2871; N 27, ст. 3477, 3480; N 30, ст. 4040, 4080; N 43, ст. 5452; N 52, ст. 6961, 6983; 2014, N 14, ст. 1557; N 16, ст. 1837; N 19, ст. 2336; N 26, ст. 3377, 3386, 3387; N 30, ст. 4218, 4220, 4225; N 42, ст. 5615; N 43, ст. 5799, 5804; N 48, ст. 6640; 2015, N 1, ст. 9, 11, 38, 52, 72, 86; N 17, ст. 2477; N 27, ст. 3967; N 29, ст. 4339, 4342, 4350, 4378, 4389; N 48, ст. 6705; 2016, N 1, ст. 22, 79; N 26, ст. 3867; N 27, ст. 4301, 4302, 4303, 4305, 4306; 2017, N 11, ст. 1540, N 25, ст. 3595, N 27, ст. 3932, N 31, ст. 4740, ст. 4767, ст. 4771, ст. 4829; 2018, N 1, ст. 39, ст. 47, ст. 90, ст. 91).
Как составить техническое задание на проектирование
ОСНОВНЫМ документом, в соответствии с которым проектировщик выполняет работы, является «Задание на проектирование». В зависимости от типа объекта и подхода к организации работ со стороны заказчика и исполнителя, этот документ может иметь различную степень детализации: от формального приложения к договору до подробного руководства к действию.
Как правило, для сложных объектов, на проектирование которых проводятся тендеры, задание составляется самим заказчиком (или специально приглашенными специалистами) и является весьма детальным. И, наоборот, для небольших проектных работ, в частности, при необходимости разработки только определенных разделов рабочей документации, задание может ограничиваться названием, а остальное заказчик объясняет на словах.
Для заказчика такой подход – это всегда возможность уйти от ответственности при возникновении конфликта на стадии окончательных расчетов с исполнителем. Фразы типа «я вам не говорил это делать», «я ждал от вас другое решение», «это нужно переделать» и прочие – известны любому проектировщику-фрилансеру. Единственный способ гарантировано избежать необоснованных претензий со стороны заказчика к разработанному проекту – взять инициативу в свои руки на стадии обсуждения технических решений, составить задание в письменном виде и добиться его утверждения.
Далее будем рассматривать именно в этом разрезе основные, установленные к составлению Задания на проектирование требования.
Форма задания на проектирование объектов непроизводственного назначения
«Задание на проектирование» и «Техническое задание»: в чем разница
В обиходе часто употребляются оба этих термина (а иногда – обобщенный термин – Техническое задание на проектирование). Тем не менее, именно «Задание на проектирование» является корректным названием, которое упоминается во всех нормативных документах. Термин «Техническое задание», как правило, относится к выполнению смежных с проектной деятельностью работ, таких как инженерные изыскания, обследование зданий, научное сопровождение, разработка конструкторской документации. В некоторых случаях техническое задание может выдаваться на разработку отдельных разделов проекта, в дополнение к Заданию на проектирование, когда требуется высокая степень детализации требований к проекту.
Нормативная база на составление Задания на проектирование
В настоящее время действуют два важных документа:
Документы регламентируют состав «Задания на проектирование», которому необходимо следовать при проектировании бюджетных объектов. Для коммерческих проектов, которые подлежат экспертизе, также необходимо следовать утвержденной форме Задания на проектирование Минстроем.
Материалы для скачивания:
Основные положения Задания на проектирование
Естественно, при разработке отдельных разделов проекта, или даже небольших комплексных проектов, проектировщики-фрилансеры не используют установленную Минстроем форму (а многие даже не знают о ней). Тем не менее, если вы решили в некоторой степени обезопасить себя при работе по «устному договору подряда» с заказчиком, то логичным решением будет как можно ближе придерживаться образца, установленного в соответствии с Приказом 125 Задания на проектирование.
Типовая форма Задания на проектирование состоит из трех основных разделов:
Что необходимо обязательно отразить в Задании на проектирование
Заглавие документа должно «буква в букву» соответствовать названию объекта, которое прописывается в штампе чертежей. Даже, если вы работаете без договора, это сведет к минимуму возможность разночтений в дальнейшем и покажет серьезность подхода с вашей стороны. Например, «Жилой дом по адресу Бестужева, 21, г. Таганрог. Раздел «Водоснабжение».
Раздел «Общие данные» Задания на проектирование объектов строительства содержит информацию о заказчике и исполнителе работ, виде строительства, наличии технических условий и требований к выделению этапов. Приводятся краткие сведения об объекте проектирования, его назначении и технико-экономических показателях.
Состав раздела «Требования к проектным решениям» зависит непосредственно от самого объекта либо конкретных разделов, которые выполняет проектировщик. Типовая форма предусматривает достаточно детальное описание требований к архитектурным, конструктивным и инженерным элементам зданий и сооружений (вплоть до дверей и внутренней отделки). Все эти пункты необходимо максимально задействовать.
Прописывайте, какая предполагается конструкция здания, из чего состоят стены, какой тип окон будет использоваться, какие планируется применить системы отопления и вентиляции, насосы, кабели, светильники и так далее – чем подробнее будет все расписано, тем меньше вероятность того, что придется переделывать проект (в том числе бесплатно).
В разделе «Иные требования» важно указать состав проекта, какие разделы подлежат разработке, а какие не выполняются в рамках настоящих работ. Требования к выполнению визуализации (в каких программах необходимо разработать, требуется ли модель BIM и т.д.) также указываются в этом разделе.
Также важным положением раздела «Иные требования» является подробный перечень исходных данных, на основании которых ведется разработка проекта.
Скачать Задание на проектирование (образец ГОСТ) можно по ссылке в конце статьи.
Как утвердить «Задание на проектирование»
В соответствии с Приказом Минстроя «Задание на проектирование» утверждается заказчиком с использованием цифровой подписи. Применительно к проектировщику-фрилансеру, который часто работает по «устному договору» подойдет любой способ, позволяющий удостовериться, что заказчик подтвердил положения «Задания» во избежание любых двояких толкований в будущем (как минимум, должно быть письменное подтверждение по электронной почте или в мессенджере).
Конечно же, наличие такого «Задания» не может ничего гарантировать проектировщику, однако при возникновении любых конфликтных ситуаций позволит ему занять настолько выгодную позицию, насколько это возможно в конкретных условиях.
Так что же такое «Техническое Задание»?
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки — выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Переводим на понятный язык
1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом — это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков: 
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть — куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты — то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.