Составление технического задания на выполнение работ. Техническое задание согласно госту
Общие положения. Это нужно для того, чтобы исполнитель понимал, что он делает. В общих положениях могут быть прописаны характеристики оборудования, на котором должна выполняться работа, разъяснения спорных моментов, глоссарий и т.п.
Второй пункт - это четко сформулированные цели, которых нужно достичь в процессе работы. Написание этого раздела поможет заказчику понять, чего он действительно хочет, а исполнителю - впоследствии предложить решения описанных проблем.
Третий пункт - это требования, которые заказчик предъявляет к выполнению задания. Без этого пункта не обходится ни одно техническое задание. В нем должно быть четко прописано, что именно, и в какой срок хочет получить заказчик. Не нужно думать, что опуская сроки выполнения задания вы даете "свободу" исполнителю. Работать в условиях неизвестности очень сложно.
Техническое задание не должно быть слишком расплывчатым - ведь исполнитель может понять его неверно или не так, как требуется заказчику. В то же время, техническое задание не должно быть слишком подробным - в любом проекте должно быть место творчеству. Кроме того, если вы досконально знаете, как должен выглядеть ваш сайт, журнал или прибор - что мешает сделать вам его самому?
Видео по теме
Источники:
- как написать тз
Вы хотите создать собственный интернет-магазин, и прежде, чем обратиться в специализированную компанию, решили продумать техническое задание. Это вполне возможно сделать своими силами. Вот несколько советов на тему, из каких компонентов состоит техзадание.
Вам понадобится
- Вам будет нужно продумать тематику сайта, сервисы, которые он будет предоставлять и его функциональность.
Инструкция
Цели . Это очень важный раздел, посвятите его обдумыванию для того, чтобы четко сформулировать цели вашего ресурса. Например, если вы задумали создать интернет-магазин, объясните будущему исполнителю, с помощью чего вы собираетесь прибыль. Это поможет исполнителю предложить вам решения, которые смогут по максимуму претворить в жизнь поставленные вами цели.
Целевая аудитория. Опишите в этом разделе аудиторию, которую вы рассчитываете привлечь. Это может не только помочь с выбором сервисов, но и в разработке дизайна.
Функциональные требования. Требования принципиально можно разделить на функциональные и не функциональные/специальные. Функциональные требования лучше описать в виде примеров их использования.
Стандарты. Опишите стандарты возможностей использования, например стандарты серии WAI, удобства использования, например, ISO/TR 16982:2002, а также другие стандарты общего назначения.
Системные требования. Перечислите системные требования, какие операционные системы должны поддерживаться, требования к памяти. Также сюда могут войти требования по отказоустойчивости, например, возможность восстановления системы после сбоя.
Производительность. В данном разделе опишите, какое количество пользователей может одновременно работать на сайте, или в определенный отрезок времени. Также, стоит отметить, каким именно инструментом будет производиться определение производительности.
Безопасность. В данном разделе опишите необходимые методы шифрования данных, способы их передачи и хранения.
Пользовательский интерфейс. Опишите способ отображения элементов пользовательского интерфейса.
Видео по теме
Обратите внимание
Техническое задание обязательно должно быть детализированным. Между представлением (идеей) проекта и техзаданием очень большая разница.
Перед началом работы с исполнителем оговорите терминологию – иначе, вы можете одним и тем же словом называть разные вещи. Подобная несогласованность может привести к путанице и повредить работе над проектом.
Источники:
- E2E4, сайт
Ни одна работа или проект, выполняемые по заказу, не могут производиться без технического задания на данные конкретные разработки. В этом документе заказчик ставит перед исполнителем задачи по созданию или разработке продукта и указывает технические характеристики, которым должен соответствовать продукт, порядок и сроки выполнения данной работы. Любое техническое задание, независимо от предмета разработки, должно иметь общие компоненты или подразделы.
Инструкция
В структуру обязательно включите раздел «Общие положения». В них оговорите используемые в техническом задании и дайте их смысловую расшифровку – приведите глоссарий. Это позволит исполнителю и заказчику разговаривать на одном и исключит двоякое толкование основных понятий и определений.
Включите в техническое задание раздел «Цели », в котором четко сформулируйте цели и задачи проекта. Грамотно изложенные цели проекта помогут исполнителю понять, что именно требуется Заказчику и выбрать те пути и методы решения поставленной задачи, которые приведут к поиску самого оптимального решения.
Изложите функциональные к разработке. Здесь же можно отразить и специальные требования. Функциональные требования целесообразно изложить в виде вариантов использования или применения результатов данного проекта. В специальных требованиях укажите стандарты, которым должна соответствовать разработка, требования по отказоустойчивости, производительности или безопасности. Если речь идет о программном продукте, укажите системные требования, и требования к пользовательскому интерфейсу.
В разделе «Допущения и ограничения», который, обычно, заполняется исполнителем, оговариваются конечные параметры и характеристики, что позволяет не увеличивать стоимость работ по проектированию до бесконечности и довести его до логического завершения. В этом разделе перечислите функциональные возможности и задачи, которые выходят за рамки проекта, технические ограничения, зависимости от непредсказуемых обстоятельств и внешних условий, которые могут изменить принятые обязательства.
В разделе «Риски» отразите факторы, которые могут повлиять на сроки исполнения работы или ее стоимость.
Видео по теме
Если в рабочей деятельности вам часто приходится иметь дело со сторонними специалистами или поручать выполнение заданий другим сотрудникам, то для успеха дела вам необходимо научиться грамотно составлять техническое задание. Конечно, в каждой сфере могут быть свои особенности, но существуют общие рекомендации для составления технического задания.
Инструкция
Написание ТЗ – начало любого , ведь результат напрямую зависит от поставленных целей. Техническое может быть как основным документом, регламентирующим отношения между заказчиком и подрядчиком, так и приложением к . В любом случае, максимально подробно опишите, что вы хотите получить в результате выполнения работы. Это может быть цель, продукция, услуга, задача. Напишите, какие задачи решает или выполняет заказываемый продукт.
Чтобы представление о достигаемой цели заказчика совпадало с видением исполнителя, необходимо детально, буквально по пунктам, описать ход выполнения работ. Указывайте все, что считаете важным и необходимым для понимания процесса. Избегайте двусмысленностей и неоднозначных трактовок. Для обеих сторон перечень и ход работ должен быть ясным и понятным.
Пропишите исходные материалы, которые потребуются для выполнения работы, их формат, а также каким образом и в какие сроки эти «исходники» будут переданы исполнителю. Все эти данные необходимо прописать до подписания , чтобы проект «не буксовал» из-за нехватки нужных материалов со стороны заказчика.
Обозначьте четкие сроки выполнения заданий. Это необходимо для того, чтобы обе стороны могли планировать свою деятельность, согласно своим возможностям и ожиданиям второй стороны. При написании технического задания держите в уме некий запас времени, ведь в процессе выполнения сроки могут сдвинуться из-за дополнительных согласований или обсуждений.
Важно в процессе составления ТЗ указать пожелания заказчика, особо понравившиеся примеры подобных работ, дополнительные требования, маркетинговую информацию или данные проведенного исследования. Исполнитель или разработчик будет четче понимать поставленные перед ним задачи, что приведет обе стороны к совместному успеху.
Видео по теме
Обратите внимание
Помните, при выполнении всех требований и задач, указанных в ТЗ, исполнитель вправе считать проект законченным. Во избежание споров и разногласий по срокам, видам и качеству работ или услуг, как можно подробнее излагайте информацию.
Полезный совет
В творческих проектах целесообразно давать исполнителю простор для фантазии и креатива. Для продуктивной работы избегайте жестких рамок и приветствуйте появление новых идей.
Источники:
- написание тз в 2018
Архитектурное проектирование – важный этап любого строительства, в том числе и ремонта жилой квартиры. Если вы хотите, чтобы работа архитектора максимально соответствовала ожидаемым и желаемым результатам, уделите время грамотному и вдумчивому составлению проектного задания, которое должно включать полный список требований к архитектору и его работе.
Инструкция
Перепланировка может включать в себя снос некоторых стен, не являющихся несущими, изменение размеров и формы жилых комнат, а также изменение местоположения дверей, замена электропроводки, газового оборудования, и других подобных параметров. Если же вы хотите поменять функциональное помещений, поменяв местами , вам придется легализовать не перепланировку, а реконструкцию.
Когда разрешение на перепланировку будет получено, договор с надежным и сертифицированным архитектором. В некоторых случаях архитектурная фирма за дополнительную плату может провести все необходимые действия по легализации и утверждению перепланировки в квартире самостоятельно, сэкономив ваше время.
В любом случае, согласовать проект необходимо своевременно – в противном случае в будущем, при различных операциях с недвижимостью, вы столкнетесь с проблемой, вызванной незаконной перепланировкой, не согласованной с БТИ. Кроме того, при незаконной перепланировке вы рискуете нарушить определенные строительные нормы – в том числе, нормы пожарной безопасности.
В задание для будущего проекта должны быть включены все нюансы, которые вы хотите видеть в ремонте, а также важные параметры, касающиеся вашего помещения – жилая площадь, электроснабжение и размещение розеток и выключателей, система освещения, которую вы хотите получить, наличие телевидения и радио, стилизация интерьера, его концепция и желаемые элементы, цветовая гамма оформления квартиры, предпочтения по мебели и аксессуарам, и так далее. Чем больше пунктов будет указано в задании, и чем подробнее оно будет составлено, тем более полученный интерьер будет соответствовать вашим ожиданиям.
Написание и оформление технического задания своими силами может стать необходимостью в том случае, если требуется создать некий продукт, а бюджет не очень большой. Еще одной причиной написания технического задания (ТЗ) может стать желание предварительно изучить заказ, который вы собираетесь сделать компании-разработчику. Например, требуется создать сайт, и вы хотите для себя прояснить все пункты, на основе которых его будет конструировать фирма-исполнитель.
Инструкция
Сначала составьте полный список составляющих технического задания, и начинайте его заполнять – так будет проще свести воедино все важные пункты и не пропустить ни одного.
Начинается оформление ТЗ с наименования Заказчика. Внесите в этот пункт полную информацию о фирме.
Затем внесите полные данные о компании-Исполнителе.
Следующий пункт очень важен: укажите четкие сроки выполнения заказа - дату начала и дату его завершения.
Затем укажите, каков бюджет проекта, его смета.
После этого распишите техническую сторону сайта. Если у вас есть познания в программировании это сделать будет достаточно просто, если нет – распишите основные параметры, а об остальных посоветуйтесь со специалистами компании – Исполнителя. Затронем некоторые из них.
Цели сайта. От этого будет зависеть дальнейшая разработка структуры, сервисы и услуги сайта.
На какую аудиторию он рассчитан. В этом пункте опишите, какого рода посетителей вы хотите привлечь на свой ресурс – возрастную категорию, социальный статус, финансовый порог. Это повлияет на дизайн ресурса и его сервисы. Например, если вы открываете интернет-магазин, это поможет определиться с порядком расчетов за приобретенный товар.
Функциональные и специальные требования. Функциональные удобнее привести в виде примеров того, как их будут использовать, а специальные оформить списком – это могут быть возможности подписки, специальных рассылок и др.
Стандарты. Этот пункт лучше обсудить с исполнителем или продвинутым другом-программистом.
Системные требования. Сюда войдут сведения о том, к каким операционным системам ваш сайт должен быть дружественным, насколько велики будут ресурсы его памяти, учесть возможность быстрого восстановления после сбоев.
Производительность. Этот пункт о том, сколько посетителей одновременно сможет принять ваш сайт и каким образом их будут «пересчитывать».
Безопасность. Очень важный раздел. Опишите, как потребуется шифровать данные, как они будут передаваться и храниться.
Полезный совет
Техническое задание обязательно должно расписано очень подробно. Иначе это будет не ТЗ, а просто описание общей идеи.
Источники:
- E2E4, сайт
Техническое задание - ключевой документ в процессе разработки программного обеспечения. Корректное ТЗ позволяет избежать множества ошибок и лишней работы. Состав его может меняться в зависимости от задачи, однако можно выделить универсальные компоненты.
Инструкция
Общие положенияВводный раздел, в котором определите основные положения, опишите используемую терминологию, он необходим для того, чтобы заказчик и не испытывали трудностей в понимании технического задания. Укажите информацию о заказчике и исполнителе, опишите документы, на основании которых принято решение о разработке программы.
ЦелиВ этом разделе укажите основные задачи, на выполнение которых направлен проект. Важно четко определить цели, которые реализует разрабатываемый продукт. Опишите предполагаемую аудиторию, которая будет работать с программой.
Функциональные требованияОсновной компонент технического задания. В этом разделе опишите функционал разрабатываемого программного обеспечения, варианты его использования, пользовательский интерфейс. Опишите структуру программы в функциональных требованиях.
Специальные требованияПеречислите все специальные требования и стандарты. Укажите технические требования: версию операционной системы, объем памяти и т.д. Требования по производительности, требования к защите информации от несанкционированного доступа, отказоустойчивости, надежности, эргономике опишите в этом разделе.
Видео по теме
Полезный совет
Избегайте избыточной и недостаточной детализации технического задания. Слишком подробные требования могут привести к отсутствию гибкости системы - внести какие-либо доработки будет очень сложно. Недостаточная детализация технического задания приведет к ряду ошибок, а так же к большому количеству лишней работы.
Будьте предельно внимательны при составлении технического задания - в дальнейшем это поможет решить спорные моменты с заказчиком.
Техническое задание, или ТЗ, – это документ, подробно описывающий все пожелания и требования заказчика к проекту. Составление его позволяет избежать недомолвок и разногласий в процессе взаимодействия клиента и исполнителя. Кроме того, нередко грамотно составленное ТЗ сокращает сроки, необходимые для выполнения задачи.
Перед началом любого проектирования между Заказчиком проекта и его Разработчиком должны быть определены назначение и область применения проектируемого устройства, а также оговорены в полном объеме все его технические (тактико-технические) характеристики. С этой целью разрабатывается специальный документ – Техническое задание на проектирование этого устройства или системы.
В дальнейшем для Разработчика Техническое задание является первичным, основополагающим документом, которым руководствуются на всех стадиях разработки проекта.
Разработка Технического задания является очень важным и ответственным процессом. Ошибки, допущенные на этом этапе разработки, могут привести к очень тяжелым последствиям.
Как правило, разработка Технического задания осуществляется совместно представителями Заказчика и Проектировщика. Техническое задание требует от разработчиков большой эрудиции и опыта. Поэтому техническое задание составляется ведущими, наиболее квалифицированными специалистами, имеющими значительный опыт в этой области.
Техническое задание определяет основные направления разработки – конструкцию и принцип действия будущего изделия (устройства, системы).
Техническое задание является начальным этапом работ и составляется на все разработки и виды работ, необходимые для создания нового изделия. Техническое задание может также включать в себя, как один из разделов, проведение
Научно-исследовательских работ,
Опытно-конструкторских работ,
Разработку средств автоматизации, отдельных узлов и систем, технологии, измерительных средств, средств контроля, техники безопасности и др.
Обязанность Заказчика – предоставить разработчику достоверные исходные данные для разработки изделия. Заказчик отвечает за предъявленные требования к новому изделию и исходные данные и несет полную ответственность за правильность предоставленной информации.
Техническое задание должно содержать три основных раздела:
1. технические и экономические требования к продукции определяющие ее потребительские свойства и эффективность применения,
2. перечень документов, требующих совместного рассмотрения Заказчиком и Разработчиком,
3. порядок сдачи и приемки результатов разработки.
При необходимости техническое задание может содержать также требования к подготовке и освоению производства.
Конкретное содержание технического задания определяют Заказчик и Разработчик, а при инициативной разработке - Разработчик.
При наличии у Заказчика индивидуальных требований к разрабатываемой продукции, которые отличаются от требований стандартов, но не снижают эффективность применения продукции в оговоренных условиях, ему следует получить заключение Госстандарта РФ о возможности разработки и производства данной продукции.
Не допускается включать в техническое задание требования, которые противоречат требованиям стандартов и нормативных документов органов, осуществляющих надзор за безопасностью, охраной здоровья и природы.
Техническое задание должно содержать максимум информации, облегчающей работу конструктора и сокращающей сроки разработки.
Качество Технического задания обеспечивается объемом и полнотой сбора материалов, необходимых для разработки. При разработке используются следующие материалы:
Научно-техническая информация,
Патентная информация,
Характеристика рынка сбыта,
Характеристика производства, на котором изделие будет изготавливаться (технологическая оснащенность, квалификация персонала, уровень организации труда и др.).
В Техническом задании, как правило, устанавливаются следующие показатели разрабатываемого изделия:
Прогнозируемые показатели технического уровня и качества,
Основное назначение,
Характеристика рынка сбыта,
Технические и тактико-технические характеристики,
Уровень стандартизации и унификации,
Технико-экономические показатели
Патентно-правовые показатели,
Специальные требования к изделию и др.
Техническое задание разрабатывают и утверждают в порядке, установленном Заказчиком и Разработчиком.
Общий порядок разработки и утверждения технического задания устанавливает Государственный стандарт России ГОСТ 15.001-88
В техническом задании оговариваются этапы разработки и сроки выполнения каждого этапа и разработки в целом.
Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам согласно Государственного стандарта ГОСТ 2.105-95.
Таблица 1
Основные разделы технического задания |
Примерный перечень вопросов, рассматриваемых в разделе |
|
Наименование и область применения (использования). |
Наименование и условное обозначение разрабатываемой продукции. Краткая характеристика области ее применения. Общая характеристика объекта, в котором используют продукцию. |
|
Основание для разработки |
Полное наименование документа, на основании которого разрабатывают продукцию. Организация, утвердившая этот документ, и дата его утверждения. Наименование и условное обозначение темы разработки. |
|
Цель и назначение разработки |
Эксплуатационное и функциональное назначение, перспективность производства продукции. |
|
Источники разработки |
Перечень научно-исследовательских и других работ. Перечень экспериментальных образцов и макетов. |
|
Технические (тактико-технические) требования |
Состав продукции и требования к конструктивному решению. Требования к техническим показателям. Требования к надежности. Требования к технологичности. Требования к уровню унификации и стандартизации. Требования безопасности. Эстетические и эргономические требования. Требования к патентной чистоте. Требования к составным частям продукции, сырью, исходным и эксплуатационным материалам. Условия эксплуатации. Дополнительные требования. Требования к маркировке и упаковке. Требования к транспортировке и хранению. Специальные требования. |
|
Экономические показатели |
Ориентировочная экономическая эффективность и срок окупаемости затрат. Предельная себестоимость. Предполагаемая годовая потребность в продукции. Экономические преимущества разрабатываемой продукции по сравнению с аналогами. |
|
Состав и этапы разработки |
Стадии разработки, этапы работ и сроки их выполнения (сроки, указываемые в техническом задании, являются ориентировочными: основные сроки указываются в плане работ или в договоре на разработку нового изделия). Предприятие-изготовитель разрабатываемого изделия. Перечень документов, предъявляемых на экспертизу, этапы, на которых она проводится, и место проведения. |
|
Порядок контроля и приемки |
Перечень конструкторских документов, подлежащих согласованию и утверждению. Перечень организаций, с которыми следует согласовывать документы. Общие требования к приемке работ на стадиях разработки. Количество изготавливаемых опытных образцов продукции. |
|
Приложения к техническому заданию |
Перечень научно-исследовательских и других работ, обосновывающих необходимость проведения разработки. Чертежи, схемы, описания, обоснования, расчеты и другие документы, которые должны быть использованы при разработке. Перечень заинтересованных организаций, с которыми согласовывают конкретные технические решения в процессе разработки продукции. Перечень нового технологического оборудования, необходимого для выпуска новой продукции. |
Стоит так же отметить что важность имеют и договора по уборке помещений, и их нужно правильно составлять. И о том, Что должно быть в договоре на уборку помещения? вы сможете узнать больше на сайте cleaning-is.ru. Этот вопрос вы сможете решить раз и навсегда, без каких либо проблем, находясь всегда в правовом поле.
Выше предоставлены документы которые вы сможете без проблем скачать нажав на активную ссылку, скачивание выбранного вами документа, начнется сразу же после клика на ваш компьютер. Это все образцы технических заданий скачать которые вы можете прямо из сайта без посредничества. Они готовы для заполнения и работы под ваши данные.
Наглядные образцы технических заданий, которые вы можете скачать
Ниже предоставлен пример документа по техническому заданию оказания услуг. Это только часть, полные версии документов вы сможете скачать по ссылка выше. Если возникнут какие-либо вопросы, пишите в комментариях, и мы постараемся на них ответить.
1. Наименование и цели использования оказываемых услуг
(с указанием краткой характеристики того, выполнение каких услуг необходимо заказчику) |
||||||||||||||||||||||||||||||||||||||||||
2. Перечень и объемы услуг
(подробный перечень действий, их количественные и качественные показатели, требуемые от исполнителя с учетом потребностей заказчика) |
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
3.
Место оказания услуг
(с указанием конкретного адреса /адресов, этажей помещений; возможно приложение схем расположения, поэтажные планы и др.) |
||||||||||||||||||||||||||||||||||||||||||
(с указанием периода/периодов, в течение которого (-ых) должны оказываться услуги или конкретной календарной даты, к которой должно быть завершено оказание услуг, или минимально приемлемой для Заказчика даты завершения оказания услуг, или срока с момента заключения договора (уплаты аванса, иного момента), с которого исполнитель должен приступить к оказанию услуг) |
||||||||||||||||||||||||||||||||||||||||||
5.
Требования по выполнению сопутствующих работ, оказанию сопутствующих услуг
(поставкам необходимых товаров, в т.ч. оборудования, комплекта расходных материалов, предоставления иллюстративных материалов, доставке, разгрузке и др.) |
||||||||||||||||||||||||||||||||||||||||||
6. Общие требования к оказанию услуг, их качеству, в том числе технологии оказания услуг, методам и методики оказания услуг | ||||||||||||||||||||||||||||||||||||||||||
(в случае, если от исполнителя требуется осуществить страхование ответственности перед третьими лицами или если оказываемые услуги могут быть связаны с возможной опасностью для жизни и здоровья людей, в данном разделе должны быть указаны соответствующие необходимые требования) |
||||||||||||||||||||||||||||||||||||||||||
(указываются мероприятия по обеспечению сдачи и приемки услуг по каждому этапу оказания услуг и в целом, содержание отчетной, технической и иной документации, подлежащей оформлению и сдаче по каждому этапу и в целом (требование испытаний, контрольных пусков, подписания актов технического контроля, иных документов при сдаче услуг) |
||||||||||||||||||||||||||||||||||||||||||
по завершению и сдаче услуг |
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
(минимально приемлемые для заказчика либо жестко установленные обязанности исполнителя в гарантийный период) |
||||||||||||||||||||||||||||||||||||||||||
(минимально приемлемые для заказчика либо жестко установленные сроки) |
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
(осуществляется по усмотрению заказчика для тех видов работ, в отношении которых законодательством Российской Федерации предусмотрены особые требования) |
||||||||||||||||||||||||||||||||||||||||||
(условия, сроки и размер оплаты по каждому этапу оказания услуг и в целом, в том числе без аванса/аванс до 30%) |
||||||||||||||||||||||||||||||||||||||||||
(для включения в договор) |
||||||||||||||||||||||||||||||||||||||||||
(общая стоимость с разбивкой по позициям, с учетом налогов/сборов и выполнения заданных требований, на основании изучения рынка услуг) |
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
Примечание: 1.Все поля обязательны к заполнению. В случае, если заказчик не предъявляет конкретного требования, то в соответствующем поле проставляется запись «Не предъявляется», «Не требуется» или др. в зависимости от контекста.
Настоящим подтверждаю правильность, точность и достоверность указанных мной в настоящей заявке сведений, соответствие их требованиям локальных, правовых актов Университета, действующим нормативно-правовым актам.
разработки (и не только), практические подготовки технического задания. Бо льшая часть уже готовых к применению логических элементов ТЗ приведены в конце статьи. Редакция от 20.06.2018.
Как писать техническое задание?!
Создан 05.02.2005 11:41:19
Твой мир пуст...
Кто печаль твою разделит?
«Как писать техническое задание?!» - из уст т. н. начинающего «технического писателя», далее по тексту - техписа. Вот она - страшная цена развала Союза и переход российской высшей школы на двухступенчатую систему образования.
Вернемся к вопросу. При «раскладке» получается:
- первый вопрос - «а зачем оно надо»;
- второй вопрос - какова должна быть структура разделов «Техническое задание»;
- третий вопрос - какие существуют способы подготовки текстов содержимого разделов технического задания?
Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.
Цели и задачи статьи
Цель статьи - облегчить жизнь совсем уж начинающим техписам.
Задачи статьи:
- дать ответы на поставленные вопросы;
- показать необходимый минимум практических подготовки текстов технического задания;
- дать начинающему техпису шанс:
- повысить собственный рейтинг;
- или окончательно уронить себя в глазах Большого Босса.
История
Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:
Первым () изделием, быть может, стал каменный топор. Или (рукотворный) глиняный черепок (), позволяющий зачерпнуть водички в ручейке.
Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом - настоящее программное изделие по, только что не, а кустарного производства. Увидеть это чудо чудное можно в Политехническом Музее г. Москвы.
Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.
История, леденящая душу
И наказал тогда царь () - построить мельницу, да такую, чтобы от силы ветра работала, круче, чем у короля аглицкого («хотелки» заказчика), да чтоб на зависть всем буржуям (соответствующую современному развития науки и и не уступающую аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам).
Приволокли опричники холопа государева, умепьца местного (), кинули царю-батюшке в ноги. Бился лбом умелец о пол каменный - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме!
Настало время, прибыл царь на мельницу (работ). Смотрит и диву дается - крылья крутятся, жернова жито молотят, мука сама собой в мешки сыплется! (Полное соответствие требованиям к функциям (задачам), выполняемым системой). Да возьми и запусти руку в мешок... (что не было предусмотрено ни, ни, поскольку не существовало таковых).
Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная.). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...
Выводы
В стародавние времена в отношениях сторон, заказчика и исполнителя (разработчика), равноправия было маловато. Чем-то, само-собой, отношения регламентировались. Возможно, готовились берестяные грамоты - прообразы современных договоров. Вряд ли в подобных договорах можно было учесть все, даже качество помола. Да и не было общепризнанных, в широком смысле все аспекты взаимоотношений заказчика и исполнителя.
Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).
Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.
Примечание от 10.05.2014 г. - Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. и.
Современное состояние
И было придумано то, что сделали танк...
из серии «Армейские приколы»
Устав от «заказчицкого» беспредела, собрались (в последнюю четверть двадцатого века) исполнители (разработчики), организовали «» и сделали танк - на структуру и (, если быть более точным) документа под названием «техническое задание». Следует отметить, что авторские коллективы состояли, как правило, из людей технически грамотных, мыслящих, смотрящих в далеко будущее.
Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.
Техническое задание и его назначение
Большому Боссу, непосредственно взаимодействующему с заказчиком, техническое задание дает возможность избежать участи мастера-умельца (об этом ранее упоминалось неоднократно).
Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:
- средство заработать себе «таки на покушать»;
- способ показать, что техпис - не тварь дрожащая, а право имеет - способ вырасти в глазах Большого Босса.
Крайнее утверждение - палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.
В любом случае способность грамотно разработать техническое задание (особенно - владение) - показатель высокой квалификации разработчика.
Считаем, что первый вопрос (в первом же приближении) закрыт.
ГОСТы на технические задания
Куст есть совокупность веток, произрастающих из одной точки.
Военная мудрость
После тяжких трудов (и страданий) увидели свет, как минимум, четыре документа, соответствующие весьма условному делению продуктов человеческой жизнедеятельности:
Примечания:
- Существуют и иные отечественные ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание». Сей факт обусловен спецификой. Перечисленная четверка была и остается для большинства предметных областей;
- Техзадание было и остается основополагающим документом, той самой «точкой опоры», из которой все и произрастает.
Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения:
- что надо сделать;
- для чего, с какой целью надо сделать это;
- где, в какой области применения, на каком объекте это должно решать задачи и выполнять свои функции;
- какие требования будут предъявлены к этому;
- какие работы потребуется выполнить, чтобы сделать это;
- каков порядок проведения и приемки-сдачи работ заказчику;
- как должно быть проведение работ;
- и, наконец, на основании каких нормативно-технических документов должны проводиться работы?
Такова обобщенная структура разделов технического задания. Второй вопрос считаем закрытым.
Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо - открываем ГОСТ 34.602-89. На - ГОСТ 19.201-78.
Покажем необходимый минимум практических приемов, позволяющих даже самому начинающему техпису немедленно приступить к разработке содержимого разделов техзадания и достичь приемлемых результатов (отдельные готовые структурные элементы технического задания по ГОСТ 34.602-89 можно найти в «подвале» данной статьи).
Практические приемы
Практические приемы разработки технического задания буквально выстраданы на основе опыта взаимодействия с заказчиком как самого автора, так и его старших товарищей, за что низкий им поклон, почет и уважение (и ныне, и присно, и во веки веков. Аминь).
Самый первый прием - создание документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде -файла, затем просто открывается вордом и в формате dot.
Электронные версии ГОСТов, хранящиеся на, в целом соответствуют официальным версиям. Сомнительные моменты всегда можно проверить путем сравнения, если не лень, конечно.
Примечание от 25.12.2011 г. - На Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате...
Детализация
Детализация - один из основополагающих приемов. Кое-кто предпочитает наукообразный термин, заимствованный у буржуев - декомпозиция. Речь пойдет о детализации структуры разделов ГОСТов на техническое задание.
Вспомним родительское - «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».
Произвольно выбранная цитата из ГОСТ 34.602-89:
Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]
Здо рово, да? Придется разгрести эту свалку. Итак, явным дроблением создаются дополнительные подпункты технического задания (это и можно, и нужно делать).
4.3.2.1 Требования к лингвистическому обеспечению системы
4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня
(текст требования)
4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы
(текст требования)
4.3.2.1.3 Требования к кодированию данных
(текст требования)
4.3.2.1.4 Требования к декодированию данных
(текст требования)
4.3.2.1.5 Требования к языкам ввода-вывода данных
(текст требования)
4.3.2.1.6 Требования к языкам манипулирования данными
(текст требования)
4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)
(текст требования)
4.3.2.1.8 Требования к способам организации диалога
(текст требования)
Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?
Примечание - Термины «понятность», «» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция - «совокупность чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».
После трансформирования сплошного текста в перечисление (, подразделы, подпункты) на понимание (хотя бы запоминание) логической структуры технического задания автору потребовалось меньше времени (и затрат усилий), поскольку подпункты стали явно «видны».
Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.
Шаблонное построение фраз
Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) - половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе ». Итак:
4.3.2.1 Требования к применению в системе языков программирования высокого уровня
В системе должны быть (именно должны - это же!) применены перечисленные ниже языки программирования высокого уровня:
- язык C++;
- язык Pascal;
- и т.д.
Для тех, кто не прочувствовал, как построить фразу, слева приведена схема ее построения.
4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
(детализируем - создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)
(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)
Численность персонала должна удовлетворять требованиям :
- быть достаточной для реализации автоматизированных () системы во всех режимах работы системы;
4.1.2.2 Требования к квалификации персонала
Квалификация персонала должна обеспечивать эффективное функционирование технических и системы во всех режимах работы системы»
В, в решениях по квалификации персонала, можно будет указать, что, на основании опыта более сотни ранее разработанных аналогичных систем, персонал должен иметь образование не ниже трех классов церковно-приходской школы. Сие утверждение порадует заказчика. Можно будет воспользоваться сверхдешевой рабочей силой. Но об этом в следующих статьях.
4.1.2.3 Требования к режиму работы персонала
Режим работы персонала - трехсменный круглосуточный.
В подразделе предусмотрен также порядок подготовки персонала, контроля знаний и навыков. О составе - ни слова. И это правильно. Состав персонала, деление его на оперативный (), ремонтный и пр., определяется при проектировании системы. Хотя никто не может запретить добавить в техническое задание Требования к составу персонала. Пожалуй, не стоит.
Простенько, но со вкусом. Чистая практика, без глубокого погружения в языковые тонкости. Детализация плюс конктерных требований технического задания.
Формализация при подготовке текста технического задания
Возможно Двести Вариантов
Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»
Вернемся к примеру из предыдущего подраздела статьи.
4.1.2.1 Требования к численности персонала
Численность персонала должна удовлетворять требованиям:
- быть достаточной для реализации автоматизированных системы во всех режимах работы системы;
- обеспечивать полную занятость персонала при реализации автоматизированных функций системы и т.д.
Лапша полнейшая, но формально все верно. Рекомендуется к применению, если невозможно конкретизировать какой-либо пункт технического задания. Если Большой Босс не будет, можно вежливо попросить его уточнить требования заказчика по данному пункту, дать более точную информацию. Это право техписа, не контактирующего непосредственно с заказчиком.
Можно добавить - «численность персонала уточняется на «Технический проект»». Большой Босс будет поражен такой осведомленностью техписа (даже если и сам ни черта не знает) в части стадий и автоматизированных систем. А если устно предложить Боссу добавить (потом) в к проекту фразу - «на основе опыта более сотни ранее разработанных подобных систем численность персонала должна составлять 10 штатных единиц» - Босс будет сражен наповал. Можно смело готовить Приказ о назначении техписа на должность системного аналитика (которая также отсутствует в общероссийском классификаторе). Или ждать, что подкинут дополнительную работенку, раз такой умный.
Примечание от 17.04.2018 г. - В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен
Штампы и унификация при подготовке текста технического задания
Вы, бабы, красивы,
А я - без прикрас
Но, все же, мужчины
Уходят от вас...
Ю. Рыбчинский, «Две сестры»
текста техзадания достигается применением штампов. Прежде всего следует усвоить простую истину - никогда, ни в одном документе не следует называть вещи своими именами .
Положим, разрабатывается универсальный преобразователь энергии в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:
Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).
И, в тексте - Изделие, Изделие, Изделие...
Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).
И, в тексте - Система, Система, Система... Программа, Программа, Программа...
Итог - догнали и завалили сразу двух зайцев. Склонять-спрягать целую кучу слов не потребуется, да и читать построенное таким образом техническое задание будет проще.
Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.
Ниже - типовые перечни штампов, долго и успешно применяемых при разработке технических заданий (по основным разделам, выделено жирным):
- назначение системы - система предназначена для
решения перечисленных ниже задач:
- задачи такой-то (первой);
- задачи сякой-то (второй);
- и так далее.
- цели создания системы - целями создания системы являются
:
- увеличение скорости...;
- повышение точности...;
- уменьшение издержек...;
- снижение потребления...;
- улучшение показателей...;
- и так далее.
Любая цель всегда подразумевает положительную динамику , изменение каких-либо показателей в лучшую сторону. К примеру, цель - повышение благосостояния всего советского народа (но не коммунизм: коммунизм - это мишень!). Цель - повышение удовлетворенности заказчика. Исключение составляют:
- получение прибыли (в контексте технического задания);
- подписание заказчиком.
Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в одном из техписовских форумов) - « позволяет ... программа выполняет ... программа делает ...». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не, не, не, не и не сдана заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!
- требования к функциям (задачам), выполняемым системой - системадолжна
перечисленных нижефункций
:
- в рамках первой задачи - выполнение функции такой-то, такой-то и еще какой-то;
- в рамках второй задачи - выполнение функции такой-то и пр.
Если функция (как и процесс) , тогда именно обеспечивать возможность выполнения указанной функции. Пользователь может убрать стопор - мельница начнет молоть муку. Но пользователь может стопор и не убрать. В указанном случае мельница (система) будет находиться в режиме ожидания (простоя).
Если функция (как и процесс) , тогда система должна именно обеспечивать выполнение функции. Функция автоматического запускается программными средствами системы (без участия персонала) по заданному расписанию и сливает базу данных на.
По части рамок задач. Задачи решаются , а функции выполняются . Чтобы решить задачу, надо выполнить ряд функций, процедур или операций. Иными словами - задача есть более крупный структурный элемент вопреки измышлениям.
В ГОСТ 34.003-90 поставлена впереди, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций... И представьте себе, как дико звучала бы декларация: «Цель партии и правительства - повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой»... (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно - для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.
Итак, пример.
В рамках задачи (или для решения задачи ) программные средства системыдолжны обеспечивать выполнение перечисленных нижефункций :
- автоматизированной функции
- автоматизированной функции сортировки записей в таблицах базы данных;
- функции автоматического резервирования базы данных.
И из предыдущего подраздела:
- должны быть ...;
- должна удовлетворять требованиям ..
В результате применения штампов тескт технического задания становится унифицированным и формализованным. Никаких прикрас . И заказчик-мужчина никуда не уйдет от вас, милые девушки-техписы, поскольку требования технического задания будут для него прозрачны .
Перечни и нумерация разделов
Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.
В, пожалуй, число элементов перечня следует снижать. В техническом задании - необязательно. Следует помнить, что техническое задание с множеством иных документов, разрабатываемых на различных стадиях и этапах создания системы (да чего угодно).
Случай первый.
«В рамках задачи (или для решения задачи должны обеспечивать возможность выполнения перечисленных нижефункций :
- автоматизированной функции добавления записей в таблицы базы данных;
- автоматизированной функции удаления записей из таблиц базы данных;
Случай второй.
«4.3.2.1 В рамках задачи (или для решения задачи ) ведения базы данных программные средства системыдолжны обеспечивать возможность выполнения перечисленных нижефункций :
- автоматизированной функции добавления записей в таблицы базы данных;
- автоматизированной функции удаления записей из таблиц базы данных;
- автоматизированной функции сортировки записей в таблицах базы данных...;»
Отличия, казалось бы, невелики. Но!
В первом случае, в документе «Программа и методика испытаний», придется написать «методика проверки выполнения системой автоматизированной функции добавления записей в таблицы базы данных».
Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».
В, в первом случае - «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае - «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?
Что касается многоуровневой нумерации разделов, подразделов, пунктов и подпунктов - на практике указанные требования в подавляющем большинстве случаев обязательны.
По списки следует «нумеровать» не цифрами, а буквами:
а) функция такая-то;
Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой организации - разработчика ТЗ и, при необходимости, подвергнуто [из п. 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.
Чуть-чуть о. Если в ТЗ имеется подраздел «Метрологическое обеспечение...», то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений согласно ГОСТ 8.417. И только.
Связка «общие сведения, назначение и состав» в техническом задании
Связка «общие сведения, назначение и состав» прекрасно показала себя не только при разработке технического задания. Связка подойдет для любых нехудожественных текстов описательного характера.
Пример - Требования к числу уровней и степени централизации системы. Вот что можно написать в указанном подразделе технического задания?
Любой человек начнет рефлекторно просматривать разделы ГОСТа на техническое задание, пытаясь найти хоть какую-то зацепку. Человек с опытом сразу вспомнит о.
2.1 Назначение системы
Товарищ, непосредственно что-то там паяющий, налаживающий, всегда сможет подсказать техпису, для чего система создается. В рамках своей компетенции, разумеется. Системотехник или Босс скажут больше. Допустим,
Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:
- задачи сбора данных с каких-то, допустим, датчиков;
- задачи обработки, хранения, отображения и пр. в центре сбора.
Вот и все. Немного фантазии, и раздел готов:
Система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:
- 1-й уровень - уровень сбора данных ;
- 2-й уровень - уровень консолидации данных (централизованная обработка, хранение и пр.).
Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?
2.1.1 Уровень сбора данных
2.1.1.1 Общие сведения
Какие-то общие сведения. Можно, к примеру, написать, что уровень характеризуется территориальной распределенностью - любая водичка сойдет, если она приблизительно соответствует.
2.1.2.2 Назначение
Уровень сбора данных предназначен (еще один штамп):
- для передачи данных каких-то датчиков уровню консолидации по запросу (инициативе) крайнего (последнего);
- для протоколирования передачи данных в журнале событий (а если по ГОСТу, то в);
- еще для чего-то.
2.1.2.3 Состав
В состав уровня сбора данных должны входить:
- датчики такие-то;
- датчики еще какие-то.
В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.
2.2.2.3.1 Датчики такие-то
2.2.2.3.1.1 Общие сведения (о таких-то датчиках)
2.2.2.3.1.2 Назначение (таких-то датчиков)
2.2.2.3.1.3 Состав (таких-то датчиков)
Главное - вовремя остановиться.
Предостережение
При разработке и наибольший интерес представляют перечисленные ниже:
- прежде всего - . Для таким является;
- , например и;
- , например;
- и, например;
- ряд других.
Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к. Характерная ошибка начинающих - «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение.
Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание и внести в него или возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.
Настало время проведения испытаний системы (программы, изделия) на соответствие требованиям технического задания. Заказчик, само собой, потребует показать, что каналы связи соответствуют требованиям ГОСТа такого-то.
Что делать? Полбеды, если каналами связи занимался, готовый предоставить Большому Боссу. Босс отмажется перед заказчиком и техпис будет жить (до очередного прокола). Но неприятный осадок в душе Большого Босса останется навсегда. Повышения ждать не приходится.
Совсем беда, если сертификатов нет. Придется Боссу платить (не предусмотренные бюджетом) денежки органу, дабы заполучить вожделенный сертификат, предъявить заказчику и закрыть работу. Такую ошибку техпису могут и не простить.
Короче, писать надо примерно так, русским по белому:
«В качестве каналов связи могут быть применены (использованы):
- каналы связи -;
- каналы операторов сотовой связи;
- каналы операторов спутниковой связи;
- коммутируемые телефонные линии общего пользования;
- объекта заказчика;
- и так далее»
Ни в коем случае нельзя указывать скорость обмена данными канала связи, т.е. конкретику. Если канал связи будет реализован на базе Ethernet, а в техническом задании будет явно указана скорость обмена не ниже 1200 бит/с, заказчик имеет полное право заставить исполнителя провести испытания по полной программе. Даже в такой, явно абсурдной ситуации.
Заключение
Итак, вспомним еще разок ключевые моменты:
- подготовка технического задания импортом электронной версии требуемого ГОСТа;
- детализация - дробление больших по объему разделов технического задания на короткие простые подразделы;
- шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
- формализация содержимого тех разделов, где невозможно (или) давать конкретику;
- применение штампов;
- применение перечней (маркированных или нумерованных списков);
- применение связки «общие сведения, назначение и состав»;
- минимальное применение «тематических» ГОСТов.
В заключении можно дать ряд дополнительных советов:
- отыскать «рыбу» технического задания и, после критического ее осмысления, позаимствовать содержимое подходящих разделов (только не с известного всем ресурса закупки.гов.ру - там лежит чушь полнейшая);
- пользоваться документами;
- без стеснения задавать вопросы.