Задание на проектирование и техническое задание в чем разница

Форум АСУТП

Техническое задание и задание на проектирование

Обсуждение вопросов, не относящихся ни к одному из других подразделов

Модератор: kirillio

17 сообщений • Страница 1 из 1
Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Техническое задание и задание на проектирование

Сообщение Denis_39 » 24 апр 2013, 18:37

Необходимо уочнение по вопросу написания ЗАДАНИЯ НА ПРОЕКТИРОВАНИЕ системы автоматизации и управления зданием (САиУЗ). Правильно ли писать ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ руководствуясь ГОСТ 34.602-89, который регламентирует написание ТЕХНИЧЕСКОГО ЗАДАНИЯ НА СОЗДАНИЕ АС? В ГОСТ 34.602-89 есть п.1.3, который и навел на размышления:
«1.3 Требования к АС в объеме, установленным настоящим стандартом, могут быть включены в ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.»
Т.е. получается что ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ это более объемный документ по сравнению с ТЕХНИЧЕСКИМ ЗАДАНИЕМ НА СОЗДАНИЕ АС? Дополненный, например, требованиями касающиеся общестроительных вопросов и т.п.

Denis_39

Михайло почётный участник форума
Сообщения: 3515 Зарегистрирован: 10 ноя 2009, 04:58 Имя: Толмачев Михаил Алексеевич город/регион: г. Чехов, МО Благодарил (а): 4 раза Поблагодарили: 233 раза

Re: Техническое задание и задание на проектирование

Сообщение Михайло » 24 апр 2013, 20:05

Отбросим слова «техническое» и «АС», остается:
Задание на проектирование
Задание на создание

ГОСТ 34 устанавливает требования к сложному (в управленческом смысле) процессу создания АСУ. Техническое же задание на проектирование — это по сути требование к изделию (термин ЕСКД), а не к управленческому процессу.

НО: как понимают эти понятия те, кто дал Вам задание на создание задания? 🙂

Михайло

Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Re: Техническое задание и задание на проектирование

Сообщение Denis_39 » 24 апр 2013, 20:48

Михайло писал(а): Отбросим слова «техническое» и «АС», остается:
Задание на проектирование
Задание на создание

Нет, не чувствую. Проектирование — это так же процесс, причем в тесном взаимодействии со смежниками (ВКашниками, ОВшниками, электриками, технологами, строителями)

ГОСТ 34 устанавливает требования к сложному (в управленческом смысле) процессу создания АСУ. Техническое же задание на проектирование — это по сути требование к изделию (термин ЕСКД), а не к управленческому процессу.

Требования к «сложному (в управленческом смысле) процессу создания АСУ» указаны в ГОСТ 34.601-90. А если, по Вашему мнению, задание на проектирование это отдельный документ, то согласно требованиям какого нормативного документа он составляется?

НО: как понимают эти понятия те, кто дал Вам задание на создание задания? 🙂

Да никак не понимают — им эти тонкости ваЩе по барабану 🙂 Это я так выясняю, для себя, на всякий случай.

Denis_39

Михайло почётный участник форума
Сообщения: 3515 Зарегистрирован: 10 ноя 2009, 04:58 Имя: Толмачев Михаил Алексеевич город/регион: г. Чехов, МО Благодарил (а): 4 раза Поблагодарили: 233 раза

Re: Техническое задание и задание на проектирование

Сообщение Михайло » 25 апр 2013, 05:37

Эти тонкости не по барабану ГОСТ 34, который устанавливает стадии:

Создание = проектирование + закупки + монтаж + наладка.

Сравните пункты в таблице 3.1 и 5.3-5.4.

Михайло

Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Re: Техническое задание и задание на проектирование

Сообщение Denis_39 » 25 апр 2013, 14:15

Вам же сказали заняться проектированием.
Спасибо, что напомнили
Сравните пункты в таблице 3.1 и 5.3-5.4.

5.4 Разработка заданий на проектирование в смежных частях проекта
объекта автоматизации.

Т.е. применительно к современным реалиям, это применимо для стадии П, в которой, согласно постанвлению правительства РФ №87, вообще отсутствует самостоятельный раздел для АС. И т.о. действительно необходимо писать задания на проектирование для всех смежников. У меня же речь идет о задании на проектирование основного комплекта рабочих чертежей марки АХХ (стадия Р). Мой косяк — не уточнил про какие стадии проектирования идет речь.

В итоге, получается, что задание на проектирование на стадии П пишется для смежников, а непосредственно для АС (так же на стадии П) пишется техническое задание на создание АС (ГОСТ 34.602-89). Только остается неясно по какому документу пишется задание на проектирование для смежников, так же по ГОСТ 34.602-89?

Последний раз редактировалось Denis_39 25 апр 2013, 17:19, всего редактировалось 1 раз.

Denis_39

Dmitry Isaev освоился
Сообщения: 203 Зарегистрирован: 22 янв 2010, 09:04 Имя: Исаев Дмитрий Валериевич Страна: Россия город/регион: Самара Благодарил (а): 3 раза Поблагодарили: 7 раз

Re: Техническое задание и задание на проектирование

Сообщение Dmitry Isaev » 25 апр 2013, 15:45

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

_____________
«Век живи — век учись! И ты, наконец, достигнешь того, что подобно мудрецу будешь иметь право сказать, что ничего не знаешь» (К.Прутков)

Dmitry Isaev

Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Re: Техническое задание и задание на проектирование

Сообщение Denis_39 » 25 апр 2013, 16:15

Dmitry Isaev писал(а): насколько я сталкивался с Заданием на проектирование, то это были листочки от заказчика с его пожелелками.
Denis_39, можно по-подробнее, кому этот документ должен быть выдан?

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

Последний раз редактировалось Denis_39 25 апр 2013, 17:26, всего редактировалось 1 раз.

Denis_39

Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Re: Техническое задание и задание на проектирование

Сообщение Denis_39 » 25 апр 2013, 17:16

BigDog писал(а): Люди, ЗП разрабатывают на технологический объект. Где отдельным разделом идет что должна быть на объекте внедрена АСУ ТП. Обычно там пара предложений на сей счет.

