Чем тз отличается от ту

Содержание

Техническое задание — это что такое? Понятие и содержание. Как составить ТЗ

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

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

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

Кроме прочего, в состав этого документа может входить список требований, касающихся тестирования (применимо к разработке программного обеспечения).

Его применяют в своей работе строители, мастера, выполняющие ремонтные работы, программисты, дизайнеры и многие другие специалисты.

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

Особенности техзадания

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

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

Назначение технического задания

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

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

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

Состав ТЗ: требования к функциональности

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

Образцом требований различных видов становится большинство ГОСТов. Они регулируют процесс составления ТЗ для строительства крупных объектов и других ответственных работ. В них обычно перечисляют такие требования:

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

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

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

Характеристика требований

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

Понятность.
Конкретность.
Тестируемость.

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

Техническое задание – это не технический проект

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

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

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

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

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

Чтобы облегчить составление и выполнение технического задания, его разрабатывают по определенной системе. Как правило, вначале, в вводной части, излагают цель и назначение проекта. Далее следует перечисление разделов, требований и их расшифровка. Чтобы понять, как выглядит ТЗ для автоматизированной системы, можно рассмотреть структуру, рекомендуемую ГОСТом 34.602-89:

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

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

Зачем составлять ТЗ для ремонта комнаты

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

По этой причине техническое задание на ремонт становится одним из важнейших этапов, так как позволяет:

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

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

Какие пункты включает техзадание для ремонта комнаты

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

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

2. Характеристика пола: объем работ, которые нужно выполнить на этом участке. Здесь можно подробно указать, что именно необходимо выполнить мастерам:

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

3. Работы с потолком:

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

4. Что требуется проделать со стенами:

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

5. Параметры окна:

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

6. Характеристики двери:

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

7. Работы с электрическими сетями:

8. Мероприятия по монтажу отопительных систем и кондиционеров:

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

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

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

Главной задачей этого мероприятия становится получение информации о состоянии помещения и более точного описания предстоящих ремонтных работ.

При обследовании комнаты обращают внимание на главные параметры и выполняют следующие действия:

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

Чтобы избежать неопределенности и предусмотреть все возможные нюансы, при обследовании пол разбирают в нескольких местах и делают выводы из увиденного.

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

Эта информация позволяет оценить уровень трудовых и финансовых затрат. Техзадание должно содержать чертежы будущих работ.

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

fb.ru

разработка и создание. Технические задания на техническое обслуживание :: BusinessMan.ru

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

Для чего это?

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

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

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

Более сложные случаи

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

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

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

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

Что представляет собой ТЗ?

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

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

Особенности использования

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

Многие специалисты по какой-то причине, разрабатывая техническое задание на проектирование объекта или проведение определенных работ, основываются исключительно на требованиях ГОСТа, но в действительности это в корне неверный подход.

Главная задача

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

Как определиться с требованиями?

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

функциональность;
безопасность и права доступа;
квалификация персонала.

Чему уделить внимание?

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

Если требования формируются неправильно, то, вне зависимости от того, насколько красивый вы на них наденете камуфляж, в конечном итоге так и не получится сделать действительно успешный проект. Конечно, по ГОСТу все требования полностью соблюдены, техническое задание (образец ниже) разработано, подписано и утверждено, а специалист получил за него оплату, но дальше нужно понять, что делать с этим документом. Если речь идет о проекте на государственный заказ, то зачастую никаких проблем не возникает, потому что там гораздо меньшие ограничения в бюджете, и в процессе реализации уже будут определены основные тонкости. Но если говорить о коммерческих организациях, где более подробно считают деньги и требуют другого результата, то здесь уже все более сложно.

Полезные и эффективные разработки

Если виды требований могут быть самыми разными, и здесь все в основном зависит исключительно от целей проекта, то свойств всего три:

понятность;
конкретность;
тестируемость.

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

Дополнительные нюансы

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

На каком языке (с точки зрения сложности восприятия) оно должно писаться?

Нужно ли описывать в нем какие-либо специфические особенности различных функций, алгоритмы, типы нужной информации и прочие технические тонкости?
Что представляет собой техническое проектирование, которое, к слову, отмечено в существующих ГОСТах, и каким образом оно относится к составляемому ТЗ?

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

