Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.).
В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.
О различных нюансах и особенностях в строительстве домов из СИП панелей и их отделке
Слово «проект» в области деятельности «управление проектами» и «управление проектированием» применяется в значении «программа», «план действий», «комплекс работ».
Участников проектных работ разделяют на потребителей (заказчиков этих работ) и поставщиков (исполнителей этих работ, подрядчиков). Исполнителя-специалиста называют проектировщиком или разработчиком. Поставщиком, как и потребителем продукции, может быть организация (юридическое лицо) или конкретный человек (физическое лицо).
Объектом проектирования может быть материальное устройство, или выполнение работы, или оказание услуги, например, сооружение или промышленный комплекс, техническое устройство (прибор, машина, аппарат), система управления,информационная система
, нормативная документация (например, стандарт) и т. д.
Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков.
Место ТЗ в структуре проектирования
Проектирование— это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
Стадии проектирования регламентированы стандартами. Это следующая последовательность:
Строительство «Лахта Центра». Из стали и бетона: композитные материалы и металлоконструкции
· Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
· Стадии рабочего проекта.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования, которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, это и есть главная цель ТЗ, обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком. Фактически это означает, что работа исполнителя над проектом уже началась.
В машиностроении этот этап иногда называют внешним проектированием.
Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Частные технические задания
В процессе проектирования сложного объекта (системы), требующего участия нескольких разработчиков, создаются частные технические задания на подсистемы.
В соответствии с полученными техническими требованиями разработчик системы формирует ТЗ и на стадии технического предложения выполняет декомпозицию объекта и подготавливает частные технические задания на подсистемы. После выполнения всех этапов технического предложения разработчик согласовывает и утверждает его у заказчика системы, при этом они совместно уточняют исходное ТЗ.
После утверждения технического предложения разработчик системы распределяет по соисполнителям частные ТЗ, на основании которых могут вырабатываться частные ТЗ для подсистем более низких уровней. Если подсистемы второго уровня отсутствуют, то техническое предложение для подсистем часто не выполняется, поскольку практически было завершено на уровне системы.
По завершении этапа распределения ТЗ разработчики системы и её подсистем приступают к выполнению стадии эскизного проекта. Проработка структуры на этой стадии ведется при тесном взаимодействии всех разработчиков. В процессе такой работы увязываются между собой отдельные части, согласовываются основные параметры проектируемого объекта. Качество проектирования зависит от широты видения разработчиком проблемы, то есть от его кругозора и способности учесть все связи рассматриваемого объекта, и наличия у него знаний, захватывающих смежные области. В процессе эскизного проектирования и согласования частных решений с общим возможна корректировка ТЗ.
После завершения эскизного проектирования, согласования и утверждения полученных технических решений у заказчика переходят к стадии технического проектирования. Здесь выполняется вся основная конструктивная проработка объекта и его частей. Возможно уточнение технических решений с возвратом на предыдущие стадии. Техническое проектирование ведется при тесном взаимодействии всех разработчиков.
Необходимость ТЗ
Исходное задание выдаётся заказчиком. Основными причинами, заставляющими его обратиться к разработчику, являются отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования).
Задание может быть чётко определено, например, когда всю работу ведет один человек, либо оно выдано авторитетным специалистом, либо не может быть подвергнуто сомнению (госзаказ). Но чаще оно формулируется в общих чертах на языке потребителя-неспециалиста, далёким от языка разработчика и терминов предметной области. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разработанного изделия. Также, разработчик должен понимать, что заказчик может не знать (или знает частично) специальных требований, что не снимает с разработчика ответственности и обязательности выполнения требований надзорных органов независимо от их наличия в задании. Таким образом, не только заказчик, но и разработчик (исполнитель) являются ответственными за постановку целей разработки и полезность ее результата.
Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).
Специалисты считают, что грамотное ТЗ — это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, — одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам — главным конструкторам, руководителям проектов и работ и т. п.
Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу.
И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить — 99 рублей.
Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!
Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:
· представить (вообразить) готовый продукт,
· выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
· уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
· осознать, что именно ему нужно,
· в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
· требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
· понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта илиавтоматизированной системы
· спланировать выполнение проекта и работать по намеченному плану,
· отказаться от выполнения работ, не указанных в ТЗ.
Содержание ТЗ
Регламентированное ТЗ
· ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления[1] (приведен порядок построения ТЗ).
В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:
· ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
· Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу[7] (приложен образец технического задания на разработку в рамках ГОЗ)
Источник: poisk-ru.ru
Техническое задание: для чего оно нужно
Техническое задание – это перечень сведений о проекте, включающий персональную информацию (сведения о заказчике, назначение проекта и т.п.), техническую информацию (формат издания, вид бумаги и т.п.), а также конкретные пожелания заказчик к дизайну и работе в целом (образцы исходных материалов, примеры нравящихся макетов, необходимые сроки выполнения и т.п.).
Техническое задание необходимо обеим сторонам – и заказчику, и исполнителю. Заказчику составление ТЗ поможет ясно определить цели и задачи проекта, подумать о стратегии, вспомнить о допущенных в прошлом ошибках (если уже имелся подобный опыт), а также решить, что он, собственно, ждет от исполнителя. Помимо всего прочего, такое ТЗ поможет заказчику упорядочить все свои мысли, идеи и требования в одном документе, чтобы не упустить что‑то важное. Не секрет, что прежде чем приступать к какой‑либо работе – ее надо бы как следует обдумать, составить план действий, а только потом начинать делать. Кроме того, сначала надо определиться с тем, что необходимо сделать, а потом уже пытаться оценить этот объем работ.
Исполнителю же ТЗ нужно в качестве исходной информации по проекту. Только ознакомившись с проектом посредством подобного ТЗ, можно делать выводы о реальном объеме работы, а значит и о ее стоимости, а также сроках выполнения. Кроме того, ТЗ используется в процессе подготовки к работе над проектом или во время его выполнения. От полноты предоставленной заказчиком информации, проработки деталей зачастую зависит и итоговый результат.
ТЗ удобно тем, что вся информация о проекте собрана в одном месте, ее не надо искать по разным источникам – аськам, личкам и почтам, вспоминать телефонные или личные переговоры, рыться в Интернете или получать очередное письмо от заказчика «Я забыл вчера вам сказать еще одну важную вещь по проекту…». Безусловно, настоящее ТЗ может существовать только в письменном виде.
Чем ТЗ отличается от брифа?
По своей сути – почти ничем. Как объясняют нам яндексы и википедии, «бриф – это краткая письменная форма согласительного порядка между планирующими сотрудничать сторонами, в которой прописываются основные параметры». Но в среде фрилансеров по устоявшейся традиции брифом чаще называют анкету с вопросами, касающимися проекта, которая высылается заказчику. Т.е. говоря простым языком, ТЗ – это заполненный бриф. У любого профи в загашнике найдутся и примеры удачных ТЗ, и разные брифы на все случаи жизни.
Как заказчики аргументируют свой отказ от оформления ТЗ?
За годы работы на фрилансе я слышала множество разных мнений от работодателей по поводу того, нужно ли вообще ТЗ для успешной работы. При этом приводятся разные доводы – серьезные или не очень. И эти аргументы зачастую сводятся к тому, что ТЗ – это якобы ненужная вещь, отнимающая время, а профи обязан и так разбираться в проекте с лету и без лишних вопросов.
При этом всегда странно, что заказчик, обращающийся к профессионалу, почему‑то начинает диктовать ему свои условия работы вместо того, чтобы прислушаться к мнению специалиста, который уже «собаку съел» на подобных проектах и по идее лучше знает, что и как необходимо делать.
Итак, что говорят / пишут некоторые заказчики в ответ на просьбу составить ТЗ на проект.
«Я не умею составлять ТЗ»
В принципе это высказывание принимается как оправдание для заказчиков, которые до этого ни разу в жизни не пытались заказать работу у фрилансера-профессионала. Их растерянность понятна. Но в этом случае на помощь приходит бриф – т. е. тот самый опросник, который обычно в наличии у каждого специалиста.
Его можно выслать заказчику с просьбой всего лишь аккуратно и подробно ответить на каждый вопрос. Большинство работодателей охотно идут на подобный шаг, ведь гораздо удобнее писать ТЗ не с нуля, а воспользовавшись грамотным шаблоном или образцом с перечнем необходимых вопросов. А кто может лучше знать о своем проекте и ответить на вопросы по нему, чем не заказчик, его задумавший?
«Мне некогда заниматься писаниной»
Подобный ответ вызывает удивление: что, разве у заказчика нет времени на СВОЙ ЖЕ проект и на то, чтобы донести максимум информации до исполнителя для получения необходимого ему же самому результата? Может быть, и проект этот не так уж важен и нужен, чтобы никак нельзя было потратить на составление ТЗ некоторое время? Словом, такой подход к работе со стороны заказчика как минимум выглядит несколько безответственно. Все‑таки выполнение проекта – это дело не только исполнителя, заказчик тоже должен активно участвовать в нем и всячески помогать. Категорический отказ заказчика от составления ТЗ может являться первым сигналом к тому, что с таким работодателем, возможно, сотрудничество станет не самым приятным.
«У нас все просто, поэтому ТЗ не нужно. Давайте я вам лучше позвоню и быстренько расскажу, что нам надо / Приезжайте к нам в офис на собеседование, и мы все обсудим»
Как показывается практика, под этой «простотой» может скрываться на самом деле все, что угодно, особенно если заказчик слабо разбирается в тонкостях работы исполнителя. А попытка заказчика уклониться от письменного ТЗ может в итоге вызвать большие проблемы с проектом у исполнителя – например, дикое количество правок и бесконечных переделок (ведь точная задача толком не была сформулирована и нигде не зафиксирована).
Кроме того, важные условия и моменты лучше не обсуждать устно, а если и обсуждать, то обязательно потом их дублировать письменно: ведь обговоренные детали можно забыть, на них нельзя сослаться, перечитать, процитировать. Заказчик может не упомянуть что‑то крайне важное, а исполнитель может какие‑то слова не так расслышать.
И все это может привести к проблемам типа «Почему вы это не сделали, я ведь вам говорил! – Нет, вы мне такого не говорили!» Поэтому я предпочитаю общаться с заказчиками через почту, ICQ или Skype. Поездке на собеседования в офис все равно необходимо предварить ознакомление хотя бы с общим ТЗ. Неприятно будет, приехав к заказчику, узнать, что предлагаемая ими работа тебе совсем не подходит. К тому же любой проект можно организовать полностью удаленно, а очное общение заказчика и фрилансера 100 %-ного результата вовсе не гарантирует.
«Вы сначала назовите цены, а ТЗ я пришлю выбранному исполнителю»
Категоричный запрос от заказчика типа «нужна верстка книги, цена и только потом я расскажу подробности» или просто без деталей «меня интересует верстка каталога, цена» – это довольно частое явление. Тот факт, что исполнитель сначала должен узнать подробности по проекту, вникнуть в него, понять, каков объем работы, а только потом называть соответствующие цены, – почему‑то некоторые заказчики упорно игнорируют.
Правда, некоторых из таких работодателей больше интересует факт низкой стоимости, а не качество исполнения работы, поэтому они и начинают общение со всеми кандидатами именно с вопроса цены. Кто меньше предложит, того и… А вот чем руководствуются исполнители, которые не видя материалов и не зная деталей по проекту, сходу называют какие‑то цифры и суммы – мне непонятно. Возможно, это новички, пока не очень разбирающиеся в теме и стремящиеся урвать проект. Кстати, «вилка цен» на какой‑либо тип проекта, которую тоже так любят спрашивать заказчики, реально может колебаться в десятки раз – не думаю, что ответ типа «от 1 000 до 100 000 руб.» может кого‑то устроить.
«Наш прошлый исполнитель всегда работал без всяких ТЗ и все было нормально»
Я, например, не могу отвечать за действия и работу других людей. И не знаю ни уровень мастерства того человека, ни манеру его работы. Кроме того, не факт, что ТЗ действительно вообще никакого не было – хотя бы в разрозненном виде в нескольких письмах как ответы на вопросы или при общении по аське. А может быть, прежний исполнитель обладает телепатией и навыком чтения мыслей заказчиков на расстоянии? В этом случае, действительно, никакое ТЗ ему не нужно было вовсе.
«Ну вы же дизайнер-профессионал, вам виднее, что и как делать. Предложите свой вариант, а мы посмотрим»
Эдакий льстящий исполнителю ответ. Но если вникнуть в суть – видимо, тут тоже имеется в виду, что исполнитель должен быть ясновидящим, чтобы без какой‑либо информации приступить к работе и выдать всем устраивающий заказчика результат. Кстати, зачастую сначала работодателем говорится «делайте все на свое усмотрение», а потом «ой, мы думали, что это будет выглядеть по‑другому».
А может, заказчик просто ленивый или необязательный по жизни человек и пытается увильнуть от своей части работы? Но чем в итоге может кончится работа без ТЗ – понятно: куча правок, переделок, затянувшиеся сроки и даже прекращение работы над проектом с формулировкой «исполнитель упорно не понимает того, что надо заказчику». Оно нам надо?
Поэтому, уважаемые заказчики, пожалуйста, не думайте, что техническое задание лишь прихоть исполнителя и не ленитесь подробно заполнить бриф на ваш же проект. И помните, что качественно составленное ТЗ – это залог успешного выполнения работы. А коллегам-фрилансерам советую не браться за проект без ТЗ, ну или во всяком случае попытаться оформить его совместно с заказчиком: такой подход к работе тоже имеет место быть.
Источник: mnogostranichka.ru
Зачем нужно ТЗ и чего ждать при работе без него?
Есть в психологии «Закон неадекватности взаимного восприятия». Его суть заключается в том, что человек никогда не воспринимает находящийся перед глазами предмет целиком, а видит его только в определенном ракурсе, по-своему.
Отсюда и возникают разногласия, несовпадающие точки зрения, противоположные мнения, в том числе конфликты между заказчиком и исполнителем при разработке сайта или мобильного приложения.
Побороть их поможет исчерпывающее техническое задание (ТЗ). Про него давайте и поговорим.
ТЗ – вещь серьезная и нужная, раз уж даже ГОСТ на него есть
Важность того, что без ТЗ не обойтись, понимали еще в СССР. В 1989 году был разработан ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Документ получился исчерпывающим и полезным. Несмотря на то, что технологии с того времени сделали колоссальный рывок вперед, большинство тезисов этого ГОСТа разработчики, и мы в uncore в том числе, используем по сей день при подготовке ТЗ на приложения, сайты или иные программные продукты.
Не верите? Попросите примеры ТЗ у нескольких подрядчиков и вы увидите, что они будут схожи по структуре и содержанию и будут перекликаться с ГОСТ 34.602-89. Правильная интерпретация положений стандарта гарантирует вам получение качественного исчерпывающего технического задания.
И это не единственный стандарт, на который можно опираться при разработке ТЗ. Полезную информацию разработчики и заказчики могут почерпнуть из ГОСТ 19.201-78, ISO/IEC/ IEEE 29148-2011, IEEE STD 830-1998.
Так что такое ТЗ, и что оно дает заказчику и подрядчику?
ТЗ (на разработку web-сайта, интернет-магазина, мобильного приложения и т.д.) — это основной документ, определяющий требования к создаваемому продукту (решению), порядок его создания и критерии оценки (приемки).
Техническое задание необходимо и заказчику, и подрядчику. Почему? Давайте разберемся.
ТЗ сводит к минимуму разногласия между заказчиком и исполнителем
На этапе разработки, обсуждения и согласования технического задания решается 99% всех возможных разногласий, в ходе реализации, конечно, могут возникать дополнительные нюансы, но как правило, они не имеют принципиального характера и быстро решаются – это нормальный рабочий процесс.
Техническое задание дает четкие критерии оценки готового продукта (сайта, сервиса, приложения)
Правильно сформулированное ТЗ дает исполнителю понимание того, что должно быть на выходе, а заказчику — как оценивать результат. Чем меньше в тех. задании абстрактных формулировок, которые можно понять по-разному, тем лучше.
Вот несколько примеров плохих и хороших формулировок из ТЗ на разработку сайта:
| Плохо, неоднозначно | Хорошо, понятно |
| Сайт должен быть быстрым. | Показатели скорости работы для десктопной и мобильной версии по Google PageSpeed Insights должны быть не ниже 90. |
| Нужна CMS для управления контентом. | CMS для сайта — Битрикс, WordPress и т.д. |
| В интернет-магазине должны быть фильтры для быстрого поиска товаров. | Реализовать фильтры по размерам, производителю, модели, году выпуска. |
| Сайт должен быть кроссбраузерным и адаптивным. | Корректное отображение (в соответствии с макетом) в браузерах: Google Chrome, Opera, ЯндексБраузер, Mozilla Firefox, Safari последних версий на момент приемки работ. Адаптация под Retina-дисплей. Сайт должен адаптироваться под следующие размеры экранов: 320px, 640px, 960px, 1024px, 1280px, 1920px. |
| Должна быть возможность загрузки товаров в интернет-магазин из внешних файлов. | Реализовать импорт товаров из файлов в формате csv с помощью модуля импорта 1С Битрикс. Пример файла импорта приложен к ТЗ. |
Т.е. нужно больше цифр и конкретных формулировок.
Зачастую за доработки, которые не определены в ТЗ разработчики берут доплату. Так что, чем оно полнее и детальнее, тем лучше.
Техническое задание поможет точно оценить затраты и возможности
Имея на руках готовое ТЗ, вы можете показать его нескольким подрядчикам. Для вас — это возможность сравнить несколько предложений и выбрать лучшее. Исполнитель, в свою очередь, проанализировав ТЗ, сможет оценить свои возможности по реализации проекта. Это позволит сразу отсечь подрядчиков, которые не способны выполнить задачу.
Кроме того, ТЗ защитит вас от переплат и неверной оценки стоимости и сроков работ, когда подрядчик в ходе выполнения работ поймет, что неправильно оценил проект и озвучил слишком низкую стоимость или наоборот “перезаложился” при оценке. Если будет подробное техническое задание, утвержденное обеими сторонами, вероятность того, что исполнитель сделает работу в срок и в рамках установленного бюджета многократно увеличивается.
ТЗ поможет организовать работу с несколькими подрядчиками или безболезненно сменить исполнителя
Вполне нормальная ситуация, когда над компонентами сайта или программы работают разные подрядчики. Грамотно составленное техническое задание — гарантия того, что части, реализованные разными исполнителями, стыкуются без проблем.
Пример — верстка сайта одним исполнителем, а его натяжка на CMS —другим. Опытный верстальщик посмотрит в ТЗ, увидит, что web-ресурс будет работать на «Битриксе» и сверстает макет с учетом особенностей этой системы управления контентом. Бекэндеру останется натянуть на движок готовую верстку. В противном случае есть вероятность того, что интеграция на CMS затянется: придется обращаться к фронтендеру для доработки каких-то моментов, которые не устраивают бекэнд разработчика, либо придумывать последнему какие-то «костыли», не прибавляющие коду лаконичности, а сайту скорости.
Случается, что в самом разгаре работ приходится менять подрядчика (причины могут быть разными, зависящими, как от заказчика, так и от исполнителя). Если у вас есть грамотно составленное ТЗ, новый подрядчик быстро войдет в курс дела и реализует все именно так, как было задумано. Если работать с несколькими исполнителями без единого технического задания, может получиться, как в известном мультфильме.
Кто составляет техническое задание и что в нем должно быть
Если подрядчик говорит вам: «Сделайте ТЗ, а я все реализую», бегите от него.
Техническое задание готовит исполнитель. Почему? Да потому что он больше знает о разработке ПО или создании сайтов, чем заказчик, и может подсказать, в каком направлении двигаться, предложить наиболее оптимальное техническое решение под конкретную задачу, сроки и бюджет. Понятно, что делает он это не самостоятельно, а совместно с заказчиком, отталкиваясь от его функциональных требований и пожеланий. Чем активнее заказчик участвует в данном процессе, тем качественней и проработанней получается результат, а риски того, что на выходе получится не совсем то, что хотел заказчик – стремятся к нулю.
Потратив неделю на работу над ТЗ совместно с подрядчиком, в будущем вы сэкономите месяцы и тысячи (а может даже и сотни тысяч) рублей на доработках не зафиксированных в техническом задании.
Что должно быть в техническом задании
- Пояснение используемых в документе терминов. Благодаря ему стороны понимают, что говорят друг с другом на одном языке и одинаково трактуют формулировки.
- Информация о компании-заказчике. Хороший подрядчик — тот, который готов вникнуть в бизнес клиента и разобраться с его потребностями, чтобы решить их максимально эффективно.
- Цели создания сайта и целевая аудитория. Понимание того, для чего делается веб-ресурс, влияет на результат. Кому-то важен дизайн и визуальные эффекты, а скорость не имеет большого значения. Кто-то будет использовать веб-ресурс как виртуальную витрину (интернет-магазин) и как основное средство коммуникации с клиентами – специфику всегда важно учитывать.
- Требования к сайту. Большой и важный раздел. Сюда включают все основные требования – технические и функциональные, описание архитектуры, ролей пользователей, сценарии использования, требования к дизайну, контенту. Обязательно должны быть указаны технические моменты (от скорости до используемых технологий и CMS). Не стоит забывать и про требования к хостингу, на котором будет размещаться веб-ресурс.
- Прототипы страниц. Не стоит пытаться описать все текстом. Наглядная информация воспринимается лучше.
- Стадии разработки. Благодаря этому заказчик видит, что и когда будет готово, и может контролировать процесс на разных этапах. А исполнитель, в свою очередь, понимает, что и когда от него ждут.
Конечно, это обобщенная модель технического задания. С учетом специфики проекта ТЗ может (и должно) содержать какие-то особенные разделы и нюансы.
Общую структуру ТЗ, которую мы используем в своих проектах, вы можете посмотреть – здесь.
Вывод
ТЗ должно быть в любом проекте и должно содержать формализованное отражение общей концепции, а также детализацию (как можно более точную) всех требований и пожеланий заказчика – иначе есть риск, что в результате вы получите не совсем то, что хотели, а в худшем случае – совсем не то.
Кроме того, проработанное ТЗ — это еще и минимизация затрат (временных и денежных). Ведь четко понимая, что должно быть в результате, исполнитель пойдет к цели кратчайшим путем.
Источник: uncore.ru