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

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

• описывать объект закупки так, как это предусмотрено КТРУ;
• включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

• общая информация;
• информация о закупаемом объекте;
• требования к поставщикам;
• условия ;
• приложения (допускается по усмотрению заказчика).

Этапы составления технического задания

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

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

• или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
• централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
• привлечение экспертов, порядок их работы.

4. Перечислить сведения о госзакупке:

• способ определения поставщика (ч. 1 ст. 24);
• обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

6. Указать исходные условия: справочная, производственная, опытная информация, которые оказывают влияние при исполнении контракта. Например, что обслуживать закупаемую технику возможно только в утренние часы.

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

10. Указать источник финансирования.

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

12. Определить условия госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

21. Определиться, нужны ли монтаж и наладка.

22. Установить порядок поставки и приемки.

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

Образцы техзаданий для товаров, работ, услуг в 2019 году

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .

Федеральный закон № 44-ФЗ о контрактной системе устанавливает единые требования к описанию объекта закупок, которым заказчик обязан следовать при составлении документации о закупке, независимо от способа их осуществления (ст. 33 44-ФЗ). Рассмотрим, какими правилами должен руководствоваться заказчик при составлении технического задания.

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

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

Заказчик может несколько изменить условия по сравнению с техническим регламентом, ГОСТом или СанПиНом, но только в сторону улучшения характеристик.

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

2. В восстановительные соки допускается добавление лимонной кислоты в дозировке не более 3 г/л (в соотв. с тех. регламентом). Заказчик может уточнить этот показатель, уменьшив ее содержание, например, до 2 г/л. Если заказчик ссылается на ГОСТ, который содержит в себе диапазонные значения, то лучше эти значения отдельно расписать, чтобы уже участник в своей заявке нам показал конкретное значение из этого диапазона ГОСТа.

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

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

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

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

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

1. При составлении документации, описание объекта закупки должно носить объективный характер. То есть четкое и ясное описание того, что именно нужно заказчику, не допускающее двусмысленностей и разночтений. Кроме того, для уточнения отдельных моментов поставщик может подать запрос на разъяснение.
2. Заказчик в описании предмета закупки описывает его функциональные, технические и иные характеристики, которые требуются от поставленного товара (произведенных работ).
3. Техническое задание должно быть нейтральным, не ставить ограничений на количество потенциальных участников путем прописывания чрезмерных требований к поставляемой продукции. Нельзя «подгонять» описание только под один конкретный товар одного производителя. Это является ограничением конкуренции. Единственным исключением тут является ситуация, когда нет другого способа исчерпывающего описания свойств объекта закупки (п.1 ч. 1 ст. 33).
4. Заказчику рекомендуется указывать в техническом задании, что поставляемый товар должен быть новым (который не был в употреблении, в ремонте, в том числе который не был восстановлен, у которого не была осуществлена замена составных частей, не были восстановлены потребительские свойства), иначе заказчик может получить товар, бывший в употреблении.

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

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

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

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

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

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

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

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

Структура документа ТЗ:

1. Оглавление
2. История изменений
3. Терминология
4. Общие сведения о проекте (назначение, цели и задачи проекта)
5. Требования к проекту (функциональные, пользовательские, общие и другие требования)
6. Требования к видам обеспечения
7. Требования к документированию
8. Стадии и этапы разработки
9. Порядок контроля и приемки проекта
10. Дополнительные материалы

Рассмотрим подробнее каждый пункт структуры.

Понятно из названия, перечень всех частей технического задания.

2. История изменений

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

3. Терминология

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

4. Общие сведения о проекте

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

5. Требования к проекту

Один из самых объемных и также основной пункт в техзадании. В нем описываются абсолютно все требования к проекту, такие как:

• требования к функционированию проекта;
• требования к надежности;
• требования к исполнительному персоналу;
• требования к патентной чистоте;
• требования к стандартизации;
• требования к конфиденциальности;
• требование к безопасности;
• и другие …

