Тз на строительно монтажные работы образец

Техническое задание на конструкторскую документацию

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

Структура разделов ТЗ

Любое техническое задание должно содержать разделы, отражающие сведения:

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

Как составить хорошее ТЗ

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

Техническое задание на проектирование — начало сметных работ

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

Основные ГОСТы на ТЗ

Перечисленные документы являются общими для всех предметных областей. Однако существуют и другие российские ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание» для своих узко-специфических отраслей.

Источник

Техническое задание и техническое решение + шаблон

Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.

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

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

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

ТЗ и ГОСТ

Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации. А пытаются это применять для проектов где работает 1-2-3 человека Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.

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

ТЗ и Бритва Оккама

Бритва Оккама в данном случае говорит о том что наиболее простое решение — наиболее верное. Если нет веских причин для усложнения.

Какое самую простую форму ТЗ можно придумать? Ответ — простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.

Иногда она может расширяться некоторыми полезными артефактами (разделами):

• Цели — описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
• Снимки, фото, звуки, примеры — бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.

Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект — тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе — у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать — не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.

Техническое решение или ТР

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

Техническое решение — пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.

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

Пример для понимания. Заказчик дает ТЗ «Я хочу есть», а Исполнитель предлагает ТР «На вот яблоко». Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения

Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.

Почему ТР важно?

ТР важно по ряду причин:

• Только Разработчик реально знает как решать задачу (по этой причине Заказчик обычно к нему и обращается), а значит только он может описать детали того как можно получить ожидаемый результат
• У любой задачи может быть 3-4 варианта решения (а часто больше), и тут Заказчик должен убедиться что Разработчик может предложить нечто адекватное
• Задача одна, но несколько вариантов решений часто означает разные цены. причем вилка цен может быть условно от 100 000 руб до 10 000 000 руб. ТР позволяет составить список условий и сузить разброс цен — уложиться в нужный бюджет и срок.

По ходу составления списка решений, предложений и условий — Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу

Именно составление ТР — позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте — зачастую приводит к недопониманию и конфликту.

Когда можно без ТР?

Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:

1. Если между Заказчиком и Разработчиком есть полное взаимопонимание и доверие, большой успешный опыт совместной работы. Когда Заказчик целиком доверяет Разработчику и полагается на его знания.
2. Если мы работаем по Agile и у нас мелкие простые задачи

Исключение из п.2 — даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) — поняли друг друга.

Шаблон

Итого

Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.

Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.

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

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

Источник