Речь идет не о задании на проектирование в целом на объект (со всем его неповторимым многообразием), а конкретно на АС (5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. ГОСТ 34.601-90), где «парой предложений на сей счет» не отделаешься (хотя не исключаю, что некоторыые именно так и делают) 😉

Дальше идет стадийность по ГОСТ: ТТ (FEED), ПСД, создание, ПНР, СМР.
Уточните пожалуйста, по какому именно ГОСТ? ГОСТов в природе не просто много, а очень много 🙂

Denis_39

Dmitry Isaev освоился
Сообщения: 203 Зарегистрирован: 22 янв 2010, 09:04 Имя: Исаев Дмитрий Валериевич Страна: Россия город/регион: Самара Благодарил (а): 3 раза Поблагодарили: 7 раз

Re: Техническое задание и задание на проектирование

Сообщение Dmitry Isaev » 25 апр 2013, 17:31

если следовать ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем», то там на этапе ТП есть «Технические задания на разработку специализированных (новых) технических средств» и есть «Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, подготовительные работы, связанных с созданием системы» ( последние в состав проекта не входят ) про последние речь?

_____________
«Век живи — век учись! И ты, наконец, достигнешь того, что подобно мудрецу будешь иметь право сказать, что ничего не знаешь» (К.Прутков)

Dmitry Isaev

Автор темы

Denis_39 здесь недавно
Сообщения: 94 Зарегистрирован: 17 фев 2012, 15:42 Имя: Денис Страна: РФ Поблагодарили: 1 раз

Re: Техническое задание и задание на проектирование

Сообщение Denis_39 » 25 апр 2013, 18:00

Dmitry Isaev писал(а): если следовать ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем», то там на этапе ТП есть «Технические задания на разработку специализированных (новых) технических средств» и есть «Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, подготовительные работы, связанных с созданием системы» ( последние в состав проекта не входят ) про последние речь?

Да. Хотя формулировка в ГОСТ 34.201-89 и не сходится на все 100% с формулировкой в ГОСТ 34.601-90, но смысл один и тот же.

Denis_39

Dmitry Isaev освоился
Сообщения: 203 Зарегистрирован: 22 янв 2010, 09:04 Имя: Исаев Дмитрий Валериевич Страна: Россия город/регион: Самара Благодарил (а): 3 раза Поблагодарили: 7 раз

Re: Техническое задание и задание на проектирование

Сообщение Dmitry Isaev » 25 апр 2013, 18:10

Тогда, ИМХО, можете применять ГОСТ34.601, можете не применять. т.к. для предприятий с наличием в штате строителей, электриков, виковцев, связистов и т.д. в различных отделах — никаких ГОСТов, одни задания смежному отделу. Если писать надо задание другой организации — скорее всего это тех.требования в виде приложения к договору.
Конкретных требований к ЗП — нет (во всяком случае я не встречал)

_____________
«Век живи — век учись! И ты, наконец, достигнешь того, что подобно мудрецу будешь иметь право сказать, что ничего не знаешь» (К.Прутков)

Dmitry Isaev

Михайло почётный участник форума
Сообщения: 3515 Зарегистрирован: 10 ноя 2009, 04:58 Имя: Толмачев Михаил Алексеевич город/регион: г. Чехов, МО Благодарил (а): 4 раза Поблагодарили: 233 раза

Re: Техническое задание и задание на проектирование

Сообщение Михайло » 25 апр 2013, 20:16

Техническое задание (задание на проектирование) — это требования и больше ничего. В моем понимании достаточно изложить требования в таком объеме и таким образом, чтобы документация смежников в последствии нормально стыковались с Вашей документацией.

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

Несмотря на мизерность объема информации, документ очень важен.

Михайло

Dmitry Isaev освоился
Сообщения: 203 Зарегистрирован: 22 янв 2010, 09:04 Имя: Исаев Дмитрий Валериевич Страна: Россия город/регион: Самара Благодарил (а): 3 раза Поблагодарили: 7 раз

Re: Техническое задание и задание на проектирование

Сообщение Dmitry Isaev » 26 апр 2013, 15:28

BigDog писал(а): Нет такого понятия- Задание на проектирование. Есть- Техническое задание. На проектирование- в т.ч.

ну здесь вы не правы: (из словаря) «ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ — перечень требований, условий, целей, задач, поставленных заказчиком в письменном виде, документально оформленных и выданных исполнителю работ проектно-исследовательского характера. Такое задание обычно предшествует разработке строительных, конструкторских проектов и призвано ориентировать проектанта на создание проекта, удовлетворяющего желаниям заказчика и соответствующего условиям использования, применения разрабатываемого проекта, а также ресурсным ограничениям. Применяется также термин «техническое задание» .»
Форму задания на проектирование можно посмотреть в СНиП 11-01-95 «О ПОРЯДКЕ РАЗРАБОТКИ, СОГЛАСОВАНИЯ, УТВЕРЖДЕНИЯ И СОСТАВЕ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ НА СТРОИТЕЛЬСТВО ПРЕДПРИЯТИЙ, ЗДАНИЙ И СООРУЖЕНИЙ» Приложение Б. (правда, не следует забывать, что он отменён).
По моему мнению здесь опять происходит не стыковка ГОСТов серии 21 (СПДС) с 24 и 34 (АС), а т.к. последние с 90-х годов никто не корректировал из-за их «сырости» и устаревания во времени, то эти различия (в терминах, названиях документов. составе проекта, оформлении и т.д.) ещё долго будут вылазить на свет божий

_____________
«Век живи — век учись! И ты, наконец, достигнешь того, что подобно мудрецу будешь иметь право сказать, что ничего не знаешь» (К.Прутков)

Техническое задание

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

В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.
Слово «проект» в области деятельности «управление проектами» и «управление проектированием» применяется в значении «программа», «план действий», «комплекс работ».

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

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

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

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

Место ТЗ в структуре проектирования

Основная статья: Проектирование

Проектирование — это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.

Стадии проектирования регламентированы стандартами. [2] [3] Это следующая последовательность:

• Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
• Техническое предложение,
• Эскизный проект,
• Технический проект,
• Стадии рабочего проекта.

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

Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Частные технические задания

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

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

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

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

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