6. Требования к видам обеспечения

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

7. Требования к документированию

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

• руководство пользователя;
• руководство администратора;
• данные по проведенным тестам;
• акт выполненных работ.

8. Стадии и этапы разработки

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

9. Порядок контроля и приемки проекта

В этом разделе описывается порядок приема проекта, система тестов.

10. Дополнительные материалы

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

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

1. Желательно по максимуму использовать графические материалы. Часто бывает так, что одна схема или диаграмма может заменить несколько страниц текста.
2. Не использовать расплывчатых, двусмысленных описаний. Все должно быть описано четко и понятно.
3. Описание проекта должно быть логически связным и не иметь противоречий.
4. Необходимо указывать абсолютно все данные и требования, даже те, которые на первый взгляд могут показаться абсурдными. Такими данными могут быть поля в форме регистрации, формат даты в статье и прочее.
5. При указании сроков, необходимо учитывать, что неотъемлемой частью разработки является тестирование и исправление ошибок, поэтому в очень короткие сроки можно не вложится.
6. После выбора исполнителя необходимо совместно просмотреть ТЗ, возможно появятся новые вопросы или дополнения.

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

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

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

Нормативная база

Основными нормативными документами, регламентирующими правила подготовки и оформления ТЗ, являются:

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

ГОСТ 34.602-89 предназначен для разработчиков автоматизированных систем, ГОСТ 19.201-78 – для разработчиков программных средств.

Обратите внимание! Согласно п. 1 ст. 46 Федерального закона от 27.12.2002 № 184-ФЗ «О техническом регулировании» (в ред. от 03.12.2012) со дня вступления в силу данного закона впредь до вступления в силу соответствующих технических регламентов требования к продукции или к продукции и связанным с требованиями к продукции процессам проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации и утилизации, установленные нормативными правовыми актами Российской Федерации и нормативными документами федеральных органов исполнительной власти, носят рекомендательный характер и подлежат обязательному исполнению только в части, соответствующей целям:

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

В этой статье мы рассмотрим правила оформления технического задания на автоматизированную систему (далее – ТЗ на АС). Согласно п. 1.1 ГОСТ 34.602-89 ТЗ на АС является основным документом , определяющим требования и порядок создания, развития или модернизации автоматизированной системы, в соответствии с которым проводится разработка системы и ее приемка при вводе в действие.

Состав ТЗ на АС

Согласно п. 2.1 ГОСТ 34.602-89 ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

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

В ТЗ на АС могут включаться приложения.

Правила оформления ТЗ на АС по ГОСТ 34.602-89

Правилам оформления ТЗ на АС в ГОСТ 34.602-89 посвящен небольшой раздел, в котором даны указания по правилам нумерации листов, оформления титульного листа и дополнений к документу.

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

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

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

Форма титульного листа ТЗ на АС приведена в Приложении 2 к ГОСТ 34.602-89 (Пример 1).

Пример 1

Форма титульного листа ТЗ на АС

Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу ТЗ. Вместо наименования «Техническое задание» пишут «Дополнение № ... к ТЗ на АС...».

■ Оформление последнего листа ТЗ на АС. Форма последнего листа ТЗ на АС, на котором помещают подписи разработчиков и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, приведена в Приложении 3 к ГОСТ 34.602-89 (Пример 2).

Пример 2

Форма последнего листа ТЗ на АС

_________________________________________

(код ТЗ)

СОСТАВИЛИ

СОГЛАСОВАНО

Согласно п. 3.2 ГОСТ 34.602-89 ТЗ на АС оформляется в соответствии с требованиями межгосударственного стандарта ГОСТ 2.105-95 «Единая система конструкторской документации . Общие требования к текстовым документам», устанавливающего общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства.

Правила оформления текстовой части ТЗ на АС по ГОСТ 2.105-95

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

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