Задание и проект

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

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

Отличия проекта от задания

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

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

Что на практике?

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

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

businessman.ru

Обсуждение:Техническое задание | Virtual Laboratory Wiki

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

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

При чем здесь техника, у нас ведь не технический проект! А какой? Ну, футурологический, социальный, демографический, экономический. Существовала масса проектов, более близких по своему профилю к нашему. Казалось бы, оттуда и имеет смысл брать методологию и подходы. Техника нам ближе не по содержанию проекта, а потому, что:

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

2) В технике наиболее четко соблюдается связь задания и результата. Если во всяких других проектах результат часто оценивается качественно и возможны всякие колебания в оценках от «отлично» до «скверно», то в технике оценки однозначны: выполняются или не выполняются ТТ. Построенный по проекту самолет полетит или не полетит, достигнет заданной скорости или не достигнет, двигатель проработает заданный срок без единого отказа, или нет.

А нельзя ли без ТТ? Нельзя, потому что неизвестно, что все-таки нужно. Интуитивное впечатление, что все и так понятно, может очень сильно подвести. Получится как с девочкой Женей из известной сказки Катаева. Она захотела на Северный полюс, что и было исполнено. Но ТТ сформулированы не были, и поэтому не была предусмотрена защита ни от холода, ни от медведей.

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

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

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

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

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

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

Американский автор С. Доул в книге «Планета для людей» рассматривает Землю как прототип для поиска подходящей планеты в бескрайнем космосе. Он составляет ТЗ на искомую планету, определяя, какие на ней должны быть условия. Понятно, что полностью похожей на Землю планеты не найдется во всей Вселенной. Но и Земля ведь тоже не идеал.

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

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

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

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

ТТ нам нужно вырабатывать двух видов. Одни на приспособления для жизни людей на планете, на системы жизнеобеспечения (СЖО) разных видов, например, как это делают для жизни в Арктике или Антарктике. Другие – на приспособление планеты для жизни на ней людей, на СЖО в масштабе планеты.

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

Значит, задача ставится вовсе по-другому, чем у Доула. Как создать СЖО на пригодной для этого, а вовсе не для жизни, планете? Не подобрать планету, годную для жизни на ней, а подобрать заготовку планеты. Это значит, что не нужно нам слоняться по бескрайнему космическому пространству, а подобрать сравнительно подходящий «участок» и на нем строить. И участок подбираем, как мы уже говорили, в пределах Солнечной системы.

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

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

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

ТТ к планете Править

. Вот сводка признаков планеты, пригодной для жизни [10, с.112].

Масса должна быть больше 0,4 массы Земли, чтобы могла образоваться и сохраниться годная для дыхания атмосфера, но меньше 2,35 массы Земли. Это условие на Венере соблюдено идеально.

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

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

Орбитальные параметры близки к земным, а характеристики главного тела (Солнца), естественно, те же самые. Все. Других условий Доул не выдвигает.

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

Можно привести такой пример. Группа туристов пришла зимой на полянку в лес. Полянка мало приспособлена для жизни. Утоптали снег – стало можно ходить уже без лыж. Расчистили место под палатку и костер, разожгли костер – уже уютнее. Настелили лапника, поставили шатровую палатку, сварили обед. В палатке подвесили портативную печку, расселись на спальниках, поели. Уже жить можно. Но это не значит, что можно жить «на полянке». На ней по-прежнему мороз и снег. Жить можно пока лишь в палатке. И то, пока есть дрова и пища. Дальше можно попытаться перекрыть полянку куполом и развести посредине огромный костер. И так далее.

Вариантов может быть неисчерпаемое число. И окончательный их отбор произведет только жизнь и время. Поэтому здесь просто изложены решения, которые представляются возможными в наших современных представлениях. Без всяких претензий на пророчество, на предсказание, на директивность. «Мне кажется, что это будет вот так». А может быть, оно будет совсем иначе. Или вообще не будет. Потомки увидят.