Необходимость ТЗ

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

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

Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).

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

Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить — 99 рублей. [4] Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

• Обеим сторонам:
  • представить (вообразить) готовый продукт,
  • выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
  • уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
  • осознать, что именно ему нужно,
    • в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
    • понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта или автоматизированной системы,
    • спланировать выполнение проекта и работать по намеченному плану,
    • отказаться от выполнения работ, не указанных в ТЗ.

    Регламентированное ТЗ

    Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ, ОСТ).

    • ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению [5] (кратко изложено содержание ТЗ);
    • ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы [6] (достаточно подробно изложены состав и содержание ТЗ);
    • ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления [1] (приведен порядок построения ТЗ).

    В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

    • ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
    • Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу [7] (приложен образец технического задания на разработку в рамках ГОЗ)

    Разделы ТЗ по ГОСТ 34.602-89 (пример)

    Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде):

    1. Общие сведения
       1. полное наименование системы и ее условное обозначение;
          1. Пример:

          Полное наименование системы: Автоматизированная система «Управление» Условное обозначение: АСУ

          1. 1. шифр темы или шифр (номер) договора;
                1. Пример:

                Договор № ХХХ от ДД.ММ.ГГГГ

                1. 1. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
                      1. Пример:

                      ЗАКАЗЧИК Наименование заказчика: ООО «МИР» Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: Pro@mir.com ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423 > 400000000234

                      ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО «ДЯТЕЛ» Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: Gena@gizni.net ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

                      1. 1. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
                         2. плановые сроки начала и окончания работы по созданию системы;
                         3. сведения об источниках и порядке финансирования работ;
                         4. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
                         1. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
                         2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
                         1. Требования к системе в целом;
                         2. Требования к функциям (задачам), выполняемым системой;
                         3. Требования к видам обеспечения.
                         1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;
                         2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
                         3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
                         4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).
                         1. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
                         2. общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
                         3. статус приемочной комиссии (государственная, межведомственная, ведомственная).
                         1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
                         2. изменения, которые необходимо осуществить в объекте автоматизации;
                         3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
                         4. создание необходимых для функционирования системы подразделений и служб;
                         5. сроки и порядок комплектования штатов и обучения персонала.
                         1. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
                         2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
                         3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

                         Вид и состав требований ТЗ

                         Часто содержание ТЗ устанавливается внутренними документами предприятия либо соглашением заказчика и исполнителя проектных работ.

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

                         • Цели в функциональном виде. Изделие является лишь материальным носителем определенных функций, выполнение которых и позволяет достигать заданные цели (удовлетворять потребности). Но одну и ту же функцию могут выполнять разные устройства. Поэтому функциональное, а не предметное указание цели расширяет область возможных решений, что необходимо для поиска оптимального решения. Также, функция — более четкий термин для описания сути назначения устройства. Уточнение целей и назначение соответствующих им функций — наиболее важная часть работы по составлению ТЗ;
                         • Выполнение функций, реализующих заданные потребности, всегда увязывается с удовлетворением определенных требований (см. перечень типовых требований к техническим устройствам), которые делают изделия более привлекательными, учитывают и конкретизируют особенности производства и эксплуатации и т. п. Для удобства требования по виду подразделяют на три группы:
                           • условия, характеризуются конкретными значениями данных (формально их можно представить в виде равенств). Например, масса изделия должна составлять 10 кг, применять сталь 40Х, место эксплуатации — тундра. Важную часть условий формирует оценка доступных ресурсов;
                           • ограничения, задают допустимую область данных (формально их можно представить в виде односторонних или двусторонних неравенств). Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;
                           • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания — максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

                           Как и процесс проектирования, работа с требованиями также подлежит управлению. Эти процедуры хорошо отработаны, например, в управлении требованиями к программному обеспечению.

                           Для конкретизации целей и требований, заданных нечётко либо качественно, применяют метод декомпозиции.

                           Основная статья: Параметр (техника)

                           Стоит отметить, что приведённые в условии данные — это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые своими предельно-допустимыми значениями (например, масса изделия 9,8…10,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

                           При формировании системы требований обязателен анализ следующих источников:

                           • Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели. Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
                           • Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора, Росприроднадзора, ГПС, МВД России, Роструда.
                           • Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

                           Составление списка требований ТЗ

                           Основная статья: Методы проектирования

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

                           Сначала приведем рассказ о том, как Эдисон ставил перед собой техническую задачу. [8]

                           Прежде, чем приступить к разработке электрического освещения в быту, Эдисон провел исследования, при каких условиях оно выдержит конкуренцию в цене, яркости и удобстве с газовым освещением (рожком). Он до тонкостей изучил газовую промышленность, разработал план центральной электростанции и схему линий электропередач к домам и фабрикам. Затем подсчитал стоимость меди и других материалов, которые потребуются для изготовления ламп и добычи электроэнергии с помощью динамо-машины, движимой паром. Анализ данных определил не только размеры лампы, но и её конкурентоспособную цену, равнявшуюся 40 центам. И лишь когда Эдисон убедился, что сможет решить проблему электрического освещения, он принялся работать над лампой накаливания с угольной нитью, помещенной в стеклянный шар, из которого откачан воздух. В поисках материала нити он опробовал около 6 000 разновидностей растительного волокна.

                           Анализ задания заказчика

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

                           Следует выявлять и стараться избегать решения следующих задач:

                           • задачи, не соответствующие общественным потребностям — криминальные, аморальные, негуманные. Их решение — дело совести разработчика;
                           • технические псевдозадачи, с ошибочно выдвинутыми целями. Это — задачи, которые уже имеют решение, либо не имеют объективных предпосылок для своего решения (преждевременные задачи, но это нуждается в обосновании, чтобы отказ в решении не был следствием психологической инерции или других субъективных причин);
                           • химерические задачи. Это — задачи с ошибочно поставленной целью, достижение которой противоречит законам физики (например, создание устройства с КПД более 100 %, устройства мгновенного действия и т. п.), либо абстрактно выдвинутые задачи, принципиально не имеющие решения (типа философского камня).

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

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

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

                           Противоречие может быть декомпозировано, то есть представлено в виде элементарных проблем.

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

                           Если прообраз существует, то рекомендуют:

                           • либо забыть о его существовании и, отталкиваясь от исходной потребности, предложить возможные варианты с последующим выбором лучшего;
                           • либо усовершенствовать прообраз, воспользовавшись ИКР;
                           • либо локализовать потребность. Обычно неудовлетворительная работа связана с несовершенством только некоторых подсистем. С этой целью прообраз декомпозируют по функциональному признаку, а противоречие представляют в виде элементарных проблем. Соотнося элементарные проблемы с определенными подсистемами прообраза, выявляют «несовершенные» подсистемы. Таким образом, от решения общей и сложной задачи переходят к более простой частной задаче. Но степень улучшения свойств может оказаться невысокой, могут возникнуть проблемы по состыковке усовершенствованных подсистем с прежними.

                           Конкретизация целей проектирования

                           После уточнения и обоснования целей разработки назначают соответствующие им функции. Чтобы предубеждения и психологическая инерция не сужали область поиска, а заказчик своей формулировкой задачи не предопределял направления поиска решения, желательно функцию формулировать обобщенно и в нейтральных терминах. Так, функцию «сбивать» (допустим, доски) лучше заменить термином «соединять», что позволяет отвлечься от естественной ассоциации — сбивать гвоздями, и предлагает более широкий круг возможных решений.

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

                           Наряду с потребностью в каком-то действии может существовать и потребность в несовершении действия или совершении действия с отрицательным эффектом.

                           Обработка собранной информации

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

                           Абстрагирование предназначено дать такую формулировку требованиям, чтобы избежать предопределения путей решения задачи (не создавать психологических барьеров). Для получения «сильных» решений рекомендуют проводить усиление системы требований и обострение противоречий путем формулирования ИКР.

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

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

                           3. Разграничение требований на условия, ограничения и показатели качества.
                           Представление требований в виде показателей позволяет получить решения с высокими характеристиками, но такая задача решается сложнее. В качестве показателей выбирают те, которые характеризуют наиболее важные свойства (с целью возможности получения наилучших значений). Для вводимых условий необходимо оценить величину разброса и необходимость указания предельных значений, то есть представления их в виде ограничений.

                           4. Параметризация.
                           Точность суждения и верность выбора зависят от степени конкретности исходных требований, представлены ли они в формализованном или неформализованном виде. Для однозначности выводов все требования должны быть переведены в формализованный вид, то есть указаны характеризующие их параметры, причем такие, которые можно измерить, проконтролировать, рассчитать. Это также позволит выделить дублирующие требования (те, которые характеризуются одними и теми же параметрами) и обобщить их (ввести обобщенные параметры с целью сокращения общего их числа, удельные характеристики).

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

                           Проблемами оценки качества посредством количественных показателей занимается наука «Квалиметрия».

                           5. Усечение списка требований.
                           Большой объем информации хотя и способен дать максимально полное представление о решаемой задаче, но труднее удерживается в голове, усложняет решение задачи. Для сокращения сведений до разумного объема (под способности каждого конкретного разработчика, соответствие его финансовым, организационно-техническим, временным ресурсам) можно воспользоваться их ранжированием или разделением на группы обязательных к учету, желательных и несущественных. К обязательным относятся те, неудовлетворение которых существенным образом влияет на выбор вариантов решений. Это — функциональные параметры, условия взаимосвязи систем и их частей и другие. Желательные требования позволяют различить варианты по степени качества.

                           Стоит принимать во внимание слова Ли Якокки: «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится ещё шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни — всё делать вовремя. … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения». [9]

                           6. Сведение требований в единый документ и утверждение его заказчиком.

                           Ссылки

                           1. ↑ 12ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления
                           2. ↑ГОСТ 2.103-68. Единая система конструкторской документации. Стадии разработки
                           3. ↑ГОСТ 19.102-77. Единая система программной документации. Стадии разработки
                           4. ↑Крылов А.Н. Мои воспоминания. — СПб. : Политехника, 2003. — 510 с.
                           5. ↑ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
                           6. ↑ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
                           7. ↑Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома 16.09.2004 №95.
                           8. ↑Уилсон М. Американские учёные и изобретатели. — М .: Знание, 1975. — 136 с.
                           9. ↑Якокка Л. Карьера менеджера. — Мн: Попурри, 2006. — 544 с. — ISBN 985-483-756-4

                           См. также

                           • Спецификация
                           • Методы проектирования
                           • Модель
                           • Показатель качества
                           • Проектирование
                           • Управление проектированием
                           • Менеджмент
                           • Разработка программного обеспечения
                           • Проектирование программного обеспечения

                           Литература

                           • Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с. — ISBN 5-217-00016-3Электронная версия 2011 г.

                           Как составить техническое задание и сэкономить 20% на стоимости проекта

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

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

                           

                           Что такое техническое задание?

                           Техническое задание — это согласованный заказчиком и исполнителем документ, который полностью описывает все требования к будущему сайту, порталу, сервису, CRM- или ERP-системе. Чем четче указаны все требования и пожелания, тем лучше обе стороны друг друга понимают, и тем выше шанс, что они останутся довольны результатом.

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

                           

                           Польза наличия технического задания для клиента

                           • Клиент может использовать ТЗ для того, чтобы понять, за что он платит деньги, какой сайт получит в итоге. Еще до начала разработки можно увидеть структуру, понять, как элементы будут взаимосвязаны между собой. И если что-то не устраивает, изменения можно внести в ТЗ до начала разработки.
                           • Убедиться в том, что исполнитель имеет нужный опыт и навыки. Техзадание пишет технический писатель, проектный менеджер или тимлид, и если оно понятное, четкое, не содержит воды или двусмысленности, то это значит, что данная выбранная команда — настоящий специалист своего дела. Если же в техзадании каша из терминов и непонятных набросков, значит нужно бежать от таких исполнителей без оглядки.
                           • Сверить готовую работу с ТЗ. Если в переданном сайте (CRM-системе, мобильном приложении) есть очевидные несоответствия документу, разработчики обязаны внести правки бесплатно, а если они отказываются, техзадание — 100%-й вариант выигрыша дела в суде.
                             Пояснение: при подписании документов о сотрудничестве к основному договору обязательно прикрепляется техническое задание, которое подписывают обе стороны. Такой документ имеет юридическую силу и может помочь вам доказать правоту при возникновении каких-либо разногласий
                           • Узнать реальную стоимость разработки сложного функционала. Невозможно оценить стоимость разработки сайта или приложения с большим функционалом, не видя картину целиком. ТЗ же позволяет разложить проект на отдельные модули, таким образом давая возможность оценить каждый из них отдельно. Обычно после написания проектной документации составляется бэклог — смета проекта. В этом документе указывается время на каждую из задач (отдельно оценивается клиентская часть, отдельно — серверная), которое умножается на стоимость одного часа работы программиста. Таким образом по итогу работ Заказчику предоставляется не только сам документ с техзаданием, то и детальная оценка проекта.

                           

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

                           Зачем техническое задание исполнителю?

                           • Необходимо для того, чтобы понять, что хочет увидеть заказчик. Перед составлением ТЗ на разработку сайта специалист задает клиенту множество вопросов, показывает готовые примеры, предлагает решения. Каждый выбор, описание каждой функции и элемента записывают в единый документ, который структурируется по разделам. Если этот документ проходит согласование у клиента – значит и заказчик, и исполнитель верно поняли друг друга, и техническое задание содержит все необходимые требования.
                           • Застраховаться от внезапных изменений. За несколько лет работы мы сталкивались с ситуациями, когда клиент посередине процесса разработки решал внести значительные изменения в проект. Как правило, все начиналось с “а можно добавить еще одну маленькую фичу”, а заканчивалось на “а давайте из лендинга сделаем второй Amazon”. Именно в таких случаях очень выручает ТЗ, ведь все работы производятся только в соответствии с ним.
                           • Не менее важное назначение ТЗ — доказать экспертность. Грамотно составленное техническое задание может переубедить даже сильно сомневающегося заказчика. Часто именно на этапе составления ТЗ наши потенциальные клиенты превращались в реальных – когда заказали лишь составление технического задания для проекта, а в по итогу увидели, что мы полностью понимаем их потребности.
                           • Упростить и ускорить работу над проектом. Вся команда, которая работает над сайтом или приложением, опирается на ТЗ, как на основной свод законов. В качественном техзадании проработана структура будущего продукта, детально описан каждый из функциональных элементов, учтены условия интеграции со сторонними сервисами, при необходимости добавлены UML-диаграммы на основе user-stories, а также Mind Map, согласно карте сайта. Таким образом, после подготовки данного документа, команда не тратит время на выяснение нужд и требований, а достаточно быстро проектирует прототип и рисует дизайн-макет, без препятствий продвигается в написании программной части проекта. Без ТЗ же обе стороны ожидают бесконечные переговоры друг с другом, выяснения нужд и требований уже по ходу работы, что ведет к перелимитам по стоимости и срокам разработки, а также отрицательно влияет на качество написанного кода.

                           

                           Кто должен составлять техническое задание?

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

                           Главная задача нашего технического писателя — это получение информации о целях, задачах будущего программного продукта. Для обозначения вышеперечисленных тезисов важно как можно глубже окунуться в бизнес клиента, дабы понять все процессы изнутри. К примеру, вы — владелец оффлайн сети магазинов, у вас грамотно налажен бизнес и вы поняли, что следующий шаг — это выход на площадку ecommerce.

                           Мы, как компания-разработчик, должны получить все данные о вашем бизнесе:

                           • используете ли Вы систему учета (например, 1С)
                           • какие пользовательские роли планируете добавить на сайте (клиент, менеджер, логист)
                           • каково Ваше УТП
                           • какая у вас целевая аудитория.

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

                           При составлении технического задания мы руководствуемся следующими принципами:

                           1. Информативность — ТЗ должно быть максимально информативным, не оставляющим места для двусмысленности
                           2. Понятность — каждая задача, описанная в ТЗ, выделена и визуально разграничена- то есть понятно, где закончился и где начался следующий пункт
                           3. Точность — в документе не должны использоваться абстрактные фразы, например, “удобная навигацию” или «красивое превью пользователя».
                           4. Наглядность — для достижения понимания, как будут выглядеть сложные интерфейсы, или же для наглядного пояснения сложных взаимосвязанных функций, к техзаданию могут быть прикреплены изображения, добавлены схемы, таблицы, графики и диаграммы.
                           5. Качество — во время написания ТЗ мы анализируем сайты с похожим функционалом, обращаемся к уже выполненным нами подобные проекты, чтобы сделать будущий продукт качественнее, нежели у конкурентов

                           

                           От теории к практике: как составить ТЗ на разработку сайта

                           Полноценное техническое задание должно грамотно раскрывать следующие темы:

                           Цели и задачи проекта
                           Данный пункт может быть принят несерьезно, однако опыт показывает, что именно первые страницы документа, описывающие суть проекта, боли, с которыми сталкивается бизнес, его цели и задачи, несут огромную ценность для людей, которые впервые открывают ТЗ. Здесь также могут быть зафиксированы желания заказчика, и ожидаемый результат (например, автоматизация бизнеса или разработка магазина с нуля). Здесь также возможно добавить описание УТП, ЦА и способы монетизации будущего проекта.

                           

                           Стоимость разработки технического задания

                           Деятельность нашей компании охватывает два направления веб-разработки: сайты и мобильные приложения. Наша специализация — сложные и высоконагруженные сервисы, интернет-порталы, системы автоматизации бизнеса. Естественно, а зависимости от типа проекта, его сложности, меняется и ТЗ, его объем и срок написания, хотя в целом, структура остается прежней. Ниже мы более подробно рассмотрим чем отличается техническое задания для крупного и мелкого проекта.

                           К данному типу проектов относятся лендинги, сайты-визитки и корпоративные сайты. Основная цель подобных проектов — презентация услуг компании или одного человека.

                           Для данного типа проектов написание технической спецификации занимает не более нескольких дней, поскольку содержание ТЗ остается прежнем, основные блоки и функционал повторяются из проекта в проект с небольшими изменениями. Если появляется какой-то нюанс, то мы детально описываем его в документации. Техзадание для данного типа проектов может занимать не более 20-30 страниц А4.

                           Для высоконагруженных сайтов и сложных систем с множеством взаимосвязей создание технического задания обычно занимает не менее одного месяца (приблизительно 160 часов рабочего времени). Объем такого ТЗ может быть 80-120 страниц, в нем очень подробно описывается весь функционал проекта, пользовательские сценарии, требования к верстке и поддержке браузерами, перечень сторонних сервисов и описание методов интеграций с ними.

                           Кроме того, крупные проекты делятся на итерации – и под каждую итерацию готовится отдельное ТЗ, так как один функционал тянет за собой появление другого при реализации следующего этапа.

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

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

                           Тип проекта	Ориентировочная стоимость проекта до ТЗ	Стоимость ТЗ (10%)
                           Корпоративные сайты	от $3 000	от $300
                           Интернет магазины	от $7 000	от $700
                           Системы автоматизации	от $15 000	от $1 500
                           Маркетплейсы	от $20 000	от $2 000

                           

                           К чему приводит отсутствие ТЗ

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

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

                           

                           Case Study

                           Мы разрабатывали CRM-систему для компании, где более 4000 клиентов, а менеджеров по работе с клиентами всего 6. Нам нужно было оптимизировать работу сотрудников так, чтобы формирование базы данных клиентов и обработке их заявок происходила в пару кликов, а в конце дня/месяца/года формировались отчеты по количествам продаж.

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

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

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

                           

                           В поисках идеального ТЗ

                           На практике идеального ТЗ не бывает, все равно возникают доработки и нюансы, которые не были учтены. Но наличие грамотного ТЗ дает возможность уменьшить количество таких недоработок, что значит – сохранить ваши средства, а это 15-20% от эстимейта и во временном, и в денежном выражении.

                           Грамотное и полное ТЗ — первая ступенька к успешному проекту. Это фундамент, на котором все держится. Если вы хотите, чтобы ваш проект полностью соответствовал всем вашим ожиданиям, то можете оставить свои данные, и наш технический писатель свяжется с вами для написания ТЗ для вашего проекта.

                           Что такое ТЗ в IT сфере?

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

                           Как правильно написать техническое задание?

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

                           Что должно содержать техническое задание?

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

                           

                           Автор: Ilya Smyrnov

                           Должность: CEO, Business analyst

                           Биография: Более 8 лет занимаюсь анализом бизнесов клиентов и повышаю их эффективность с помощью внедрения IT-решений.

                           Ваc может заинтересовать

                           

                           Диджитализация

                           Фокус на бизнес-целях

                           Зачастую, IT подрядчик выполняет исключительно технические задачи: “скажите, что нужно сделать и мы сделаем”, совсем не понимая проблему, которую нужно решить. За 8 лет работы, мы пришли к выводу, что разработка сайта или приложения, не является конечной целью. Это лишь инструмент, помогающий решить проблему заказчика. В центре нашего подхода — цели клиента. Мы разбираемся в […]

                           

                           Веб-разработка

                           Какие существуют виды сайтов ?

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

                           

                           Веб-разработка

                           Этапы создания сайта

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

                           ОБСУДИТЬ ПРОЕКТ

                           Расскажите о своих бизнес-целях и наш опыт поможет их достичь!

                           Пример ТЗ на разработку сайта: универсальные пункты и образец составления

                           

                           816

                           • Что такое тз для сайта и зачем оно нужно
                             • Кто составляет задание на создание сайта
                             • Как написать хорошее ТЗ
                             • Десктопная версия
                             • Мобильная вёрстка

                             Как думаете, легко ли развивать сайт, который сделан по объявлению вроде: «Сайт за 500 грн.», «Сайт за 1000 руб.»?

                             

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

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

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

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

                             Что такое тз для сайта и зачем оно нужно

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

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

                             

                             Конкретные его пункты мы рассмотрим ниже.

                             От брифа ТЗ отличается тем, что оно гораздо более детализировано, благодаря чему можно:

                             • Сэкономить время и бюджет. Чем детальнее расписаны требования и инструкции, тем проще и быстрее их внедрить.
                             • Гарантировать результат. Документ фиксирует все работы, а потому недобросовестного исполнителя можно привлечь к ответственности. Или наоборот, разработчику требовать доплату за сверхурочные работы.
                             • Повысить эффективность сотрудничества. В процессе написания ТЗ заказчик и исполнитель оговаривают все важные моменты, что позволяет посмотреть на ситуацию с другой стороны и избежать недопонимания.

                             Кто составляет задание на создание сайта?

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

                             Например, заказчику ТЗ позволяет:

                             • Понять, на что используется бюджет.
                             • Удостовериться в компетентности исполнителя.
                             • Контролировать сроки и полноту выполнения работ.
                             • Быстро передать проект другой команде в случае ненадёжности исполнителя.

                             Для исполнителя же техзадание полезно тем, что:

                             • Можно понять желания и виденье заказчика, чтобы сразу удовлетворить его.
                             • Облегчить процесс разработки.
                             • Застраховаться от внезапных хотелок клиента.

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

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

                             Как написать хорошее ТЗ?

                             Прежде всего, техническое задание это регулирующий документ, а потому он должен быть:

                             1. Понятным для всех сторон. Добавьте расшифровку сложных терминов, которые используются в документе. Если в нём приводятся инструкции, они должны быть достаточно подробными и выполнимыми.
                             2. Показательным. Как правило, работа над созданием или редизайном сайта начинается с дизайнера, ведь на выходе вы получаете картинку. Однако сложно найти человека, который поймёт, что вы хотите, и сможет оцифровать эту картинку в вашей голове. Поэтому всё нужно продемонстрировать.Не стесняйтесь и не ленитесь приводить примеры сайтов, на которых вам нравится тот или иной функционал или элементы дизайна, вёрстка, эффекты.

                             Но! не просто давайте ссылки, а прикрепляйте скриншоты. Вы можете составить ТЗ, а владелец сайта (который вы приведёте в пример) к тому моменту, когда ТЗ перейдёт к исполнителю, поменяет вёрстку. Тогда вам снова придётся искать пример и объяснять, что вы имели в виду. Обязательно сохраняйте скриншоты себе на компьютер или в облачный сервис, чтобы они не были удалены через месяц (как, например, это возможно при использовании бесплатной версии сервиса Joxi). Всё должно храниться ещё хотя бы месяц после того, как сайт появится с обновлённой вёрсткой/функционалом.

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

                             Конкретным и однозначным. Уточняйте моменты, которые субъективны или их можно трактовать по-разному, иначе непонятно, какой результат вы ожидаете увидеть, и какой объём работ предстоит сделать исполнителю:

                             Неправильно	Правильно
                             Сайт должен быть быстрым.	Сайт должен загружаться в среднем за n-секунд на десктопах. Или сайт должен набирать минимум n-баллов по PageSpeed.
                             Форма заявки на услугу должна быть простой и удобной.	В форме заявки должно быть два поля: «Номер телефона» и «Ваше имя», а также кнопка «Заказать услугу». При этом номер телефона должен подгружаться автоматически у зарегистрированных пользователей.
                             CMS должна быть оптимизирована для интернет-магазина.	CMS должна иметь возможность создавать и удалять страницы, добавить товар в любой каталог сайта и другие требования.

                             Пример оформления технического задания для сайта

                             Каждая ситуация уникальна, но по нашему примеру вы сможете примерно понять, как происходит разработка ТЗ для сайта.

                             Для разработки общей концепции сайта выясняются:

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

                             Например, ООО «Принтфоревери», компания основана в 2007 году, изготавливаем рекламную (брендированную) и фанатскую продукцию не только на продажу, но и под заказ. Есть все виды печати на тканях, канцелярия, керамика и типография. Есть доставка по стране. Регулярно спонсируем фестиваль «Летний». Конкуренты: «Принтпризер», «Яркокрасочка».

                             1. Назначение (очень важный пункт). Опишите целевую аудиторию и задачи сайта, ответив на вопрос: кого вы хотите привлечь и для чего?

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

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

                             Аудитория компании по производству печатной продукции может делиться на несколько сегментов:

                             • Лица, ответственные за брендированную продукцию компании. Обычно заходят с ПК, с 9:00 до 18:00, возраст до 35 лет, локация — центр крупных городов, чаще — наш город. Заказывают канцелярию и кружки большой партией.
                             • Фанаты фильмов и сериалов. Молодые люди до 20 лет, пользуются преимущественно смартфонами, в любое время суток, локация — вся страна, заказ поштучный готового и индивидуального дизайна.
                             • Дизайнеры. От 25 до 45 лет, пользуются ноутбуками, в любое время суток, локация — центр города, заказывают печать своего дизайна малыми партиями.
                             1. Дополнительные пожелания клиента. Владелец описывает, что нравится или не нравится (особенно актуально, если у вас есть старый сайт).

                             Например, хочется домен .ru и адаптивный шаблон.

                             Следующие пункты уже непосредственно входят в типовой шаблон ТЗ:

                             1. Структура сайта. Здесь на основании семантики приводится иерархия разделов и её визуализация (для небольшого сайта можно обойтись списком). Также на данном этапе описываются навигационные цепочки.
                             2. Прототипы страниц и сценарии использования сайта. Пункт, в котором фиксируются требования и схематическое изображение страниц для создания шаблонов.Здесь же описываются все интерактивные элементы и их реакция на взаимодействие пользователя.На основе этих данных дизайнер, предварительно обсудив цветовые схемы, шрифты и стилистику, прорисовывает элементы сайта для вёрстки.
                             3. Требования к текстовому наполнению и SEO-параметрам. В этом пункте расписываются все особенности генерации URL, Title, Description для каждого типа страниц.

                             Например, что у страниц пагинации Title должен создаваться по шаблону «название раздела» + «номер страницы», а в урлах категорий не должны формироваться лишние уровни вложенности. Подробнее о требованиях ПС вы можете прочитать в статье «Чек-лист по внутренней и технической оптимизации сайта».

                             

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

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

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

                             Важно! Хостинг нужно выбирать только после выбора CMS, так как тарифы у хостингов разные и некоторые хостинги могут не поддерживать все типы систем управления сайтом.

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

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

                             

                             Как выглядит техзадание

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

                             Десктопная версия

                             Общая информация

                             Ширина сайта – 1140 px.

                             Шапка и футер растягиваются по ширине экрана и одинаковы для всех страниц.

                             Семейство шрифтов: Cambria (предпочтительно), Century, Georgia. Можно указать и другие популярные шрифты с засечками.

                             Размеры шрифтов (для Cambria):

                             • Текст под логотипом в шапке – 15px
                             • Ссылки в шапке – 14px
                             • Текст в футере – 16px

                             Главная страница – home.png

                             

                             Текст над строкой поиска – 25px

                             Текст под строкой поиска – 14px

                             1, 2 – цифры с реальным числом магазинов и отзывов. Можно пересчитывать один раз в 24 часа.

                             3 – категории. Располагаем вручную в таком порядке, как на макете.

                             4 – ссылки на магазины. Рядом с названием магазина выводим число отзывов. Если отзывов ещё нет, ничего не выводим.

                             Под каждой категорией выводим 6 самых популярных по количеству отзывов магазинов. Если в категории есть ещё магазины, на неё ведёт ссылка «Ещё N», где N – число магазинов. Если больше магазинов нет, на категорию ведёт ссылка «Показать всё».

                             5 – список низкопопулярных категорий. Выводим их тут.

                             Страница с описанием магазина и отзывами – shop-page.png

                             

                             Заголовок H1 – 30px

                             Заголовок H2 – 22px

                             1, 2, 3 – место под рекламные блоки. Нужно отметить это место при вёрстке и закрыть к индексации.

                             4 – контент страницы. Дизайн меняется таким образом, чтобы все изменения можно было внести глобально, без редактирования каждой страницы по отдельности:

                             • добавлен серый фон контентного блока;
                             • добавлен белый border у таблиц (по умолчанию, вроде, нигде не прописывался);
                             • добавлено место под рекламный блок над отзывами.

                             5 – заголовок формы. Нужно проставить «Добавить отзыв».

                             6 – последние отзывы (сквозной блок для постов и категорий). Это примерное отображение, допускается готовый плагин с похожей визуализацией.

                             Страница категории – category-archieve.png

                             

                             Ссылки на магазины – 18 px, цвет # 336699

                             Текст в анонсах – 14px

                             1,2 – место под рекламные блоки.

                             3 – контентная часть. Нужно удалить все описания категорий (тексты сохранить в отдельном .doc-файле и загрузить этот файл на сервер).

                             4 – ссылка на отзывы. Во всех шаблонах ТЗ слово «комментарии» меняем на «отзывы».

                             Служебная страница – page.png

                             

                             Размер шрифта – 15px

                             Рекламные блоки не выводим.

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

                             404 ошибка – 404.png

                             

                             404 – шрифт 80px

                             Текст под ним – 20px

                             Наклонный текст – 15px

                             Ссылки навигации:

                             • на главную – 16px;
                             • на служебные страницы– 14px

                             Активные элементы:

                             Все ссылки подчёркнутые, убираем подчёркивание при наведении, цвет ссылки на несколько оттенков темнее (на усмотрение исполнителя).

                             Цвет кнопки #ddd, при наведении появляется курсор в виде руки.

                             Рекомендую делать отдельные макеты и описывать поведение всех ссылок, кнопок, выпадающих меню, всплывающих окон.

                             Мобильная вёрстка

                             Сейчас лучше ставить мобильную вёрстку главной и от неё «плясать». Не зря же вся справка и блог Google пестрят «Mobile first» — сначала мобильные или мобильность. Мы говорим вам об этом с 2014 года в статьях:

                             • 3 способа быстро адаптировать сайт под мобильные устройства.
                             • Мобильная адаптация сайта — ответы на вопросы.
                             • Как продвигаться в нишах, где преобладает мобильный трафик.

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

                             • Контактам. Номера телефонов должны быть кликабельными – при нажатии должна открываться панель ввода номера с уже набранным номером и кнопкой вызова.
                             • Меню. Опишите, как оно должно открываться: выезжать сбоку, сверху и т. д.
                             • Не должно быть горизонтальной прокрутки на страницах сайта (это само собой разумеется, но я всё же решила напомнить).

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

                             Основные требования:

                             • меню-бургер – раскрывается вниз при касании значка меню:
                               
                               
                             • сайдбар опускаем под основной контент:
                             • все элементы в футере находятся друг под другом:

                             Главная страница

                             

                             Все элементы выводятся друг под другом:

                             • краткое описание;
                             • форма поиска;
                             • подробное описание;
                             • списки магазинов, разделённые по категориям.

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

                             Страница категории

                             

                             Страница магазина

                             

                             Все элементы выводим друг под другом, в том числе колонки в таблице.

                             Информационная страница

                             

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

                             Где найти образцы хороших сайтов

                             При составлении технического задания вы можете брать идеи у:

                             • Похожих сайтов в ТОПе по интересующим вас запросам.
                             • Успешных сайтов из разных тематик и регионов — их можно найти в онлайн-рейтингах вроде AWWWards или Similarweb, а также в MasterfulMobileWeb (от Google). Рекомендуем смотреть именно высококонкурентные рынки, ведь у них борьба за ТОП сложнее, а значит и приёмы выбираются самые эффективные.

                             Заключение и шаблон

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

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

                             Поздравляем, начало успешного проекта положено! Грамотно составленное ТЗ действительно может дать хороший буст для нового веб-сайта или редизайна старого, но если хотите достичь ТОПовых позиций, то работать придётся комплексно. Возможно, в этом вам помогут статьи:

                             • Жизненный цикл проекта в SEO.
                             • SEO продвижение нового сайта в Яндекс и Google.
                             • SEO чек-лист: что проверять перед запуском сайта?

                             Если у Вас возникли проблемы с продвижением нового сайта, обращайтесь к нам!

                             Подписаться на рассылку

                             • Обновление PageSpeed Insights: что изменилось, на какие метрики обращать внимание? 1. Обновленный PageSpeed Insights Оценка скорости загрузки Данные наблюдений Имитация загрузки страницы Оптимизация Диагностика и успешные аудиты 2. Итоги Ни для кого не секрет, что.
                             • Безопасный переезд сайта с http на https в Яндексе и Google В последние время всё больше владельцев проектов задумываются о переводе сайтов на защищённый протокол. Не перестают напоминать об этом и представители поисковых систем. Яндекс пока.
                             • Гайд по robots.txt: создаём, настраиваем, проверяем В этой статье мы рассмотрим: Что такое robots.txt? Все директивы файла: Disallow и Allow Sitemap Host Crawl-delay Clean-param Использование спецсимволов Как проверить корректную работу файла.
                             • Все на капремонт, или Не пора ли вам делать редизайн сайта? Время от времени редизайн нужен сайтам практически любой тематики. Прочитав эту статью, вы поймете, в чем польза редизайна, пора ли обновлять ваш сайт и на.
                             • Страницы низкого качества или как понять, что твой сайт «не очень» Не так страшен чёрт, как его малюют – русская пословица Иногда довольно сложно понять, что от тебя хотят поисковые системы, что именно они понимают под.

                             

                             Пришла с небольшими знаниями в настройке, установке и принципах работы нескольких CMS. С тех пор «обросла» знаниями и опытом в разработке сайтов на следующих CMS, PHP и JS/CSS-фреймворках: WordPress, Joomla, Bitrix, MODx, Drupal, Codeigniter, Laravel, Bootstrap.

                             Разрабатывает, дорабатывает, перерабатывает и адаптирует сайты.

                             Девиз: если очень захотеть, можно в космос полететь

                             Похожие публикации:

                             1. Rig v2 как ставить аккумуляторы
                             2. Где найти кэп в облаке
                             3. Как восстановить аккаунт коинлист
                             4. Что такое кб в апекс