Требования к текстовым документам, содержащим в основном сплошной текст, подробно изложены в четвертом разделе ГОСТ 2.105-95. Рассмотрим основные положения этого раздела.

■ Построение документа. В п. 4.1 ГОСТ 2.105-95 приведены подробные инструкции по нумерации и расположению разделов, подразделов, пунктов и подпунктов.

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

Разделы, как и подразделы, могут состоять из одного или нескольких пунктов.

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

Если раздел или подраздел состоит из одного пункта, он также нумеруется.

Если текст документа подразделяется только на пункты, они нумеруются порядковыми номерами в пределах документа.

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

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

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

Обратите внимание: переносы слов в заголовках не допускаются.

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

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

В п. 4.2 ГОСТ 2.105-95 приведены правила изложения текста документов . Эти правила адресованы в основном разработчикам ТЗ на АС, однако некоторые из них полезно знать всем работникам, чья деятельность связана с составлением и оформлением документов.

Например, не только в тексте ТЗ, но и в тексте любого документа рекомендуется соблюдать ограничения, предусмотренные ГОСТ 2.105-95. Так, согласно подп. 4.2.3 ГОСТ 2.105-95 в тексте документа не допускается:

– применять обороты разговорной речи, техницизмы, профессионализмы;

– применять для одного и того же понятия различные научно-технические термины, близкие по смыслу (синонимы), а также иностранные слова и термины при наличии равнозначных слов и терминов в русском языке;

– применять произвольные словообразования;

– применять сокращения слов, кроме установленных правилами русской орфографии, соответствующими государственными стандартами, а также в данном документе;

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

В соответствии с подп. 4.2.4 ГОСТ 2.105-95 в тексте документа, за исключением формул, таблиц и рисунков, не допускается:

– применять математический знак минус (–) перед отрицательными значениями величин (следует писать слово «минус»);

– применять знак «Ø» для обозначения диаметра (следует писать слово «диаметр»);

– применять без числовых значений математические знаки, например > (больше), < (меньше), = (равно), ≥ (больше или равно), ≤(меньше или равно), ≠ (не равно), а также знаки № (номер), % (процент).

Если в тексте приводится ряд числовых значений, выраженных в одной и той же единице физической величины, то ее указывают только после последнего числового значения, например: 1,50 ; 1,75 ; 2,00 м .

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

От 1 до 5 мм.

От плюс 10 до минус 40 °С.

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

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

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

Примеры оформления примечаний:

Примечание – ________________________________________________________

Примечания

1. __________________________________________________________________

2. __________________________________________________________________

Обратите внимание! Согласно подп. 4.6.2 ГОСТ 2.105-95 примеры, которые приводятся в тексте документа, размещают, нумеруют и оформляют так же, как и примечания (подп. 4.2.21 ГОСТ 2.105-95).

Правила оформления иллюстраций и приложений приведены в п. 4.3 ГОСТ 2.105-95.

■ Иллюстрации , за исключением иллюстраций приложений, следует нумеровать арабскими цифрами сквозной нумерацией. Если рисунок один, то он обозначается: Рисунок 1 . Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения, например: Рисунок А.3 . Мелкие иллюстрации, которые размещены непосредственно в тексте и на которые в дальнейшем нет ссылок, допускается не нумеровать.

Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой, например: Рисунок 1.1 .

Иллюстрации, при необходимости, могут иметь наименование и пояснительные данные (подрисуночный текст). Слово «Рисунок» и наименование помещают после пояснительных данных и располагают следующим образом: Рисунок 1 – Детали прибора .

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

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

Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, З, Й, О, Ч, Ь, Ы, Ъ. Допускается обозначение приложений буквами латинского алфавита, за исключением букв I и О. Если в документе одно приложение, оно обозначается «Приложение А».

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

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

■ Таблицы. Их построению посвящен п. 4.4 ГОСТ 2.105-95. Это наиболее полное и подробное описание правил создания и оформления таблиц в текстовых документах из тех, с которыми автору приходилось встречаться.