Чтобы не делать бесконечных оговорок «если», «в том случае» и тому подобных, представим себе, что идея преобразования Венеры руководящими умами овладела, что решение принято, деньги нашлись и работы начаты…

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

Земной этап. Естественно, все начнется на Земле и задолго до того, как не только первый исследователь «ступит на поверхность Венеры», но даже и до того, как следующая, после долгого перерыва, космическая станция полетит к планете. До того, как что-либо из огромной инфраструктуры будет создано на планете, все это должно быть промоделировано, испробовано, доведено до совершенства на Земле. Собственно, так выполнялись космические проекты и до сих пор. В этой скрупулезной предварительной отработке и есть главный секрет непостижимых успехов в космосе. А в ее отсутствии или недостаточности – объяснение большинства космических неудач.

Орбитальный этап. Первоначально работа на планете будет происходить с околопланетной орбиты. На ней станет летать сначала одна, потом несколько орбитальных станций, подобных «Миру» или МКС, только гораздо более продвинутых и мощных. С них, так же как на Земле, будут изучать планету. Но с той разницей, что планета пока необитаемая. А база исследователей будет от них в десятках миллионов километров. Отсюда основное отличие: станции с самого начала будут переходить на все большую автономность, независимость. Они сами должны стать опорой для всей земной инфраструктуры. Но основная задача будет состоять не в изучении, а в подготовке освоения. В опробовании разработанных на земле методах. Придется опробовать разнообразные системы аэростатов и все более длительные периоды жизни на них в атмосфере.

Атмосферный этап. Базы на плавучих островах в атмосфере. Перенос на планету разработанных на Земле технологий, подготовка к преобразованию атмосферы с помощью микроорганизмов. Это вовсе не служебный, промежуточный или вспомогательный этап, как может показаться. Хотя бы потому, что он может растянуться и на столетие. Можно провести параллель с освоением Арктики или Антарктики. Но более выпуклую аналогию можно привести с освоением Северной Америки или Канады. «Освоением» это может назвать историк в ретроспективе, а для поселенцев это была их жизнь, для многих – вся их жизнь и жизнь их детей, внуков и правнуков. Так и в атмосфере Венеры люди будут жить и работать, одновременно осваивая планету. Его завершением будет развитая инфраструктура атмосферных станций и отработанные технологии преобразования атмосферы.

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

Эти этапы (блоки) представляют предварительную стадию освоения планеты. На протяжении их должны быть исследовваны возможности глобального преобразоввания атмосферы и отработаны методы

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

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

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

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

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

ru.vlab.wikia.com

Сертификация определенных типов продукции

Производство продукции на территории нашей страны сегодня регламентируется двумя типами стандартов: ГОСТ и ТУ. Цели и задачи обоих этих стандартов едины – создание рамок, которых производитель должен придерживаться при производстве продукции. Но вот для достижения этих задач каждый стандарт использует свой набор рычагов и способов воздействия.

Рассмотрим чем отличается ГОСТ от ТУ, и какова специфика каждого стандарта.

ГОСТ (Государственный стандарт)

Система ГОСтов была разработана и запущена ещё в СССР. ГОСТ – это система стандартов, регламентирующих производство товаров. Предполагалось, что абсолютно все товары и услуги должны соответствовать ГОСТам, а каждый тип товара будет регламентироваться отдельным стандартом. Требования государственных стандартов были обязательны для соблюдения. После 1996 года государственные стандарты обретают форму обязательных для исполнения только после регистрации в Министерстве юстиции. В ином случае — производить товар по ГОСТу или в соответствии с другими нормативными документами, решает только сам производитель.

ТУ (Технические условия)

В период перехода экономики к рыночным отношениям стало очевидно – ГОСТы уже не успевают за динамичным развитием. Тогда и были введены ТУ, целью которых стало регламентировать производство товаров, которым не выпало «счастье» попасть под действе ГОСТа. Более того, разработкой и контролем соблюдения ТУ должен заниматься сам производитель. Собственно, это и есть основной момент, в части того, чем отличается ГОСТ от ТУ. По сути, технические условия являются собственностью того, на кого они зарегистрированы.

Найди четыре отличия

1. Разработка и утверждение
Государственные стандарты, как можно догадаться из названия, разрабатываются исключительно государством. Регистрируются ГОСТы в Минюсте. Пакет документов ТУ готовится по заказу производителя в коммерческой структуре, либо самим производителем, если есть такая возможность. Обязательной регистрации технических условий не предусмотрено, но при желании можно это сделать. Правда, нести документы нужно не в Минюст, а в Госстандарт. И, по своей сути, это будет лишь акт закрепления права собственности на конкретное ТУ.

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

При этом ТУ признается нижестоящим стандартом, так как его положения не могут противоречить аналогичным положениям ГОСТ.

3. Гарантии соблюдения норм регламента
Чем отличается ГОСТ от ТУ? Самым популярным ответом на этот вопрос будет лаконичное: «жесткостью». Именно жёсткостью норм, а не качеством товара произведенного по тем или иным стандартам. Причины вполне понятны – ГОСТы разрабатываются государством, для которого не является приоритетом рентабельность производства и упрощение технологии. Главная цель ГОСТа – качество и безопасность. Производитель же при разработке ТУ руководствуется экономической целесообразностью и выгодой. При этом в плане качества он не склонен закладывать излишний запас прочности – это чревато увеличением себестоимости.

И, самое главное, большинство ГОСТов являются обязательными нормами, и товары, которые подпадают под их действие, должны быть произведены только по ГОСТу. Применение ТУ носит упрощенный характер.

4. Объект регулирования и подробность регламента
Как правило, ГОСТ регламентирует процесс производства, хранения, маркировки и транспортировки определенного товара. Государственный стандарт – это подробное описание пути продукта от сырья до потребителя. Технические условия не так подробно регламентируют процесс маркировки и реализации товара. Зачастую в положениях ТУ заложены маркетинговые хитрости, основная задача которых — помочь продать товар.

Это, пожалуй, полный список того, чем отличается ГОСТ от ТУ. Может возникнуть мнение, что государственный стандарт – это определенно лучший показатель качества, нежели ТУ, но не все так однозначно. Зачастую, производитель поставлен рынком в такие рамки, в которых нужно выпускать товар, превосходящий требования ГОСТов. Как правило, это отрасли, подверженные жесткой конкуренции. И наоборот, туманность и непродуманность ГОСТов оставляет огромный простор для маневра для недобросовестного производителя.

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

ofsert.ru

Так что же такое «Техническое Задание»? / Habr

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

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

Переводим на понятный язык

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

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

habr.com

Хитрости госзаказчика: техническое задание | zakupkihelp.ru

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

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

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

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

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

Как поступить если Вы столкнулись с данной проблемой?

Если при рассмотрении документации и изучении технического задания Вы обнаружили какие-либо несоответствия, то необходимо отправить Заказчику запрос на разъяснение положений документации. Шаблон такого запроса можно скачать в разделе сайта «Формы и шаблоны», но зачастую данная форма уже имеется в составе документации.

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

Еще запомните один очень важный момент — никогда не звоните заказчику по телефону, отправляйте официальный письменный запрос, на который заказчик ОБЯЗАН ответить в установленный срок.

Если представленные заказчиком ответы на Ваш запрос не прояснили ситуацию или заказчик отказывается дать развернутый ответ, то можно обратиться с жалобой в территориальное Управление Федеральной Антимонопольной Службы РФ (УФАС РФ) на соответствующие нарушения требований 94-ФЗ. В качестве подтверждения своих доводов можно приложить официальные ответы заказчика.

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

На этом все. Желаю Вам удачи и новых побед!

zakupkihelp.ru

Что такое ТЗ

Категория: Интернет-проекты

Опубликовано: 19 Июль 2013

Позвольте начать с анекдота про армию. Командир отдает приказ роте солдат Стройбат: «Копаем от забора, до заката!» Подобная ситуация может возникнуть у разработчиков. Каждый в команде может спросить: «А когда конец»? И действительно, в этой области работа может продолжаться длительное время. В разработке программного обеспечения и разработке дизайна сайта необходимо знать уровень, который удовлетворяет заказчика.

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

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

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

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

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

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

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

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

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

Чем тз отличается от ту – ?