Рассмотрим наиболее важные правила из тех, что приведены в п. 4.4 ГОСТ 2.105-95.

Таблицы (за исключением таблиц приложений) следует нумеровать арабскими цифрами сквозной нумерацией. В каждом приложении таблицы нумеруют отдельно арабскими цифрами с указанием перед цифрой обозначения приложения. Например:

Таблица 1 – если в документе одна таблица;

Таблица В.1 – если таблица приведена в приложении В.

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

Обратите внимание! В тексте документа должны быть приведены ссылки на все таблицы документа , при ссылке следует писать слово «таблица» с указанием ее номера.

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

Обратите внимание! Разделять заголовки и подзаголовки боковика и граф диагональными линиями не допускается.

Таблицу, в зависимости от ее размера, помещают под текстом, в котором впервые дана ссылка на нее, или на следующей странице, а при необходимости – в приложении к документу.

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

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

Обратите внимание! В соответствии с Изменением № 1, введенным в действие приказом Ростехрегулирования от 22.06.2006 № 117-ст, при подготовке текстовых документов с использованием программных средств (например, приложения MS Word или MS Excel) надпись «Продолжение таблицы» допускается не указывать .

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

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

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

Для сокращения текста заголовков и подзаголовков граф отдельные понятия заменяют буквенными обозначениями, установленными ГОСТ 2.321-84 «ЕСКД. Обозначения буквенные» (переиздан в марте 2002 г.), или другими обозначениями, если они пояснены в тексте или приведены на иллюстрациях, например D – диаметр , Н – высота , L – длина .

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

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

■ Сноски. Их оформление регламентировано п. 4.5 ГОСТ 2.105-95.

Согласно подп. 4.5.1 ГОСТ 2.105-95 сноски в тексте располагают с абзацного отступа в конце страницы, на которой они обозначены, и отделяют от текста короткой тонкой горизонтальной линией с левой стороны, а к данным, расположенным в таблице, – в конце таблицы над линией, обозначающей окончание таблицы.

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

Правила оформления документов, приведенные в ГОСТ 2.105-95, проиллюстрированы рисунками, которые не приведены в статье, но с которыми имеет смысл ознакомиться – эти иллюстрации помогут вам лучше понять требования государственного стандарта.

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

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

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

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

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

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

Что было плохо:

1. Мы писали список требований к иллюстрациям для анимации, не сопроводив эти требования примерами с картинками и видео. Это был просто текст вроде: “старайтесь рисовать гнущиеся элементы таким образом, чтобы энкор поинты суставов совпадали друг с другом”. Из-за того что мы поленились это проиллюстрировать, наш иллюстратор сделал то что нужно только с третьего раза.
2. Мы насыщали ТЗ слишком большим количеством примеров. Иллюстратор буквально тонул в изобилии работ, которые нам нравятся. Не было четкого стилистического ориентира.
3. Много текста. Мы писали лишнюю информацию о проекте. Эта информация никак не могла помочь иллюстратору сделать его работу.
4. Раскадровка с недостаточными пояснениями о том что будет происходить в слайде.
5. Доступность ТЗ только онлайн, на Гугл Диске.
6. Мы не имели четкого представления для кого пишем это ТЗ. Мы не вошли в роль этого человека для нашего проекта.

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

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

Суть нашего нового подхода к написанию ТЗ свелась к следующему:

1. Очень кратко и емко нужно описать для кого этот проект, какие задачи нужно решить по окончанию проекта, и какую конкретную задачу решает человек, которого вы нанимаете на проект. Таким образом, он не будет работать вслепую, понимание “что” и “зачем” позволит ему предложить вам лучшие решения.

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

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

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

5. Теперь мы скидываем не только текст в формате Гугл Докс, но еще ссылку на скачивание PDF версии ТЗ, чтобы в случае неполадок с интернетом, ТЗ было под рукой.

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