Руководства для технических писателей

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

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

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

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

Category:

• Литература
• Cancel

Что почитать начинающему техническому писателю

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

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

Основы профессии

• Sarah O’Keefe, Alan S. Pringle «Technical Writing 101: A Real-World Guide to Planning and Writing Technical Documentation» — азы профессии и некоторые полезные фишки: как общаться с разработчиком и организовывать рабочий процесс;
• Mark Baker «Every Page Is Page One: Topic-Based Writing for Technical Communication and the Web» — как писать эффективную документацию в контексте веба;
• Express Knowledge Base Contributor Guides —  шаблоны статей различных типов, рекомендации по оформлению;
• protext.su — постоянно обновляемый ресурс о техническом документировании: методики, инструменты и тонкости профессии.

Стиль

• Microsoft Russian Style Guide — руководство по стилю от Microsoft: как правильно называть элементы, какие формулировки лучше использовать;
• Нора Галь «Слово живое и мертвое» — как побороть канцелярский стиль и писать живым языком;
• Ли ЛеФевер «Искусство объяснять» — как преподносить свои идеи и избавиться от «проклятия знания»;
• Дэн Роэм «Бла-бла-бла или Что делать, когда слова не работают» — как подкреплять свои мысли живыми образами;
• soviet.glvrd.ru — советы и статьи от Максима Ильяхова;

Стандарты

• rugost.com — разработка документации по ГОСТ 34, 19, РД-50;
• docs.su — теория и практика технического документирования по ГОСТам;
• popel-studio.com/blog/article/dokumentacija-po-gostu.html — ГОСТы для веб-разработчика;
• habrahabr.ru/post/116825 — отечественные и зарубежные стандарты документации;
• ГОСТ Р — cтиль изложения документации пользователя.

Примеры (документация)

• support.google.com  —  справочный центр Google, пример составления базы данных для большого количества продуктов;
• yandex.ru/support —  Яндекс.Помощь, ещё один пример;
• docs.microsoft.com — документация Microsoft c простой навигацией и обратной связью;
• msdn.microsoft.com — документация Microsoft с четкой структурой и удобной боковой панелью навигации;
• codex.wordpress.org — кодекс WordPress, пример построения четкой структуры по принципам EPPO и DITA;
• wiki.wargaming.net — документация Wagraming, пример удачного использования графических элементов и решения проблемы версионности;
• docs.basex.org — документация Base X, простой пример использования контекстных ссылок для доступа к вспомогательным материалам;
• help.loco2.com — отличный пример документации, в которой всё разложено по полочкам.

Примеры (руководства по стилю и редполитика)

• МФТИ
• Тинькофф-банк
• Модульбанк

                    ± ь» т

БИБЛИОТЕКА ПРОГРАММИСТА
Вадим Глаголев
РАЗРАБОТКА
ТЕХНИЧЕСКОЙ
ДОКУМЕНТАЦИИ
Руководство для технических
писателей и локализаторов ПО
Москва - Санкт-Петербург - Нижний Новгород • Воронеж
Ростов-на-Дону - Екатеринбург • Самара - Новосибирск
Киев - Харьков - Минск
2008

ББК 32.973.2-018-02
УДК 004.41
Г52
Глаголев В. А.
Г52 Разработка технической документации: Руководство для технических писателей
и локализаторов ПО (+CD). — СПб.: Питер, 2008. —192 с: ил.
ISBN 978-5-388-00101-6
Эта книга станет незаменимым помощником в работе технических писателей, специалистов по
стандартизации и переводчиков-локализаторов программного обеспечения.
Издание посвящено вопросам разработки текстовой технической документации на аппаратно-
программные комплексы, автоматизированные системы и программные продукты, к которым
относится большая часть современного рынка высоких технологий. Приведены общие сведения о
промышленной продукции и технической документации, основные понятия о государственной
системе обеспечения единства измерений (ГСИ), единых системах конструкторской, программной
и технологической документации (ЕСКД, ЕСПД и ЕСТД), комплексе стандартов на авто
ванные системы (КСАС). Рассмотрен жизненный цикл технической документации. Значительное
место отведено вопросам разработки основных видов текстовой технической документации на
аппаратно-программные комплексы и автоматизированные системы — технического задания,
технических условий, программы и методики испытаний, а также эксплуатационной документации —
руководства по эксплуатации, руководства пользователя, инструкции по эксплуатации,
формуляра, паспорта, этикетки ведомости эксплуатационных документов. Изложены рекомендации по
переводу, локализации, оформлению и приданию юридического статуса технической документации
на продукцию зарубежных производителей. Рассмотрены основные программные инструменты,
предназначенные для разработки текстовой технической документации.
Книга рассчитана как на получение начального образования молодыми специалистами, так и на
углубление знаний опытных разработчиков текстовой технической документации. Будет представлять
интерес для переводчиков и редакторов переводов иноязычной технической документации.
К изданию прилагается компакт-диск с дополнительными материалами, которые могут
оказаться полезными при разработке текстовой документации. В состав этих материалов включены
нормативные документы, на которые даны ссылки в пособии, методические рекомендации по
разработке и оформлению технической документации, а также шаблоны основных текстовых
конструкторских документов.
ББК 32.973.2-018-02
УДК 004.41
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как
надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не
может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за
возможные ошибки, связанные с использованием книги.
ISBN 978-5-388-00101-6 О ООО «Питер Пресс», 2008

Краткое содержание
Перечень аббревиатур и сокращений 11
Введение 13
1. Общие сведения о промышленной продукции
технической документации 15
2. Основные сведения о Государственной системе обеспечения
единства измерений (ГСИ). Сертификация промышленной
продукции 29
3. Единая система конструкторской документации
(ЕСКД) как базовая система стандартов
для разработки ТД 33
4. Единая система программной документации (ЕСПД) и ее применение
при разработке ТД на АПК и АС 57
5. Основные сведения о единой системе
технологической документации (ЕСТД) 73
6. Жизненный цикл технической документации 77
7. Разработка основных видов текстовой технической
документации на АПК согласно требованиям ЕСКД 89
8. Разработка основных видов текстовой
технической документации на АС
согласно требованиям КСАС 141
9. Перевод, локализация, редактирование, придание
юридического статуса и оформление переводов
иностранной технической документации 173
10. Основные программные инсгрументы,рекомендуемые
для разработки текстовой технической документации.
Принцип «единого источника» при создании
связанных документов 185
Заключение 191

Содержание
Перечень аббревиатур и сокращений 11
Введение 13
От издательства 14
1. Общие сведения о промышленной продукции
технической документации 15
1.1. Определения и термины. Жизненный цикл
промышленной продукции 16
1.2. Стандартизация в промышленном производстве. Современное
российское законодательство о техническом регулировании.
Основные системы государственных стандартов России
и бывшего СССР 21
1.3. Система разработки и постановки продукции
на производство (СРПП). Стадии разработкипромышленной
продукции. Место и роль ТД при разработке, производстве,
эксплуатации и ремонте промышленной продукции.
Классификация ТД 25
2. Основные сведения о Государственной системе обеспечения
единства измерений (ГСИ). Сертификация
промышленной продукции 29
3. Единая система конструкторской документации (ЕСКД)
как базовая система стандартов для разработки ТД 33
3.1. Виды изделий. Классификация и иерархия типовой
промышленной продукции 34
3.2. Виды, обозначение и комплектность КД на АПК и ТД на АС.
Типовой состав текстовой ТД и общие правила ее оформления ... 37
3.3. Основные требования к оформлению текстовой ТД 44
3.3.1. Форматы и основные надписи. Общие правила оформления
текстового документа. Шрифты. Титульный лист,
лист утверждения и лист регистрации изменений 44
3.3.2. Правила построения и изложения текста 46
3.3.3. Оформление таблиц и иллюстраций 48

8 Содержание
3.3.4. Формулы и единицы физических величин в текстовой документации . . 51
3.3.5. Оформление приложений. Сокращения и аббревиатуры,
буквенные обозначения, сноски, ссылки и примеры
в текстовой документации 54
4. Единая система программной документации (ЕСПД)
и ее применение при разработке ТД на АПК и АС 57
4.1. Термины и определения. Виды и содержание
программных документов 58
4.2. Правила обозначения ПД 61
4.3. Порядок разработки и состав ПД на АПК и АС 63
4.4. Разработка отдельных видов ПД на АПК и АС 65
5. Основные сведения о единой системе технологической
документации (ЕСТД) 73
6. Жизненный цикл технической документации 77
6.1. Стадии разработки ТД. Порядок разработки, согласования
и утверждения ТД. Бумажная и электронная формы ТД.
Примерные нормы временина разработку текстовой ТД 78
6.2. Нормоконтроль, учет, хранение и оборот ТД. Внесение изменений
в техническую документацию. Информационная защита ТД 83
6.2.1 Права 86
6.2.2. Обязанности 86
6.2.3 Ответственность 87
7. Разработка основных видов текстовой технической
документации на АПК согласно требованиям ЕСКД 89
7.1. Техническое задание на ОКР 90
7.2. Место и роль графической КД при разработке текстовой ТД 93
7.3. Технические условия 95
7.4. Программы и методики испытаний 108
7.4.1. Приемосдаточные испытания 112
7.4.2. Периодические испытания 112
7.4.3. Правила проведения типовых испытаний 113
7.5. Ведомость эксплуатационных документов 118
7.6. Руководство по эксплуатации 120
7.7. Формуляр, паспорт и этикетка '. 131
8. Разработка основных видов текстовой технической
документации на АС согласно требованиям КСАС 141
8.1. Техническое задание на АС 142
8.2. Описание информационного обеспечения системы 152

Содержание 9
8.3. Описание программного обеспечения 154
8.4. Программа и методика испытаний (компонентов, комплексов
средств автоматизации, подсистемы, систем) 156
8.5. Руководство пользователя АС 165
8.6. Инструкция по эксплуатации КТС 167
8.7. Технологическая инструкция, формуляр, паспорт 169
9. Перевод, локализация, редактирование, придание
юридического статуса и оформление переводов
иностранной технической документации 173
9.1. Особенности перевода технической документации и его качество . . 174
9.2. Рекомендации переводчику технической документации 176
9.3. Памятка редактору перевода технической документации 180
9.4. Придание юридического статуса переводу
технической документации 182
10. Основные программные инструменты, рекомендуемые
для разработки текстовой технической документации.
Принцип «единого источника» при создании
связанных документов 185
Заключение 191

Перечень аббревиатур
и сокращений
АПК — аппаратно-программный комплекс
АС — автоматизированная система
АСУ — автоматизированная система управления
АСУТП — автоматизированная система управления технологическим
процессом
ВЭ — ведомость эксплуатационных документов
ГОСТ — государственный стандарт
ГСИ — государственная система обеспечения единства измерений
ГСМ — горючесмазочные материалы
ГСС — государственная система стандартизации
ЕСЗКС — единая система защиты от коррозии и старения
ЕСКД — единая система конструкторской документации
ЕСПД — единая система программной документации
ЕСТД — единая система технологической документации
ЖЦ — жизненный цикл
ЗИП — запасные части, инструмент и принадлежности
ИИ — извещение об изменении
ИЭ — инструкция по эксплуатации
ИСО — Международная организация по общей стандартизации
(ISO)
КД — конструкторская документация
КСАС — комплекс стандартов на автоматизированные системы
ЛР — лист регистрации изменений
МИ — методика измерений
МЭК — Международная электротехническая комиссия
(IEC)
НИОКР — научно-исследовательская и опытно-конструкторская
работа
НИР — научно-исследовательская работа

12 Перечень аббревиатур и сокращений
НТД — научно-техническая документация
ОКП — общероссийский классификатор продукции
ОКПО — общероссийский классификатор предприятий и организаций
ОКР — опытно-конструкторская работа
ОО — опытный образец
ОС — операционная система
ОТК — отдел технического контроля
ПД — программная документация
ПК — персональный компьютер
ПМ — программа и методика испытаний
ПО — программное обеспечение
ПП — программные продукты
ПС — паспорт
РД — ремонтная документация, руководящий документ
РКД — рабочая конструкторская документация
РО — руководство оператора
РЭ — руководство по эксплуатации
САПР — система автоматизированного проектирования
СВТ — средство вычислительной техники
СРПП — система разработки и постановки продукции на производство
ССИБИ — система стандартов по информации, издательству и библио-
Д течному делу
ТД — техническая документация, технические данные
ТЗ — техническое задание
ТЛД — технологическая документация
ТО — техническое обслуживание, техническое описание
ТУ — технические условия
ФЗ — Федеральный закон
ФО — формуляр
ЭВМ — электронная вычислительная машина
ЭД — эксплуатационная документация, электронный документ
ЭТ — этикетка
ЭЦП — электронная цифровая подпись

Введение
В настоящее время российская экономика ориентирована на разработку и
внедрение как на внутреннем, так и на внешнем рынке продукции высоких технологий,
включая разработку аппаратно-программных комплексов (АПК),
автоматизированных систем (АС) и программных продуктов (ПП). Существенно возросло
число отечественных предприятий, выполняющих научно-исследовательские и
опытно-конструкторские работы (НИОКР) по упомянутым направлениям.
Неотъемлемой частью любой НИОКР является разработка различной
технической документации (ТД). К сожалению, опытные специалисты в этой
сфере за годы экономической стагнации нашли другие области применения своих
талантов, а современные учебные заведения не готовят
инженеров-разработчиков ТД из числа молодежи. В связи с этим сегодня в России отсутствуют
какие-либо учебные пособия, посвященные разработке ТД.
Во многих отечественных разработках сегодня широко применяются
импортные составные части и комплектующие изделия, поставляемые с
технической документацией на иностранном языке. В то же время ни инженеры, ни
профессиональные переводчики в своем большинстве не знакомы с
принципами и правилами перевода, локализации, оформления и легализации переводов
иноязычных технических документов, информация о которых не обобщена и не
систематизирована.
Помимо того, произошедшие изменения в законодательстве о техническом
регулировании, сделавшие необязательным следование требованиям ГОСТ,
обобщивших лучший опыт советских времен, а также искусственно создаваемые
сложности свободного доступа к этим документам затруднили возможности
самообразования в области разработки и перевода технической документации.
В последние годы многие фирмы все чаще приглашают на работу
«технических писателей», называя этим модным словосочетанием разработчиков ТД на
различную продукцию — аппаратуру, автоматизированные системы и
программные продукты. И у молодежи, в свою очередь, возрос интерес к освоению этой
новой для них профессии.
Учебное пособие рассчитано на начальное образование молодых инженеров
и углубление знаний опытных разработчиков текстовой технической
документации на программно-управляемую аппаратуру, к которой относятся многие
современные устройства — от бытовых приборов до сложных измерительных
систем и систем контроля, на автоматизированные системы учета и управления
производственными процессами, на различные программные продукты. Пособие
также будет полезным для переводчиков и редакторов переводов иноязычной
технической документации.
Предполагается, что разработчик технической документации имеет
техническое образование, позволяющее ему четко понимать физическую сущность
происходящих в разрабатываемой аппаратуре и системах процессов и описывать

14 Введение
их на профессиональном уровне. В пособии практически не затрагиваются
вопросы стилистики и семантико-лингвистических правил изложения текста
документов, которым посвящены образовательные курсы для технических писателей,
разрабатывающих в основном текстовую документацию на программные
продукты, например: http://vvvvw.philosoftm/m/trainings.htrnl
или http://www.tBdivyoitBS.ru/kursy/.
Данное пособие предполагает необходимость самостоятельного
ознакомления обучающихся с основными рекомендуемыми нормативными документами,
которые либо являются приложением к пособию, либо имеют ссылку на
интернет-ресурсы, содержащие нужные документы, и ставит целью обратить
внимание обучающихся на основные положения этих документов.
Поскольку как сама техника, так и ее нормативная база не стоят на месте,
автор оставляет за собой право вносить в данное пособие соответствующие
коррективы и улучшения.
В конце каждой темы даются ссылки на информационные источники и
приводятся контрольные вопросы, ответы на которые позволяют проверить
качество усвоения изложенных материалов. Нормативные документы получены из
открытых сетевых источников, в связи с чем автор не несет ответственности за
их качество и полное соответствие тексту официальных документов.
Дополнительно обучающимся предоставляется возможность получить
электронные шаблоны основных текстовых документов в формате .DOC приложения
MS Word, которые являются электронным приложением к данному пособию.
Полезную информацию обучающиеся также могут почерпнуть из
следующих интернет-ресурсов, посвященных разработке и переводу технической
документации:
• http://authorit.ai/;
• http://www.philosoft.ru/;
• http://www.dOc.ru/;
• http://www.rugost.com/;
• http://www.trworkshop.net/;
• http://www.wordexpert.ru.
Автор выражает глубокую признательность инженеру А. Колесникову за
консультации и помощь в написании разделов по документации на
автоматизированные системы.
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу электронной
почты comp@piter.com (издательство «Питер», компьютерная редакция). Мы
будем рады узнать ваше мнение! Подробную информацию о наших книгах вы
найдете на веб-сайте издательства www.piter.com.

Общие сведения о промышленной
продукции технической
документации

16 Глава 1*0 промышленной продукции технической документации
1.1. Определения и термины. Жизненный цикл
промышленной продукции
Согласно ГОСТ 15.001-97. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения и ГОСТ Р
15.201-2000. Система разработки и постановки продукции на производство.
Продукция производственно-технического назначения. Порядок разработки
и постановки продукции на производство, промышленной продукцией
называют народнохозяйственную продукцию, изготовляемую для удовлетворения
потребностей народного хозяйства, населения и экспорта, и продукцию
производственно-технического назначения, предназначенную для использования в качестве
средств промышленного и сельскохозяйственного производства.
Основными отличиями промышленной продукции от других видов
продукции являются ее следующие особенности.
Промышленная продукция:
• разрабатывается на основе технического задания (ТЗ) и выполненного
в соответствии с ним проекта;
• изготавливается по разработанной в ходе проектирования технической
документации;
• подвергается испытаниям на соответствие основным заявляемым
характеристикам;
• принимается по результатам испытаний независимым лицом (органом).
В последующих материалах курса используются следующие термины и
определения.
Аппаратно-программный комплекс (АПК) — комплекс, в состав которого
входит аппаратура, управляемая с помощью программных средств,
являющихся неотъемлемой частью данного комплекса.
Аппаратура — изделие приборостроения.
Автоматизированная система (АС) — по ГОСТ 34.003-90: система,
состоящая из персонала и комплекса средств автоматизации, реализующая
информационную технологию выполнения установленных функций.
ПРИМЕЧАНИЕ
Несмотря на кажущуюся схожесть АПК и АС, между ними имеются следующие
принципиальные различия:
¦ в состав АПК персонал (пользователь) не входит. Он, в отличие от АС, находится вне
системы. Более того, полностью автоматизированный АПК может работать и без оператора. АС без
оператора работать не может;
¦ в АПК не реализуются информационные технологии выполнения установленных функций,
а решаются определенные инженерные задачи, например: прием и обработка сигналов по
заданным алгоритмам, измерения физических величин и т. п.;

1.1. Определения и термины. Жизненный цикл промышленной продукции 17
¦ аппаратная часть АС играет второстепенную роль и часто содержит только покупные
изделия, в то время как аппаратная часть АПК имеет столь же существенное значение, как и
программная. Довольно часто аппаратные средства АПК являются уникальными
изделиями собственной разработки, к которым предъявляются достаточно жесткие технические
требования, особенно — к их метрологическим параметрам.
Блок — часть устройства или самостоятельный функциональный узел,
включающий совокупность элементов, имеющую определенное функциональное
назначение, представляющий собой законченную конструкцию и имеющий
в своем составе функциональные узлы более низкого уровня иерархии
(модули, платы и т. д.).
Деталь — по ГОСТ 2.101-68: изделие, изготовленное из однородного по
наименованию и марке материала, без применения сборочных операций.
Документ — материальный носитель данных с записанной на нем
информацией, предназначенный для ее передачи во времени и в пространстве.
ПРИМЕЧАНИЕ
Документ, выполненный с применением средств автоматического проектирования,
рассматривается как база данных.
Изделие — любой материальный объект, изготовленный на предприятии.
Изделие основного производства — изделие, предназначенное для поставки
(реализации).
Изделие вспомогательного производства — изделие, предназначенное
только для собственных нужд предприятия. Изделие, предназначенное для
поставки (реализации) и одновременно используемое предприятием для собственных
нужд, относится к изделию основного производства.
Интеллектуальный продукт — материализовавшиеся либо нашедшие
объективную форму выражения результаты интеллектуальных усилий
сотрудников предприятия.
ПРИМЕЧАНИЕ
К интеллектуальным продуктам относятся, в частности, базы данных (техническая
документация, созданная с применением средств автоматического проектирования) и программы.
Комплекс — по ГОСТ 2.101-68: два и более специфицированных изделия
(имеющие составные части), не соединенные на предприятии-изготовителе
сборочными операциями, но предназначенные для выполнения взаимосвязанных
эксплуатационных функций и составляющие в функциональном отношении
единое целое.
Комплект — по ГОСТ 2.101-68: два и более изделия, не соединенные на
предприятии-изготовителе сборочными операциями и представляющие набор
изделий, имеющих общее эксплуатационное назначение вспомогательного
характера.
Модуль — часть блока или самостоятельный функциональный узел,
включающий совокупность элементов, имеющую определенное функциональное
назначение, представляющий собой законченную конструкцию и имеющий

18 Глава 1 • О промышленной продукции технической документации
в своем составе функциональные узлы более низкого уровня иерархии (платы
и т. д.).
Плата — часть модуля или самостоятельный конструктив, содержащий
единственную печатную плату с вмонтированными в нее электрорадиоэлементами
или функциональными узлами.
Прибор — часть устройства или самостоятельный функциональный узел,
включающий в себя совокупность элементов, имеющую самостоятельное
функциональное назначение, представляющий собой законченную конструкцию
и имеющий в своем составе функциональные узлы более низкого уровня
иерархии (блоки, модули, платы и т. д.).
Программа — объективная форма представления совокупности данных и
команд, предназначенных для функционирования ЭВМ и других компьютерных
устройств с целью получения определенного результата, а также
подготовительные материалы, полученные в ходе ее разработки, и порождаемые
программой аудиовизуальные отображения.
Продукция — совокупность материальных и нематериальных результатов
труда работников предприятия (обработки, переработки, исследования).
Руководство предприятия — генеральный директор и его заместители.
Сборочная единица — по ГОСТ 2.101-68: изделие, составные части
которого подлежат соединению между собой на предприятии-изготовителе
сборочными операциями.
Система — совокупность сборочных единиц, комплектов, деталей, программ,
находящихся в отношениях и связях друг с другом, имеющая самостоятельное
функциональное назначение.
Товарная продукция — продукция, произведенная для продажи.
Узел — часть машины, механизма, установки и т. п., состоящая из
нескольких более простых элементов (деталей).
Устройство — с учетом ГОСТ 2.701-84 — сборочная единица, имеющая
определенное функциональное назначение, представляющая собой единую
конструкцию и имеющая в своем составе функциональные узлы более низкого
уровня иерархии (блоки, модули, детали и т. д.).
Согласно ГОСТ Р 15.000-94. Система разработки и постановки
продукции на производство. Основные положения, жизненный цикл (ЖЦ)
промышленной продукции в общем случае включает в себя следующие стадии:
• исследования — разработка технического задания (ТЗ) на проведение
научно-исследовательских работ (НИР) и выполнение НИР в соответствии
с ГОСТ 15.101-98. Система разработки и постановки продукции на
производство. Порядок выполнения научно-исследовательских работ;
• разработка ТЗ на выполнение опытно-конструкторской работы (ОКР)
в соответствии с ГОСТ Р 15.201-2000. Система разработки и
постановки продукции на производство. Продукция
производственно-технического назначения. Порядок разработки и постановки продукции на
производство;
• ОКР в соответствии с ГОСТ Р 15.201-2000. Система разработки и
постановки продукции на производство. Продукция производственно-тех-

1.1. Определения и термины. Жизненный цикл промышленной продукции 19
нического назначения. Порядок разработки и постановки продукции на
производство, включающая:
• выполнение эскизного, технического и рабочего проектирования по
созданию рабочей конструкторской документации (РКД) на опытный
образец (ОО);
• изготовление опытных образцов;
• испытания опытных образцов (предварительные и приемочные) в
соответствии с ГОСТ 15.309-98. Система разработки и постановки
продукции на производство. Испытания и приемка выпускаемой продукции.
Основные положения;
• корректировку РКД по результатам испытаний;
• приемку результатов ОКР в соответствии с ГОСТ 15.309-98. Система
разработки и постановки продукции на производство. Испытания и
приемка выпускаемой продукции. Основные положения;
• постановка на производство в соответствии с ГОСТ Р 15.201-2000.
Система разработки и постановки продукции на производство. Продукция
производственно-технического назначения. Порядок разработки и
постановки продукции на производство, включающая в себя:
• подготовку производства;
• освоение производства;
• изготовление установочной серии;
• квалификационные испытания (периодические и типовые) в
соответствии с ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции.
Основные положения;
• единичное (повторяющееся, серийное, массовое) производство;
• передача в эксплуатацию (поставка);
• эксплуатация (применение, хранение);
• ремонт в соответствии с ГОСТ 15.601-98. Система разработки и
постановки продукции на производство. Техническое обслуживание и ремонт
техники;
• снятие с производства и утилизация.
Отдельные стадии ЖЦ для конкретных видов продукции могут
отсутствовать или быть объединены друг с другом.
Информационные источники
ГОСТ 2.101-68. Единая система конструкторской документации (ЕСКД). Виды
изделий.
ГОСТ 2.701-84. Единая система конструкторской документации (ЕСКД).
Схемы, виды и типы. Общие требования к выполнению.
ГОСТ Р 15.000-94. Система разработки и постановки продукции на
производство. Основные положения.

20 Глава 1*0 промышленной продукции технической документации
ГОСТ 15.001-97. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
ГОСТ 15.101-98. Система разработки и постановки продукции на
производство. Порядок выполнения научно-исследовательских работ.
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
Порядок разработки и постановки продукции на производство.
ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции. Основные
положения.
ГОСТ 15.601-98. Система разработки и постановки продукции на
производство. Техническое обслуживание и ремонт техники.

1.2. Стандартизация в промышленном производстве 21
1.2. Стандартизация в промышленном
производстве. Современное российское
законодательство о техническом
регулировании. Основные системы
государственных стандартов России
и бывшего СССР
Необходимость стандартизации и унификации при производстве
промышленной продукции и даже в повседневной жизни трудно переоценить. Для этого
достаточно вспомнить, как совсем недавно мы пытались включать импортную
технику в электрические розетки советских времен. Стандартизация
производства дает значительный экономический эффект, который оценивается рядом
зарубежных экспертов в 1 % внутреннего валового продукта страны.
История стандартизации восходит корнями к Древнему Египту, когда при
строительстве пользовались кирпичами постоянного стандартного размера;
при этом контролем размеров кирпичей занимались специальные чиновники.
Стандартизация в той или иной степени развивалась во всех странах по мере
развития в них промышленного производства, но, прежде всего, внутри
отдельных фирм и предприятий.
В большинстве промышленно развитых зарубежных стран
стандартизацией занимались и занимаются неправительственные организации —
ассоциации, общества, институты, членами которых являются фирмы, компании,
торговые корпорации и частные лица. Подавляющее большинство
национальных зарубежных стандартов не имеют законодательной силы, за исключением
стандартов по технике безопасности, здравоохранению и защите окружающей
среды.
Первые сведения о стандартизации в России относятся к 1555 году. При
Иване Грозном специальным указом были установлены постоянные размеры
пушечных ядер и введены калибры для проверки этих размеров. В 1904 году
были установлены стандарты на вагоны и другие изделия, применяемые в
железнодорожном транспорте. Однако в царской России стандартизация далее
отдельных предприятий и ведомств не продвинулась.
После революции 1917 года национальная система стандартизации в нашей
стране получила государственный статус. 15 сентября 1925 года Постановлением
Совета Народных Комиссаров СССР был создан Комитет по стандартизации
при Совете Труда и Обороны (СТО). Название этого органа часто менялось
(наиболее известное из них — Госстандарт СССР), менялись и его задачи.
Основными задачами стандартизации в СССР были:
• установление требований к техническому уровню и качеству продукции,
сырья, материалов, полуфабрикатов и комплектующих изделий;

22 Глава 1*0 промышленной продукции технической документации
• установление норм, требований и методов в области проектирования и
производства продукции, позволяющих обеспечить их оптимальное
качество и ликвидировать нерациональное многообразие видов, марок и
типоразмеров;
• повышение эффективности эксплуатации и ремонта изделий;
• обеспечение единства и достоверности измерений в стране, создание и
совершенствование государственных эталонов единиц физических величин,
а также методов и средств измерений высшей точности;
• установление унифицированных систем документации, систем
классификации и кодирования технико-экономической информации;
• установление единых терминов и обозначений в важнейших областях
науки, техники, в отраслях народного хозяйства;
• установление системы стандартов безопасности труда.
К началу 1975 года в нашей стране действовало более 20 тыс. государственных
стандартов (ГОСТ) и более 15 тыс. отраслевых стандартов (ОСТ). Начиная
с 1968 года и вплоть до распада СССР были созданы и внедрены межотраслевые
системы стандартов общегосударственного значения: Единая система
конструкторской документации (ЕСКД), Единая система технологической
подготовки производства (ЕСТПП), Единая система классификации и кодирования
технико-экономической информации и др.
После распада Советского Союза в 1991 году Госстандарт СССР был
преобразован в Госстандарт России, была пересмотрена государственная политика в
отношении стандартизации, которая сместилась в направлении опыта зарубежных
стран, что нашло отражение в Федеральном законе от 27 декабря 2002 г.
№ 184-ФЗ «О техническом регулировании». Госстандарт России в 2004 году
был преобразован в Федеральное агентство по техническому регулированию
и метрологии («Ростехрегулирование»).
Суть нового закона состоит в том, чтобы полностью изменить
существующую систему стандартизации продукции и процессов производства, а именно
заменить обязательную стандартизацию добровольной.
Закон вводит два уровня требований к продукции, процессам (методам)
производства, эксплуатации, хранения, перевозки, реализации и утилизации:
• первый уровень — технические регламенты;
• второй уровень — стандарты.
Технические регламенты принимаются только в целях защиты жизни,
здоровья физических лиц, имущества физических или юридических лиц,
государственного или муниципального имущества, охраны окружающей среды, в том
числе жизни и здоровья животных или растений, а также в целях
предотвращения введения в заблуждение потребителей продукции. Принятие технических
регламентов в иных целях не допускается. Технические регламенты
принимаются международными договорами, ратифицируемыми в установленном
порядке, федеральными законами и постановлениями Правительства.
Технические регламенты являются обязательными для исполнения.
Стандарты носят добровольный характер. Могут применяться российские
и зарубежные стандарты, утвержденные национальным органом по стандарта-

1.2. Стандартизация в промышленном производстве 23
зации, международные стандарты, стандарты организаций. Добровольно могут
применяться как действующие стандарты бывшего СССР (ГОСТ), так и вновь
разработанные и действующие стандарты России (ГОСТ Р).
Кратко о международных стандартах. По мере развития сотрудничества
разных стран международная стандартизация стала приобретать все большее
значение. Так, в 1906 году была основана Международная электротехническая
комиссия по стандартизации в области электрических, электронных и смежных
технологий (IEC — МЭК). Первая международная организация по общей
стандартизации (ISO — ИСО) была учреждена в 1946 г. МЭК и ИСО разработан ряд
международных стандартов, которые также могут добровольно применять
предприятия-разработчики. Здесь следует заметить, что сегодня некоторым
национальным стандартам присвоен статус стандартов ИСО и МЭК.
Основными системами стандартов, действующими в настоящее время и
относящимися к разработке промышленной продукции и документации на нее,
которые могут добровольно применять разработчики и производители
продукции, являются следующие системы стандартов России и бывшего СССР:
ГСС — Государственная система стандартизации (ГОСТ 1).
ЕСКД — Единая система конструкторской документации (ГОСТ 2).
ЕСТД — Единая система технологической документации (ГОСТ 3).
ССИБИД — Система стандартов по информации, библиотечному и
издательскому делу (ГОСТ 7).
ГСИ — Государственная система обеспечения единства измерений (ГОСТ 8).
ЕСЗКС — Единая система защиты от коррозии и старения (ГОСТ 9).
СРПП — Система разработки и постановки продукции на производство
(ГОСТ 15).
ЕСПД — Единая система программной документации (ГОСТ 19).
КСАС — Информационные технологии. Комплекс стандартов на
автоматизированные системы (ГОСТ 34).
Информационные источники
Федеральный закон РФ от 27 декабря 2002 г. № 184-ФЗ «О техническом
регулировании» — http://www.garant.ai/law/12029354-000.htm.
ГОСТ (Р) 1 -... Государственная система стандартизации (ГСС) —
http://www.pntdoc.ai/goststp.html.
ГОСТ 2 -... Единая система конструкторской документации (ЕСКД) —
http://www.elecab.ai/norm/?c= 10.
ГОСТ 3 -... Единая система технологической документации (ЕСТД) —
http://gosts.org/downloads_gost3.php.
ГОСТ 7 -... Система стандартов по информации, библиотечному и
издательскому делу (ССИБИД) — http://www.csrs.ai/gost/7.htm.
ГОСТ (Р) 8 -... Государственная система обеспечения единства
измерений (ГСИ) — http://www.gosthelp.aj/home/download.php?list.6.
ГОСТ 9 -... Единая система защиты от коррозии и старения (ЕСЗКС) —
http://gosts.org/downloads_gost9.php.

24 Глава 1*0 промышленной продукции технической документации
ГОСТ (Р) 15 -... Система разработки и постановки продукции на
производство (СРПП) — http://gosts.ong/downloads_gostl5.php.
ГОСТ 19 -... Единая система программной документации (ЕСПД) —
http://www.elecab.ru/norm/7csll.
ГОСТ 34 -... Информационные технологии. Комплекс стандартов на
автоматизированные системы (КСАС) — http://www.nistru/hr/doc/gost/gost34.htm.
Дополнительные интернет-ресурсы по всем упомянутым выше
информационным источникам:
http://gosts.org/downloads.php, http://www.allgost.ru/, http://www.pntd.ru/.

1.3. Система разработки и постановки продукции на производство (СРПП) 25
1.3. Система разработки и постановки продукции
на производство (СРПП). Стадии разработки
промышленной продукции. Место и роль ТД
при разработке, производстве, эксплуатации
и ремонте промышленной продукции.
Классификация ТД
Порядок разработки и постановки на производство промышленной
продукции общего назначения, включая АПК, АС .и ПП, определяется комплексом
ГОСТ 15. Система разработки и постановки продукции на производство (СРПП).
В состав комплекса входят следующие основные стандарты:
ГОСТ Р 15.000-94. Система разработки и постановки продукции на
производство. Основные положения.
ГОСТ 15.001-97. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
ГОСТ 15.005-86. Система разработки и постановки продукции на
производство. Создание изделий единичного и мелкосерийного производства,
собираемых на месте эксплуатации.
ГОСТ 15.007-88. Система разработки и постановки продукции на
производство. Продукция легкой промышленности.
ГОСТ 15.009-91. Система разработки и постановки продукции на
производство. Непродовольственные товары народного потребления.
ГОСТ Р 15.011-96. Система разработки и постановки продукции на
производство. Патентные исследования. Содержание и порядок проведения.
ГОСТ 15.012-84. Система разработки и постановки продукции на
производство. Патентный формуляр.
ГОСТ Р 15.013-94. Система разработки и постановки продукции на
производство. Медицинские изделия.
ГОСТ 15.101-98. Система разработки и постановки продукции на
производство. Порядок выполнения научно-исследовательских работ.
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на произ-,
водство. Продукция производственно-технического назначения. Порядок
разработки и постановки продукции на производство.
ГОСТ 15.214-90. Система разработки и постановки продукции на
производство. Народнохозяйственная продукция, поставляемая организациям
Министерства обороны СССР.
ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции. Основные
положения.
ГОСТ 15.311-90. Система разработки и постановки продукции на
производство. Постановка на производство продукции по технической
документации иностранных фирм.

26 Глава 1 • О промышленной продукции технической документации
ГОСТ 15.601-98. Система разработки и постановки продукции на
производство. Техническое обслуживание и ремонт техники.
ГОСТ 15.901-91. Система разработки и постановки продукции на
производство. Конструкции, изделия и материалы строительные.
Стадии разработки промышленной продукции
производственно-технического назначения определены ГОСТ 15.001-97. Система разработки и
постановки продукции на производство. Продукция
производственно-технического назначения. Для автоматизированных систем стадии разработки
АС определены ГОСТ 34.601-90. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Стадии создания,
гармонизированным с упомянутым стандартом СРПП. Согласно обоим
стандартам стадии разработки полностью соответствуют стадиям ЖЦ промышленной
продукции:
• разработка технического задания (которой предшествует проведение
научных исследований для АПК, формирование требований для АС и
разработка концепции ее создания);
• разработка технической документации — проектной в рамках эскизного
и технического проектов, рабочей конструкторской документации (РКД),
рабочей документации на АС, программной (ПД) и технологической (ТЛД)
документации в рамках рабочего проекта;
• изготовление и испытания образцов продукции;
• приемка результатов разработки;
• подготовка и освоение производства (для АС последние три стадии
объединены в одну под названием «ввод в действие»);
• эксплуатация изделия (сопровождение изделия для АС).
Разработка народнохозяйственной промышленной продукции
выполняется по той же схеме, однако в целях защиты прав и здоровья потребителей при
определении характеристик этой продукции в ТЗ и проведении ее испытаний
выдвигаются дополнительные требования по обеспечению безопасности для
жизни и здоровья населения и охране окружающей среды.
Основные положения по разработке технического задания,
конструкторской и рабочей документации, приемке результатов разработки, подготовке
и освоению производства, испытаниям опытных образцов продукции и
продукции, изготовленной при освоении производства, а также по подтверждению их
соответствия обязательным требованиям также сформулированы в ГОСТ Р
15.201-2000. Система разработки и постановки продукции на производство.
Продукция производственно-технического назначения. Порядок разработки
и постановки продукции на производство.
На любой стадии разработки промышленной продукции предприятия
создается и (или) используется та или иная техническая документация. Роль ТД
трудно переоценить. Без технической документации невозможны ни
производство промышленной продукции, ни ее эксплуатация и ремонт.
Разработчик ТД должен ясно понимать назначение каждого вида ТД,
представлять целевую аудиторию пользователей этой документации и
разрабатывать документацию с учетом этих знаний. Техническое задание, к примеру,

1.3. Система разработки и постановки продукции на производство (СРПП) 27
определяет технические характеристики будущего изделия и порядок его
разработки. Им будут пользоваться разработчики изделия. В технических
условиях (ТУ) на АПК приводятся основные технические характеристики изделия,
достигнутые по результатам его проектирования, и определяется порядок
приемки продукции. Им будут пользоваться разработчики и производители изделия.
Руководство по эксплуатации (РЭ) АПК также содержит основные
характеристики производимого изделия и порядок работы с ним. Для продукции
производственно-технического назначения пользоваться РЭ будут технические
специалисты, а для народнохозяйственной продукции — простые обыватели.
Аналогичным образом различно назначение рабочей и эксплуатационной
документации, разрабатываемой на программные продукты и автоматизированные
системы. По этой причине язык и стиль изложения различных документов
должен соответствовать техническому уровню их пользователей.
Техническая документация является интеллектуальным продуктом и
составной частью промышленной продукции предприятия.
Напомним, что интеллектуальным продуктом называют
материализовавшиеся либо нашедшие объективную форму выражения результаты
интеллектуальных усилий сотрудников предприятия. Интеллектуальные продукты, созданные
в порядке выполнения производственного задания, являются
нематериальными объектами интеллектуальной собственности предприятия, к которым, в
частности, относятся:
• изобретения, полезные модели и промышленные образцы;
• товарные знаки, знаки обслуживания, наименования мест происхождения
товаров;
• программы для ЭВМ и базы данных;
• топологии интегральных микросхем;
• секреты производства (ноу-хау).
Под документацией понимается материальный носитель данных
(бумажный, электронный и пр.) с записанной на нем информацией, причем
документация, разработанная с применением средств автоматического проектирования,
рассматривается как база данных. Поскольку базы данных и секреты
производства (ноу-хау), информация о которых содержится в разрабатываемой
технической документации, относятся к интеллектуальным продуктам, ТД является
интеллектуальным продуктом предприятия.
Нематериальные объекты собственности вполне полноценны в
хозяйственном отношении. Они имеют стоимость, включаемую в состав затрат на
производство, с ними могут совершаться сделки купли-продажи, а потому они ничем не
отличаются от материальных объектов хозяйственной деятельности
предприятия. Таким образом, ТД как интеллектуальный продукт обоснованно является
составной частью промышленной продукции предприятия.
К технической документации на промышленную продукцию относится
следующая документация:
• технические задания;
• программная документация;

28 Глава 1 • О промышленной продукции технической документации
• КД на АПК и рабочая документация на АС:
• собственно КД на АПК и рабочая документация на АС;
• эксплуатационная документация;
• ремонтная документация;
• технологическая документация.
Виды конструкторской, эксплуатационной, ремонтной, программной и
технологической документации для АПК определены соответствующими
стандартами ЕСКД, ЕСПД и ЕСТД, а рабочей документации на АС — стандартами
КСАС.
Информационные источники
ГОСТ (Р) 15 —... Система разработки и постановки продукции на
производство (СРПП) — http://gosbs.org/downloadsjgostl5.php.
Гражданский кодекс Российской Федерации. Статья 138.
Интеллектуальная собственность — http://www.a)nsultantoi/popular/gkrfl/5_20.html#pl296.
Закон РФ «О правовой охране программ для ЭВМ и баз данных» от 23.09.92
№ 3523-1 - http://www.patentoved.com/content.php?id=55.

Основные сведения
о Государственной
системе обеспечения
единства измерений (ГСИ).
Сертификация промышленной
продукции

30 Глава 2 • Основные сведения о ГСИ
Разработчик технической документации на аппаратно-программные
комплексы должен знать основные принципы измерений и системы единиц физических
величин, основы законодательной и нормативной базы по обеспечению
единства измерений, изложенные в комплексе стандартов ГОСТ (Р) 8 -...
Государственная система обеспечения единства измерений (ГСИ). Ниже приводятся
основные стандарты ГСИ, используемые при разработке ТД:
ГОСТ Р 8.000-2000. ГСИ. Основные положения.
ГОСТ 8.395-80. ГСИ. Нормальные условия измерений при поверке.
Общие требования.
ГОСТ 8.401-80. ГСИ. Классы точности средств измерений. Общие
требования.
ГОСТ 8.417-2002. ГСИ. Единицы физических величин.
ГОСТ 8.508-84. ГСИ. Метрологические характеристики средств
измерений и точностные характеристики средств автоматизации ГСП. Общие
методы оценки и контроля.
ПРИМЕЧАНИЕ
ГСП — Государственная система промышленных приборов и средств автоматизации по
ГОСТ 12997-76.
ГОСТ Р 8.563-96. ГСИ. Методики выполнения измерений.
Помимо стандартов ГСИ часто оказываются полезными некоторые другие
стандарты и иные нормативные документы ГСИ, например следующие:
ГОСТ Р 51672-2000. Метрологическое обеспечение испытаний
продукции для целей подтверждения соответствия.
МИ 2267-2000. ГСИ. Обеспечение эффективности измерений при
управлении технологическими процессами. Метрологическая экспертиза
технической документации.
МИ 2377-98. ГСИ. Рекомендация. Разработка и аттестация методик
выполнения измерений.
МИ 2440-97. ГСИ. Рекомендация. Методы экспериментального
определения и контроля характеристик погрешности измерительных каналов,
измерительных систем и измерительных комплексов.
МИ 2441-97. ГСИ. Рекомендация. Испытания для целей утверждения типа
измерительных систем. Общие требования.
МИ 2091-90. ГСИ. Рекомендация. Измерение физических величин. Общие
требования.
МИ 2222-92. ГСИ. Виды измерений, классификация.
МИ 2439-97. ГСИ. Рекомендация. Метрологические характеристики
измерительных систем. Номенклатура. Принципы регламентации,
определения и контроля.
ПР 50.2.009. ГСИ. Порядок проведения испытаний и утверждения типа
средств измерений.
РМГ 29-99. ГСИ. Метрология. Основные термины и определения.
Из всех приведенных нормативных документов стоит обратить особое
внимание на следующие документы:
ГОСТ Р 8.000-2000. ГСИ. Основные положения.

Основные сведения о ГСИ 31
В стандарте, в частности, излагаются правовые основы ГСИ,
устанавливающие согласованные требования к следующим взаимосвязанным объектам
деятельности по обеспечению единства измерений:
• совокупности узаконенных единиц величин и шкал измерений;
• терминологии в области метрологии;
• воспроизведению и передаче размеров единиц величин и шкал измерений;
• способам и формам представления результатов измерений и
характеристик их погрешности;
• методам оценивания погрешности и неопределенности измерений;
• порядку разработки и аттестации методик выполнения измерений;
• комплексам нормируемых метрологических характеристик средств
измерений;
• порядку проведения поверки и калибровки средств измерений;
• порядку осуществления метрологического контроля и надзора;
• методикам выполнения измерений.
РМГ 29-99. ГСИ. Метрология. Основные термины и определения.
В данном документе приведены термины и определения, касающиеся
метрологии и ее разделов, физических величин, измерений и единиц измерений
физических величин, средств измерительной техники, принципов, методов и
методик измерений, результатов измерений физических величин, погрешности
измерений и средств измерений, условий измерений, эталонов единиц
физических величин. Приведен алфавитный указатель терминов на русском языке.
ГОСТ 8.417-2002. ГСИ. Единицы физических величин.
Согласно подразделу 1.1 этого стандарта в технической документации
подлежат обязательному применению единицы Международной системы единиц
(СИ), а также десятичные кратные и дольные от них.
В табл. 1-5 стандарта приводятся основные, дополнительные и
производные единицы системы СИ, их правильные сокращения на русском языке и для
международного применения; в табл. 6 и 7 — единицы, не входящие в систему
СИ, но допускаемые к использованию; в табл. 8 — правила образования
десятичных кратных и дольных единиц, их наименования и обозначения.
Раздел 5 стандарта посвящен правилам написания обозначений единиц в
текстовой документации.
С обеспечением единства измерений тесно смыкается вопрос о
сертификации промышленной продукции. Основным нормативным документом по
сертификации является Федеральный закон РФ от 10 июня 1993 г. № 5151-1 (ред. от
10.01.2003).
Сертификация — это процедура подтверждения соответствия, посредством
которой независимая от изготовителя (продавца, исполнителя) и потребителя
(покупателя) организация (орган по сертификации, аккредитованный
соответствующими министерствами и ведомствами, см. http://megasert.ai) удостоверяет
в письменной форме тот факт, что продукция соответствует установленным
требованиям (стандартам, ТУ и пр.).

32 Глава 2 • Основные сведения о ГСИ
Сертификат соответствия — это официальный документ органа по
сертификации, в котором зафиксировано, что продукция (объект сертификации)
соответствует определенным требованиям (качества, безопасности и т. д.).
Сертификация бывает обязательная и добровольная.
Обязательной сертификации подлежат детские товары, строительные
материалы, хозяйственные товары и ряд других. Вся остальная продукция может
быть подвергнута только добровольной сертификации.
Сама сертификация, если не вдаваться в мелочи, зиждется на одном-единст-
венном ките: проведении независимых испытаний продукции. Испытания
проводятся в аккредитованной лаборатории, выдающей протокол испытаний. Это
и есть основной документ, на основании которого органом по сертификации
выдается сертификат.
Информационные источники
ГОСТ (Р) 8 —... Государственная система обеспечения единства
измерений (ГСИ) — http://wvw.gosthelp.ru/home/download.php?list.6.
Федеральный закон РФ от 27 декабря 2002 г. № 184-ФЗ «О техническом
регулировании» — http://www.garant.ru/law/12029354-000.htm.
Федеральный закон РФ от 10 июня 1993 г. № 5151-1 (ред. от 10.01.2003)
«О сертификации продуктов и услуг» — http://www.consultant.ru/popular/sertif.

Единая система конструкторской
документации (ЕСКД)
как базовая система стандартов
для разработки ТД

34 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
3.1. Виды изделий. Классификация и иерархия
типовой промышленной продукции
Виды изделий определены ГОСТ 2.101-68. Единая система конструкторской
документации (ЕСКД). Виды изделий.
Согласно разделу 4 этого стандарта устанавливаются следующие виды
изделий:
• детали;
• сборочные единицы;
• комплексы;
• комплекты.
Определения видов изделий было дано в первой главе в общей
терминологии. Напомним эти определения.
Деталь — изделие, изготовленное из однородного по наименованию и марке
материала, без применения сборочных операций.
Сборочная единица — изделие, составные части которого подлежат
соединению между собой на предприятии-изготовителе сборочными операциями.
Комплекс — два и более специфицированных изделия (имеющие составные
части), не соединенные на предприятии-изготовителе сборочными
операциями, но предназначенные для выполнения взаимосвязанных эксплуатационных
функций и составляющие в функциональном отношении единое целое.
Комплект — два и более изделия, не соединенные на
предприятии-изготовителе сборочными операциями и представляющие собой набор изделий, имеющих
общее эксплуатационное назначение вспомогательного характера.
Виды изделий и их структура представлены на рис. 1.
1
Детали
—
1
Сборочные
единицы
Сборочные
единицы
Детали
Комплекты
Изделия
1
Комплексы
Комплексы
Сборочные
единицы
Детали
Комплекты
—
1
Комплекты
Сборочные
единицы
Детали
Комплекты
Рис 1. Виды изделий и их структура

3.1. Виды изделий. Классификация и иерархия 35
Классификация и иерархия типовой промышленной продукции
представлена на рис. 2.
I_
п
1
1J
I
X
Рис 2. Классификация и иерархия типовой промышленной продукции

36 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
В соответствии с приведенной классификацией автоматизированную систему
можно считать особым видом аппаратно-программного комплекса.
Информационные источники
ГОСТ 2.101-68. Единая система конструкторской документации (ЕСКД).
Виды изделий.

3.2. Виды, обозначение и комплектность КД на АПК и ТД на АС 37
3.2. Виды, обозначение и комплектность КД
на АПК и ТД на АС. Типовой состав текстовой
ТД и общие правила ее оформления
Виды конструкторской документации на АПК определены ГОСТ 2.102-68.
Единая система конструкторской документации. Виды и комплектность
конструкторских документов.
К конструкторским документам относят графические и текстовые
документы, которые в отдельности или в совокупности определяют состав и устройство
изделия и содержат необходимые данные для его разработки или изготовления,
контроля, приемки, эксплуатации и ремонта.
Документы подразделяют на виды, указанные в табл. 1 упомянутого
стандарта. Оставив за рамками рассмотрения графические документы (чертежи
и схемы), перечислим виды текстовых конструкторских документов,
содержащих в основном текст.
Спецификация — документ, определяющий состав сборочной единицы,
комплекса или комплекта.
Ведомость — документ, содержащий какой-либо перечень.
Пояснительная записка — документ, содержащий описание устройства и
принципа действия разрабатываемого изделия, а также обоснование принятых
при его разработке технических и технико-экономических решений.
Технические условия — документ, содержащий требования (совокупность
всех показателей, норм, правил и положений) к изделию, его изготовлению,
контролю, приемке и поставке, которые нецелесообразно указывать в других
конструкторских документах.
Программа и методика испытаний — документ, содержащий технические
данные, подлежащие проверке при испытании изделий, а также порядок и
методы их контроля.
Таблица — документ, содержащий в зависимости от его назначения
соответствующие данные, сведенные в таблицу.
Расчет — документ, содержащий расчеты параметров и величин, например:
расчет размерных цепей, расчет на прочность и др.
Эксплуатационные документы — документы, предназначенные для
использования при эксплуатации, обслуживании и ремонте изделия в процессе
эксплуатации.
Ремонтные документы — документы, содержащие данные для проведения
ремонтных работ на специализированных предприятиях.
Инструкция — документ, содержащий указания и правила, используемые
при изготовлении изделия (сборке, регулировке, контроле, приемке и т. п.).
Документы в зависимости от стадии разработки подразделяются на
проектные (техническое предложение, эскизный проект и технический проект) и
рабочие (рабочая документация).

38 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
Среди всех видов КД выделяют основной конструкторский документ.
Основным конструкторским документом называют такой, который полностью и
однозначно определяет данное изделие и его состав. За основной
конструкторский документ принимают: для деталей — чертеж детали, для сборочных
единиц, комплексов и комплектов — спецификацию.
В табл. 2 ГОСТ 2.102-68. Единая система конструкторской документации.
Виды и комплектность конструкторских документов даны определения
конструкторских документов в зависимости от способа их выполнения и характера
использования.
Оригиналы — документы, выполненные на любом материале и
предназначенные для изготовления по ним подлинников.
Подлинники — документы, заверенные подлинными установленными
подписями и выполненные на любом материале, позволяющем многократное
воспроизведение с них копий. Допускается в качестве подлинника использовать
оригинал, репрографическую копию или экземпляр документа, изданного
типографским способом, завизированные подлинными подписями лиц,
разработавших данный документ и ответственных за нормоконтроль.
Дубликаты — копии подлинников, обеспечивающие идентичность
воспроизведения подлинника, выполненные на любом материале, позволяющем снимать
с них копии.
Копии — документы, выполненные способом, обеспечивающим их
идентичность с подлинником (дубликатом), и предназначенные для непосредственного
использования при разработке, в производстве, эксплуатации и ремонте изделий.
Виды технической документации на АС определены ГОСТ 34.201-89.
Комплекс стандартов на автоматизированные системы. Виды, комплектность и
обозначение документов при создании автоматизированных систем.
ТД на АС, как и КД на АПК, в зависимости от стадии разработки
подразделяется на предпроектную и проектную (стадии исследования и обоснования
создания АС, техническое задание, эскизный проект и технический проект)
и рабочую (стадия разработки рабочей документации).
В состав ТД на АС, так же как и в состав КД на АПК, входят графические
и текстовые документы, которые по отдельности или в совокупности
определяют состав и устройство изделия и содержат необходимые данные для его
разработки или изготовления, контроля, приемки, эксплуатации и ремонта.
Документы подразделяют на виды, указанные в табл. 1 и 2 упомянутого
стандарта. Оставив за рамками рассмотрения графические и проектно-сметные
рабочие документы, перечислим виды текстовой ТД на АС, содержащей в
основном текст.
Ведомость (код документа «В») — перечисление в систематизированном
виде объектов, предметов и т. д.
Инструкция (код документа «И») — изложение состава действий и правил
их выполнения персоналом.
Обоснование (код документа «Б») — изложение сведений,
подтверждающих целесообразность принимаемых решений.
Описание (код документа «П») — пояснение назначения системы, ее частей,
принципов их действия и условий применения.

3.2. Виды, обозначение и комплектность КД на АПК и ТД на АС 39
Конструкторский документ - по ГОСТ 2.102-68.
Программный документ - по ГОСТ 19.101-77.
Порядок обозначения конструкторских документов на АПК определен
ГОСТ 2.201-80. Единая система конструкторской документации.
Обозначение изделий и конструкторских документов.
В соответствии с данным стандартом каждому изделию должно быть
присвоено обозначение. Обозначение изделия является одновременно обозначением
его основного конструкторского документа (чертежа детали или
спецификации). Изделия и конструкторские документы сохраняют присвоенное им
обозначение независимо от того, в каких изделиях и конструкторских документах
они применяются. Обозначение должно быть указано на каждом листе
конструкторского документа, выполненного на нескольких листах.
Устанавливается следующая структура обозначения изделия и основного
конструкторского документа АПК (рис. 3):
хххх хххххх ххх
Код организации разработчика |
Код классификационной характеристики
Порядковый регистраци
Рис 3. Структура обозначения изделия и основного конструкторского документа АПК
Четырехзначный буквенный код организации-разработчика обычно
присваивается централизованно. Для этого следует обратиться, например, в Центр
научно-технических исследований, сертификации и постановки продукции на
производство (ЦНТИСиП): http://www.cntisip.ru/usl/opgcode.htm.
Код классификационной характеристики присваивают изделию и
конструкторскому документу непосредственно в организации-разработчике по
классификатору изделий и конструкторских документов машиностроения и
приборостроения (классификатору ЕСКД). На сегодняшний день наиболее
полную версию классификатора ЕСКД можно приобрести в компании «Аскон»:
http://www.kompas.asc^ В бесплатном
доступе имеются кодификаторы лишь отдельных классов ЕСКД.
Порядковый регистрационный номер присваивают от 001 до 999 в
организации-разработчике.
Обозначение неосновного конструкторского документа АПК должно
состоять из обозначения изделия и кода документа, установленного
стандартами ЕСКД (рис. 4):
ХХХ.ХХХХХХ.ХХХХХХХ
Обозначение изделия
Код документа
Рис 4. Обозначение неосновного конструкторского документа
В коде документа должно быть не более четырех знаков, включая номер
части документа, как например: АВГБ.061341.021СБ, АВГБ.061341.021ТУ1,

40 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
АВГБ.061341.021ИЭ12. Коды документов приведены в табл. 3 ГОСТ 2.102-68
со ссылками в необходимых случаях на другие стандарты.
Структура обозначения автоматизированной системы или ее части
практически совпадает со структурой обозначения изделия и основного
конструкторского документа АПК, представленной на рис. 3, со следующими отличиями:
• код организации-разработчика может быть присвоен в соответствии с
общесоюзным классификатором предприятий, учреждений и организаций
(ОКПО) - ОК 007-93;
• код классификационной характеристики системы или ее части
(подсистемы, комплекса, компонента) присваивают на основе 425 подклассов
общесоюзного классификатора продукции (ОКП): http://www.fpp-iis.ru/iss.php7page»
5&subj?age=10&ac?=show_c»^
и/или общесоюзного классификатора подсистем и комплексов задач АСУ —
184 154.
Пример обозначения АС: АВГБ.425621.001.
Обозначение технического документа на АС состоит из обозначения
системы, за которым через разделитель-точку последовательно записываются:
• код документа, состоящий из двух буквенно-цифровых знаков. Код
проставляют в соответствии с графой 3 табл. 2 ГОСТ 34.201-89. Код
дополнительных документов формируют следующим образом: первый знак —
буква, означающая вид документа согласно табл. 1 упомянутого
стандарта, второй знак — цифра или буква, указывающая порядковый номер
документа данного вида;
• двузначный порядковый номер документа одного наименования
начиная со второго;
• одна цифра номера редакции документа начиная со второй, дефис и одна
цифра номера части документа (для документов, состоящих из одной
части, дефис и номер части не проставляют);
• буква «М» только для документа, выполненного на машинном носителе.
Пример обозначения технического документа на АС: АВГБ.425621.001.
П1.02. 2-1.М.
Комплектность КД, разрабатываемой на АПК в зависимости от стадий
разработки, представлена в табл. 3 ГОСТ 2.102-68; комплектность ТД на АС,
разрабатываемой на различных стадиях разработки, приведена в табл. 1 и 2
ГОСТ 34.201-89.
Минимально необходимый состав текстовой КД на АПК приведен в
приложении А на компакт-диске.
Рекомендуется следующая последовательность разработки текстовой
документации на АПК и АС:
• участие в создании схемы деления структурной (см. раздел 7.2):
определение наименований и децимальных номеров составных частей изделия;
• разработка и утверждение номенклатуры разрабатываемой ТД, сроков
представления необходимых исходных данных и сдачи документов;
• разработка рабочей, конструкторской и эксплуатационной документации.

3.2. Виды, обозначение и комплектность КД на АПК и ТД на АС 41
Формы и общие правила, используемые для оформления некоторых текстовых
конструкторских документов изделий машиностроения и приборостроения
излагаются в ГОСТ 2.106-96. Единая система конструкторской документации.
Текстовые документы. В этом стандарте рассмотрены следующие текстовые
документы:
• спецификация (кода не имеет);
• ведомость спецификаций (ВС);
• ведомость ссылочных документов (ВД);
• ведомость покупных изделий (ВП);
• ведомость разрешения применения покупных изделий (ВИ);
• ведомость держателей подлинников (ДП);
• ведомость технического предложения (ПТ);
• ведомость эскизного проекта (ЭП);
• ведомость технического проекта (ТП);
• пояснительная записка (ПЗ);
• программа и методика испытаний (ПМ);
• таблица (ТБ);
• расчет (РР);
• инструкция (И);
• документ прочий (Д).
Формы и общие правила оформления документов на АС излагаются в РД
50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания. В методических указаниях
рассмотрены следующие текстовые документы на АС:
• ведомость эскизного проекта (ЭП);
• пояснительная записка к эскизному проекту (П1);
• перечень заданий на разработку специализированных (новых)
технических средств (В9);
• ведомость технического проекта (ТП);
• ведомость покупных изделий (ВП);
• перечень входных сигналов и данных (В1);
• перечень выходных сигналов (документов) (В2);
• перечень заданий на разработку строительных, электротехнических, сани-
тарно-технических и других разделов проекта, связанных с созданием
системы (ВЗ);
• пояснительная записка к техническому проекту (П2);
• описание автоматизируемых функций (ПЗ);
• описание постановки задач (комплекса задач) (П4);
• описание информационного обеспечения системы (П5);
• описание организации информационной базы (П6);

42 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
• описание систем классификации и кодирования (П7);
• описание массива информации (П8);
• описание комплекса технических средств (П9);
• описание программного обеспечения (ПА);
• описание алгоритма (проектной процедуры) (ПБ);
• описание организационной структуры (ПВ);
• локальный сметный расчет (Б2);
• проектная оценка надежности системы (Б1);
• ведомость держателей подлинников (ДП);
• ведомость эксплуатационных документов (ЭД);
• спецификация оборудования (В4);
• ведомость потребности в материалах (В5);
• ведомость машинных носителей информации (ВМ);
• массив входных данных (В6);
• каталог базы данных (В7);
• состав выходных данных (сообщений) (В8);
• локальная смета (БЗ);
• методика (технология) автоматизированного проектирования (И1);
• технологическая инструкция (И2);
• руководство пользователя (ИЗ);
• инструкция по формированию и ведению базы данных (набора данных)
(И4);
• инструкция по эксплуатации КТС (ИЭ);
• описание технологического процесса обработки данных (включая
телеобработку) (ПГ);
• общее описание системы (ПД);
• программа и методика испытаний (компонентов, комплексов средств
автоматизации, подсистемы, систем) (ПМ).
По аналогии с минимально необходимым составом текстовой КД на АПК
можно предложить аналогичный перечень документов для АС. По мнению
ряда специалистов, в этот перечень должны входить следующие документы:
• описание информационного обеспечения системы (П5);
• описание программного обеспечения (ПА);
• программа и методика испытаний (компонентов, комплексов средств
автоматизации, подсистемы, систем) (ПМ);
• технологическая инструкция (И2);
• руководство пользователя АС (ИЗ);
• инструкция по эксплуатации КТС (ИЭ);
• формуляр (ФО) или паспорт (ПС).
Порядок оформления ТД на АС изложен в главе 8 настоящего пособия.

3.2. Виды, обозначение и комплектность КД на АПК и ТД на АС 43
Документы на технические средства, используемые при создании АС и ее
частей, оформляют по ГОСТ 2.102-68, на программные средства,
используемые при создании АС и ее частей, — по ГОСТ 19.101-77.
Формы и правила оформления эксплуатационных и ремонтных документов на
АПК и АС излагаются в ГОСТ 2.601-2006. Единая система конструкторской
документации. Эксплуатационные документы, ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных
документов и ГОСТ 2.602-95. Единая система конструкторской документации.
Ремонтные документы.
Информационные источники
ГОСТ 2.101-68. Единая система конструкторской документации (ЕСКД).
Виды изделий.
ГОСТ 2.102-68. Единая система конструкторской документации. Виды
и комплектность конструкторских документов.
ГОСТ 2.106-96. Единая система конструкторской документации.
Текстовые документы.
ГОСТ 2.201-80. Единая система конструкторской документации.
Обозначение изделий и конструкторских документов.
ГОСТ 2.601-2006. Единая система конструкторской документации.
Эксплуатационные документы.
ГОСТ 2.602-95. Единая система конструкторской документации.
Ремонтные документы.
ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов.
ГОСТ 19.101-77. Единая система программной документации. Виды
программ и программных документов.
ГОСТ 34.201-89. Комплекс стандартов на автоматизированные системы.
Виды, комплектность и обозначение документов при создании
автоматизированных систем.
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.

44 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
3.3. Основные требования к оформлению
текстовой ТД
3.3.1. Форматы и основные надписи. Общие правила
оформления текстового документа. Шрифты.
Титульный лист, лист утверждения и лист
регистрации изменений
В настоящее время основной формой официального представления
технической документации является бумажная форма. Документация в электронном
виде сегодня является лишь инструментом для создания бумажной документации.
Причиной такого положения дел является отсутствие утвержденного стандарта об
электронной цифровой подписи, без которого электронная версия не может
являться официальным документом.
Конструкторская документация на АПК и ТД на АС оформляются на
листах определенного размера (формата), требования к которым определены
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
Текстовая документация, как правило, оформляется на листах формата А4 —
B10 х 297) мм и A3 — B97 х 420) мм как при книжном, так и при альбомном
расположении листа. На практике более предпочтительным расположением
листа является книжное.
Листы документации оформляются по определенным правилам. Одним из
основных правил является наличие на каждом листе рамок и так называемой
«основной надписи» (в обиходе называемой «штампом»), требования к
которой изложены в ГОСТ 2.104-2006. Единая система конструкторской
документации. Основные надписи. В текстовой документации основная надпись и
дополнительные графы для первого (или заглавного) листа оформляются по
форме 2 упомянутого стандарта, для последующих листов — по форме 2а того
же стандарта.
Основные правила оформления текстовых документов определены ГОСТ
2.105-95. Единая система конструкторской документации. Общие требования
к текстовым документам, который устанавливает правила выполнения
текстовых документов на изделия машиностроения, приборостроения и
строительства.
Текстовые документы подразделяют на документы, содержащие в основном
сплошной текст (технические условия, паспорта, расчеты, пояснительные
записки, инструкции и т. п.), и документы, содержащие текст, разбитый на графы
(спецификации, ведомости, таблицы и т. п.).
Подлинники текстовых документов выполняют одним из следующих
способов:
• машинописным. Шрифт пишущей машинки должен быть четким,
высотой не менее 2,5 мм, лента только черного цвета (полужирная);

3.3. Основные требования к оформлению текстовой ТД 45
• рукописным — чертежным шрифтом по ГОСТ 2.304 с высотой букв и цифр
не менее 2,5 мм. Цифры и буквы необходимо писать четко черной тушью;
• с применением печатающих и графических устройств вывода ЭВМ
(ГОСТ 2.004);
• на магнитных носителях данных (ГОСТ 28388).
Копии текстовых документов выполняют одним из следующих способов:
• типографским — в соответствии с требованиями, предъявляемыми к
изданиям, изготовляемым типографским способом;
• ксерокопированием — при этом рекомендуется размножать документы
способом двустороннего копирования;
• светокопированием;
• микрофильмированием;
• на магнитных носителях данных.
В настоящее время бумажные подлинники текстовых документов
выполняют почти исключительно с применением печатающих устройств вывода ЭВМ
(ПК) — принтеров согласно ГОСТ 2.004-88. Единая система конструкторской
документации. Общие требования к выполнению конструкторских и
технологических документов на печатающих и графических устройствах вывода ЭВМ,
а копии — ксерокопированием.
В стандартах ЕСКД и КСАС нет четких указаний о шрифтах оформления
текстового документа, выполняемого с использованием принтеров. Многие
разработчики тем не менее предпочитают шрифт, похожий на шрифт пишущей
машинки. Наиболее близок к нему шрифт Times New Roman с кеглем от 13 до
14 пт. В то же время при оформлении текстовых документов не возбраняется
использовать и иные шрифты достаточно строгой формы.
Расстояние от рамки формы до границ текста в начале и в конце строк
должно составлять не менее 3 мм. Расстояние от верхней или нижней строки текста
до верхней или нижней рамки должно быть не менее 10 мм. Абзацы в тексте
начинают отступом в пределах от 15 до 17 мм.
Для размещения утверждающих и согласующих подписей к текстовым
документам рекомендуется составлять титульный лист и (или) лист утверждения в
соответствии с разделом 6 данного стандарта. Обязательность и особенности
выполнения титульных листов оговорены в стандартах ЕСКД на правила выполнения
соответствующих документов.
К текстовым документам рекомендуется выпускать лист регистрации
изменений в соответствии с приложением 3 ГОСТ 2.503-90. Единая система
конструкторской документации. Правила внесения изменений.
Информационные источники
ГОСТ 2.004-88. Единая система конструкторской документации. Общие
требования к выполнению конструкторских и технологических документов на
печатающих и графических устройствах вывода ЭВМ.
ГОСТ 2.104-2006. Единая система конструкторской документации. Основные
надписи.

46 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
ГОСТ 2.503-90. Единая система конструкторской документации. Правила
внесения изменении.
3.3.2. Правила построения и изложения текста
Правила построения и изложения текста в текстовом документе определяются
требованиями ГОСТ 2.105-95. Единая система конструкторской
документации. Общие требования к текстовым документам.
К основным положениям этого стандарта в части построения и изложения
текста относятся следующие требования.
Текст документа при необходимости разделяют на разделы, подразделы,
пункты и подпункты.
При большом объеме документа допускается разделять его на части, а части,
в случае необходимости, на книги. Каждую часть и книгу комплектуют отдельно.
Всем частям дают наименования и присваивают обозначение документа.
Обозначение частей документа осуществляется согласно стандартам ЕСКД и КСАС.
Внутри пунктов или подпунктов могут быть приведены перечисления.
Перед каждой позицией перечисления следует ставить дефис или при
необходимости ссылки в тексте документа на одно из перечислений, строчную букву, после
которой ставится скобка. Для дальнейшей детализации перечислений
необходимо использовать арабские цифры, после которых ставится скобка, а запись
производится с абзацного отступа, как показано в примере.
Пример
а)
б)
1)
2)
в)
Каждый пункт, подпункт и перечисление записывают с абзацного отступа.
Разделы, подразделы должны иметь заголовки. Пункты, как правило,
заголовков не имеют. Заголовки должны четко и кратко отражать содержание
разделов, подразделов. Заголовки следует печатать с прописной буквы без точки
в конце, не подчеркивая. Переносы слов в заголовках не допускаются. Если
заголовок состоит из двух предложений, их разделяют точкой.
Расстояние между заголовком и текстом должно составлять 15 мм, между
заголовками раздела и подраздела — 8 мм. Каждый раздел текстового документа
рекомендуется начинать с нового листа (страницы).
Полное наименование изделия на титульном листе, в основной надписи
и при первом упоминании в тексте документа должно быть одинаковым с
наименованием его в основном конструкторском документе.
В последующем тексте порядок слов в наименовании должен быть прямой,
то есть на первом месте должно быть определение (имя прилагательное), а за-

3.3. Основные требования к оформлению текстовой ТД 47
тем название изделия (имя существительное); при этом допускается
употреблять сокращенное наименование изделия. Наименования, приводимые в тексте
документа и на иллюстрациях, должны быть одинаковыми.
Текст документа должен быть кратким, четким и не допускать различных
толкований. При изложении обязательных требований в тексте должны
применяться слова «должен», -«следует», «необходимо», «требуется, чтобы»,
«разрешается только», «не допускается», «запрещается», «не следует». При
изложении других положений следует применять слова «могут быть», «как правило»,
«при необходимости», «может быть», «в случае» и т. д.
При этом допускается использовать повествовательную форму изложения
текста документа, например: «применяют», «указывают» и т. п.
В документах должны применяться научно-технические термины,
обозначения и определения, установленные соответствующими стандартами, а при их
отсутствии — общепринятые в научно-технической литературе.
Если в документе принята специфическая терминология, то в конце его
(перед списком литературы) должен быть перечень принятых терминов с
соответствующими разъяснениями. Перечень включают в содержание документа.
В тексте документа не допускается:
• применять обороты разговорной речи, техницизмы, профессионализмы;
• применять для одного и того же понятия различные научно-технические
термины, близкие по смыслу (синонимы), а также иностранные слова
и термины при наличии равнозначных слов и терминов в русском языке;
• применять произвольные словообразования;
• применять сокращения слов, кроме установленных правилами русской
орфографии, соответствующими государственными стандартами, а также
в данном документе;
• сокращать обозначения единиц физических величин, если они
употребляются без цифр, за исключением единиц физических величин в головках и
боковиках таблиц и в расшифровках буквенных обозначений, входящих в
формулы и рисунки.
В тексте документа, за исключением формул, таблиц и рисунков, не
допускается:
• применять математический знак минус (-) перед отрицательными
значениями величин (следует писать слово «минус»);
• применять знак 0 для обозначения диаметра (следует писать слово
«диаметр»);
• применять без числовых значений математические знаки, например: >
(больше), < (меньше), - (равно), > (больше или равно), < (меньше или
равно), * (не равно), а также знаки № (номер), % (процент);
• применять индексы стандартов, технических условий и других
документов без регистрационного номера.
Если в документе приводятся поясняющие надписи, наносимые
непосредственно на изготовляемое изделие (например, на планки, таблички к элементам

48 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
управления и т. п.), их выделяют прописными буквами (без кавычек), например:
ВКЛ., ОТКЛ., или кавычками, если надпись состоит из цифр и (или) знаков.
Наименования команд, режимов, сигналов и т. п. в тексте следует выделять
кавычками, например: «Сигнал +27 В включен*.
В тексте документа числовые значения величин с обозначением единиц
физических величин и единиц счета следует писать цифрами, а числа от единицы
до девяти без обозначения единиц физических величин и единиц счета —
словами.
Примеры
Провести испытания пяти труб, каждая длиной 5 м.
Отобрать 15 труб для испытаний на давление.
Примечания приводят в документах, если необходимы пояснения или
справочные данные к содержанию текста, таблиц или графического материала.
Примечания не должны содержать требований.
Примечания следует помещать непосредственно после текстового,
графического материала или в таблице, к которым относятся эти примечания, и
печатать с прописной буквы с абзаца. Если примечание одно, то после слова
«Примечание» ставится тире и примечание печатается тоже с прописной буквы.
Одно примечание не нумеруют. Несколько примечаний нумеруют по порядку
арабскими цифрами без точки, начиная каждое с абзацного отступа.
Примечание к таблице помещают в конце таблицы над линией, обозначающей
окончание таблицы.
Информационные источники
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
3.3.3. Оформление таблиц и иллюстраций
Правила оформления таблиц и иллюстраций в текстовом документе
определяются требованиями ГОСТ 2.105-95. Единая система конструкторской
документации. Общие требования к текстовым документам.
К основным положениям этих разделов в части оформления таблиц и
иллюстраций относятся следующие требования.
Таблицы, приводимые в тексте, должны иметь заголовок «Таблица» с ее
порядковым номером. Таблицы, за исключением таблиц приложений, следует
нумеровать арабскими цифрами сквозной нумерацией. Таблицы каждого
приложения обозначают отдельной нумерацией арабскими цифрами с добавлением
перед цифрой буквенного обозначения приложения с точкой. Номер таблице
присваивается даже в том случае, если она является единственной.
За номером таблицы через длинное тире «—» (Alt + 0151) может быть
приведено ее название, начинающееся с прописной буквы. Номер таблицы (и ее
название) следует помещать над таблицей. Название таблицы должно отражать

3.3. Основные требования к оформлению текстовой ТД 49
ее содержание, быть точным, кратким. При переносе части таблицы на ту же
или другие страницы название помещают только над первой частью таблицы.
На все таблицы документа должны быть приведены ссылки в тексте
документа, при ссылке следует писать слово «таблица» с указанием ее номера.
Наименования элементов таблицы представлены на рис. 5.
Таблица —_
название таблицы
Головка
Заголовки граф
Подзаголовки граф
Строки
(горизонтальные ряды)
Графы (колонки)
Рис. 5. Наименования элементов таблицы
Боковик (графа для
заголовков)
Заголовки граф и строк таблицы следует писать с прописной буквы, а
подзаголовки граф — со строчной буквы, если они составляют одно предложение
с заголовком, или с прописной буквы, если они имеют самостоятельное
значение. В конце заголовков и подзаголовков таблиц точки не ставят. Заголовки
и подзаголовки граф указывают в единственном числе.
Таблицы слева, справа и снизу, как правило, ограничивают линиями.
Разделять заголовки и подзаголовки боковика и граф диагональными линиями не
допускается. Горизонтальные и вертикальные линии, разграничивающие
строки таблицы, допускается не проводить, если их отсутствие не затрудняет
пользование таблицей.
Заголовки граф, как правило, записывают параллельно строкам таблицы.
При необходимости допускается перпендикулярное расположение заголовков
граф.
Головка таблицы должна быть отделена линией от остальной части таблицы.
Высота строк таблицы должна быть не менее 8 мм.
Таблицу, в зависимости от ее размера, помещают под текстом, в котором
впервые дана ссылка на нее, или на следующей странице, а при
необходимости — в приложении к документу. Допускается помещать таблицу вдоль
длинной стороны листа документа.
Если строки или графы таблицы выходят за формат страницы, ее делят на
части, помещая одну часть под другой или рядом, при этом в каждой части
таблицы повторяют ее головку и боковик. При делении таблицы на части
допускается ее головку или боковик заменять соответственно номером граф и строк.
При этом нумеруют арабскими цифрами графы и (или) строки первой части
таблицы.
Слово «Таблица» указывают один раз слева над первой частью таблицы, над
другими частями пишут слова «Продолжение таблицы» с указанием номера
таблицы.

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

3.3. Основные требования к оформлению текстовой ТД 51
цифрами с добавлением перед цифрой буквенного обозначения приложения с
точкой. Номер иллюстрации присваивается даже в том случае, если она
является единственной.
За номером иллюстрации через длинное тире «—» (Alt + 0151) может быть
приведено ее наименование, начинающееся с прописной буквы. Номер
иллюстрации (и ее название) следует помещать под иллюстрацией. Название
иллюстрации должно отражать ее содержание, быть точным, кратким.
На все иллюстрации документа должны быть приведены ссылки в тексте
документа, при ссылке следует писать слово «рисунок» с указанием его номера.
При необходимости иллюстрации могут иметь пояснительные данные (подри-
суночный текст). Слово «Рисунок» и наименование помещают после
пояснительных данных.
Если в тексте документа имеется иллюстрация, на которой изображены
составные части изделия, то на данной иллюстрации должны быть указаны
номера позиций этих составных частей в пределах данной иллюстрации, которые
располагают в возрастающем порядке, за исключением повторяющихся позиций,
а для электро- и радиоэлементов — позиционные обозначения, установленные
в схемах данного изделия. Исключение составляют электро- и радиоэлементы,
являющиеся органами регулировки или настройки, для которых (кроме номера
позиции) дополнительно указывают в подрисуночном тексте назначение каждой
регулировки и настройки, позиционное обозначение и надписи на
соответствующей планке или панели. Допускается, при необходимости, номер, присвоенный
составной части изделия на иллюстрации, сохранять в пределах документа.
На приводимых в документе электрических схемах около каждого элемента
указывают его позиционное обозначение, установленное соответствующими
стандартами, и, при необходимости, номинальное значение величины.
Информационные источники
ГОСТ 2.105-95. Цдиная система конструкторской документации. Общие
требования к текстовым документам.
3.3.4. Формулы и единицы физических величин
в текстовой документации
Правила оформления формул и применения единиц физических величин
в текстовой документации определяются требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к текстовым
документам.
К основным положениям этих разделов в части формул и единиц
физических величин относятся следующие требования.
В формулах в качестве символов следует применять обозначения,
установленные соответствующими государственными стандартами. Пояснения
символов и числовых коэффициентов, входящих в формулу, если они не
пояснены ранее в тексте, должны быть приведены непосредственно под формулой.

52 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
Пояснения каждого символа следует давать с новой строки в той
последовательности, в которой символы приведены в формуле. Первая строка
пояснения должна начинаться со слова «где* без двоеточия после него.
Пример: плотность каждого образца р, кг/м3, вычисляют по формуле
Л т
где т — масса образца, кг,
V — объем образца, м3.
Формулы, следующие одна за другой и не разделенные текстом, разделяют
запятой.
Переносить формулы на следующую строку допускается только на знаках
выполняемых операций, причем знак в начале следующей строки повторяют.
При переносе формулы на знаке умножения применяют знак «х».
Формулы, за исключением формул, помещаемых в приложении, должны
нумероваться сквозной нумерацией арабскими цифрами, которые записывают
на уровне формулы справа в круглых скобках. Единственную формулу также
нумеруют.
Ссылки в тексте на порядковые номера формул дают в скобках, например:
«... в формуле A)».
Формулы, помещаемые в приложениях, должны нумероваться отдельной
нумерацией арабскими цифрами в пределах каждого приложения с
добавлением перед каждой цифрой обозначения приложения, например: формула (В.1).
Порядок изложения в документах математических уравнений такой же, как
и формул.
В документе следует применять стандартизованные единицы физических
величин, их наименования и обозначения в соответствии с ГОСТ 8.417-2002.
Государственная система обеспечения единства измерений. Единицы
физических величин.
Единица физической величины одного и того же параметра в пределах
одного документа должна быть постоянной.
Если в тексте приводится ряд числовых значений, выраженных в одной и
той же единице физической величины, то ее указывают только после
последнего числового значения, например: 1,50; 1,75; 2,00 м.
Если в тексте документа приводят диапазон числовых значений физической
величины, выраженных в одной и той же единице физической величины, то
обозначение единицы физической величины указывается после последнего
числового значения диапазона.
Примеры
1. От 1 до 5 мм.
2. От 10 до 100 кг.
3. От плюс 10 до минус 40 °С,
от плюс 10 до плюс 40 °С.
Недопустимо отделять единицу физической величины от числового
значения (переносить их на разные строки или страницы), кроме единиц физических
величин, помещаемых в таблицах.

3.3. Основные требования к оформлению текстовой ТД 53
Приводя наибольшие или наименьшие значения величин, следует
применять словосочетание «должно быть не более (не менее)». Приводя допустимые
значения отклонений от указанных норм, требований, следует применять
словосочетание «не должно быть более (менее)».
Числовые значения величин в тексте следует указывать со степенью точности,
которая необходима для обеспечения требуемых свойств изделия, при этом в ряду
величин осуществляется выравнивание числа знаков после запятой.
Округление числовых значений величин до первого, второго, третьего и т. д.
десятичного знака для различных типоразмеров, марок и т. п. изделий
одного наименования должно быть одинаковым. Например, если градация
толщины стальной горячекатаной ленты 0,25 мм, то весь ряд толщин ленты
должен быть указан с таким же количеством десятичных знаков, например: 1,50;
1,75; 2,00.
Дробные числа необходимо приводить в виде десятичных дробей, за
исключением размеров в дюймах, которые следует записывать 1/2"; 1/4" (но не -; -).
2 4
Для написания значений величин следует применять обозначения единиц
буквами или специальными знаками (°,', ").
Буквенные обозначения единиц должны печататься прямым шрифтом. В
обозначениях единиц точку как знак сокращения не ставят.
Между последней цифрой числа и обозначением единицы следует
оставлять пробел. Правильное написание — 100 кВт, 80 %, 20 °С. Исключения
составляют обозначения в виде знака, поднятого над строкой, перед которым
пробела не оставляют. Правильное написание — 20°, 10".
При наличии десятичной дроби в числовом значении величины обозначение
единицы следует помещать после всех цифр. Правильное написание — 423,06 м,
5,758е или 5°45'28,8".
При указании значений величин с предельными отклонениями следует
заключать числовые значения с предельными отклонениями в скобки и
обозначение единицы помещать после скобок или проставлять обозначения единиц после
числового значения величины и после ее предельного отклонения. Правильное
написание — A00 ± 1) кг, 50 г ± 1 г.
Буквенные обозначения единиц, входящих в произведение, следует
отделять точками на средней линии как знаками умножения. Правильное
написание — А*м2. Допускается буквенные обозначения единиц, входящих в
произведение, отделять пробелами, если это не приводит к недоразумению.
В буквенных обозначениях отношений единиц в качестве знака деления
должна применяться только одна черта: косая или горизонтальная. Допускается
применять обозначения единиц в виде произведения обозначений единиц,
возведенных в степени (положительные и отрицательные). Правильное написание —
Вт • м • К или —-—, неправильное — Вт/м2/К.
мг К
При указании производной единицы, состоящей из двух и более единиц, не
допускается комбинировать буквенные обозначения и наименования единиц,
то есть для одних единиц приводить обозначения, а для других —
наименования. Правильное написание — 80 км/ч, 80 километров в час, неправильное —
80 км/час, 80 км в час.

54 Глава 3 • ЕСКД как базовая система стандартов для разработки ТД
ПРИМЕЧАНИЕ
Допускается применять сочетания специальных знаков (°,',", %, %о) с буквенными
обозначениями единиц, например °/с и т. д.
Информационные источники
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 8.417-2002. Государственная система обеспечения единства
измерений. Единицы физических величин.
3.3.5. Оформление приложений. Сокращения
и аббревиатуры, буквенные обозначения,
сноски, ссылки и примеры в текстовой
документации
Правила оформления приложений, применения сокращений и аббревиатур,
использования буквенных обозначений, сносок и ссылок, оформления
примеров в текстовой документации определяются требованиями разделов 4 и 5
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
К основным положениям этих разделов в части приложений, сокращений
и аббревиатур, буквенных обозначений, сносок, ссылок и примеров относятся
следующие требования.
Материал, дополняющий текст документа, допускается помещать в
приложениях. Приложениями могут быть, например, графический материал,
таблицы большого формата, расчеты, описания аппаратуры и приборов, описания
алгоритмов и программ задач, решаемых на ЭВМ, и т. д.
Приложение оформляют как продолжение данного документа на
последующих его листах или выпускают в виде самостоятельного документа.
Приложения могут быть обязательными и информационными.
Информационные приложения могут быть рекомендуемого или справочного характера.
В тексте документа на все приложения должны быть даны ссылки. Степень
обязательности приложений при ссылках не указывается. Приложения
располагают в порядке ссылок на них в тексте документа, за исключением
информационного приложения «Библиография», которое располагают последним.
Каждое приложение следует начинать с новой страницы с указанием
посередине страницы вверху слова «Приложение» и его обозначения, а под ним
в скобках для обязательного приложения пишут слово «обязательное», а для
информационного — «рекомендуемое» или «справочное».
Приложение должно иметь заголовок, который записывают симметрично
относительно текста с прописной буквы отдельной строкой.
Приложения обозначают заглавными буквами русского алфавита начиная с
А, за исключением букв Ё, 3, Й, О, Ч, Ь, Ы, Ъ. После слова «Приложение»
следует буква, обозначающая его последовательность. Допускается обозначение при-

3.3. Основные требования к оформлению текстовой ТД 55
ложений буквами латинского алфавита, за исключением букв I и О. В случае
полного использования букв русского и латинского алфавитов допускается
обозначать приложения арабскими цифрами. Если в документе одно приложение,
оно обозначается «Приложение А».
Текст каждого приложения, при необходимости, может быть разделен на
разделы, подразделы, пункты, подпункты, которые нумеруют в пределах
каждого приложения. Перед номером ставится обозначение этого приложения.
Приложения должны иметь общую с остальной частью документа сквозную
нумерацию страниц.
Все приложения должны быть перечислены в содержании документа (при
наличии) с указанием их номеров и заголовков.
Приложения, выпускаемые в виде самостоятельного документа, оформляют
по общим правилам. Приложениям, выпущенным в виде самостоятельного
документа, обозначение присваивают как части документа с указанием в коде
документа ее порядкового номера. Если приложение имеет титульный лист, то на
нем под наименованием документа указывают слово «Приложение» и его
обозначение в случае двух и более приложений.
Допускается в качестве приложения к документу использовать другие
самостоятельно выпущенные конструкторские документы (габаритные чертежи,
схемы и др.).
Перечень допускаемых сокращений слов и аббревиатур установлен в
приложении к ГОСТ 2.316-68. Единая система конструкторской документации.
Правила нанесения на чертежах надписей, технических требований и таблиц.
Если в документе принята особая система сокращения слов или наименований
и аббревиатур, то в нем должен быть приведен перечень принятых сокращений,
который помещают в конце документа перед перечнем терминов.
Условные буквенные обозначения, изображения или знаки должны
соответствовать принятым в действующем законодательстве и государственных
стандартах. В тексте документа перед обозначением параметра дают его пояснение,
например: «Временное сопротивление разрыву — рр». При необходимости
применения условных обозначений, изображений или знаков, не установленных
действующими стандартами, их следует пояснять в тексте или в перечне
обозначений.
В текстовом документе допускаются ссылки на данный документ,
стандарты, технические условия и другие документы при условии, что они полностью
и однозначно определяют соответствующие требования и не вызывают
затруднений в пользовании документом. Ссылаться следует на документ в целом или
его разделы и приложения. Ссылки на подразделы, пункты, таблицы и
иллюстрации не допускаются, за исключением подразделов, пунктов, таблиц и
иллюстраций данного документа.
При ссылках на стандарты и технические условия указывают только их
обозначение, при этом допускается не указывать год их утверждения при
условии записи обозначения с годом утверждения в конце текстового документа
под рубрикой «ССЫЛОЧНЫЕ НОРМАТИВНЫЕ ДОКУМЕНТЫ» по
форме табл. 1.

56 Глава 2 • ЕСКД как базовая система стандартов для разработки ТД
Таблица!
Обозначение документа,
на который дана ссылка
Номер раздела, подраздела, пункта, подпункта, перечисления,
приложения, разрабатываемого документа, в котором дана
ссылка
При ссылках на другие документы в графе «Обозначение документа»
указывают также и наименование документа. При ссылках на раздел или приложение
указывают его номер.
При необходимости пояснить отдельные данные, приведенные в документе,
эти данные следует обозначать надстрочными знаками сноски. Сноски в тексте
располагают с абзацного отступа в конце страницы, на которой они обозначены,
и отделяют от текста короткой тонкой горизонтальной линией с левой стороны,
а к данным, расположенным в таблице, — в конце таблицы над линией,
обозначающей окончание таблицы.
Знак сноски ставят непосредственно после того слова, числа, символа,
предложения, к которому дается пояснение, и перед текстом пояснения. Знак
сноски выполняют арабскими цифрами со скобкой и помещают на уровне
верхнего обреза шрифта. Нумерация сносок — отдельная для каждой страницы.
Допускается вместо цифр выполнять сноски звездочками: «*». Применять
более четырех звездочек не рекомендуется.
В тексте документа могут приводиться примеры. Примеры приводятся
в тех случаях, когда они поясняют требования документа или способствуют
более краткому их изложению. Примеры размещают, нумеруют и оформляют так
же, как и примечания.
Информационные источники
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.316-68. Единая система конструкторской документации. Правила
нанесения на чертежах надписей, технических требований и таблиц.

Единая система
программной
документации (ЕСПД) |
и ее применение при разработке
ТДнаАПКиАС

58 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
4.1. Термины и определения. Виды и содержание
программных документов
Основным нормативным документом, определяющим правоотношения в сфере
программного обеспечения (ПО), является комплекс стандартов ГОСТ 19. — Цди-
ная система программной документации. В стандартах ЕСПД устанавливают
требования, регламентирующие разработку, сопровождение, изготовление и
эксплуатацию программ и программных документов. Правила и положения,
установленные в стандартах ЕСПД, распространяются на программы и
программную документацию (ПД) для вычислительных машин, комплексов и систем
независимо от их назначения и области применения.
Для правильного понимания положений, изложенных в стандартах ЕСПД,
обратимся к терминологии. ГОСТ 19.004-80. Единая система программной
документации. Термины и определения и ГОСТ 19.101-77. Единая система
программной документации. Виды программ и программных документов
определяют основные термины, относящиеся к программным продуктам и
документам.
Программное изделие — программа на носителе данных, являющаяся
продуктом промышленного производства.
Компонент — программа, рассматриваемая как единое целое, выполняющая
законченную функцию и применяемая самостоятельно или в составе комплекса.
Комплекс — программа, состоящая из двух или более компонентов и (или)
комплексов, выполняющих взаимосвязанные функции, и применяемая
самостоятельно или в составе другого комплекса.
Программный документ — документ, содержащий сведения, необходимые
для разработки, изготовления, эксплуатации и сопровождения программного
изделия.
Определенный интерес также представляет терминология, изложенная
в ГОСТ 19781-90. Обеспечение систем обработки информации программное.
Термины и определения. И хотя этот стандарт не относится к комплексу
стандартов ЕСПД, приведенная в нем терминология часто оказывается полезной
при разработке ПО на АПК и АС.
ПО как составная часть АПК и АС должно входить в спецификацию
комплекса. Для правильного выбора раздела спецификации, в котором должно
размещаться ПО (возможные варианты — «Комплексы», «Комплекты» или
«Прочие изделия»), следует четко представлять его функциональные
характеристики. Если ПО удовлетворяет определению комплекса, его размещают в разделе
«Комплексы». Самостоятельный и единственный программный компонент
размещают в разделе «Прочие изделия». Совокупность программных
компонентов, имеющих общее эксплуатационное назначение вспомогательного
характера, но не выполняющих взаимосвязанные функции, является комплектом
и размещается в разделе «Комплекты».

4.1. Термины и определения. Виды и содержание программных документов 59
ГОСТ 19.101-77. Единая система программной документации. Виды
программ и программных документов определяет следующие виды и содержание
программных и эксплуатационных программных документов, приведенные в
табл. 2 и 3.
Таблица 2
Вид программного
Спецификация
Ведомость держателей
подлинников
Текст программы
Описание программы
Программа и методика
испытаний
Техническое задание
Пояснительная записка
Эксплуатационные документы
Состав программы и документации на нее
Перечень предприятий, на которых хранят подлинники
программных документов
Запись программы с необходимыми комментариями
Сведения о логической структуре и функционировании
программы
Требования, подлежащие проверке при испытании
программы, а также порядок и методы их контроля
Назначение и область применения программы,
технические, технико-экономические и специальные требования,
предъявляемые к программе, необходимые стадии и сроки
разработки, виды испытаний
Схема алгоритма, общее описание алгоритма и (или)
функционирования программы, а также обоснование
принятых технических и технико-экономических решений
Сведения для обеспечения функционирования и
эксплуатации программы
Таблица 3
Вид эксплуатационного
документа
Ведомость эксплуатационных
документов
Формуляр
jvnjmvnK применении
Руководство системного
программиста
Руководство программиста
Руководство оператора
Описание языка
Содержание эксплуатационного документа
Перечень эксплуатационных документов на программу
Основные характеристики программы, комплектность
и сведения об эксплуатации программы
Сведения о назначении программы, области применения,
применяемых методах, классе решаемых задач,
ограничениях для применения, минимальной конфигурации
технических средств
Сведения для проверки, обеспечения функционирования
и настройки программы на условия конкретного применения
Сведения для эксплуатации программы
Сведения для обеспечения процедуры общения оператора
с вычислительной системой в процессе выполнения
программы
Описание синтаксиса и семантики языка
продолжение

60 Глава 4 • ЕСГТД и ее применение при разработке ТД на АПК и АС
Таблица 3 (продолжение)
Вид эксплуатационного
документа
Руководство по техническому
обслуживанию
Содержание эксплуатационного документа
Сведения для применения тестовых и диагностических
программ при обслуживании технических средств
Информационные источники
ГОСТ 19.004-80. Единая система программной документации. Термины и
определения.
ГОСТ 19.101-77. Единая система программной документации. Виды
программ и программных документов.
ГОСТ 19781-90. Обеспечение систем обработки информации
программное. Термины и определения.

4.2. Правила обозначения ПД 61
4.2. Правила обозначения ПД
В соответствии с ГОСТ 19.103-77. Единая система программной
документации. Обозначение программ и программных документов устанавливается
следующая структура обозначения программы и ее программного
документа-спецификации (рис. 6).
Общая часть обозначения
программы и программных
документов на нее
Код страны
Код организации-разработчика
А.В.ХХХХХ-ХХ
Номер издания (для программы)
Номер редакции (для документа)
Рис б. Структура обозначения программы и программного документа
Коды страны и предприятия-разработчика присваивают в установленном
порядке. Например, для России код страны — RU, для Украины — UA и т. д.
Код предприятия-разработчика был подробно рассмотрен в разделе 3.2 главы 3.
Регистрационный номер присваивают в соответствии с Общесоюзным
классификатором программ, утверждаемым Госстандартом, в установленном
порядке.
До утверждения Общесоюзного классификатора программ допускается
присваивать регистрационный номер в порядке возрастания с 00001 до 99999
для каждого предприятия-разработчика. Удобно для этих целей использовать
классификатор ОКП в части программных продуктов (раздел 5), без учета
последней цифры.
Номер издания программы или номер редакции документа присваивают
в порядке возрастания с 01 до 99.
Структура обозначения других программных документов приведена на рис. 7.
А.В.ХХХХХ-ХХ XX ХХ-Х
Общая часть обозначения программы
и программных документов на нее
Номер редакции документа
Код вида документа
Номер документа данного вида
Номер части документа
Рис 7. Структура обозначения прочих программных документов
Код вида документа присваивают как того требует ГОСТ 19.101-77. Единая
система программной документации. Виды программ и программных
документов, приведенными в табл. 4.

62 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
Таблица 4
Код вида документа
-
-
05
12
13
20
30
31
32
33
34
35
46
51
81
90
Вид документа
Техническое задание
Спецификация
Ведомость держателей подлинников
Текст программы
Описание программы
Ведомость эксплуатационных документов
Формуляр
Общее описание
Руководство системного программиста
Руководство программиста
Руководство оператора
Описание языка
Руководство по техническому обслуживанию
Программа и методика испытаний
Пояснительная записка
Документы прочие
Номер документа данного вида присваивают в порядке возрастания с 01 до 99.
Номер части одного и того же документа присваивают в порядке возрастания с
1 до 9. Если документ состоит из одной части, то дефис и порядковый номер
части не указывают.
Информационные источники
ГОСТ 19.101-77. Единая система программной документации. Виды
программ и программных документов.
ГОСТ 19.103-77. Единая система программной документации.
Обозначение программ и программных документов.

4.3. Порядок разработки и состав ПД на АПК и АС 63
4.3. Порядок разработки и состав ПД на АПК и АС
Как видно из таблиц, определяющих вид и содержание программных
документов, в структуре и составе программной и конструкторской документации
имеется много схожего (спецификация, ведомость держателей подлинников,
программа и методика испытаний, техническое задание, пояснительная записка
в общей части, ведомость эксплуатационных документов и формуляр в части
ЭД). Аналогии также прослеживаются и в стадиях разработки ПО и
аппаратуры, см. ГОСТ 19.102-77. Единая система программной документации. Стадии
разработки. Схожи и правила оформления программных и конструкторских
документов, см. ГОСТ 19.105-78. Единая система программной
документации. Общие требования к программным документам.
Поэтому при проектировании АПК и АС удобно вести параллельную
разработку аппаратной и программной частей по правилам ЕСКД и КСАС с учетом
специфики, накладываемой требованиями ЕСПД.
Здесь также полезно определить минимально необходимый состав ПД на
АПК (АС), который приведен в приложении Б на компакт-диске.
Представляется важным сделать еще одно замечание. Единая система
программной документации создавалась в конце 70-х годов прошлого столетия,
когда в эксплуатации находились большие вычислительные машины (типа
БЭСМ, ЕС и аналогичные), использовавшиеся в основном для выполнения
расчетных задач и моделирования. На этих машинах работали специально
обученные операторы. В их задачи входили обеспечение проведения
вычислительного процесса в соответствии с рабочими программами (которые
разрабатывали программисты), подготовка технических носителей информации на
устройствах подготовки данных и их контроль, запись, считывание и
перезапись информации с одного вида носителей на другой, наблюдение за работой
ЭВМ и ее обслуживание. Пользователем ЭВМ в те годы считался специалист,
ставящий задачу программистам и получающий результаты вычислений от
операторов. В связи с отмеченным обстоятельством ЕСПД была (и, к
сожалению, остается) ориентирована на создание документации для программистов
и операторов ЭВМ.
По мере развития вычислительной техники и создания персональных
компьютеров с графическим интерфейсом пользователя изменилось содержание
понятий «оператор» и «пользователь». Пользователем стал считаться
специалист, непосредственно работающий на ПК, то есть как бы в прошлом
понятии — оператор. В комплексе же стандартов ЕСПД данное смещение понятий
отражения не нашло. Поэтому стало возникать определенное несоответствие
между содержанием документа «Руководство оператора» и ожидаемым от
этого документа описания порядка действия пользователя ПК.
Для устранения данного несоответствия в начале 80-х годов была начата
разработка комплекса ГОСТ 24. Единая система стандартов
автоматизированных систем управления, а в конце 80-х годов — ГОСТ 34. Информационная
технология. Комплекс стандартов на автоматизированные системы. В ГОСТ

64 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
34.201-89. Информационная технология. Комплекс стандартов на
автоматизированные системы. Виды, комплектность и обозначения документов при
создании автоматизированных систем, для АС был впервые определен новый
документ — руководство пользователя. Данный документ применительно к
автоматизированной системе в некоторой степени является аналогом руководства
по эксплуатации аппаратного изделия, то есть содержит сведения,
необходимые для правильной работы АС и его ПО: состав и содержание
дистрибутивного носителя данных; порядок загрузки данных и программ; описание всех
выполняемых функций, задач, процедур и т. п.
На основании изложенного представляется целесообразным для ПО АПК
не разрабатывать ни руководство оператора, ни руководство пользователя,
а порядок работы с ПО излагать в руководстве по эксплуатации комплекса,
используя рекомендации по построению руководства пользователя АС.
Информационные источники
ГОСТ 2 -... Цдиная система конструкторской документации (ЕСКД) —
http://www.elecab.ru/norm/7cs 10.
ГОСТ 19 -... Единая система программной документации (ЕСПД) —
http://www.elecab.ru/norm/7cs 11.
ГОСТ 34 -... Информационная технология. Комплекс стандартов на
автоматизированные системы (КСАС) — http://www.nist.ru/hr/doq/gost/gost34.htm.

4.4. Разработка отдельных видов ПД на АПК и АС 65
4.4. Разработка отдельных видов ПД на АПК и АС
В данном разделе рассмотрены правила разработки следующих обязательных
видов программных и эксплуатационных программных документов:
• спецификации (кода не имеет);
• текста программы (код 12);
• описания программы (код 13);
• описания применения (код 31);
• руководства системного программиста (код 32);
• руководства оператора (код 34).
Остальные виды программных документов разработчик ПД вполне может
разработать самостоятельно по аналогии с описанными выше документами,
пользуясь соответствующими стандартами ЕСПД.
Все программные документы оформляют в соответствии с требованиями
ГОСТ 19.105-78. Единая система программной документации. Общие
требования к программным документам.
Любой программный документ состоит из следующих условных частей:
• титульной;
• информационной;
• основной;
• регистрации изменений.
Правила оформления документа и его частей на каждом носителе данных
устанавливаются стандартами ЕСПД на правила оформления документов на
соответствующих носителях данных.
Титульная часть состоит из листа утверждения и титульного листа.
Правила оформления листа утверждения и титульного листа устанавливаются
по ГОСТ 19.104-78. Единая система программной документации.
Основные надписи.
Информационная часть должна состоять из аннотации и содержания.
Необходимость включения информационной части в различные виды программных
документов установлена соответствующими стандартами ЕСПД на эти
документы. В аннотации приводят сведения о назначении документа и краткое
изложение его основной части. Содержание включает в себя перечень записей
о структурных элементах основной части документа, в каждую из которых
входят:
• обозначение структурного элемента (номер раздела, подраздела и т. д.);
• наименование структурного элемента;
• адрес структурного элемента на носителе данных (например, номер
страницы, номер файла и т. п.).

66 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
Правила обозначения структурных элементов основной части документа и
их адресации устанавливаются стандартами ЕСПД на правила оформления
документов на соответствующих носителях данных.
Состав и структура основной части программного документа
устанавливаются стандартами ЕСПД на соответствующие документы.
О каждом изменении программного документа в этой части делается запись
в соответствии с требованиями ГОСТ 19.603-78. Единая система
программной документации. Общие правила внесения изменений.
Правила разработки документа «Спецификация» изложены в ГОСТ 19.202—78.
Единая система программной документации. Спецификация. Требования к
содержанию и оформлению.
Спецификация является основным программным документом для
компонентов, применяемых самостоятельно, и для комплексов. Для компонентов, не
имеющих спецификации, основным программным документом является текст
программы.
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Информационную часть (аннотацию и содержание) допускается в документ не
включать.
Спецификация в общем случае должна содержать разделы:
• документация;
• комплексы;
• компоненты.
Форма спецификации приведена в обязательном приложении к
стандарту. Наименование каждого раздела указывают в виде заголовка в графе
«Наименование». Для документов, выполненных печатным способом, заголовок
подчёркивают.
В раздел «Документация» вносят программные документы на данную
программу, кроме спецификации и технического задания, в порядке возрастания
кода вида документа, входящего в обозначение.
Далее записывают заимствованные программные документы. Запись их
производится в порядке возрастания кодов предприятий-разработчиков и далее в
порядке возрастания кода вида документа, входящего в обозначение.
После каждого раздела спецификации необходимо оставлять несколько
свободных строк для дополнительных записей. Графы спецификаций
заполняют следующим образом.
В графе «Обозначение» указывают:
• в разделе «Документация» — обозначение записываемых документов
программы;
• в разделе «Комплексы» — обозначение спецификаций комплексов,
входящих в данный комплекс;
• в разделе «Компоненты» — обозначения основных программных
документов компонентов.

4.4. Разработка отдельных видов ПД на АПК и АС 67
В графе «Наименование» указывают:
• в разделе «Документация» — наименование и вид документа для
документов на данную программу; полное наименование программы, наименование
и вид документа для заимствованных документов;
• в разделах «Комплексы» и «Компоненты» — полное наименование
программы, наименование и вид документа.
В графе «Примечание» указывают дополнительные сведения, относящиеся
к записанным в спецификации программам.
При отсутствии места в графе «Примечание» допускается записывать только
порядковые номер примечаний. Текст примечаний записывают в конце
соответствующих разделов спецификации. Допускается текст примечаний
записывать на последних листах спецификации на листах без граф с проставлением
порядкового номера примечаний.
В графе «Обозначение» запись производят в одну строку. В остальных
графах спецификации записи допускаются в несколько строк.
Правила разработки документа «Текст программы» изложены в ГОСТ
19.401-78. Единая система программной документации. Текст программы.
Требования к содержанию и оформлению.
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Составление информационной части (аннотация и содержание) является
обязательным.
Основная часть документа должна состоять из текстов одного или
нескольких разделов, которым даны наименования.
Допускается вводить наименования также и для совокупности разделов.
Каждый из этих разделов реализуется одним из типов символической
записи, например:
• символическая запись на исходном языке;
• символическая запись на промежуточных языках;
• символическое представление машинных кодов и т. п.
В символическую запись разделов рекомендуется включать комментарии,
которые могут отражать, например, функциональное назначение, структуру.
В связи с тем, что современные программы достаточно объемны,
допускается следующее решение, не противоречащее требованиям нормативных
документов. В документе приводится следующая таблица.
Таблица... Описание исходных модулей
№
п/п

Наименование

Описание
Адрес
хранения
Тип носителя
Примечание
Идентификатор
хранителя
Папка
Имя файла
В столбце «Тип носителя» приводится ссылка на компакт-диск, на кою-
ром записан текст программы и который хранится в архиве ТД в качестве кон-

68 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
структорского документа, куда можно оперативно вносить изменения. К
компакт-диску прикладывается информационно-удостоверяющий лист.
Правила разработки документа «Описание программы* изложены в ГОСТ
19.402-78. Единая система программной документации. Описание
программы. Требования к содержанию и оформлению.
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Составление информационной части (аннотации и содержания) является
обязательным.
Описание программы должно содержать следующие разделы:
• общие сведения;
• функциональное назначение;
• описание логической структуры;
• используемые технические средства;
• вызов и загрузка;
• входные данные;
• выходные данные.
В зависимости от особенностей программы допускается вводить
дополнительные разделы или объединять отдельные разделы.
В разделе «Общие сведения» должны быть указаны:
• обозначение и наименование программы;
• программное обеспечение, необходимое для функционирования программы;
• языки программирования, на которых написана программа.
В разделе «Функциональное назначение» должны быть указаны классы
решаемых задач и (или) назначение программы и сведения о функциональных
ограничениях на применение.
В разделе «Описание логической структуры» должны быть указаны:
• алгоритм программы;
• используемые методы;
• структура программы с описанием функций составных частей и связи
между ними;
• связи программы с другими программами.
Описание логической структуры программы выполняют с учетом текста
программы на исходном языке.
В разделе «Используемые технические средства* должны быть указаны
типы электронно-вычислительных машин и устройств, которые используются
при работе программы.
В разделе «Вызов и загрузка» должны быть указаны:
• способ вызова программы с соответствующего носителя данных;
• входные точки в программу.
Допускается указывать адреса загрузки, сведения об использовании
оперативной памяти, объем программы.

4.4. Разработка отдельных видов ПД на АПК и АС 69
В разделе «Входные данные» должны быть указаны:
• характер, организация и предварительная подготовка входных данных;
• формат, описание и способ кодирования входных данных.
В разделе «Выходные данные» должны быть указаны:
• характер и организация выходных данных;
• формат, описание и способ кодирования выходных данных.
Допускается содержание разделов иллюстрировать пояснительными
примерами, таблицами, схемами, графиками.
В приложение к описанию программы допускается включать различные
материалы, которые нецелесообразно включать в разделы описания.
Правила разработки документа «Описание применения» изложены в ГОСТ
19.502-78. Единая система программной документации. Описание
применения. Требования к содержанию и оформлению.
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Составление информационной части (аннотации и содержания) является
обязательным.
Текст документа должен состоять из следующих разделов:
• назначение программы;
• условия применения;
• описание задачи;
• входные и выходные данные.
В зависимости от особенностей программы допускается вводить
дополнительные разделы или объединять отдельные разделы.
В разделе «Назначение программы» указывают назначение, возможности
программы, её основные характеристики, ограничения, накладываемые на
область применения программы.
В разделе «Условия применения» указываются условия, необходимые для
выполнения программы (требования к необходимым для данной программы
техническим средствам и другим программам, общие характеристики входной
и выходной информации, а также требования и условия организационного,
технического и технологического характера и т. п.).
В разделе «Описание задачи» должны быть указаны определения задачи
и методы ее решения.
В разделе «Входные и выходные данные» должны быть указаны сведения
о входных и выходных данных.
В приложение к общему описанию могут быть включены справочные
материалы (иллюстрации, таблицы, графики, примеры и т. п.).
Правила разработки документа «Руководство системного программиста»
изложены в ГОСТ 19.503-79. Единая система программной документации.
Руководство системного программиста. Требования к содержанию и
оформлению.

70 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Составление информационной части (аннотации и содержания) является
обязательным.
Руководство системного программиста должно содержать следующие
разделы:
• общие сведения о программе;
• структура программы;
• настройка программы;
• проверка программы;
• дополнительные возможности;
• сообщения системному программисту.
В зависимости от особенностей документа допускается объединять
отдельные разделы или вводить новые.
В обоснованных случаях допускается раздел «Дополнительные
возможности» не приводить, а в наименованиях разделов опускать слово «программа»
или заменять его на «наименование программы».
В разделе «Общие сведения о программе» должны быть указаны назначение
и функции программы и сведения о технических и программных средствах,
обеспечивающих выполнение данной программы.
В разделе «Структура программы» должны быть приведены сведения
о структуре программы, ее составных частях, о связях между составными
частями и о связях с другими программами.
В разделе «Настройка программы» должно быть приведено описание
действий по настройке программы на условия конкретного применения (настройка
на состав технических средств, выбор функций и др.). При необходимости
приводят поясняющие примеры.
В разделе «Проверка программы» должно быть приведено описание
способов проверки, позволяющих дать общее заключение о работоспособности
программы (контрольные примеры, методы прогона, результаты).
В разделе «Дополнительные возможности» должно быть приведено описание
дополнительных разделов функциональных возможностей программы и способов
их выбора.
В разделе «Сообщения системному программисту» должны быть указаны
тексты сообщений, выдаваемых в ходе выполнения настройки, проверки
программы, а также в ходе выполнения программы, описание их содержания и
действий, которые необходимо предпринять по этим сообщениям.
В приложении к руководству системного программиста могут быть
приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики
и т. п.).
Правила разработки документа «Руководство оператора» изложены в ГОСТ
19.505-79. Единая система программной документации. Руководство
оператора. Требования к содержанию и оформлению.

4.4. Разработка отдельных видов ПД на АПК и АС 71
Структуру и оформление документа устанавливают в соответствии с ГОСТ
19.105-78. Единая система программной документации. Общие требования к
программным документам.
Составление информационной части (аннотации и содержания) является
обязательным.
Руководство оператора должно содержать следующие разделы:
• назначение программы;
• условия выполнения программы;
• выполнение программы;
• сообщения оператору.
В зависимости от особенностей документа допускается объединять
отдельные разделы или вводить новые.
В разделе «Назначение программы» должны быть указаны сведения о
назначении программы и информация, достаточная для понимания функций
программы и ее эксплуатации.
В разделе «Условия выполнения программы» должны быть указаны
условия, необходимые для выполнения программы (минимальный и (или)
максимальный состав аппаратурных и программных средств и т. п.).
В разделе «Выполнение программы» должна быть указана последовательность
действий оператора, обеспечивающих загрузку, запуск, выполнение и завершение
программы, должно быть приведено описание функций, формата и возможных
вариантов команд, с помощью которых оператор осуществляет загрузки и управляет
выполнением программы, а также ответы программы на эти команды.
В разделе «Сообщения оператору» должны быть приведены тексты
сообщений, выдаваемых в ходе выполнения программы, описание их содержания и
соответствующие действия оператора (действия оператора в случае сбоя,
возможности повторного запуска программы и т. п.).
Допускается содержание разделов иллюстрировать поясняющими
примерами, таблицами, схемами, графиками.
В приложения к руководству оператора допускается включать различные
материалы, которые нецелесообразно включать в разделы руководства.
Информационные источники
ГОСТ 19.104-78. Единая система программной документации. Основные
надписи.
ГОСТ 19.105-78. Единая система программной документации. Общие
требования к программным документам.
ГОСТ 19.202-78. Единая система программной документации.
Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.401-78. Единая система программной документации. Текст
программы. Требования к содержанию и оформлению.
ГОСТ 19.402-78. Единая система программной документации. Описание
программы. Требования к содержанию и оформлению.
ГОСТ 19.502-78. Единая система программной документации. Описание
применения. Требования к содержанию и оформлению.

72 Глава 4 • ЕСПД и ее применение при разработке ТД на АПК и АС
ГОСТ 19.503-79. Единая система программной документации. Руководство
системного программиста. Требования к содержанию и оформлению.
ГОСТ 19.505-79. Единая система программной документации.
Руководство оператора. Требования к содержанию и оформлению.
ГОСТ 19.603-78. Единая система программной документации. Общие
правила внесения изменений. ?

Основные сведения о единой
системе технологической
документации (ЕСГД)

74 Глава 5 • Основные сведения о ЕСТД
Единая система технологической документации (ЕСТД, ГОСТ 3) — комплекс
государственных стандартов и рекомендаций, устанавливающих взаимосвязанные
правила и положения по порядку разработки, комплектации, оформления и
обращения технологической документации, применяемой при изготовлении и
ремонте изделий (включая сбор и сдачу технологических отходов). ЕСТД
применяется на машиностроительных и приборостроительных предприятиях России
и СНГ.
Из определения ЕСТД следует, что технологическая документация
разрабатывается для использования на стадиях производства и ремонта жизненного
цикла изделий.
Технологическая документация предназначена для установления единых
требований и правил по оформлению документов на единичные, типовые и
групповые технологические процессы (операции), в зависимости от степени
детализации описания технологических процессов, снижения трудоемкости
инженерно-технических работ, выполняемых в сфере технологической
подготовки производства и в управлении производством.
В зависимости от назначения технологические документы подразделяют на
основные и вспомогательные. К основным относят документы, содержащие
сводную информацию, необходимую для решения одной или комплекса
инженерно-технических, планово-экономических и организационных задач, полностью
и однозначно определяющих технологический процесс (операцию)
изготовления или ремонта изделия (составных частей изделия). К вспомогательным
относят документы, применяемые при разработке, внедрении и
функционировании технологических процессов и операций, например карту заказа на
проектирование технологической оснастки, акт внедрения технологического процесса
и др.
Основные технологические документы подразделяют на документы общего
и специального назначения. К документам общего назначения относят
технологические документы, применяемые в отдельности или в комплектах
документов на технологические процессы (операции), независимо от применяемых
технологических методов изготовления или ремонта изделий (составных
частей изделий), например карту эскизов, технологическую инструкцию. К
документам специального назначения относят документы, применяемые при
описании технологических процессов и операций в зависимости от типа и вида
производства и применяемых технологических методов изготовления или
ремонта изделий (составных частей изделий), например маршрутную карту,
карту технологического процесса и др.
Стадии разработки технологической документации, применяемой для
технологических процессов изготовления изделий (составных частей изделий),
определяются в зависимости от стадий разработки используемой
конструкторской документации по ГОСТ 2.103-68. Единая система конструкторской
документации. Стадии разработки.
Так, на основании конструкторской документации, выполненной на стадиях
«Эскизный проект» и «Технический проект» разрабатывается технологическая
документация, предназначенная для изготовления и испытания макета
изделия. При разработке РКД опытного образца (опытной партии) выполняется
разработка технологической документации, предназначенной для изготовле-

Основные сведения о ЕСТД 75
ния и испытания опытного образца (опытной партии), без присвоения литеры
и т. д. Таким образом, разработка технологической (как и программной)
документации выполняется одновременно с разработкой КД.
Стадии разработки рабочей технологической документации, применяемой
для технологических процессов ремонта изделий (составных частей изделий),
определяются разработчиком документации в зависимости от применяемых
видов документов на ремонт по ГОСТ 2.602-95. Единая система
конструкторской документации. Ремонтные документы и стадий разработки
конструкторской документации по ГОСТ 2.103-68. Единая система конструкторской
документации. Стадии разработки.
Правила оформления текстовых технологических документов определяются
требованиями ГОСТ 3.1127-93. ЕСТД. Общие правила выполнения текстовых
технологических документов.
В заключение данной темы следует отметить, что на практике
технологическая документация разрабатывается только на те изделия, технические
характеристики которых в существенной степени зависят от технологии их
изготовления. Если для изготовления и ремонта изделий используются типовые
технологические процессы, параметры которых не влияют на характеристики
изделия, технологическая документация разработчиками изделия, как правило, не
создается, а ее разработка выполняется на серийных заводах, выпускающих
изделия по конструкторской документации разработчика после ее передачи на
производство.
Информационные источники
ГОСТ 2.103-68. Единая система конструкторской документации. Стадии
разработки.
ГОСТ 2.602-95. Единая система конструкторской документации. Ремонтные
документы.
ГОСТ 3.1127-93. ЕСТД. Общие правила выполнения текстовых
технологических документов.

Жизненный цикл технической
документации

78 Глава б • Жизненный цикл технической документации
6.1. Стадии разработки ТД. Порядок разработки,
согласования и утверждения ТД.
Бумажная и электронная формы ТД.
Примерные нормы времени
на разработку текстовой ТД
Разработчик технической документации не только создает документ, но и
сопровождает его на всех стадиях его жизненного цикла.
Поскольку техническая документация является одним из видов продукции
промышленного предприятия, ее жизненный цикл повторяет жизненный цикл
любого изделия, разрабатываемого и выпускаемого предприятием, который
определен требованиями ГОСТ Р 15.000-94. Система разработки и постановки
продукции на производство. Основные положения.
По той же причине стадии разработки технической документации
совпадают со стадиями разработки промышленной продукции, определенными ГОСТ
15.001-97. Система разработки и постановки продукции на производство.
Продукция производственно-технического назначения.
Более подробно стадии разработки промышленной продукции и
технической документации определены требованиями ГОСТ 2.103-68. Единая
система конструкторской документации. Стадии разработки (сравните с
материалами, приведенными в приложениях А и Б на компакт-диске). Стадии разработки
промышленной продукции приведены в табл. 5.
Таблица 5
Стадия разработки
Техническое предложение
Эскизный проект
Технический проект
Подбор материалов. Разработка
технического предложения с присвоением
документам литеры «п». Рассмотрение и
утверждение технического предложения
Разработка эскизного проекта с
присвоением документам литеры «Э».
Изготовление и испытание макетов (при
необходимости). Рассмотрение и утверждение
эскизного проекта
Разработка технического проекта с
присвоением документам литеры «Т».
Изготовление и испытание макетов (при
необходимости). Рассмотрение и
утверждение технического проекта

6.1. Стадии разработки ТД 79
Стадия разработки
Этапы выполнения работ
Рабочая конструкторская документация:
а) опытного образца (опытной партии) изделия,
предназначенного для серийного (массового) или
единичного производства (кроме разового
изготовления)
Разработка конструкторской
документации, предназначенной для изготовления
и испытания опытного образца (опытной
партии), без присвоения литеры.
Изготовление и предварительные испытания
опытного образца (опытной партии).
Корректировка конструкторской
документации по результатам изготовления и
предварительных испытаний опытного
образца (опытной партии) с присвоением
документам литеры «О». Приемочные
испытания опытного образца (опытной
партии). Корректировка конструкторской
документации по результатам приемочных
испытаний опытного образца (опытной
партии) с присвоением документам
литеры «01». Для изделия,
разрабатываемого по заказу Министерства обороны, при
необходимости, — повторное
изготовление и испытания опытного образца
(опытной партии) по документации с
литерой «01» и корректировка
конструкторских документов с присвоением
им литеры «02»
Рабочая конструкторская документация:
б) серийного (массового) производства
Изготовление и испытание установочной
серии по документации с литерой «01»
(или «02»). Корректировка
конструкторской документации по результатам
изготовления и испытания установочной
серии, а также оснащения
технологического процесса изготовления
изделия, с присвоением конструкторским
документам литеры «А». Для изделия,
разрабатываемого по заказу
Министерства обороны, при необходимости, —
изготовление и испытание головной
(контрольной) серии по документации
с литерой «А» и соответствующая
корректировка документов с присвоением
им литеры «Б»
Техническое предложение — совокупность конструкторских документов,
которые должны содержать технические и технико-экономические обоснования
целесообразности разработки документации изделия на основании анализа
технического задания заказчика и различных вариантов возможных решений
изделий, сравнительной оценки решений с учетом конструктивных и
эксплуатационных особенностей разрабатываемого и существующих изделий и патентные
исследования.

80 Глава 6 • Жизненный цикл технической документации
Техническое предложение после согласования и утверждения в
установленном порядке является основанием для разработки эскизного
(технического) проекта.
Объем работ — по ГОСТ 2.118-73. Единая система конструкторской
документации. Техническое предложение.
Эскизный проект — совокупность конструкторских документов, которые
должны содержать принципиальные конструктивные решения, дающие общее
представление об устройстве и принципе работы изделия, а также данные,
определяющие назначение, основные параметры и габаритные размеры
разрабатываемого изделия.
Эскизный проект после согласования и утверждения в установленном
порядке служит основанием для разработки технического проекта или рабочей
конструкторской документации.
Объем работ — по ГОСТ 2.119-73. Единая система конструкторской
документации. Эскизный проект.
Технический проект — совокупность конструкторских документов, которые
должны содержать окончательные технические решения, дающие полное
представление об устройстве разрабатываемого изделия, и исходные данные для
разработки рабочей документации.
Технический проект после согласования и утверждения в установленном
порядке служит основанием для разработки рабочей конструкторской
документации.
Объем работ — по ГОСТ 2.120-73. Единая система конструкторской
документации. Технический проект.
Общий порядок проверки, согласования и утверждения ТД определяется
требованиями ГОСТ 2.902-68. Единая система конструкторской
документации. Порядок проверки, согласования и утверждения документации. Действие
данного стандарта распространяется на ТД изделий народнохозяйственного
назначения, поставляемых Министерству обороны, однако его некоторые
положения на усмотрение разработчика целесообразно использовать при создании
любой ТД, вне зависимости от ее назначения.
Конкретный порядок разработки, согласования и утверждения ТД обычно
определяется стандартом организации-разработчика, базирующимся на
требованиях СРПП, ЕСКД, ЕСПД, ЕСТД и ГСИ, в котором определяется
разработчик того или иного документа, номенклатура и расположение в его тексте
согласующих и утверждающих подписей.
Исходные данные для разработки такого стандарта приведены в
приложении В на компакт-диске.
На сегодняшний день основной формой представления технической
документации (подлинников и копий) является бумажная форма, хотя
оригиналами ТД могли бы служить и электронные документы.
До недавнего времени не существовало нормативных документов по
электронной документации, и лишь год назад в комплексе стандартов ЕСКД
появились ГОСТ, регламентирующие отдельные аспекты, связанные с
электронными документами. Это — ГОСТ 2.051-2006. ЕСКД. Электронные документы.
Общие положения, ГОСТ 2.052-2006. ЕСКД. Электронная модель изделия.

6.1. Стадии разработки ТД 81
Общие положения и ГОСТ 2.053-2006. ЕСКД. Электронная структура
изделия. Общие положения. К сожалению, этих стандартов явно недостаточно для
создания полноценных электронных документов, которые могли бы наравне
с бумажными полностью соответствовать требованиям, предъявляемым к
подлинным документам.
И хотя Постановлением Госстандарта России от 12 сентября 2001 г. был
введен в действие ГОСТ Р 34.10-2001. Информационная технология.
Криптографическая защита информации. Процессы формирования и проверки
электронной цифровой подписи —ЭЦП (http://yvvm.termika.rn/dou/docs/gost3410.html),
10 января 2002 г. принят Федеральный закон Российской Федерации № 1-ФЗ
«Об электронной цифровой подписи» (hty://www.signak^
indecphp), за время существования этих документов закон так и не обрел
действительно широкого применения в силу ряда причин. Прежде всего потому, что
является, по своей сути, техническим дополнением к другим законопроектам,
таким, как «Об электронном документе», «Об электронной торговле», «О
предоставлении электронных и финансовых услуг», которые до настоящего
времени не приняты Госдумой.
Кроме того, по мнению экспертов, ряд причин, послуживших сдерживанию
применения закона на практике, был заложен в самом законе:
• до сих пор не заработала система лицензирования ЭЦП;
• не сформулированы материальные и финансовые требования к
удостоверяющим центрам;
• предусмотрен только один формат электронной подписи (технология
открытых ключей), предполагающий наличие государственного корневого
удостоверяющего центра, то есть полностью зависимый от используемой
технологии;
• отсутствует и до сих пор не принята подзаконными актами регламентация
вопросов признания иностранных электронных подписей.
Для устранения указанных недостатков Мининформсвязи РФ намерено
внести соответствующие поправки в Федеральный закон об ЭЦП, с тем чтобы
сделать его реально работоспособным. В проекте нового закона закреплены
различные виды электронных подписей, существующих в настоящий момент
в РФ. По мнению разработчиков законопроекта, участники правовых
отношений вправе по своему усмотрению использовать ту электронную подпись,
которую они считают наиболее приемлемой для себя. Также механизм
лицензирования деятельности удостоверяющих центров заменен добровольной
аккредитацией. Кроме того, будут уточнены полномочия федерального органа
исполнительной власти в сфере электронной подписи, закреплены условия
использования подписи на основании сертификата, выданного иностранным
удостоверяющим центром, закреплена ответственность удостоверяющего
центра за нарушение обязанностей.
Таким образом, единственным легитимным техническим документом пока
можно считать только бумажный документ, а его электронная форма может
рассматриваться лишь как инструмент для создания полноценных оригиналов
и подлинников.

82 Глава б • Жизненный цикл технической документации
О нормах времени на разработку технической документации. Известны
три документа, которые в той или иной степени, пусть косвенно, но нормируют
труд разработчика технической документации. Это — типовые нормы времени
на разработку КД (проектирование технологического оснащения),
утвержденные Постановлением Госкомтруда СССР и Секретариата ВЦСПС 17 марта
1986 г. № 93/6-6 (приложение Г на компакт-диске), которые могут быть приняты
за основу при оценке трудоемкости создания чертежей механических узлов.
Также существует справочник базовых цен на разработку технической
документации на автоматизированные системы управления (АСУТП), утвержденный
Министерством промышленности Российской Федерации 14 марта 1997 г.
(приложение Д на компакт-диске), в котором приведены данные о
трудоемкости разработки проектной документации на АСУТП. Третий документ —
межотраслевые укрупненные нормативы времени на работы по документационно-
му обеспечению управления, утвержденные Постановлением Минтруда РФ от
25 ноября 1994 г. № 72 (приложение Е на компакт-диске). На основе
упомянутых документов и личного опыта разработки документации можно считать, что
на разработку одного стандартного листа текстовой технической документации
формата А4 требуется от 0,5 до 4,0 часов в зависимости от степени сложности
и подготовленности исходных данных.
Информационные источники
ГОСТ 2.103-68. Единая система конструкторской документации. Стадии
разработки.
ГОСТ 2.118-73. Единая система конструкторской документации.
Техническое предложение.
ГОСТ 2.119-73. Единая система конструкторской документации.
Эскизный проект.
ГОСТ 2.120-73. Единая система конструкторской документации.
Технический проект.
ГОСТ 2.902-68. Единая система конструкторской документации. Порядок
проверки, согласования и утверждения документации.
ГОСТ 15.001-97. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
ГОСТ Р 15.000-94. Система разработки и постановки продукции на
производство. Основные положения.
Федеральный закон Российской Федерации № 1-ФЗ «Об электронной
цифровой подписи» (ht^://www.signal-com.ru/ru/law/law_284/law.ll3/index.php).

6.2. Нормоконтроль, учет, хранение и оборот ТД 83
6.2. Нормоконтроль, учет, хранение и оборот ТД.
Внесение изменений в техническую
документацию. Информационная защита ТД
Техническая документация, созданная разработчиком, в соответствии с ГОСТ
2.111-68. Единая система конструкторской документации. Нормоконтроль
и ГОСТ 3.1116-79. Единая система технологической документации.
Нормоконтроль подлежит обязательной проверке службой нормативного контроля.
Нормоконтролю подлежит конструкторская, технологическая (и
программная) документация на изделия основного и вспомогательного производства
независимо от подчиненности и служебных функций подразделений,
выпустивших указанную документацию.
Проведение нормоконтроля направлено:
• на соблюдение в разрабатываемых изделиях норм и требований,
установленных в государственных, отраслевых, республиканских стандартах
и стандартах предприятий;
• на правильное выполнение конструкторских документов в соответствии
с требованиями стандартов Единой системы конструкторской
документации;
• на достижение в разрабатываемых изделиях высокого уровня
стандартизации и унификации на основе широкого использования ранее
спроектированных, освоенных в производстве и стандартизованных изделий,
типовых конструкторских решений и исполнений;
• на рациональное использование установленных ограничительных
номенклатур стандартизованных изделий, конструктивных норм (резьб,
диаметров, шлицевых соединений, модулей зубчатых колес, допусков и посадок,
конусностей и других элементов деталей машин), марок материалов,
профилей и размеров проката и т. п.
ГОСТ 2.111-68. Единая система конструкторской документации.
Нормоконтроль определяет примерное содержание нормоконтроля в зависимости от
видов документов и стадий разработки. Нормоконтролер в проверяемых
документах наносит карандашом условные пометки к элементам, которые должны быть
исправлены или заменены, и составляет перечень замечаний. Сделанные
пометки сохраняются до подписания подлинников, и снимает их
нормоконтролер. В перечне замечаний нормоконтролера против номера каждой пометки
кратко и ясно излагается содержание замечаний и предложений. Разработчик
документации обязан исправить ее в соответствии с замечаниями
нормоконтролера Разногласия разрешаются в установленном стандартом порядке.
Нормоконтроль является завершающим этапом разработки
конструкторской документации. В соответствии с этим передачу подлинников документов
на хранение отделу технической документации или заменяющему его
подразделению рекомендуется поручать нормоконтролеру.

84 Глава б • Жизненный цикл технической документации
Документацию, утверждаемую руководителем организации или
предприятия, нормоконтролер визирует до передачи на утверждение и подписывает в
установленном месте после утверждения.
Исправлять и изменять подписанные нормоконтролером, но не сданные на
хранение подлинники документов без его ведома не допускается.
Исправленные по результатам нормоконтроля, подписанные и
утвержденные в установленном порядке подлинники документов в обязательном порядке
учитываются и передаются на хранение в архив технической документации.
Правила учета и хранения ТД определены требованиями ГОСТ 2.501-88.
Единая система конструкторской документации. Правила учета и хранения,
ГОСТ 19.601-78. Единая система программной документации. Общие
правила дублирования, учета и хранения.
Согласно этим правилам подлинники документов, пришедшие в негодность
или утерянные, должны быть восстановлены. В восстановленный подлинник
должны быть внесены все внесенные в него изменения. В листе регистрации
изменений восстановленного подлинника должны быть воспроизведены данные,
относящиеся ко всем ранее внесенным в этот документ изменениям (начиная
с первого изменения). Взамен подлинных подписей, виз и дат, имеющихся на
подлиннике (в том числе на поле для подшивки и листе регистрации
изменений), в восстановленном подлиннике в круглых скобках должно быть
написано: «(Подпись)» и «(дата)». Восстановленные подлинники должны быть
подписаны ответственным лицом по указанию руководителя подразделения,
выпустившего подлинники или ведущего наблюдение за изготовлением изделия.
Также подлежат учету и хранению копии, выполненные с подлинников
документов. На предприятии могут хранить следующие копии конструкторских
и технологических документов: архивные, контрольные и рабочие. Архивные
и контрольные копии абонентам не выдают.
Для текущей работы подразделению, выпустившему подлинники
документов или ведущему наблюдение за изготовлением изделия в производстве,
выделяют экземпляр копий соответствующих документов. На лицевой стороне
каждого листа копий или на самом видном месте папки (альбома) ставят штамп
«ЭКЗЕМПЛЯР РАЗРАБОТЧИКА».
На копиях документов, об изменениях которых после высылки абонентов не
извещают, ставят штамп «ОБ ИЗМЕНЕНИИ НЕ СООБЩАЕТСЯ».
Копии документов, изъятых из обращения вследствие прекращения
производства изделий, а также копии документов, аннулированных или замененных
в связи с внесением изменений, уничтожают после составления акта об
уничтожении или описи копий.
Внесение изменений в техническую документацию осуществляется в
соответствии с ГОСТ 2.503-90. Единая система конструкторской документации.
Правила внесения изменений, ГОСТ 2.603-68. Единая система
конструкторской документации. Внесение изменений в эксплуатационную и ремонтную
документацию, ГОСТ 19.603-78. Единая система программной
документации. Общие правила внесения изменений.
Под изменением документа понимается любое исправление, исключение или
добавление каких-либо данных в этот документ. Изменения в документы вносят
в случае, если они не нарушают взаимозаменяемость изделия с изделиями,

6.2. Нормоконтроль, учет, хранение и оборот ТД 85
изготовленными ранее. Любое изменение в документе, вызывающее какие-либо
изменения в других документах, должно одновременно сопровождаться
внесением соответствующих изменений во все взаимосвязанные документы.
Изменение документов на всех стадиях жизненного цикла изделия
производят на основании извещения об изменении (ИИ), форма которого
приводится в приложении 2 к ГОСТ 2.503-90.
Выпускать ИИ и вносить изменения в подлинники изменяемых документов
имеет право только предприятие — держатель подлинников этих документов.
Изложенные в извещении указания обязательны для всех подразделений
предприятия, выпустившего извещение, а также предприятий, применяющих
изменяемую документацию.
Изменения в документы вносят рукописным, машинописным или
автоматизированным (машинным) способом.
Внесение изменений в документы производят зачеркиванием, подчисткой
(смывкой), закрашиванием белым цветом, введением новых данных, заменой
листов и (или) документов, введением новых дополнительных листов и (или)
документов.
Изменение документа, выполненного автоматизированным способом,
осуществляют заменой (перевыпуском) всего документа в целом или его отдельных
листов (страниц), а также добавлением или исключением отдельных листов.
Допускается вносить изменения в эти документы рукописным или
машинописным способом.
Изменения обозначают порядковыми номерами арабскими цифрами A, 2,3
и т. д.). Один порядковый номер изменения присваивают всем изменениям,
которые вносят в документ по одному извещению. Его указывают для всего
документа, независимо от того, на скольких листах он выполнен.
ИИ составляют на один или несколько документов. Одно ИИ составляют на
несколько документов при условии одновременного внесения изменений во все
изменяемые документы. Каждое ИИ должно иметь обозначение, состоящее из
кода предприятия, выпустившего ИИ, и отделенного точкой порядкового
регистрационного номера. Порядковый регистрационный номер обозначения ИИ
устанавливают в пределах предприятия. Допускается к обозначению ИИ
добавлять последние две цифры года выпуска ИИ, отделенные дефисом. ИИ
выполняют на любом материале, позволяющем производить многократное снятие
с них копий, и заполняют любым способом.
Изменения, внесенные в подлинник, указывают: в таблице изменений
основной надписи по ГОСТ 2.104 — для конструкторских документов, в блоке
внесения изменений по ГОСТ 3.1103 — для технологических документов, в
соответствии с ГОСТ 19.603 — для программных документов или в листе регистрации
(ЛР) изменений.
Если для внесения изменений недостаточно места или возможно нарушение
четкого изображения при исправлении, изготовляют новый подлинник с
учетом вносимых изменений и сохраняют его прежнее обозначение.
При добавлении нового листа документа допускается присваивать ему номер
предыдущего листа с добавлением очередной строчной буквы русского алфавита
или через точку арабской цифры, например: За или 3.1. При этом на первом
(заглавном) листе изменяют общее количество листов.

86 Глава б • Жизненный цикл технической документации
В текстовых документах, содержащих в основном сплошной текст,
допускается при добавлении нового пункта (раздела, подраздела, подпункта), таблицы,
графического материала присваивать им номер предыдущего пункта (раздела,
подраздела, подпункта), таблицы, графического материала с добавлением
очередной строчной буквы русского алфавита.
При аннулировании пункта (раздела, подраздела, подпункта), таблицы,
графического материала сохраняют номера последующих пунктов (раздела,
подраздела, подпункта), таблиц, графических материалов.
Все оформленные ИИ с приложениями, при их наличии, передаются в службу
технической документации. Одновременно с ИИ передаются подлинники,
выпущенные в связи с заменой или добавлением листов изменяемых документов,
а также вновь введенные или замененные подлинники.
Определенная часть сведений, содержащихся в технической документации,
может являться коммерческой тайной предприятия и подпадать под действие
Федерального закона от 29 июля 2004 г. № 98-ФЗ «О коммерческой тайне*
(приложение Ж на компакт-диске).
Разработчик ТД, с одной стороны, должен знать свои обязанности по
защите и сохранению коммерческой тайны, содержащейся в разрабатываемых им
документах, и ответственность за раскрытие этих сведений, а с другой
стороны — четко понимать свои права в данном вопросе.
6.2.1 Права
• На предприятии должно иметься Положение о коммерческой тайне,
содержащее перечень сведений, составляющих коммерческую тайну, с которым
разработчик ТД должен быть ознакомлен.
• С разработчиком ТД должен быть оформлен трудовой договор
(дополнительное соглашение к действующему трудовому договору) с оговоркой
об ответственности работника за разглашение сведений, являющихся
коммерческой тайной предприятия. Работа со сведениями,
составляющими коммерческую тайну, должна быть отражена в должностной
инструкции работника.
• На предприятии должны быть созданы условия, позволяющие
разработчику ТД обеспечивать сохранение сведений, составляющих коммерческую
тайну (персональный компьютер с авторизацией входа, защищенное
хранилище носителей информации, инструкция о порядке разработки и
хранения технической документации в электронной и бумажной форме, система
регистрации и учета движения документов и т. п.).
6.2.2. Обязанности
• Разработчик ТД должен четко соблюдать все положения внутренних
нормативных документов, обеспечивающих защиту информации,
содержащейся в разрабатываемых им документах.

6.2. Нормоконтроль, учет, хранение и оборот ТД 87
• Разработчик ТД не должен допускать разглашения сведений,
составляющих коммерческую тайну, по неосторожности, в служебной переписке
и при разговорах как со сторонними лицами, так и с коллегами по работе.
• Разработчик ТД должен немедленно ставить в известность свое
непосредственное руководство обо всех случаях преднамеренных сторонних
попыток завладеть сведениями, составляющими коммерческую тайну.
6.2.3 Ответственность
За умышленное или неосторожное разглашение сведений, составляющих
коммерческую тайну, разработчик ТД может нести ответственность в рамках
трудового, гражданского и уголовного законодательства. Работник может быть
уволен с работы, с него может быть взыскан материальный ущерб, понесенный
предприятием вследствие его неправомерных действий. На работника может
быть наложен штраф или предусмотрено наказание в виде лишения свободы на
срок до трех лет.
Информационные источники
ГОСТ 2.111-68. Единая система конструкторской документации.
Нормоконтроль.
ГОСТ 2.501-88. Единая система конструкторской документации. Правила
учета и хранения.
ГОСТ 2.503-90. Единая система конструкторской документации. Правила
внесения изменений.
ГОСТ 2.603-68. Единая система конструкторской документации. Внесение
изменений в эксплуатационную и ремонтную документацию.
ГОСТ 19.601-78. Единая система программной документации. Общие
правила дублирования, учета и хранения.
ГОСТ 19.603-78. Единая система программной документации. Общие
правила внесения изменений.
ГОСТ 3.1116-79. Цдиная система технологической документации.
Нормоконтроль.
Федеральный закон РФ от 29 июля 2004 г. № 98-ФЗ «О коммерческой
тайне».

Разработка основных видов
текстовой технической
документации на АПК согласно
требованиям ЕСКД

90 Глава 7 • Разработка текстовой технической документации на АПК
7.1. Техническое задание на ОКР
Основными документами, определяющими порядок разработки и содержание
технического задания (ТЗ) на АПК, являются ГОСТ Р 15.201-2000. Система
разработки и постановки продукции на производство. Продукция
производственно-технического назначения. Порядок разработки и постановки
продукции на производство и (с определенными ограничениями) — ГОСТ 34.602-89.
Информационная технология. Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной системы.
Согласно ГОСТ Р 15.201-2000. Система разработки и постановки
продукции на производство. Продукция производственно-технического назначения.
Порядок разработки и постановки продукции на производство ТЗ,
утвержденное заказчиком, и договор (контракт) с ним являются основанием для
выполнения ОКР. В качестве ТЗ может быть использован иной документ,
содержащий необходимые и достаточные требования для разработки продукции и
взаимопризнаваемый заказчиком и разработчиком. В случае инициативной
разработки продукции основанием для выполнения ОКР является
утвержденное руководством предприятия-разработчика ТЗ (или заменяющий его
документ), базирующееся на результатах исследования рынка.
В ТЗ рекомендуется указывать технико-экономические требования к
продукции, определяющие ее потребительские свойства и эффективность
применения, перечень документов, требующих совместного рассмотрения, порядок
сдачи и приемки результатов разработки.
В ТЗ предусматривают реализацию всех обязательных требований,
распространяющихся на данную продукцию. В ТЗ указывают предусмотренную
законодательством форму подтверждения соответствия продукции обязательным
требованиям.
Конкретное содержание ТЗ определяют заказчик и разработчик, а при
инициативной разработке — разработчик. Не допускается включать в ТЗ
требования, которые противоречат законам Российской Федерации и обязательным
требованиям.
В ТЗ рекомендуется предусматривать следующие положения:
• прогноз развития требований на данную продукцию на предполагаемый
период ее выпуска;
• рекомендуемые этапы модернизации продукции с учетом прогноза
развития требований;
• соответствие требованиям стран предполагаемого экспорта с учетом
прогноза развития этих требований;
• характеристики ремонтопригодности;
• возможность замены запасных частей без применения промышленной
технологии;
• доступность и безопасность эффективного использования продукции.

7.1. Техническое задание на ОКР 91
Техническое задание разрабатывают и утверждают в порядке,
установленном заказчиком и разработчиком. К разработке ТЗ могут привлекаться другие
заинтересованные организации (предприятия): изготовитель, торговая
(посредническая) организация, страховая организация,
организация-проектировщик, монтажная организация и др.
Для подтверждения отдельных требований к продукции, в том числе
требований безопасности, охраны здоровья и окружающей среды, а также оценки
технического уровня продукции ТЗ может быть направлено разработчиком или
заказчиком на экспертизу (заключение) в сторонние организации. Решение по
полученным заключениям принимают разработчик и заказчик до утверждения
ТЗ.
На любом этапе разработки продукции при согласии заказчика и
разработчика в ТЗ или документ, его заменяющий, могут быть внесены изменения и
дополнения, не нарушающие условия выполнения обязательных требований.
Согласно ГОСТ 34.602-89. Информационная технология. Комплекс
стандартов на автоматизированные системы. Техническое задание на создание
автоматизированной системы в ТЗ включают следующие разделы, которые могут быть
разделены на подразделы:
• общие сведения;
• назначение и цели создания (развития) системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по созданию системы;
• порядок контроля и приемки системы;
• требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие;
• требования к документированию;
• источники разработки.
Поскольку АПК и АС имеют определенные различия, в ТЗ на ОКР по
созданию АПК нет смысла включать разделы, касающиеся объектов
автоматизации. Рекомендуется следующая структура построения ТЗ на АПК.
1. Наименование ОКР, основание, исполнитель и сроки выполнения ОКР:
1.1. Наименование ОКР
1.2. Основание для выполнения ОКР
1.3. Исполнитель ОКР
1.4. Срок выполнения ОКР
2. Цель выполнения ОКР, наименование и индекс изделия:
2.1. Цель ОКР
2.2. Наименование и индекс образца
3. Технические требования к изделию:
3.1. Состав изделия
3.2. Требования назначения:
3.2.1. Назначение
3.2.2. Функции

92 Глава 7 • Разработка текстовой технической документации на АПК
3.2.3. Метрологические характеристики
3.2.4. Требования к электропитанию
3.3. Требования электромагнитной совместимости
3.4. Требования живучести и стойкости к внешним воздействиям
3.5. Требования надежности
3.6. Требования эргономики, обитаемости и технической эстетики
3.7. Требования к эксплуатации, хранению, удобству технического
обслуживания и ремонта
3.8. Требования транспортабельности
3.9. Требования безопасности
3.10. Требования стандартизации и унификации
3.11. Требования технологичности
3.12. Конструктивные требования
4. Технико-экономические требования
5. Требования к видам обеспечения:
5.1. Требования к метрологическому обеспечению
5.2. Требования к программному обеспечению
6. Требования к сырью, материалам и комплектующим изделиям
7. Требования к консервации, упаковке и маркировке
8. Требования к учебно-тренировочным средствам
9. Специальные требования
10. Этапы выполнения ОКР
11. Порядок выполнения и приемки этапов ОКР
Разумеется, предложенная структура является только схемой. Отдельные
разделы при составлении ТЗ могут быть объединены либо за ненадобностью
опущены.
Образец технического задания на АПК представлен в приложении И на
компакт-диске.
Информационные источники
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения. Порядок
разработки и постановки продукции на производство.
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание
автоматизированной системы.

7.2. Место и роль графической КД при разработке текстовой ТД 93
7.2. Место и роль графической КД
при разработке текстовой ТД
Для разработки текстовой ТД необходимо иметь ряд исходных данных,
источником которых может быть не только техническое задание, но и уже
разработанная при выполнении ОКР КД в графической форме — схемы и чертежи.
Видное место среди этой КД занимает схема деления структурная АПК,
которая является одним из основных конструкторских документов, в существенной
степени определяющих содержание разрабатываемой текстовой ТД и
используемую в ней терминологию. Поэтому во избежание последующей
многократной корректировки текста документов из-за взаимных нестыковок разработчик
ТД должен знать требования нормативных документов к схеме деления
структурной и, в первую очередь, должен изучить эту схему.
Схема деления структурная разрабатывается в соответствии с
требованиями ГОСТ 2.711-82. Единая система конструкторской документации. Схема
деления изделия на составные части.
Схема деления представляет собой конструкторский документ, определяющий
состав изделия, входимость составных частей, их назначение и взаимосвязь.
Схему деления разрабатывают на стадии технического проекта (эскизного
проекта, если технический проект не выполняется) и обозначают и по ГОСТ
2.201-80. Единая система конструкторской документации. Обозначение
изделий и конструкторских документов с присвоением кода Е1 по ГОСТ 2.701-84.
Единая система конструкторской документации. Схемы. Виды и типы. Общие
требования к выполнению.
В схеме деления приводят состав изделия (комплексы, сборочные единицы,
детали, входящие в изделие, как вновь разработанные, так и заимствованные и
покупные). При этом указывают обозначение изделия и его составных частей
по ГОСТ 2.201-80. Единая система конструкторской документации.
Обозначение изделий и конструкторских документов; наименование изделия и его
составных частей. Уровень деления (раскрытия) изделия на составные части
зависит от сложности и специфики изделия и устанавливается разработчиком
изделия по согласованию с заказчиком.
Главным при разработке схемы деления является присвоение и
утверждение наименований и обозначений изделию и его составным частям, которые
в дальнейшем будут фигурировать во всей разрабатываемой текстовой
документации. Условные обозначения изделий и их составных частей,
используемые при разработке схемы деления, представлены на рис. 8.
Нужную информацию при разработке текстовой ТД можно получить и из
других конструкторских документов, в первую очередь — схем
электрических соединений и подключения; сборочного чертежа и чертежа общего вида
и т. д.

94 Глава 7 • Разработка текстовой технической документации на АПК
а — вновь разработанные изделия и составные части;
б—заимствованные изделия; в — покупные изделия
Рис 8. Условные обозначения изделий и их составных частей
Информационные источники
ГОСТ 2.201-80. ЕСКД. Обозначение изделий и конструкторских
документов.
ГОСТ 2.701-84. ЕСКД. Схемы. Виды и типы. Общие требования к
выполнению.
ГОСТ 2.711-82. ЕСКД. Схема деления изделия на составные части.

7.3. Технические условия 95
7.3. Технические условия
Одним из основных текстовых документов на АПК являются технические
условия, разработка которых выполняется в соответствии с требованиями ГОСТ
2.114-95. Цдиная система конструкторской документации. Технические условия.
Технические условия (ТУ) являются неотъемлемой частью комплекта
конструкторской или другой технической документации на продукцию, а при
отсутствии документации должны содержать полный комплекс требований
к продукции, ее изготовлению, контролю и приемке.
Технические условия разрабатывают:
• на одно конкретное изделие, материал, вещество и т. п.;
• на несколько конкретных изделий, материалов, веществ и т. п. (групповые
технические условия).
Требования, установленные ТУ, не должны противоречить обязательным
требованиям государственных (межгосударственных) стандартов,
распространяющихся на данную продукцию.
Если отдельные требования установлены в стандартах или других
технических документах, распространяющихся на данную продукцию, то в ТУ эти
требования не повторяют, а в соответствующих разделах ТУ дают ссылки на эти
стандарты и документы в соответствии с ГОСТ 2.105-95. Единая система
конструкторской документации. Общие требования к текстовым документам.
Здесь для разработчиков ТУ на АПК может оказаться полезным ГОСТ
12997-84. Изделия ГСП. Общие технические условия, который
распространяется на изделия государственной системы промышленных приборов и средств
автоматизации (ГСП), предназначенных для построения автоматических и
автоматизированных систем измерения, контроля, регулирования, диагностики
и управления производственными процессами, технологическими линиями
и агрегатами.
Государственная система промышленных приборов и средств
автоматизации представляет собой эксплуатационно, информационно, метрологически
и конструктивно организованную совокупность средств измерений, средств
автоматизации, средств управляющей вычислительной техники, а также
программных средств (далее — изделия).
Изделия, относящиеся к ГСП, должны выполнять одну или несколько из
следующих функций:
• получение информации;
• передача, ввод и (или) вывод информации;
• преобразование, обработка или хранение информации;
• использование информации;
• вспомогательные (источники питания и др.).

96 Глава 7 • Разработка основных видов текстовой технической документации
Требования пп. 2.15,2.16,2.18,2.20,2.21,2.23,2.25,2.27...2.30, разд. 3 и п. 5.1
настоящего стандарта являются для изделий ГСП обязательными, то есть должны
включаться в их ТУ.
ТУ оформляют на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы с основной надписью — по ГОСТ
2.104-2006. Единая система конструкторской документации. Основные
надписи (формы 2 и 2а), а титульный лист оформляют по ГОСТ 2.105-95. Единая
система конструкторской документации. Общие требования к текстовым
документам со следующими дополнениями: ниже обозначения ТУ при
необходимости указывают в скобках обозначение документа, взамен которого выпущены
данные ТУ по типу «(Взамен...)», дату введения или срок действия ТУ (при
необходимости).
Схемы, чертежи и таблицы, иллюстрирующие отдельные положения ТУ,
выполняют на листах форматов по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы, при этом основную надпись выполняют по
форме 2а ГОСТ 2.104-2006. Единая система конструкторской документации.
Основные надписи.
Обозначение ТУ присваивает разработчик. На изделия машиностроения и
приборостроения ТУ обозначают по ГОСТ 2.201-80. Единая система
конструкторской документации. Обозначение изделий и конструкторских
документов.
Пример - ШРПИ.041221.002ТУ.
Допускается обозначение ТУ формировать из следующих компонентов:
• кода «ТУ»;
• кода группы продукции по классификатору продукции
страны-разработчика ТУ;
• трехразрядного регистрационного номера, присваиваемого разработчиком;
• кода предприятия-разработчика ТУ по классификатору предприятий
страны-разработчика ТУ;
• двух последних цифр года утверждения документа.
Пример обозначения ТУ для Российской Федерации
ТУ 1115-017-38576343-93,
где 1115 — код группы продукции по Общероссийскому классификатору
продукции (ОКП);
38576343 — код предприятия по Общероссийскому классификатору
предприятий и организаций (ОКПО).
Допускается использовать двойное обозначение ТУ.
Пример
ТУ 4311-182-38576343-92 (АБВГ.523142.025),
где 4311 — код группы продукции по Общероссийскому классификатору
продукции (ОКП);
38576343 — код предприятия по Общероссийскому классификатору
предприятий и организаций (ОКПО).
Учет, хранение и внесение изменений в ТУ на изделия машиностроения и
приборостроения проводят в порядке, установленном ГОСТ 2.501-88. Единая

7.3. Технические условия 97
система конструкторской документации. Правила учета и хранения и ГОСТ
2.503-90. Единая система конструкторской документации. Правила внесения
изменений.
ТУ должны содержать вводную часть и разделы, расположенные в
следующей последовательности:
• технические требования;
• требования безопасности;
• требования охраны окружающей среды;
• правила приемки;
• методы контроля;
• транспортирование и хранение;
• указания по эксплуатации;
• гарантии изготовителя.
Состав разделов и их содержание определяет разработчик в соответствии
с особенностями продукции. При необходимости ТУ, в зависимости от вида
и назначения продукции, могут быть дополнены другими разделами
(подразделами), или в них могут не включаться отдельные разделы (подразделы), или
отдельные разделы (подразделы) могут быть объединены в один.
Вводная часть должна содержать наименование продукции, ее назначение,
область применения (при необходимости) и условия эксплуатации.
Наименование продукции должно соответствовать наименованию,
указанному в основном документе1 на эту продукцию.
Изложение вводной части должно начинаться словами: «Настоящие
технические условия распространяются на ... (наименование, условное обозначение
продукции), предназначенный (-ую, -ое) для ..>.
Пример
«Настоящие технические условия распространяются на тепловоз
магистральный А-62, предназначенный для грузовых и пассажирских перевозок в
условиях влажного тропического климата» или «Настоящие технические
условия распространяются на эмаль БТА-185, предназначенную для окрашивания
изделий, эксплуатируемых в условиях влажного тропического климата».
В конце вводной части приводят пример записи продукции в других
документах и (или) при заказе.
Если в продукции, на которую отсутствует конструкторская (техническая)
документация, использованы изобретения, то в конце вводной части
(последним абзацем) приводят сведения об использованных изобретениях.
В разделе «Технические требования» должны быть приведены требования и
нормы, определяющие показатели качества и потребительские
(эксплуатационные) характеристики продукции.
1 Для изделий машиностроения и приборостроения основным документом является
спецификация. Для материалов, веществ и т. п. основным документом является рецептурный,
технологический или другой документ, который в совокупности с другими записанными
в нем документами полностью и однозначно определяет данную продукцию.

98 Глава 7 • Разработка основных видов текстовой технической документации
Раздел должен начинаться словами: «... (наименование продукции) должен
(-на, -но) соответствовать требованиям настоящих технических условий и
комплекта документации согласно ... (обозначение основного
конструкторского или другого технического документа)».
При наличии стандартов, общих технических условий, а также стандартов
на конкретное изделие тут же должна быть ссылка на них.
Раздел в общем случае должен состоять из следующих подразделов:
• основные параметры и характеристики (свойства);
• требования к сырью, материалам, покупным изделиям;
• комплектность;
• маркировка;
• упаковка.
В подразделе «Основные параметры и характеристики (свойства)» помещают:
• основные параметры и характеристики, характеризующие тип (вид,
марку, модель) продукции (при необходимости дают ее изображение с
габаритными, установочными и присоединительными размерами или дают
ссылку на конструкторские или другие технические документы с
указанием их обозначений). При необходимости чертежи изделий, на которые
даны ссылки, допускается помещать в приложении к ТУ. При разработке
групповых ТУ в разделе указывают коды ОКП каждого исполнения по
классификатору продукции страны-разработчика;
• требования назначения, характеризующие свойства продукции,
определяющие ее основные функции, для выполнения которых она предназначена в
заданных условиях, требования совместимости и взаимозаменяемости,
например: требования к производительносга, точности, быстроте обработки,
прочности, калорийности и т. п.; требования к составу и структуре (химическому,
фракционному, концентрации примесей, содержанию компонентов и т. п.),
физико-химическим, механическим и другим свойствам (прочность,
твердость, теплостойкость, износоустойчивость и т. п.); требования по
функциональной, геометрической, биологической, электромагнитной, электрической,
прочностной, программной, технологической, метрологической,
диагностической, организационной, информационной и другим видам совместимости;
• требования надежности к выполнению продукцией своих функций с
заданной эффективностью в заданном интервале времени и их сохранению
при заданных условиях технического обслуживания, ремонта, хранения,
транспортирования, в том числе количественные требования, в виде
значений комплексных показателей надежности продукции и (или)
единичных показателей ее безопасности, долговечности, ремонтопригодности и
сохраняемости. На продукцию, использование которой по истечении
определенного срока представляет опасность для жизни, здоровья людей,
окружающей среды или может причинить вред имуществу граждан,
должны устанавливаться сроки службы. На продукцию, потребительские
свойства которой могут ухудшиться с течением времени (продукты питания,
парфюмерно-косметические товары, медикаменты, изделия бытовой
химии и прочие), должны указываться сроки годности;

7.3. Технические условия 99
• требования радиоэлектронной защиты к продукции по обеспечению
помехозащищенности, защиты от электромагнитных и ионизирующих
излучений как собственных, так и посторонних, преднамеренных
электромагнитных излучений и других электронных излучений естественного и
искусственного происхождения;
• требования стойкости к внешним воздействиям и живучести, направленные
на обеспечение работоспособности продукции при воздействии и (или) после
воздействия сопрягаемых объектов и природной среды либо специальных
сред, в том числе: требования стойкости к механическим воздействиям
(вибрационным, ударным, скручивающим, ветровым и т. п.); требования стойкости
к климатическим воздействиям (колебаниям температуры, влажности и
атмосферного давления, солнечной радиации, атмосферных осадков, соленого
(морского) тумана, пыли, воды и т. п.); требования стойкости к специальным
воздействиям (биологическим, радиоэлектронным, химическим, в том числе
агрессивным газам, моющим средствам, топливу, маслам и т. п.,
электромагнитным полям, средствам дезактивации, дегазации, дезинфекции и т. п.);
• требования эргономики, направленные на обеспечение согласования
технических характеристик продукции с эргономическими
характеристиками и свойствами человека (требования к рабочим местам
обслуживающего персонала, соответствие изделия и его составных частей размерам
тела человека и т. п.);
• требования экономного использования сырья, материалов, топлива,
энергии и трудовых ресурсов, направленные на экономное использование сырья,
материалов, топлива, энергии и трудовых ресурсов при производстве
продукции и при регламентированном режиме использования (применения)
продукции по назначению (удельный расход сырья, материалов, топлива,
энергии и энергоносителя, а также коэффициент полезного действия,
трудоемкость в расчете на единицу потребительских свойств и т. п.);
• требования технологичности, определяющие приспособленность
продукции к изготовлению, эксплуатации, ремонту с минимальными затратами
при заданных значениях показателей качества;
• конструктивные требования, предъявляемые к продукции в форме
конкретных конструктивных решений, обеспечивающих наиболее
эффективное выполнение продукцией ее функций, а также рациональность при ее
разработке, производстве и применении: предельно допустимые масса и
габаритные размеры продукции; обеспечение внешних связей и
взаимодействие с другими изделиями, их совместимость, взаимозаменяемость,
направления вращения, направления движения и т. п.; конструкционные
материалы, виды покрытий (металлические и неметаллические) и их
функциональное назначение (защита от коррозии и т. п.); требования
исключения возможности неправильной сборки и неправильного
подключения кабелей, шлангов и других ошибок обслуживающего персонала во
время технического обслуживания и ремонта; применение базовых
конструкций и базовых изделий; агрегатирования и блочно-модульного
построения изделий и т. п.
Требования, помещаемые в подразделе «Основные параметры и
характеристики (свойства)», указываются применительно к режимам и условиям ее
эксплуатации (применения) и испытаний продукции.

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

7.3. Технические условия 101
• правила подготовки продукции к упаковыванию (включая демонтаж,
консервацию) с указанием применяемых средств;
• потребительскую транспортную тару, в том числе многооборотную
тару, вспомогательные материалы, применяемые при упаковывании, а
также требования технической этикетки (для товаров народного
потребления);
• количество продукции в единице потребительской упаковки и
транспортной тары;
• способы упаковывания продукции в зависимости от условий
транспортирования (в таре, без тары и т. п.);
• порядок размещения и способ укладывания продукции;
• перечень документов, вкладываемых в тару при упаковывании, и способ
их упаковывания.
В разделе «Требования безопасности» устанавливают требования, которые
должны содержать все виды допустимой опасности и устанавливаться таким
образом, чтобы обеспечивалась безопасность продукции в течение срока ее
службы (годности).
В разделе указывают: требования электробезопасности; требования
пожарной безопасности; требования взрывобезопасности; требования радиационной
безопасности; требования безопасности от воздействия химических и
загрязняющих веществ, в том числе предельно допустимые концентрации веществ
или входящих в них компонентов; требования безопасности при обслуживании
машин и оборудования, в том числе требования безопасности при ошибочных
действиях обслуживающего персонала и самопроизвольном нарушении
функционирования; требования к защитным средствам и мероприятиям обеспечения
безопасности, в том числе к устройству ограждений, ограничений хода,
блокировок, концевых выключателей подвижных элементов, креплений и
фиксаторов подвижных частей, оснащению рабочих мест, органам управления и
приборам контроля, аварийной сигнализации, требования к нанесению сигнальных
цветов и знаков безопасности, требования по удалению, снижению,
локализации опасных и вредных производственных факторов в местах их образования.
При необходимости приводят класс опасности, допустимые уровни опасных
и вредных производственных факторов, создаваемых оборудованием и
машинами, характер действия вещества на организм человека, сведения о
способности материала, вещества к образованию токсичных и пожарю- и взрывоопасных
соединений в воздушной среде и сточных водах в присутствии других веществ
или факторов, сведения о пожаро- и взрывоопасных свойствах материала,
вещества и мерах по предупреждению их самовозгорания и (или) взрыва,
способы обезвреживания и захоронения вещества, материала с выраженными
токсичными и пожаро- и взрывоопасными свойствами.
В разделе «Требования охраны окружающей среды» устанавливают
требования для предупреждения вреда окружающей природной среде, здоровью и
генетическому фонду человека при испытании, хранении, транспортировании,
эксплуатации (применении) и утилизации продукции, опасной в экологическом
отношении.

102 Глава 7 • Разработка основных видов текстовой технической документации
В раздел включают показатели и нормы, определяющие:
• требования по допустимым (по уровню и времени) химическим,
механическим, радиационным, электромагнитным, термическим и
биологическим воздействиям на окружающую среду;
• требования по устойчивости загрязняющих, ядовитых веществ в объектах
окружающей среды (водная среда, атмосферный воздух, почва, недра,
флора, моносфера и т. д.);
• требования при утилизации и к местам захоронения опасной
продукции и отходов и т. д.
В разделе «Правила приемки» указывают порядок контроля продукции,
порядок и условия предъявления и приемки продукции органами технического
контроля предприятия-изготовителя и потребителем (заказчиком), размер
предъявляемых партий, необходимость и время выдержки продукции до начала
приемки, сопроводительную предъявительскую документацию, а также
порядок оформления результатов приемки.
В зависимости от характера продукции устанавливают программы
испытаний (например, приемосдаточных, периодических, типовых, на надежность),
а также указывают порядок использования (хранения) продукции, прошедшей
испытания, необходимость отбора и хранения образцов для повторного
(дополнительного) испытания и т. п.
Для каждой категории испытаний устанавливают периодичность их
проведения, количество контролируемых образцов, перечень контролируемых
параметров, норм, требований и характеристик продукции и последовательность,
в которой осуществляется контроль. Возможность изменения
последовательности проведения контроля, при необходимости, оговаривается особо.
При выборочном или статистическом контроле качества указывают план
контроля (объем контролируемой партии, объем выборок для штучной или проб для
нештучной продукции, контрольные нормативы и решающие правила).
В разделе оговаривают правила и условия приемки, порядок и условия за-
бракования продукции и возобновления приемки (повторного контроля) после
анализа выявленных дефектов и их устранения.
Если повторный контроль возвращенной продукции не допускается, то это
должно быть оговорено в ТУ особо.
В разделе должны быть оговорены условия и порядок окончательного за-
бракования продукции.
В разделе, при необходимости, должен быть установлен порядок и место
проставления клейм, штампов, пломб, подтверждающих приемку продукции
органами контроля.
В разделе «Методы контроля» устанавливают приемы, способы, режимы
контроля (испытаний, измерений, анализа) параметров, норм, требований и
характеристик продукции, необходимость контроля которых предусмотрена в
разделе «Правила приемки».
Методы контроля (испытаний, измерений, анализа) должны быть
объективными, четко сформулированными, точными и должны обеспечивать
последовательные и воспроизводимые результаты.

7.3. Технические условия 103
Методы и условия контроля (испытаний, измерений, анализа) должны быть
максимально приближены к условиям использования продукции.
Допускается устанавливать несколько эквивалентных методов контроля
параметров и свойств продукции.
Для каждого метода контроля (испытаний, измерений, анализа), в
зависимости от специфики проведения, должны быть установлены:
• методы отбора проб (образцов);
• оборудование, материалы и реактивы и др.;
• подготовка к контролю (испытанию, измерению, анализу);
• проведение контроля (испытания, измерения, анализа);
• обработка результатов.
Если для нескольких методов контроля содержание отдельных требований
совпадает, то соответствующие требования приводят только для первого
метода, а для остальных дают ссылки на первый метод.
При изложении методов отбора проб (образцов) следует указывать место,
способ отбора и количество проб (образцов), их форму, вид, размеры или
массу. Если необходима средняя проба, то указывают методы ее отбора.
При изложении требований к оборудованию, материалам и реактивам
приводят перечень применяемого оборудования (установок, приборов,
приспособлений, инструмента) и нормы его погрешности, а также перечень материалов
и реактивов, используемых при испытаниях.
При необходимости однозначного определения конкретного вида или
конкретной марки оборудования, материала или реактива должно быть дано их
условное обозначение и указаны документы, по которым осуществляют их
поставку.
При применении универсального оборудования указывают его наименование,
класс или точность и т. п.
При применении оборудования, материалов или реактивов, изготавливаемых
специально для контроля данной продукции, в тексте ТУ или в приложении
к ним приводят описание схемы, рецептуры или ссылки на соответствующую
документацию, необходимую для их изготовления и контроля их качества.
Допускаемая эквивалентная замена средств контроля должна быть
оговорена конкретно с указанием особенностей применения этих средств. При этом
в ТУ должно быть оговорено, какое средство контроля является арбитражным.
При изложении требований по подготовке продукции к контролю
(испытанию, измерениям, анализу) указывают данные, касающиеся подготовки к
контролю продукции, а также оборудования, материалов и реактивов, необходимых
для контроля.
В тексте ТУ или в приложении к ТУ, при необходимости, приводят схемы
соединения оборудования с контролируемой продукцией.
При изложении требований к проведению контроля приводят
последовательность проводимых операций, их описание, а также, при необходимости,
порядок ведения записей.
Если в процессе контроля проводится проверка возможности подстройки
(регулировки) параметров или проведения операций, аналогичных проводимым

104 Глава 7 • Разработка основных видов текстовой технической документации
в условиях эксплуатации, то методы их выполнения должны совпадать с
оговоренными в эксплуатационной документации.
При описании операций контроля приводят указания по технике
безопасности и особые меры предосторожности.
При изложении требований к обработке результатов приводят расчетные
формулы, указывают точность вычислений и степень округления полученных
данных, а также допускаемые расхождения при параллельных определениях
(расчетах).
ПРИМЕЧАНИЕ
Методы контроля, средства контроля, а также оборудование, применяемое при контроле, не
указывают в ТУ, если они установлены в государственных и отраслевых стандартах, а также в
инструкциях или программах и методиках испытаний, разрабатываемых в соответствии
с ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность
конструкторских документов, при этом в ТУ должна быть ссылка на эти документы.
В разделе «Транспортирование и хранение» устанавливают требования
к обеспечению сохраняемости продукции при ее транспортировании и
хранении, в том числе по обеспечению безопасности.
В разделе указывают виды транспорта (воздушный, железнодорожный,
морской, автомобильный) и транспортных средств (крытые или открытые вагоны,
рефрижераторные вагоны, цистерны, трюмы или палубы судов, закрытые
автомашины и т. п.), способы крепления и укрытия продукции в этих средствах,
а также требования по перевозке продукции в универсальных,
специализированных контейнерах, специализированным транспортом и в пакетах, количество
мест (массу) продукции в контейнерах, габаритные размеры пакетов, порядок
размещения пакетов и т. д.
В разделе указывают параметры транспортирования (допускаемую
дальность, скорость и т. п.) и допустимые механические воздействия при
транспортировании, климатические условия, специальные требования к продукции при
транспортировании (необходимость защиты от внешних воздействующих
факторов, от ударов при погрузке и выгрузке и правила обращения с продукцией
после транспортирования при отрицательных температурах, порядок
расконсервации и т. п.).
В разделе указывают условия хранения продукции, обеспечивающие ее
сохранность, в том числе требования к месту хранения продукции (навес, крытый
склад, отапливаемое помещение и т. д.), к защите продукции от влияния
внешней среды (влаги, вредных испарений и т. п.), температурный режим хранения,
а при необходимости — требования к срокам периодических осмотров
хранимой продукции, регламентным работам, а также необходимые методы
консервации и консервационные материалы, марку и документы, по которым
осуществляют их поставку, либо дают ссылки на соответствующие документы.
Кроме того, приводят способ укладывания продукции (в штабеля, на
стеллажи, подкладки и т. п.), а также специальные правила хранения
скоропортящейся, ядовитой, огнеопасной, взрывоопасной и тому подобной продукции.
Правила хранения продукции излагают в следующей последовательности:
• место хранения;
• условия хранения;

7.3. Технические условия 105
• условия складирования;
• специальные правила и сроки хранения (при необходимости).
Требования к транспортированию и хранению могут быть приведены
только при отсутствии на данную продукцию стандарта транспортирования и
хранения.
В разделе «Указания по эксплуатации» приводят указания по установке,
монтажу и применению продукции на месте ее эксплуатации (применения),
например: способ соединения с другой продукцией; требования к условиям
охлаждения с указанием, при необходимости, критериев и методов контроля;
возможность работы в других средах; особые условия эксплуатации
(необходимость защиты от электрических и радиационных полей, требования
периодической тренировки, эксплуатационного обслуживания и т. п.) — либо дают ссылки
на соответствующие документы.
Раздел «Гарантии изготовителя» должен быть изложен в соответствии с
ныне действующим ГОСТ 22352.
В приложении к ТУ, при необходимости, приводят:
• перечень документов (стандартов, инструкций, технических условий и
других документов), на которые даны ссылки в данных ТУ;
• перечень оборудования (стендов, приборов, приспособлений, оснастки,
инструмента, посуды и др.), материалов и реактивов, необходимых для
контроля продукции;
• краткое описание с характеристиками оборудования, материалов и
реактивов, необходимых для контроля продукции;
• указания по применению и периодической проверке, если эти данные не
изложены в самостоятельных документах.
ТУ подлежат согласованию на приемочной комиссии, если решение о
постановке продукции на производство принимает приемочная комиссия.
Разработчик согласовывает с заказчиком (потребителем) ТУ и вместе с
другими документами, подлежащими согласованию на приемочной комиссии,
направляет их не позднее чем за один месяц до начала ее работы в организации
(на предприятии), представители которой включены в состав приемочной
комиссии по ГОСТ 15.001. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
Подписание акта приемки опытного образца (опытной партии) продукции
членами приемочной комиссии означает согласование ТУ.
ТУ, содержащие требования, относящиеся к компетенции органов
государственного контроля и надзора, если они не являются членами приемочной
комиссии, подлежат согласованию с ними.
Необходимость направления ТУ на согласование в другие заинтересованные
организации, если они не являются членами приемочной комиссии, определяет
разработчик совместно с заказчиком (потребителем).
Если решение о постановке продукции на производство принимают без
приемочной комиссии, ТУ направляют на согласование заказчику
(потребителю).

106 Глава 7 • Разработка основных видов текстовой технической документации
ТУ, содержащие требования, относящиеся к компетенции органов
государственного контроля и надзора, подлежат согласованию с ними.
Необходимость направления ТУ на согласование другим заинтересованным
организациям при наличии в них требований, относящихся к их компетенции,
определяет разработчик совместно с заказчиком (потребителем). ТУ следует
направлять во все организации одновременно.
ТУ, содержащие ссылки на государственные стандарты, включающие
требования к качеству продукции, обеспечивающие ее безопасность для жизни,
здоровья и имущества людей, охрану окружающей среды, а также содержащие
ссылки на правила и нормы, установленные органами государственного контроля
и надзора, могут с ними не согласовываться.
Для технологического комплекса, поставляемого комплектно заказчику
(потребителю), ТУ дополнительно согласовываются с организацией,
осуществляющей монтаж, в части требований, относящихся к ее компетенции, если эти
требования не были согласованы с ней ранее.
Рассмотрение ТУ, представленных на согласование, не должно превышать
20 дней с момента поступления их в организацию.
Согласование ТУ оформляют подписью руководителя (заместителя
руководителя) согласующей организации под грифом «СОГЛАСОВАНО» или
отдельным документом (актом приемочной комиссии, письмом, протоколом
и т. п.), при этом под грифом указывают дату и номер документа.
При согласовании не допускается запись «Согласовано с замечаниями».
Необходимость согласования с потребителем ТУ на продукцию,
разработанную в инициативном порядке, определяет разработчик.
Изменения к ТУ согласовываются в порядке, установленном для ТУ.
Допускается изменения к ТУ согласовывать только с заказчиком (потребителем), если
они не затрагивают ранее согласовавших ТУ организаций.
ТУ утверждает разработчик ТУ.
Изменения к ТУ утверждает держатель подлинника ТУ, если иное не
установлено в договоре о передаче комплекта технической документации.
Утверждение ТУ (изменений к ним) оформляют подписью руководителя
(заместителя руководителя) разработчика под грифом «УТВЕРЖДАЮ» на
титульном листе документа.
ТУ утверждают, как правило, без ограничения срока действия.
Ограничение срока действий ТУ устанавливают, при необходимости, по
согласованию с заказчиком (потребителем).
Образец ТУ на АПК представлен в приложении К на компакт-диске.
Информационные источники
ГОСТ 2.102-68. Единая система конструкторской документации. Виды
и комплектность конструкторских документов.
ГОСТ 2.104-2006. Цдиная система конструкторской документации. Основные
надписи.
ГОСТ 2.105-95. Цдиная система конструкторской документации. Общие
требования к текстовым документам.

7.3. Технические условия 107
ГОСТ 2.114-95. Единая система конструкторской документации.
Технические условия.
ГОСТ 2.201-80. Единая система конструкторской документации.
Обозначение изделий и конструкторских документов.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
ГОСТ 2.501-88. Единая система конструкторской документации. Правила
учета и хранения.
ГОСТ 2.503-90. Единая система конструкторской документации. Правила
внесения изменений.
ГОСТ 15.001-97. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.

108 Глава 7 • Разработка основных видов текстовой технической документации
7.4. Программы и методики испытаний
Согласно ГОСТ Р 15.201-2000. Система разработки и постановки продукции
на производство. Продукция производственно-технического назначения.
Порядок разработки и постановки продукции на производство и ГОСТ
15.309-98. Система разработки и постановки продукции на производство.
Испытания и приемка выпускаемой продукции. Основные положения на всех
стадиях жизненного цикла разработанное и изготовленное изделие
подвергают различным видам испытаний.
Для грамотного составления программ и методик различных видов испытаний
разработчик ТД должен четко ориентироваться в последовательности и сроках их
проведения, назначении и содержании испытаний.
Испытания опытных образцов продукции
Для оценки и контроля качества результатов, полученных на определенных этапах
ОКР, опытные образцы (опытную партию) продукции (головные образцы
продукции) подвергают контрольным испытаниям по следующим категориям:
• предварительные испытания, проводимые с целью предварительной
оценки соответствия опытного образца продукции требованиям ТЗ, а также для
определения готовности опытного образца к приемочным испытаниям;
• приемочные испытания, проводимые с целью оценки всех определенных
ТЗ характеристик продукции, проверки и подтверждения соответствия
опытного образца продукции условиям реальной эксплуатации
(применения, использования) продукции, а также для принятия решений о
возможности промышленного производства и реализации продукции.
Предварительные испытания продукции организует исполнитель ОКР.
По результатам предварительных испытаний выполняется корректировка КД,
после которой документации присваивается литера «О».
Приемочные испытания продукции организует ее разработчик. По
результатам приемочных испытаний также выполняется корректировка КД, после
которой документации присваивается литера «О1».
Предварительные и приемочные испытания проводят по соответствующим
программам и методикам испытаний (далее — программам испытаний),
разрабатываемым и утверждаемым стороной, несущей ответственность за
проведение этих испытаний.
Программа и методика приемочных испытаний опытных образцов
продукции должны, кроме того, содержать проверку качества рабочей
конструкторской и эксплуатационной документации (включая проект технических условий
для промышленного производства продукции) для принятия решения о
пригодности документации в промышленном производстве.
Программы испытаний разрабатывают на основе требований ТЗ,
конструкторской документации с использованием, при необходимости, типовых программ,
типовых (стандартизованных) методик испытаний и других нормативных
документов в части организации и проведения испытаний.

7.4. Программы и методики испытаний 109
В программу испытаний включают:
• объект испытаний;
• цель испытаний;
• объем испытаний;
• условия и порядок проведения испытаний;
• материально-техническое обеспечение испытаний;
• метрологическое обеспечение испытаний;
• отчетность по испытаниям.
В программы испытаний включают перечни конкретных проверок
(решаемых задач, оценок), которые следует проводить при испытаниях для
подтверждения выполнения требований ТЗ со ссылками на соответствующие
методики испытаний.
В методику испытаний включают:
• оцениваемые характеристики (свойства, показатели) продукции;
• условия и порядок проведения испытаний;
• способы обработки, анализа и оценки результатов испытаний;
• используемые средства испытаний, контроля и измерений;
• отчетность.
Методики испытаний, применяемые для определения соответствия
продукции обязательным требованиям, если они не являются типовыми
стандартизованными методиками, должны быть аттестованы в установленном порядке
и согласованы с соответствующими органами государственного надзора.
В процессе испытаний ход и результаты испытаний документально фиксируют
по форме и в сроки, предусмотренные в программе испытаний. В обоснованных
случаях испытания могут быть прерваны или прекращены, что оформляют
документально.
Заданные и фактические данные, полученные при испытаниях, отражают
в протоколе (протоколах). В протоколах испытаний тексты, касающиеся
проверок обязательных требований, следует оформлять в соответствии с
требованиями правил оценки соответствия.
Испытания считают законченными, если их результаты оформлены актом,
подтверждающим выполнение программы испытаний и содержащим оценку
результатов испытаний с конкретными точными формулировками, отражающими
соответствие испытуемого опытного образца продукции требованиям ТЗ.
На стадии подготовки и освоения производства с целью демонстрации
готовности предприятия к выпуску продукции проводят квалификационные
испытания.
Квалификационные испытания проводят по программе, разработанной
изготовителем с участием разработчика продукции и согласованной с
заказчиком. В программе указывают:
• количество единиц продукции, подвергаемых испытаниям и проверкам,
исходя из их сложности, стоимости, надежности и других факторов,
необходимых для достоверных оценок;

110 Глава 7 • Разработка основных видов текстовой технической документации
• все виды испытаний, соответствующих периодическим испытаниям,
указанным в ТУ, а также другие испытания и проверки, позволяющие
достигнуть цели квалификационных испытаний;
• место проведения испытаний.
В программу квалификационных испытаний допускается не включать
проверки отдельных требований КД, которые не могут измениться в ходе работ по
постановке на производство.
Квалификационные испытания организует и обеспечивает их проведение
изготовитель (поставщик) продукции.
Испытания и приемка серийных образцов продукции
Порядок испытаний серийно выпускаемой продукции определяется
требованиями ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции, которые
распространяются на все виды народнохозяйственной продукции, кроме судов и других
изделий, для которых соответствующими стандартами устанавливаются
специальные правила испытаний и приемки.
Под приемкой продукции понимается процесс проверки ее соответствия
требованиям, установленным в стандартах, конструкторской документации,
технических условиях.
Образцом продукции называется единица конкретной продукции,
используемая в качестве представителя этой продукции при испытаниях, контроле и оценке.
Категории испытаний определяются по ГОСТ 16504-81. Система
государственных испытаний. Испытания и контроль качества продукции. Основные
термины и определения.
Согласно ГОСТ 15.309-98. Система разработки и постановки продукции
на производство. Испытания и приемка выпускаемой продукции для контроля
качества и приемки изготовленной продукции устанавливают следующие
основные категории испытаний:
• приемосдаточные;
• периодические.
Для оценки эффективности выпускаемой продукции также проводят типовые
испытания, порядок проведения которых приведен в приложении А к стандарту.
Периодические испытания не проводят в тех случаях, когда при
приемосдаточных испытаниях проверяются все установленные требования к серийной
продукции.
Испытания проводят в соответствии с требованиями стандартов на
продукцию, правил приемки и методов испытаний. При отсутствии подобных
стандартов или при отсутствии в них необходимых требований дополнительные
требования к испытаниям включают в ТУ (программу и методику испытаний,
инструкцию и т. п.).
В документах, по которым проводят испытания любой категории, в общем
случае устанавливаются (непосредственно либо в виде ссылок на другие
документы) следующие положения:
• требования к продукции, подлежащей контролю (включая требования по
безопасности, охране здоровья и окружающей среды, в том числе
гармонизированные с требованиями международных документов);

7.4. Программы и методики испытаний 111
• категории и виды испытаний, включая состав проверок,
последовательность их проведения и распределение по категориям испытаний;
• планы контроля;
• методы и условия (режимы) испытаний;
• требования к средствам испытаний (пределы измерений, пределы
допускаемых погрешностей, расходуемые материалы, безопасность для здоровья
персонала и для окружающей среды и др.);
• требование к количеству единиц продукции, отбираемых для каждой
категории (вида, группы) испытаний, установленной в документах, а также к
порядку отбора единиц продукции;
• требования по подготовке к проведению испытаний;
• порядок обработки данных, полученных при испытаниях, и критерии
принятия решений по ним, а также порядок оформления и представления
результатов испытаний;
• требования к принимаемым решениям и области распространения
результатов испытаний.
Категории испытаний по составу могут включать в себя один или несколько
видов или групп испытаний (механические, электрические, климатические, на
надежность и др.) и (или) видов контроля (визуальный, измерительный и др.)
и проводиться в один или несколько этапов испытаний.
Применяемые при испытаниях и контроле средства измерений и контроля
должны быть поверены, а испытательное оборудование аттестовано в
установленном порядке.
Образцы (единицы) продукции, предъявляемые на испытания, должны быть
укомплектованы в соответствии с требованиями стандартов (при типовых
испытаниях — с требованиями программ и методик). В процессе испытаний не
допускается подстраивать (регулировать) единицы продукции и заменять
входящие в них сменные элементы, если это не предусмотрено специальными
требованиями стандартов на продукцию (в виде непосредственной записи либо в
виде ссылок на другие документы).
Единицу продукции, предназначенную для функционирования совместно
с единицей продукции другого вида, рекомендуется испытывать во
взаимосвязи с последней в условиях, максимально приближенных к реальным условиям
эксплуатации (на стенде, с имитатором и т. п.).
Результаты испытаний единиц продукции считают положительными, а
продукцию — выдержавшей испытания, если она испытана в объеме и
последовательности, которые установлены для данной категории испытаний в стандартах на
продукцию, а результаты подтверждают соответствие испытуемых единиц
продукции заданным требованиям.
Результаты испытаний единиц продукции считают отрицательными, а
продукцию — не выдержавшей испытания, если по результатам испытаний будет
установлено несоответствие продукции хотя бы одному требованию,
установленному в стандартах на продукцию для проводимой категории испытания.
Результаты испытаний единиц продукции по каждой категории должны
быть документально оформлены, в том числе и результаты поэтапных
испытаний (при проведении категории испытаний в несколько этапов, если таковые
предусмотрены в нормативных документах на продукцию).

112 Глава 7 • Разработка основных видов текстовой технической документации
Приемку продукции, изготовленной для поставки заказчику (потребителю)
и (или) непосредственной продажи (реализации) покупателю, проводит отдел
технического контроля (ОТК).
Принятыми считаются единицы (партии) продукции, которые выдержали
приемосдаточные испытания, промаркированы, укомплектованы и упакованы
в соответствии с требованиями стандартов на продукцию и условиями
договоров (контрактов) на ее поставку (реализацию), опломбированы ОТК.
Принятая продукция подлежит отгрузке или передаче на ответственное
хранение.
7.4.1. Приемосдаточные испытания
Приемосдаточные испытания проводит ОТК изготовителя с применением
сплошного или выборочного контроля. Выборочный контроль рекомендуется
проводить статистическими методами в соответствии со стандартами на
статистический контроль. При этом в стандартах на продукцию должны
предусматриваться условия перехода от нормального контроля к ослабленному или
усиленному контролю в зависимости от получаемых результатов контроля по
определенному в стандартах критерию.
На приемосдаточные испытания (приемку) предъявляют единицы, партии,
комплекты продукции, выдержавшие предъявительские испытания и (или)
производственный контроль.
Результаты приемосдаточных испытаний оформляют протоколом (по форме
приложения В стандарта).
Возвращенные единицы (партии) продукции после устранения дефектов
(исключения дефектных изделий), повторной приемки изготовителем (новых
предъявительских испытаний) с положительными результатами повторно
предъявляют на приемосдаточные испытания с документом, подтверждающим
принятые меры.
Повторные приемосдаточные испытания проводят в полном объеме
приемосдаточных испытаний.
В технически обоснованных случаях (в зависимости от характера дефекта)
допускается проводить повторные приемосдаточные испытания по
сокращенной программе, включая только те проверки из объема приемосдаточных
испытаний, по которым выявлены несоответствия установленным требованиям и по
которым испытания при первичном предъявлении не проводились.
7.4.2. Периодические испытания
Периодические испытания проводит изготовитель (поставщик) с привлечением,
при необходимости, других заинтересованных сторон, в том числе
представителей потребителя (заказчика).
Периодические испытания проводят в объеме и последовательности, которые
установлены в стандартах на продукцию для данной категории испытаний.

7.4. Программы и методики испытаний 113
Периодичность испытаний устанавливают в стандартах или договорах на
поставку. Периодичность может быть задана по времени или по количеству
изготовленной продукции (образцов или партий).
Результаты периодических испытаний оформляют актом, который
подписывают участники испытаний и утверждает изготовитель (поставщик).
Если образцы продукции не выдержали периодических испытаний, то
приемку и отгрузку принятой продукции приостанавливают до выявления причин
возникновения дефектов, их устранения и получения положительных
результатов повторных периодических испытаний.
Изготовитель (поставщик) совместно с представительством потребителя
(заказчика) (при его наличии) анализирует результаты периодических
испытаний для выявления причин появления и характера дефектов, составляет
перечень дефектов и мероприятий по устранению дефектов и (или) причин их
появления, который оформляют в порядке, принятом на предприятии.
Повторные периодические испытания проводят в полном объеме
периодических испытаний на доработанных (или вновь изготовленных) образцах
продукции после устранения дефектов.
В технически обоснованных случаях в зависимости от характера дефектов
повторные периодические испытания допускается проводить по сокращенной
программе, включая только те виды испытаний, при проведении которых
обнаружено несоответствие продукции установленным требованиям, а также виды,
по которым испытания не проводились.
При положительных результатах повторных периодических испытаний
приемку и отгрузку продукции возобновляют.
7.4.3. Правила проведения типовых испытаний
Типовые испытания продукции проводят с целью оценки эффективности и
целесообразности предлагаемых изменений в конструкции или технологии
изготовления, которые могут повлиять либо на технические характеристики
продукции, связанные с безопасностью для жизни, здоровья или имущества
граждан, либо на эксплуатацию продукции, в том числе на важнейшие
потребительские свойства продукции или на соблюдение условий охраны окружающей
среды.
Типовые испытания проводит изготовитель (поставщик) или по договору
с ним и при его участии испытательная (сторонняя) организация с участием,
при необходимости, представителей разработчика продукции, заказчика
(потребителя), природоохранных органов и других заинтересованных сторон.
Типовые испытания проводят по программе и методикам, которые в основном
должны содержать:
• необходимые проверки из состава приемосдаточных и периодических
испытаний;
• требования по количеству образцов, необходимых для проведения
типовых испытаний;
• указание об использовании образцов, подвергнутых типовым испытаниям.

114 Глава 7 • Разработка основных видов текстовой технической документации
Программу и методики типовых испытаний разрабатывает изготовитель
(поставщик) продукции или иная организация по договору с ним; утверждают
(согласовывают) те же инстанции, которые в установленном порядке
утверждали конструкторскую или технологическую документацию на продукцию
или изменения в указанной документации.
Типовые испытания проводят на образцах продукции, изготовленных с
внесением в конструкцию, рецептуру или технологию изготовления предлагаемых
изменений.
Если эффективность и целесообразность предлагаемых изменений
конструкции (рецептуры, технологии изготовления) подтверждена положительными
результатами типовых испытаний, то эти изменения вносят в документацию на
продукцию в соответствии с установленным порядком.
Если эффективность и целесообразность предлагаемых изменений не
подтверждена положительными результатами типовых испытаний, то эти изменения
в соответствующую утвержденную и действующую документацию на
продукцию не вносят и принимают решение по использованию образцов продукции,
изготовленных для проведения типовых испытаний (в соответствии с
требованиями программы испытаний).
Результаты типовых испытаний оформляют актом (по форме 3 приложения В
к стандарту) и протоколами типовых испытаний с отражением всех результатов,
которые оформляют в порядке, установленном изготовителем (поставщиком).
Теперь, при полном понимании необходимости, назначения,
последовательности и содержания различных категорий испытаний, а также видов
документации, разрабатываемой для их проведения, перейдем непосредственно к
порядку разработки программ и методик испытаний.
Для организации и проведения испытаний выпускают документ под
названием «Программа и методика испытаний» (код ПМ), разработка которого
выполняется в соответствии с требованиями ГОСТ 2.106-96. Единая система
конструкторской документации. Текстовые документы.
В соответствии с этим стандартом ПМ выполняют на формах 9 и 9а,
приведенных в приложении А к данному стандарту. Необходимые схемы, таблицы и
чертежи допускается выполнять на форматах A3 по ГОСТ 2.301-68. Единая
система конструкторской документации. Форматы, при этом основную
надпись и дополнительные графы к ней выполняют в соответствии с ГОСТ
2.104-2006. Единая система конструкторской документации. Основные
надписи (форма 1а).
ПМ может разрабатываться как на изделие в целом, так и на его составные
части.
ПМ в общем случае должна состоять из следующих разделов:
• общие положения;
• общие требования к условиям, обеспечению и проведению испытаний;
• требования безопасности;
• определяемые показатели (характеристики) и точность их измерений;
• режимы испытаний изделия;
• методы испытаний и (или) измерений;
• отчетность.

7.4. Программы и методики испытаний 115
В зависимости от особенностей изделия и специфики его испытаний
допускается объединять или исключать отдельные разделы, а также включать в ПМ
дополнительные разделы.
В разделе «Общие положения» помещают:
• наименование и обозначение изделия в соответствии с основным
конструкторским документом;
• цель испытаний;
• вид (виды) испытаний, которым подвергается изделие;
• условия предъявления изделия на испытания (порядок отбора,
количество, комплектность, документальное сопровождение при предъявлении);
• порядок взаимодействия предъявителя изделия с представителем
заказчика и другими предприятиями, участвующими в испытаниях.
В разделе «Общие требования к условиям, обеспечению и проведению
испытаний» помещают требования:
• к месту проведения испытаний (цех, лаборатория, полигон и т. п.);
• к средствам проведения испытаний (приспособлениям, стендам,
измерительной и вычислительной технике и т. п.);
• к условиям проведения испытаний (состояние окружающей,
искусственно создаваемой или моделируемой среды и т. п.);
• к основным и дублирующим видам топлива, масел, охлаждающей
жидкости, газов и т. п.;
• к подготовке изделия к испытаниям;
• к порядку работы на изделии по завершении испытаний;
• к персоналу, осуществляющему подготовку к испытанию и испытание.
В разделе «Требования безопасности» помещают:
• требования безопасности при подготовке изделия к испытаниям;
• требования безопасности при проведении испытаний;
• требования безопасности при выполнении работ по завершении
испытаний.
В разделе «Определяемые показатели (характеристики) и точность их
измерений» помещают:
• перечень определяемых показателей (характеристик) с указанием
наименования, обозначения (при наличии), единицы измерения;
• номинальные значения показателей (характеристик) и предельные
отклонения от номинальной величины или пределы изменения;
• указания, на каких видах и на каких этапах видов испытаний
определяются показателя (характеристики);
• перечень оборудования, материалов и реактивов (стенды, приборы,
приспособления, оснастка, инструмент и др.) для определения каждого
показателя;
• класс точности измерительного оборудования;
• допускаемую погрешность измерения (расчета) определяемых показателей;

116 Глава 7 • Разработка основных видов текстовой технической документации
• указания, по какой методике, инструкции или нормативному документу
следует определять (измерять) показатель (характеристику);
• правила регулировки (настройки) в процессе подготовки изделия к
испытаниям и (или) при испытаниях;
• формулы расчета для определения показателей (характеристик), которые
не могут быть определены прямым или косвенным измерением.
В разделе «Режимы испытаний изделия» помещают:
• режимы испытаний изделия;
• ограничения и другие указания, которые необходимо выполнять на всех
или на отдельных режимах испытаний;
• условия аннулирования и возобновления испытаний на всех или на
отдельных режимах.
В разделе «Методы испытаний и (или) измерений показателей
(характеристик)» помещают:
• схемы испытаний (измерений);
• описание метода испытаний (измерений);
• формулы расчета;
• номограммы, диаграммы, графики зависимости отдельных параметров
изделия от состояния внешней среды, других параметров, необходимые для
определения показателей (характеристик) изделия.
В разделе «Отчетность» помещают:
• перечень документов, в которых фиксируют результаты испытаний,
измерений и анализов в процессе испытаний и по их завершении;
• правила оформления таких документов;
• правила хранения и рассылки отчетных документов.
Допускается выполнять ПМ испытаний отдельными частями, например:
ПМ — программа испытаний, в которой излагают содержание следующих
разделов ПМ:
• общие положения;
• общие требования к условиям, обеспечению и проведению испытаний;
• отчетность.
ПМ1 — методика испытаний, в которой излагают содержание следующих
разделов ПМ:
• определяемые показатели (характеристики) и точность их измерений;
• режимы испытаний изделий;
• методы испытаний и (или) измерений.
Образцы программы и методик приемочных (как наиболее объемной
категории) испытаний АПК представлены в приложении Л на компакт-диске.

7.4. Программы и методики испытаний 117
Информационные источники
ГОСТ 2.106-96. Единая система конструкторской документации.
Текстовые документы.
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения. Порядок
разработки и постановки продукции на производство.
ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции. Основные
положения.
ГОСТ 16504-81. Система государственных испытаний. Испытания и
контроль качества продукции. Основные термины и определения.

118 Глава 7 • Разработка основных видов текстовой технической документации
7.5. Ведомость эксплуатационных документов
Разработка ведомости эксплуатационных документов (код — ВЭ) выполняется
в соответствии с ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов.
Титульный лист ВЭ выполняют в соответствии с требованиями ГОСТ
2.105-95. Единая система конструкторской документации. Общие требования
к текстовым документам.
В ВЭ перечисляют все документы, входящие в комплект эксплуатационных
документов на изделие.
Запись документов производят по разделам, которые располагают в
последовательности:
• общая документация (на изделие в целом);
• документация на составные части изделия, включая покупные изделия;
• перечень папок и футляров, в которые уложена документация.
Документы внутри раздела записывают в ВЭ в последовательности,
приведенной в ГОСТ 2.102-68. Единая система конструкторской документации.
Виды и комплектность конструкторских документов и ГОСТ 2.601-2006. Единая
система конструкторской документации. Эксплуатационные документы.
В разделе «Документация общая» первым документом записывают ВЭ.
Сведения в ВЭ рекомендуется излагать в виде табл. 6.
Таблица б
Ободиочоиис
документе
документе
Количество
экземпляров? шт«
пляра
Пилит
место
нехождения
Наименование разделов в таблице записывают в виде заголовков в графе
«Наименование документа».
При записи папок и футляров в таблице указывают:
• в графе «Обозначение документа» делают прочерк;
• в графе «Наименование документа» — наименование и номер папки и
футляра, например «Папка № 1», «Футляр № 2»;
• в графе «Количество экземпляров» — количество экземпляров папок и
футляров данного наименования, входящих в состав одного комплекта
ЭД;
• в графе «Номер экземпляра» — номер экземпляра папки или футляра
(при их наличии);
• в графе «Место нахождения» — места расположения папок и футляров.
Образец ведомости эксплуатационных документов приведен в приложении М
на компакт-диске.

7.5. Ведомость эксплуатационных документов 119
Информационные источники
ГОСТ 2.102-68. Единая система конструкторской документации. Виды
и комплектность конструкторских документов.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.601-2006. Единая система конструкторской документации.
Эксплуатационные документы.
ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов.

120 Глава 7 • Разработка основных видов текстовой технической документации
7.6. Руководство по эксплуатации
Одним из основных эксплуатационных документов на АПК является
руководство по эксплуатации (код — РЭ), которое разрабатывается в соответствии
с требованиями ГОСТ 2.601-2006. Единая система конструкторской
документации. Эксплуатационные документы и ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных
документов.
Руководство по эксплуатации — это документ, содержащий сведения о
конструкции, принципе действия, характеристиках (свойствах) изделия, его составных
частях и указания, необходимые для правильной и безопасной эксплуатации
изделия (использования по назначению, технического обслуживания, текущего
ремонта, хранения и транспортирования) и оценок его технического состояния
при определении необходимости отправки его в ремонт, а также сведения по
утилизации изделия и его составных частей.
РЭ оформляют на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы с основной надписью по ГОСТ
2.104-2006. Единая система конструкторской документации. Основные
надписи (формы 2 и 2а), а титульный лист оформляют по ГОСТ 2.105-95. Единая
система конструкторской документации. Общие требования к текстовым
документам.
РЭ, как правило, включает в себя введение и следующие части:
• описание и работа;
• использование по назначению;
• техническое обслуживание;
• текущий ремонт;
• хранение;
• транспортирование;
• утилизация.
Введение излагают без заголовка. Оно содержит:
• назначение и состав РЭ;
• требуемый уровень специальной подготовки обслуживающего персонала;
• распространение РЭ на модификации изделия;
• другие сведения (при необходимости).
Для изделий, которые при определенных условиях могут представлять
опасность для жизни и здоровья человека, во введении должна быть приведена
информация о видах опасных воздействий.
Часть «Описание и работа» состоит из разделов:
• описание и работа изделия;
• описание и работа составных частей изделия.

7.6. Руководство по эксплуатации 121
Раздел «Описание и работа изделия» содержит подразделы:
• назначение изделия;
• технические характеристики (свойства);
• состав изделия;
• устройство и работа;
• средства измерения, инструмент и принадлежности;
• маркировка и пломбирование;
• упаковка.
Подраздел «Назначение изделия» содержит наименование изделия, его
обозначение, назначение, область применения, параметры, размеры,
характеризующие условия эксплуатации.
Подраздел «Технические характеристики» содержит технические данные,
основные параметры и характеристики (свойства), необходимые для изучения
и правильной технической эксплуатации изделия. При изложении сведений
о контролируемых (измеряемых) параметрах необходимо указывать
наименование параметра, номинальное значение, допуск (доверительный интервал),
применяемое средство измерения.
Подраздел «Состав изделия» содержит наименования, обозначения и места
расположения основных составных частей изделия и установленных для изделия
комплектов ЗИП. Здесь же указывают общие отличия в конструкции различных
модификаций изделий от базового изделия и друг от друга и особенности их
комплектации. Допускается приводить схему деления изделия на составные части.
Подраздел «Устройство и работа» содержит общие сведения о принципе
действия, устройстве и режимах работы изделия в целом, взаимодействии
составных частей изделия. Здесь же указывают, при необходимости,
взаимодействие данного изделия с другими изделиями.
Подраздел «Средства измерения, инструмент и принадлежности» содержит
назначение, перечень, места расположения и краткие основные технические
(в том числе метрологические) характеристики, а также устройство и принцип
действия специальных средств измерения, испытательного и другого
оборудования, инструмента и принадлежностей, которые необходимы для контроля,
регулирования (настройки), выполнения работ по техническому
обслуживанию и текущему ремонту изделия и его составных частей.
Подраздел «Маркировка и пломбирование» содержит сведения для всего
изделия в целом о маркировании и пломбировании изделия, тары и упаковочных
материалов.
Подраздел «Упаковка» содержит для всего изделия в целом описание
конструкции и порядка использования тары, упаковочных материалов и т. п.,
порядок пломбирования и распломбирования.
Раздел «Описание и работа составных частей изделия» содержит общие
сведения о составных частях изделия и состоит из подразделов:
• общие сведения;
• работа;
• маркировка и пломбирование;
• упаковка.

122 Глава 7 • Разработка основных видов текстовой технической документации
Подраздел «Общие сведения» содержит в общем виде назначение и
описание составных частей изделия, из каких основных составных частей более
мелкого уровня деления состоит описываемая составная часть изделия, где они
расположены, какие выполняют функции, их взаимосвязь и др.
Подраздел «Работа» содержит описание работы составных частей изделия.
Содержание подразделов «Маркировка и пломбирование» и «Упаковка»
составных частей изделия аналогично содержанию подразделов для изделия
в целом.
Часть «Использование по назначению» состоит из разделов:
• эксплуатационные ограничения;
• подготовка изделия к использованию;
• использование изделия;
• действия в экстремальных условиях;
• особенности использования доработанного изделия.
Раздел «Эксплуатационные ограничения» содержит те технические
характеристики изделия, несоблюдение которых недопустимо по условиям
безопасности и которые могут привести к выходу изделия из строя. Эти характеристики с
указанием их количественных значений рекомендуется излагать в виде таблиц в
порядке, соответствующем последовательности этапа использования изделия
по назначению. Все ограничения, помещаемые в данном разделе, должны
обеспечивать возможность их контроля обслуживающим персоналом.
Раздел «Подготовка изделия к использованию» содержит указания по
проверке и приведению изделия к использованию по назначению. Раздел, как
правило, содержит подразделы:
• меры безопасности при подготовке изделия;
• правила и порядок заправки изделия ГСМ с указанием их количества
и марки, а также условия и порядок заправки дублирующими
(резервными) ГСМ и, при необходимости, зарубежными ГСМ;
• объем и последовательность внешнего осмотра изделия;
• правила и порядок осмотра рабочих мест;
• правила и порядок осмотра и проверки готовности изделия к
использованию;
• описание положений органов управления и настройки после подготовки
изделия к работе и перед включением;
• указания об ориентировании изделия (с приложением схем при
необходимости);
• особенности подготовки изделия к использованию из различных степеней
готовности;
• при необходимости, указания о взаимосвязи (соединении) данного
изделия с другими изделиями;
• указания по включению и опробованию работы изделия с описанием
операций по проверке изделия в работе, в том числе с помощью средств
измерения, входящих в состав изделия ^приводятся значения показаний средств
измерений, соответствующие установленным режимам работы, и
допустимые отклонения от этих значений);

7.6. Руководство по эксплуатации 123
• перечень возможных неисправностей изделия в процессе его
подготовки и рекомендации по действиям при их возникновении.
Описание порядка выполнения каких-либо работ дается в логической
последовательности их выполнения. Перечень работ допускается оформлять
в виде таблицы.
В тексте документа при изложении указаний о проведении работ применяют
глаголы в повелительном наклонении, например, «Открыть люк..>, «Нажать
кнопку...» и т. п.
Раздел «Использование изделия» содержит, как правило, подразделы:
• порядок действия обслуживающего персонала при выполнении задач
применения изделия;
• порядок контроля работоспособности изделия в целом с описанием
методик выполнения измерений, регулирования (настройки), наладки
изделия, а также схем соединения изделия со средствами измерений и
вспомогательными устройствами, используемыми для измерений;
• перечень возможных неисправностей в процессе использования изделия
по назначению и рекомендации по действиям при их возникновении;
• перечень режимов работы изделия, а также характеристики основных
режимов работы;
• порядок и правила перевода изделия с одного режима работы на другой
с указанием необходимого для этого времени;
• порядок приведения изделия в исходное положение;
• порядок выключения изделия, содержание и последовательность осмотра
изделия после окончания работы;
• порядок замены, пополнения и контроля качества (при необходимости)
ГСМ;
• меры безопасности при использовании изделия по назначению. При этом
должны быть отражены требования, обеспечивающие безопасность
обслуживающего персонала, техники и экологическую безопасность проводимых
работ.
Раздел «Действия в экстремальных условиях» содержит случаи отказа
изделия в экстремальных условиях и условия, которые могут привести к аварийной
ситуации. Раздел содержит, как правило, действия при:
• пожаре на изделии на различных этапах использования изделия;
• отказах систем изделия, способных привести к возникновению опасных
аварийных ситуаций;
• попадании в аварийные условия эксплуатации;
• экстренной эвакуации обслуживающего персонала.
Раздел «Особенности использования доработанного изделия» содержит:
• основные конструктивные отличия данного изделия от базового изделия
и обусловленные ими изменения в эксплуатационных ограничениях и
рекомендациях по эксплуатации;
• особенности выполнения операций на всех этапах подготовки и
использования по назначению модифицированного изделия.

124 Глава 7 • Разработка ось
: видов текстовой технической документации
Допускается приводить эти особенности, не выделяя в отдельный раздел.
Часть «Техническое обслуживание» содержит сведения по ТО изделия и его
составных частей и состоит из разделов:
• техническое обслуживание изделия;
• техническое обслуживание составных частей изделия.
Состояние изделия и его составных частей, на которых проводят работы по
техническому обслуживанию (далее — объекты ТО), виды и объемы работ и
периодичность их выполнения надежности объектов ТО при условии
рациональных сроков проведения ТО и расходов материальных средств и трудовых
ресурсов на ТО.
Раздел 4Техническое обслуживание изделия» состоит из подразделов:
• общие указания;
• меры безопасности;
• порядок технического обслуживания изделия;
• проверка работоспособности изделия;
• техническое освидетельствование;
• консервация (расконсервация, переконсервация).
Подраздел «Общие указания» содержит:
• характеристику принятой системы ТО: виды, объемы и периодичность
ТО, особенности организации ТО изделия и его составных частей в
зависимости от этапов его эксплуатации (использования по назначению,
хранения, транспортирования и т. д.) и условий эксплуатации
(климатические, временные и т. д.), указания по организации ТО;
• требования к составу и квалификации обслуживающего персонала;
• требования к изделию, направляемому на ТО;
• перечень основных и дублирующих (резервных) ГСМ и, при
необходимости, зарубежных эквивалентов для них, применяемых в изделии.
Перечень ГСМ, применяемых в изделии, рекомендуется излагать в виде
табл. 7.
Таблица 7

Наименование и

обозначение
изделия (со-
ставной
части)

Наименование и
марка
ГСМ,
обозначение
Масса,
(объем)
заправки
ГСМ, кг
(дог)
порма
расхода
ГСМ
Периодич-
иость
способов
смены

(пополнения) ГСМ
Номера
позиций
точек
заправки
ГСМ на
схеме

Примечание
Таблицу заполняют на основании химмотологической карты по ГОСТ 25549.
Графу «Норма расхода ГСМ* заполняют в случае необходимости
определения расхода ГСМ на расчетный период времени или наработки.

7.6. Руководство по эксплуатации 125
Графу «Периодичность способов смены (пополнения) ГСМ» заполняют
в случае наличия в РЭ схемы заправки ГСМ. При необходимости допускается
указывать дублирующие, резервные ГСМ, а также зарубежные ГСМ-аналоги.
Подраздел 4 Меры безопасности* содержит правила, которые необходимо
соблюдать в соответствии с особенностями конструкции, изделия и его
эксплуатации, действующими положениями нормативных документов, а также
перечень обязательных требований по техническому обслуживанию и (или)
ремонту, невыполнение которых может привести к опасным последствиям для
жизни, здоровья человека или окружающей среды. Здесь же излагают правила
пожарной безопасности, взрывобезопасности и т. п.
Подраздел «Порядок технического обслуживания изделия» содержит
характеристику каждого вида ТО изделия и его составных частей, в том числе —
замена смазки, заправка специальными жидкостями, кислородом и др., дренаж
трубопроводов и агрегатов и т. д. в зависимости от особенностей и условий
эксплуатации; периодичность видов ТО, в том числе и при хранении сведения по
всем видам ТО, принятым для эксплуатируемого изделия.
Содержание подраздела рекомендуется излагать в виде табл. 8.
Таблица 8
Пункт РЭ
Наименование объекта ТО и работы
Виды ТО
Примечание
В графе «Пункт РЭ» указывают порядковый номер пункта (работы), под
ним — номер раздела, подраздела, пункта РЭ.
В графе «Наименование объекта ТО и работы» приводят наименование
объекта ТО и перечень работ, проводимых при ТО.
В графе «Виды ТО» приводят условное обозначение вида ТО или периода
выполнения видов ТО, а также условное обозначение выполняемой («+») или
невыполняемой («-») работы.
Графа может состоять из одной или нескольких колонок.
Подраздел «Проверка работоспособности изделия» содержит
последовательность выполнения" работ по проверке работоспособности изделия.
Содержание подраздела рекомендуется излагать в виде табл. 9.
Таблица 9
ние работы
Ктовыпол-
Средства измерений,
вспомогательные технические устройства
и материалы
Контрольные
значения параметров
В графе 4 Наименование работы» приводят наименования выполняемых
работ в последовательности их выполнения.
В графе «Кто выполняет» указывают в сокращенном виде, кто выполняет
работу, например: М — механик, О — оператор и т. д.
В графе «Средства измерений, вспомогательные технические устройства
и материалы» указывают измерительные и вспомогательные устройства, а также
материалы, которые не входят в изделие, но которые необходимо использовать.

126 Глава 7 • Разработка основных видов текстовой технической документации
В графе 4 Контрольные значения параметров» указывают значения, в
пределах которых должны находиться параметры, контролируемые при проверке
исправности изделия, и значения параметров, при которых изделие отправляют
в ремонт. При изложении сведений о контролируемых (измеряемых)
параметрах необходимо указывать: наименование параметра; номинальное значение;
допуск (доверительный интервал); применяемое средство измерения.
В подразделе также приводят указания о порядке проведения предремонт-
ной дефектации изделия с целью оценки его технического состояния и
определения необходимости отправки изделия в капитальный (средний) ремонт.
Подраздел 4Техническое освидетельствование» содержит порядок и
периодичность освидетельствования изделия и (или) его составных частей органами
инспекции и надзора, а также указания, в каком месте формуляра или паспорта
приведен перечень поверяемых средств измерения, освидетельствованных
сосудов, работающих под высоким давлением, грузоподъемных средств,
входящих в изделие и его комплекты. Здесь же указывают требования по подготовке
средств измерений к поверке и методики поверки встроенных средств
измерений без демонтажа их с изделия.
Подраздел 4Консервация (расконсервация, переконсервация)» содержит
сведения о средствах и методах наружной и внутренней консервации,
расконсервации, переконсервации (далее — консервации) изделия в целом,
периодичности консервации при хранении, порядке приведения изделия в состояние
готовности к использованию по назначению из состояния консервации, перечень
используемых инструментов, приспособлений и материалов.
Раздел «Техническое обслуживание составных частей изделия», как правило,
содержит подразделы:
• обслуживание;
• демонтаж и монтаж;
• регулирование и испытание;
• осмотр и проверка;
• очистка и окраска;
• консервация.
Подраздел «Обслуживание» содержит правила и порядок замены и
заправки изделия ГСМ с указанием их количества и марки по соответствующему
нормативному документу, а также условия и порядок заправки
дублирующими (резервными) ГСМ и, при необходимости, зарубежными ГСМ.
Подраздел «Демонтаж и монтаж» содержит порядок работ по демонтажу
и монтажу, церечень приспособлений и инструментов, необходимых для
отсоединения, снятия, обратной установки и присоединения сборочных единиц
(деталей), меры предосторожности, перечень регулировочных работ после
монтажа. Указание «Установку проводить в обратной последовательности»
приводить не разрешается.
Подраздел «Регулирование и испытание» содержит порядок работ,
необходимых для регулирования (настройки) составной части изделия для получения
требуемых технических характеристик и параметров.

7.6. Руководство по эксплуатации 127
Подраздел «Осмотр и проверка» содержит порядок работ, необходимых для
осуществления доступа к осматриваемой части изделия; виды и методы ее
осмотра и проверки; порядок работ, необходимых для проведения технического
освидетельствования составных частей изделия органами инспекции и надзора,
а также оценки технического состояния составных частей изделия при
определении необходимости отправки их в ремонт.
Подраздел «Очистка и окраска» содержит порядок работ по очистке и
подкраске составных частей изделия, условий их выполнения и перечень
используемых инструментов, приспособлений и материалов.
Подраздел «Консервация» содержит требования, аналогичные изложенным
в соответствующем подразделе для изделия в целом.
Часть «Текущий ремонт» содержит сведения, необходимые для организации
и проведения текущего ремонта изделия и его составных частей в условиях
эксплуатации, и состоит из разделов:
• текущий ремонт изделия;
• текущий ремонт составных частей изделия.
Раздел «Текущий ремонт изделия» содержит подразделы:
• общие указания;
• меры безопасности.
Подраздел «Общие указания» содержит требования по проведению
ремонта, методы ремонта, требования к квалификации персонала, описание и
характеристики диагностических возможностей систем встроенного контроля, а
также перечень составных частей изделия, текущий ремонт которых может быть
осуществлен только в условиях ремонтных органов, описание и характеристики
диагностических возможностей внешних средств диагностирования. При
необходимости приводят схемы поиска отказов и повреждений.
Подраздел «Меры безопасности» содержит правила предосторожности,
которые в соответствии с действующими нормативами должны быть соблюдены
при проведении работ.
Раздел «Текущий ремонт составных частей изделия» содержит указания по
поиску и устранению отказов, повреждений и их последствий применительно к
каждой составной части изделия, текущий ремонт которых возможен при
эксплуатации. Раздел состоит из подразделов:
• поиск отказов, повреждений и их последствий;
• устранение отказов, повреждений и их последствий.
Подраздел «Поиск отказов, повреждений и их последствий» содержит
указания по последовательности и объему работ, необходимых для отыскания
отказов и повреждений, а также для установления их последствий как на уровне
составной части, подлежащей текущему ремонту, так и на уровне той составной
части изделия, в которую входит данная составная часть, вплоть до уровня
конечного изделия.
Подраздел «Устранение отказов, повреждений и их последствий» содержит
указания о методах устранения отказов, повреждений и их последствий, а также

128 Глава 7 • Разработка основных видов текстовой технической документации
перечень необходимых для этого средств измерения, инструмента и
приспособлений. Подраздел рекомендуется оформлять в виде карты работы (см.
приложение Б ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов).
Раздел 4Текущий ремонт составных частей изделия* допускается не
разделять на подразделы, а сведения излагать в виде табл. 10.
Таблица 10
Описание
отказов и
повреждений
Описание по*
следствий
отказов и
повреждений
Возможные
причины
отказов и
повреждений
Указания по
способам
обнаружения ОТ"
назови
повреждений
сборочной
единицы
(детали) и их
последствий
Указания по
способам ycib
ранения
отказов,
повреждений и их
последствий
В графе «Описание отказов и повреждений» приводят описания отказов
и повреждений, записываемые в порядке убывания вероятности их появления,
и, при необходимости, указывают внешние проявления отказов и повреждений
и другие дополнительные признаки, свидетельствующие о возникновении
отказов и повреждений.
В графе «Описание последствий отказов и повреждений» для каждого
отказа (повреждения) описывают возможные последствия как на уровне составной
части изделия, подлежащей текущему ремонту, так и на уровне той составной
части изделия, в которую входит данная составная часть, вплоть до уровня
конечного изделия. Последствия описывают в порядке убывания вероятности их
возникновения.
В графе «Возможные причины отказов и повреждений» указывают, какая из
составных частей, входящих в составную часть, подлежащую текущему ремонту,
может отказать и быть повреждена, а также указывают конструктивные
(недостатки конструкции), производственно-технологические (отклонения от
установленных технологических процессов изготовления и сборки), эксплуатационные
(ошибки персонала) и иные возможные причины отказов и повреждений.
Причины отказов и повреждений перечисляют в порядке убывания вероятности их
возникновения. Для деталей могут указываться физические причины отказов и
повреждений (например, поломка вследствие концентрации усталостных
напряжений, поломка вследствие износа и т. д.)
В графе «Указания по способам обнаружения последствий отказов и
повреждений сборочной единицы (детали) и их последствий» приводят
последовательность действий и другие указания, необходимые для установления (отыскания)
отказов и повреждений сборочной единицы (детали) и их последствий.
В графе «Указания по способам устранения отказов и повреждений и их
последствий» приводят последовательность действий и другие указания,
необходимые для устранения отказов, повреждений и их последствий, или приводят
ссылки на другие документы, по которым проводят соответствующие работы.

7.6. Руководство по эксплуатации 129
При необходимости перечень наиболее вероятных последствий отказов,
повреждений и их последствий может быть выделен в самостоятельную таблицу.
Часть «Хранение» содержит:
• правила постановки изделия на хранение и снятия его с хранения;
• перечень составных частей изделия с ограниченными сроками хранения;
• перечень работ, правила их проведения, меры безопасности при
подготовке изделия к хранению, при кратковременном и длительном хранении
изделия, при снятии изделия с хранения;
• условия хранения изделия (вид хранилищ, температура, влажность,
освещенность и т. п.) для определенных сроков хранения;
• способы утилизации (если изделие представляет опасность для жизни,
здоровья людей или окружающей среды после окончания срока
эксплуатации);
• предельные сроки хранения в различных климатических условиях.
Часть «Транспортирование» содержит:
• требования к транспортированию изделия и условиям, при которых
оно должно осуществляться;
• порядок подготовки изделия для транспортирования различными видами
транспорта;
• способы крепления изделия для транспортирования его различными
видами транспорта с приведением необходимых схем крепления;
• порядок погрузки и выгрузки изделия и меры предосторожности.
Одновременно в разделе приводят транспортные характеристики изделия
(масса, габаритные размеры, положение центра тяжести и т. п.), а также схему
изделия применительно к расположению его на транспортном средстве с
указанием основных размеров изделия и точек крепления. При необходимости
указывают сведения по буксированию изделия и эвакуации.
Часть «Утилизация», как правило, содержит:
• меры безопасности;
• сведения и проводимые мероприятия по подготовке и отправке изделия
на утилизацию;
• перечень утилизируемых составных частей (расчетный);
• перечень утилизируемых составных частей, выявляемых по результатам
текущего ремонта, технического обслуживания и хранения (при
необходимости);
• показатели утилизации;
• методы утилизации, если изделие представляет опасность для жизни,
здоровья людей и окружающей среды после окончания срока службы
(эксплуатации).
Разработку разделов осуществляют в соответствии с ГОСТ 30167 и другими
нормативными документами в этой области.

130 Глава 7 • Разработка основных видов текстовой технической документации
ПРИМЕЧАНИЕ
Если требования утилизации изложены в ФО, ПС или ЭТ, то эти требования в РЭ не излагают.
При необходимости допускается не включать в состав РЭ отдельные
разделы (подразделы) или объединять их, а также вводить дополнительные разделы
(подразделы).
Образец РЭ на АПК представлен в приложении Н на компакт-диске.
Информационные источники
ГОСТ 2.104-2006. Единая система конструкторской документации. Основные
надписи.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
ГОСТ 2.601-2006. Единая система конструкторской документации.
Эксплуатационные документы.
ГОСТ 2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.

7.7. Формуляр, паспорт и этикетка 131
7.7. Формуляр, паспорт и этикетка
Важными эксплуатационными документами на АПК и его составные части
являются формуляр (код — ФО), паспорт (код — ПС) и этикетка (код — ЭТ),
которые разрабатываются в соответствии с требованиями ГОСТ 2.601-2006.
Единая система конструкторской документации. Эксплуатационные
документы и ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов.
Формуляр составляют на изделия, в период эксплуатации которых
необходимо вносить сведения о значениях основных параметров и характеристиках
(свойствах) изделия, отражающих техническое состояние данного изделия,
и (или) данные о процессе эксплуатации (длительности и условиях работы),
данные о проведении технического обслуживания, ремонта и другие данные.
Как правило, на изделие, имеющее самостоятельное применение,
разрабатывают один ФО. ФО на составные части изделия допускается разрабатывать,
если эти части ремонтируют отдельно от изделия в целом.
ФО на изделие содержит титульный лист, содержание, правила ведения
формуляров и паспортов и в общем виде состоит из следующих разделов:
• общие указания;
• основные сведения об изделии;
• основные технические данные;
• индивидуальные особенности изделия;
• комплектность;
• ресурсы, сроки службы и хранения, гарантии изготовителя (поставщика);
• консервация;
• свидетельство об упаковывании;
• свидетельство о приемке;
• движение изделия при эксплуатации;
• учет работы изделия;
• учет технического обслуживания;
• учет работы по бюллетеням и указаниям;
• работы при эксплуатации;
• хранение;
• ремонт;
• особые отметки;
• сведения об утилизации;
• контроль состояния изделия и ведения формуляра;
• сведения о цене и условиях приобретения изделия;
• перечень приложений.
Допускается отдельные части, разделы и подразделы ФО объединять или
исключать, а также вводить новые в зависимости от особенностей изделий кон-

132 Глава 7 • Разработка основных видов текстовой технической документации
кретных видов техники с учетом их специфики, объема сведений и условий
эксплуатации.
ФО выполняют, как правило, с титульным листом, пример оформления
которого представлен на рис. 1 ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов.
Тексту ФО предшествует содержание формуляра.
Раздел «Общие указания» содержит указания для обслуживающего
персонала по эксплуатации изделия и правила заполнения и ведения формуляра.
Правила заполнения и ведения формуляра должны содержать необходимые
сведения для правильного его заполнения и ведения при эксплуатации и
ремонте изделия, в том числе должно быть указано следующее:
• перед эксплуатацией необходимо внимательно ознакомиться с ЭД на
изделие;
• ФО должен постоянно находиться с изделием;
• при записи в ФО в бумажной форме не допускаются записи карандашом,
смывающимися чернилами и подчистки;
• при выполнении ФО в бумажной форме неправильная запись должна
быть аккуратно зачеркнута и рядом записана новая. При выполнении ФО
в электронной форме неправильная запись должна быть помечена, а
вместо нее выполнена новая. Новые записи должны быть заверены
ответственным лицом;
• после подписи проставляют фамилию и инициалы ответственного лица
(вместо подписи допускается проставлять личный штамп исполнителя);
• при передаче изделия на другое предприятие итоговые суммирующие
записи по наработке заверяют печатью предприятия, передающего изделие.
Раздел «Основные сведения об изделии» содержит наименование изделия,
его обозначение, дату изготовления, наименование или почтовый адрес
изготовителя, заводской номер изделия (серии) и другие подобные сведения об
изделии в целом. Также в разделе указывают сведения о сертификате (номер
сертификата, срок действия и орган, его выдавший), обозначение стандартов
(международных правил) или иного официального документа, содержащего
перечень стандартов, на соответствие которым производилась сертификация.
Раздел «Основные технические данные» содержит необходимые для
эксплуатации изделия номинальные и фактические значения основных
параметров и характеристик (свойств), в том числе и показатели надежности,
относящиеся к этому изделию. Для изделий, использование которых по истечении
определенного срока представляет опасность для жизни, здоровья человека и может
причинить вред его имуществу, должен быть указан срок службы или годности.
Для составных частей, которые могут привести к критическим отказам,
представляющим опасность для жизни, здоровья человека и его имущества,
приводят сроки их замены (восстановления) или критерии предельного состояния,
при которых эксплуатация допустима. В разделе, при необходимости, приводят
таблицы ^Основные технические данные» и «Результаты контроля
параметров», формы которых представлены, соответственно, табл. 5 и 6 ГОСТ 2.610-2006.
Единая система конструкторской документации. Правила выполнения
эксплуатационных документов.

7.7. Формуляр, паспорт и этикетка 133
При наличии драгоценных материалов и цветных металлов в составных
частях изделия (в том числе в запасных частях, перечисленных в разделе
«Комплектность»), не имеющих паспортов или этикеток, в раздел вводят подраздел
под названием «Сведения о содержании драгоценных материалов и цветных
металлов». В подразделе приводят сведения по драгоценным материалам и
цветным металлам в соответствии с ГОСТ 2.601-2006. Единая система
конструкторской документации. Эксплуатационные документы. Сведения о драгоценных
материалах и цветных металлах допускается помещать в приложении к ФО.
Раздел ^Индивидуальные особенности изделия» содержит особенности
данного изделия, которые необходимо учитывать при его эксплуатации и
ремонте. При необходимости в разделе приводят указания по особой
осторожности при упаковывании, погрузке, выгрузке, транспортировании, извлечении из
упаковки, а также сведения о наличии на изделии радиоактивных и токсичных
веществ, работа с которыми требует особых мер безопасности.
Раздел «Комплектность» состоит из подразделов:
• составные части изделия и изменения в комплектности;
• запасные части, инструмент, приспособления и средства измерения (или
их комплекты) (ЗИП);
• изделия с ограниченным ресурсом;
• эксплуатационная документация;
• дополнительные сведения о комплектности.
Раздел разрабатывают, если:
• изделие состоит из нескольких составных частей;
• к изделию прилагают отдельные сборочные единицы и детали для
монтажа;
• к изделию прилагают ЗИП;
• формуляры (паспорта, этикетки) на составные части изделия включены
в комплектность.
При необходимости в разделе приводят рисунок общего вида изделия или
другие необходимые иллюстрации.
Если комплект состоит из самого изделия и документации на него, раздел не
разрабатывают.
Раздел рекомендуется выполнять в виде табл. 7 ГОСТ 2.610-2006. Единая
система конструкторской документации. Правила выполнения
эксплуатационных документов.
Подраздел «Составные части изделия и изменения в комплектности»
содержит перечень входящих в состав изделия комплектующих изделий, на которые
имеются формуляры (паспорта, этикетки) и ресурсы и сроки службы которых
равны установленным для изделия в целом или больше их.
Графы табл. 7 заполняет изготовитель изделия. Изменения в комплектности
в процессе эксплуатации, ремонта или модернизации заполняет
эксплуатирующее или ремонтное предприятие.
Подраздел «ЗИП» содержит перечень передаваемых с изделием запасных
частей, инструментов, приспособлений, средств измерений, снаряжения и других

134 Глава 7 • Разработка основных видов текстовой технической документации
технических средств, закрепленных за данным изделием. Если в комплекте ЭД
на изделие включена ЗИ, то вошедшие в нее ЗИП не перечисляют. В этом
случае в графе «Наименование изделия» табл. 7 указывают наименование
комплекта, а в графе «Заводской номер» — документ, по которому осуществляют
поставку, и его обозначение. Подраздел заполняет изготовитель изделия.
Подраздел «Изделия с ограниченным ресурсом» содержит перечень изделий,
ресурс и (или) срок службы которых до первого ремонта меньше
установленного для изделия в целом.
Подраздел «Эксплуатационная документация» содержит перечень всех ЭД,
закрепленных за данным изделием. Если в формуляре изделия в этом подразделе
включена ВЭ, то вошедшие в нее ЭД не перечисляют. Если в изделие входят
составные части, имеющие свои комплекты ЭД (ведомости ЭД), то в основном
формуляре в разделе «Эксплуатационная документация» указывают комплекты
ЭД и обозначения ведомостей ЭД.
Подраздел «Дополнительные сведения о комплектности» вводят в ФО, когда
требуется отразить в нем варианты комплектности изделия. Подраздел
содержит перечень комплектующих изделий, применяемых в конкретном варианте
комплектации, а также и при поставках на экспорт.
Раздел «Ресурсы, сроки службы и хранения, гарантии изготовителя
(поставщика)» состоит из подразделов:
• ресурсы, сроки службы и хранения;
• гарантии изготовителя (поставщика);
• изменение ресурсов, сроков службы и хранения, гарантий изготовителя
(поставщика).
Раздел рекомендуется выполнять по форме, приведенной на рис. 2 ГОСТ
2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.
Подраздел «Ресурсы, сроки службы и хранения» содержит установленные
ресурсы, сроки службы и хранения изделия. Ресурсы устанавливают в
параметрах, характеризующих наработку изделия в целом. Если ресурсы, сроки
службы и хранения комплектующих изделий, входящих в составную часть изделия,
меньше установленных для составной части, то в ФО после изложения данных
о ресурсах, сроках службы и хранения составной части дополнительно
указывают: «Ресурсы и сроки службы комплектующих изделий, входящих в
составную часть, определяются в соответствии с индивидуальными формулярами
(паспортами, этикетками) на них».
В подразделе «Гарантии изготовителя (поставщика)» устанавливают права
и обязанности изготовителя (поставщика) по гарантиям в соответствии с
действующим законодательством. При необходимости здесь же перечисляют
адреса предприятий, выполняющих в соответствии с принятыми изготовителем
(поставщиком) обязательствами безвозмездный ремонт или замену изделий
(составных частей изделия) в течение установленных гарантийных сроков.
Граждане, осуществляющие предпринимательскую деятельность по изготовлению
изделий, должны дополнительно приводить в этом подразделе информацию
о регистрации и наименовании органа, их зарегистрировавшего.

7.7. Формуляр, паспорт и этикетка 135
Подраздел «Изменение ресурсов, сроков службы и хранения, гарантий
изготовителя (поставщика)» содержит сведения об изменении ресурсов, срока
службы и хранения и гарантий.
Раздел ^ Консервация» содержит сведения о консервации, расконсервации
и переконсервации изделия. Раздел рекомендуется выполнять в виде табл. 8
ГОСТ 2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.
Первую запись в таблицу, при необходимости, делает изготовитель изделия,
и эта запись является свидетельством о консервации изделия. Последующие
записи вносят при эксплуатации и ремонте.
Раздел «Свидетельство об упаковывании» содержит свидетельство об
упаковывании изделия, подписанное ответственными за упаковывание лицами, пример
записи приведен на рис. 3 ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов.
Свидетельство об упаковывании заполняет изготовитель изделия.
Раздел «Свидетельство о приемке» содержит сведения о приемке изделия,
подписанные лицами, ответственными за соответствие изделия действующей
технической документации на него. Пример формы записи приведен на рис. 4
ГОСТ 2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов. Помимо свидетельства о приемке в
разделе могут быть приведены необходимые для эксплуатации данные
контрольных, в том числе и приемосдаточных, испытаний и заключение
испытателя. Раздел заполняет изготовитель изделия.
Раздел «Движение изделия при эксплуатации» состоит из подразделов:
• прием и передача изделия;
• сведения о закреплении изделия при эксплуатации;
• ограничения по транспортированию.
Раздел рекомендуется выполнять в виде табл. 9 ГОСТ 2.610-2006. Единая
система конструкторской документации. Правила выполнения
эксплуатационных документов.
Подраздел «Прием и передача изделия» содержит данные о передаче
изделия от одного потребителя другому, а также сведения о техническом состоянии
изделия на момент передачи.
Подраздел «Сведения о закреплении изделия при эксплуатации» содержит
сведения о закреплении изделия (составных частей изделия) за ответственным
лицом.
Подраздел «Ограничения по транспортированию» содержит необходимые
ограничения, соблюдение которых обязательно при транспортировании изделия.
Если на изделие выполнено РЭ, содержащее раздел «Транспортирование»,
данный подраздел не разрабатывают. Подраздел заполняет изготовитель изделия.
Подразделы «Прием и передача изделия» и «Сведения о закреплении
изделия при эксплуатации» рекомендуется выполнять в виде табл. 10 и И ГОСТ
2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов соответственно.
Раздел «Учет работы изделия» содержит сведения о продолжительности
работы изделия в единицах измерения, принятых для ресурса. Учет работы

136 Глава 7 • Разработка основных видов текстовой технической документации
изделия ведут начиная с момента испытания его изготовителем. Раздел
рекомендуется выполнять в виде табл. 12 ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных документов.
Допускается исключать графы, а также вводить дополнительные графы,
номенклатуру и состав которых устанавливает разработчик ФО в зависимости от
особенностей изделий конкретных видов техники, с учетом их специфики,
объема сведений и условий эксплуатации. При поставке изделий на экспорт
непосредственно из эксплуатирующих организаций настоящий раздел оформляют
согласно дополнительным указаниям потребителя для этих организаций ГОСТ
2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.
Раздел «Учет технического обслуживания» содержит дату проведения
технического обслуживания, вид технического обслуживания, наработку изделия
на момент начала обслуживания и подписи лиц, выполнивших и проверивших
выполнение работ. Первые записи в разделе могут быть сделаны изготовителем
изделия. Раздел рекомендуется выполнять в виде табл. 13 ГОСТ 2.610-2006.
Единая система конструкторской документации. Правила выполнения
эксплуатационных документов. Допускается исключать графы, а также вводить
дополнительные графы, номенклатуру и состав которых устанавливает
разработчик ФО в зависимости от особенностей изделий, конкретных видов
техники, с учетом их специфики, объема сведений и условий эксплуатации. При
поставке изделий на экспорт непосредственно из эксплуатирующих организаций
настоящий раздел оформляют согласно ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных
документов и дополнительным указаниям потребителя для этих организаций.
Раздел «Учет работы по бюллетеням и указаниям» содержит данные по
учету работы с изделием, выполняемой по бюллетеням и указаниям заказчика, и
состоит из подразделов:
• учет работы, выполняемой по бюллетеням;
• учет работы, выполняемой по указаниям заказчика.
Раздел рекомендуется выполнять в виде табл. 14 ГОСТ 2.610-2006. Единая
система конструкторской документации. Правила выполнения
эксплуатационных документов.
Раздел «Работы при эксплуатации» состоит из подразделов:
• учет выполнения работ;
• особые замечания по эксплуатации и аварийным случаям;
• периодический контроль основных эксплуатационных и технических
характеристик;
• поверка средств измерений;
• техническое освидетельствование контрольными органами;
• сведения о рекламации.
Подраздел «Учет выполнения работ» содержит записи о внеплановых
работах по текущему ремонту изделия при его эксплуатации с указанием причины
выполнения, включая замену отдельных составных частей изделия (комплек-

7.7. Формуляр, паспорт и этикетка 137
тующих, покупных изделий). Подраздел рекомендуется выполнять в виде
табл. 15 ГОСТ 2.610-20066. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов.
Подраздел 4Особые замечания по эксплуатации и аварийным случаям»
содержит сведения об основных замечаниях по эксплуатации и данные по
аварийным случаям, возникшим из-за неисправности изделия, а также о принятых
мерах по их устранению.
Подраздел 4 Периодический контроль основных эксплуатационных и
технических характеристик» содержит записи о контроле основных характеристик,
предусмотренных в ЭД. Перечень, наименования, единицы измерения
проверяемых характеристик (номинальные значения и предельные отклонения)
указывает изготовитель изделия. Подраздел рекомендуется выполнять в виде табл.
16 ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов. Первые четыре графы таблицы
заполняет изготовитель изделия, последующие графы заполняет лицо,
выполнявшее контроль характеристик в соответствии с ЭД.
Подраздел «Поверка средств измерений» содержит перечень средств
измерений, которые подвергаются периодической поверке, с указанием их
заводских номеров, периодичности поверки и даты проведения поверок. Подраздел
рекомендуется выполнять в виде табл. 17 ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных
документов. Первые четыре графы таблицы заполняет изготовитель изделия,
последующие графы заполняет лицо, выполнявшее поверку средств измерения.
Подраздел «Техническое освидетельствование контрольными органами»
содержит перечень составных частей изделия, которые подвергают
периодическому освидетельствованию контрольными органами, периодичность и
даты освидетельствования. Подраздел рекомендуется выполнять в виде табл. 18
ГОСТ 2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов. Первые четыре графы таблицы
заполняет изготовитель изделия. Последующие графы заполняет лицо,
проводившее освидетельствование.
В подразделе «Сведения о рекламациях» регистрируют все предъявленные
рекламации, их краткое содержание и меры, принятые по рекламации. Подраздел
должен начинаться с краткого изложения порядка предъявления рекламации.
Раздел «Хранение» содержит сведения о датах приемки изделия на хранение
и снятия с хранения, об условиях, видах хранения и антикоррозионной
защите. Раздел рекомендуется выполнять в виде табл. 19 ГОСТ 2.610-2006. Единая
система конструкторской документации. Правила выполнения
эксплуатационных документов.
Раздел «Ремонт» состоит из подразделов:
• краткие записи о произведенном ремонте;
• данные приемосдаточных испытаний;
• свидетельство о приемке и гарантии.
Подраздел «Краткие записи о произведенном ремонте» содержит
причины сдачи в ремонт изделия, наработку изделия на момент сдачи его в ремонт,
наименование (условное обозначение) ремонтной организации, проводившей

138 Глава 7 • Разработка основных видов текстовой технической документации
ремонт, краткие сведения о произведенном ремонте. Рекомендуемая форма
записи приведена на рис. 5 ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов.
Подраздел «Данные приемосдаточных испытаний» содержит указания о
соответствии технических характеристик, полученных при испытаниях изделия после
ремонта, требованиям ремонтной документации.
Подраздел «Свидетельство о приемке и гарантии» содержит сведения о
приемке изделия после ремонта, годности изделия для дальнейшей эксплуатации
и гарантии исполнителя ремонта. Пример записи приведен на рис. 6 ГОСТ
2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.
При выполнении ФО в бумажной форме раздел «Особые отметки»
содержит несколько чистых листов для различного рода записей, которые могут
быть внесены в ФО во время эксплуатации изделия.
Раздел «Сведения об утилизации» содержит указания по мерам
безопасности, краткие сведения по подготовке и отправке изделия на утилизацию,
перечень утилизированных составных частей (при необходимости), основные
методы утилизации (при необходимости) и показатели утилизируемое™. Раздел
выполняют в соответствии с п. 5.9 ГОСТ 2.610-2006. Единая система
конструкторской документации. Правила выполнения эксплуатационных
документов.
Раздел «Контроль состояния изделия и ведения формуляра» содержит
записи должностных лиц, проводивших контроль состояния изделия и
правильность ведения формуляра. Раздел рекомендуется выполнять в виде табл. 20
ГОСТ 2.610-2006. Единая система конструкторской документации. Правила
выполнения эксплуатационных документов.
Раздел «Сведения о цене и условиях приобретения изделия» в общем случае
содержит сведения о продажной стоимости (цене изделия на момент продажи),
необходимости предпродажной подготовки, об условиях обмена и прочее.
Раздел «Перечень приложений» содержит перечень приложений к ФО
с указанием их места нахождения. Раздел рекомендуется выполнять в виде
табл. 21 ГОСТ 2.610-2006. Цдиная система конструкторской документации.
Правила выполнения эксплуатационных документов.
При выполнении ФО в бумажной форме на обороте последнего листа должна
быть сделана запись: «Итого в формуляре пронумерованных страниц
(количество)», заверенная подписью должностного лица, поставлены дата и печать.
Паспорт составляют на изделия, для которых объем необходимых для
эксплуатации данных и основных показателей незначителен и в период
эксплуатации которых нет необходимости вносить сведения о значениях и (или)
подтверждении этих показателей.
ПС на изделия состоит из титульного листа и, в общем случае, из
следующих разделов:
• основные сведения об изделии и технические данные;
• комплектность;
• ресурсы, сроки службы и хранения и гарантии изготовителя (поставщика);
• консервация;

7.7. Формуляр, паспорт и этикетка 139
• свидетельство об упаковывании;
• свидетельство о приемке;
• движение изделия в эксплуатации (при необходимости);
• ремонт и учет работы по бюллетеням и указаниям (при необходимости);
• заметки по эксплуатации и хранению (при необходимости);
• сведения об утилизации;
• особые отметки;
• сведения о цене и условиях приобретения изделия (раздел выполняют в
соответствии с п. 7.25 ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов).
Титульный лист ПС выполняют аналогично титульному листу ФО, но с
наименованием «Паспорт» вместо «Формуляр».
Построение и изложение разделов ПС должно соответствовать построению
и изложению одноименных разделов ФО.
Раздел ««Заметки по эксплуатации и хранению» содержит:
• сведения о взаимозаменяемости с ранее выпущенными
модификациями изделия;
• предупреждение о необходимости сохранения пломб изготовителя изделия;
• перечень особых мер безопасности при работе;
• требования к проверке перед установкой на другое изделие;
• перечень особых условий эксплуатации.
В разделе допускается приводить и другие сведения (например, с какими
изделиями взаимодействует при работе данное изделие, результаты входного
контроля и др.).
Этикетку составляют на изделия, для которых данные, необходимые для
эксплуатации, не превышают пяти-шести основных показателей, когда для
подтверждения этих показателей нет необходимости составлять ФО (ПС) и
технически их невозможно и (или) нецелесообразно маркировать на изделии.
ЭТ, как правило, содержит разделы:
• основные сведения об изделии и технические данные;
• свидетельство о приемке;
• ресурсы, сроки службы и хранения, гарантии изготовителя (поставщика).
В зависимости от особенностей изделия и его использования в ЭТ
допускается включать и другие дополнительные сведения, например сведения о
качестве изделия, его упаковке.
Построение и изложение разделов ЭТ аналогично построению и изложению
одноименных разделов ФО и ПС. Порядок расположения разделов ЭТ, при
необходимости, может быть изменен.
Пример оформления первой страницы ЭТ, выполненной без основной
надписи, приведен на рис. 7 ГОСТ 2.610-2006. Единая система конструкторской
документации. Правила выполнения эксплуатационных документов.
ЭТ выпускают на изделие или на партию изделий. В ЭТ на партию изделий
указывают номер партии и заводские номера изделий, входящих в партию.

140 Глава 3 • Разработка основных видов текстовой технической документации
В ЭТ на изделие, входящее в составную часть, ниже заводского номера
должно быть указано в скобках (см. паспорт на
(обозначение составной части) № (заводской номер)).
Образцы ФО, ПС и ЭТ представлены в приложениях П, Р и С на
компакт-диске.
Информационные источники
ГОСТ 2.601-2006. Единая система конструкторской документации.
Эксплуатационные документы.
ГОСТ 2.610-2006. Единая система конструкторской документации.
Правила выполнения эксплуатационных документов.

Разработка основных
видов текстовой технической
документации на АС согласно
требованиям КСАС

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

8.1. Техническое задание на АС 143
• требования к документированию;
• источники разработки.
В ТЗ на АС могут включаться приложения. В зависимости от вида,
назначения, специфических особенностей объекта автоматизации и условий
функционирования системы допускается оформлять разделы ТЗ в виде приложений,
вводить дополнительные, исключать или объединять подразделы ТЗ.
В ТЗ на части системы не включают разделы, дублирующие содержание
разделов ТЗ на АС в целом.
В разделе «Общие сведения» указывают:
• полное наименование системы и ее условное обозначение;
• шифр темы или шифр (номер) договора;
• наименование предприятий (объединений) разработчика и заказчика
(пользователя) системы и их реквизиты;
• перечень документов, на основании которых создается система, кем и
когда утверждены эти документы;
• плановые сроки начала и окончания работы по созданию системы;
• сведения об источниках и порядке финансирования работ;
• порядок оформления и предъявления заказчику результатов работ по
созданию системы (ее частей), по изготовлению и наладке отдельных средств
(технических, программных, информационных) и
программно-технических (программно-методических) комплексов системы.
Раздел «Назначение и цели создания (развития) системы» состоит из
подразделов:
• назначение системы;
• цели создания системы.
В подразделе «Назначение системы» указывают вид автоматизируемой
деятельности (управление, проектирование и т. п.) и перечень объектов
автоматизации (объектов), на которых предполагается ее использовать.
Для АСУ дополнительно указывают перечень автоматизируемых органов
(пунктов) управления и управляемых объектов.
В подразделе «Цели создания системы» приводят наименования и
требуемые значения технических, технологических, производственно-экономических
или других показателей объекта автоматизации, которые должны быть
достигнуты в результате создания АС, и указывают критерии оценки достижения
целей создания системы.
В разделе «Характеристики объекта автоматизации» приводят:
• краткие сведения об объекте автоматизации или ссылки на документы,
содержащие такую информацию;
• сведения об условиях эксплуатации объекта автоматизации и
характеристиках окружающей среды.
ПРИМЕЧАНИЕ
Для САПР в разделе дополнительно приводят основные параметры и характеристики
объектов проектирования.

144 Глава 8 • Разработка текстовой технической документации на АС
Раздел «Требования к системе» состоит из следующих подразделов:
• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения.
Состав требований к системе, включаемых в данный раздел ТЗ на АС,
устанавливают в зависимости от вида, назначения, специфических особенностей
и условий функционирования конкретной системы. В каждом подразделе
приводят ссылки на действующие НТД, определяющие требования к системам
соответствующего вида.
В подразделе «Требования к системе в целом» указывают:
• требования к структуре и функционированию системы;
• требования к численности и квалификации персонала системы и режиму
его работы;
• показатели назначения;
• требования к надежности;
• требования безопасности;
• требования к эргономике и технической эстетике;
• требования к транспортабельности для подвижных АС;
• требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов системы;
• требования к защите информации от несанкционированного доступа;
• требования по сохранности информации при авариях;
• требования к защите от влияния внешних воздействий;
• требования к патентной чистоте;
• требования по стандартизации и унификации;
• дополнительные требования.
В требованиях к структуре и функционированию системы приводят:
• перечень подсистем, их назначение и основные характеристики,
требования к числу уровней иерархии и степени централизации системы;
• требования к способам и средствам связи для информационного обмена
между компонентами системы;
• требования к характеристикам взаимосвязей создаваемой системы со
смежными системами, требования к ее совместимости, в том числе указания
о способах обмена информацией (автоматически, пересылкой
документов, по телефону и т. п.);
• требования к режимам функционирования системы;
• требования по диагностированию системы;
• перспективы развития, модернизации системы.
В требованиях к численности и квалификации персонала на АС приводят:
• требования к численности персонала (пользователей) АС;
• требования к квалификации персонала, порядку его подготовки и
контроля знаний и навыков;
• требуемый режим работы персонала АС.

8.1. Техническое задание на АС 145
В требованиях к показателям назначения АС приводят значения параметров,
характеризующие степень соответствия системы ее назначению.
Для АСУ указывают:
• степень приспособляемости системы к изменению процессов и методов
управления, к отклонениям параметров объекта управления;
• допустимые пределы модернизации и развития системы;
• вероятностно-временные характеристики, при которых сохраняется
целевое назначение системы.
В требования к надежности включают:
• состав и количественные значения показателей надежности для системы
в целом или ее подсистем;
• перечень аварийных ситуаций, по которым должны быть
регламентированы требования к надежности, и значения соответствующих показателей;
• требования к надежности технических средств и программного
обеспечения;
• требования к методам оценки и контроля показателей надежности на
разных стадиях создания системы в соответствии с действующими
нормативно-техническими документами.
В требования по безопасности включают требования по обеспечению
безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте
технических средств системы (защита от воздействий электрического тока,
электромагнитных полей, акустических шумов и т. п.), по допустимым уровням
освещенности, вибрационных и шумовых нагрузок.
В требования по эргономике и технической эстетике включают
показатели АС, задающие необходимое качество взаимодействия человека с
машиной и комфортность условий работы персонала. Для подвижных АС в
требования к транспортабельности включают конструктивные требования,
обеспечивающие транспортабельность технических средств системы, а также
требования к транспортным средствам.
В требования к эксплуатации, техническому обслуживанию, ремонту и
хранению включают:
• условия и регламент (режим) эксплуатации, которые должны
обеспечивать использование технических средств (ТС) системы с заданными
техническими показателями, в том числе виды и периодичность обслуживания
ТС системы или допустимость работы без обслуживания;
• предварительные требования к допустимым площадям для размещения
персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;
• требования по количеству, квалификации обслуживающего персонала и
режимам его работы;
• требования к составу, размещению и условиям хранения комплекта
запасных изделий и приборов;
• требования к регламенту обслуживания.
В требования к защите информации от несанкционированного доступа
включают требования, установленные в НТД, действующей в отрасли
(ведомстве) заказчика.

146 Глава 8 • Разработка текстовой технической документации на АС
В требованиях по сохранности информации приводят перечень событий:
аварий, отказов технических средств (в том числе — потеря питания) и т. п.,
при которых должна быть обеспечена сохранность информации в системе.
В требованиях к средствам защиты от внешних воздействий приводят:
• требования к радиоэлектронной защите средств АС;
• требования по стойкости, устойчивости и прочности к внешним
воздействиям (среде применения).
В требованиях по патентной чистоте указывают перечень стран, в отношении
которых должна быть обеспечена патентная чистота системы и ее частей.
В требования к стандартизации и унификации включают: показатели,
устанавливающие требуемую степень использования стандартных, унифицированных
методов реализации функций (задач) системы, поставляемых программных
средств, типовых математических методов и моделей, типовых проектных
решений, унифицированных форм управленческих документов, установленных
ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической
информации и классификаторов других категорий в соответствии с областью их
применения, требования к использованию типовых автоматизированных рабочих
мест, компонентов и комплексов.
В дополнительные требования включают:
• требования к оснащению системы устройствами для обучения
персонала (тренажерами, другими устройствами аналогичного назначения) и
документацией на них;
• требования к сервисной аппаратуре, стендам для проверки элементов
системы;
• требования к системе, связанные с особыми условиями эксплуатации;
• специальные требования по усмотрению разработчика или заказчика
системы.
В подразделе «Требования к функциям (задачам), выполняемым системой»,
приводят:
• по каждой подсистеме перечень функций, задач или их комплексов (в том
числе обеспечивающих взаимодействие частей системы), подлежащих
автоматизации;
• при создании системы в две или более очереди — перечень
функциональных подсистем, отдельных функций или задач, вводимых в действие в
первой и последующих очередях;
• временной регламент реализации каждой функции, задачи (или
комплекса задач);
• требования к качеству реализации каждой функции (задачи или
комплекса задач), к форме представления выходной информации, характеристики
необходимой точности и времени выполнения, требования
одновременности выполнения группы функций, достоверности выдачи результатов;
• перечень и критерии отказов для каждой функции, по которой задаются
требования по надежности.
В подразделе «Требования к видам обеспечения» в зависимости от вида
системы приводят требования к математическому, информационному, лингвистиче-

8.1. Техническое задание на АС 147
скому, программному, техническому, метрологическому, организационному,
методическому и другим видам обеспечения системы.
Для математического обеспечения системы приводят требования к составу,
области применения (ограничения) и способам использования в системе
математических методов и моделей, типовых алгоритмов и алгоритмов,
подлежащих разработке.
Для информационного обеспечения системы приводят требования:
• к составу, структуре и способам организации данных в системе;
• к информационному обмену между компонентами системы;
• к информационной совместимости со смежными системами;
• по использованию общесоюзных и зарегистрированных республиканских,
отраслевых классификаторов, унифицированных документов и
классификаторов, действующих на данном предприятии;
• по применению систем управления базами данных;
• к структуре процесса сбора, обработки, передачи данных в системе и
представлению данных;
• к защите данных от разрушений при авариях и сбоях в электропитании
системы;
• к контролю, хранению, обновлению и восстановлению данных;
• к процедуре придания юридической силы документам, продуцируемым
техническими средствами АС (в соответствии с ГОСТ 6.10.4).
Для лингвистического обеспечения системы приводят требования к
применению в системе языков программирования высокого уровня, языков
взаимодействия пользователей и технических средств системы, а также требования
к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам
манипулирования данными, средствам описания предметной области (объекта
автоматизации), к способам организации диалога.
Для программного обеспечения системы приводят перечень покупных
программных средств, а также требования:
• к независимости программных средств от используемых СВТ и
операционной среды;
• к качеству программных средств, а также к способам его обеспечения и
контроля;
• по необходимости согласования вновь разрабатываемых программных
средств с фондом алгоритмов и программ.
Для технического обеспечения системы приводят требования:
• к видам технических средств, в том числе к видам комплексов
технических средств, программно-технических комплексов и других
комплектующих изделий, допустимых к использованию в системе;
• к функциональным, конструктивным и эксплуатационным
характеристикам средств технического обеспечения системы.
В требованиях к метрологическому обеспечению приводят:
• предварительный перечень измерительных каналов;

148 Глава 8 • Разработка текстовой технической документации на АС
• требования к точности измерений параметров и (или) к метрологическим
характеристикам измерительных каналов;
• требования к метрологической совместимости технических средств
системы;
• перечень управляющих и вычислительных каналов системы, для которых
необходимо оценивать точностные характеристики;
• требования к метрологическому обеспечению технических и
программных средств, входящих в состав измерительных каналов системы, средств
встроенного контроля, метрологической пригодности измерительных
каналов и средств измерений, используемых при наладке и испытаниях
системы;
• вид метрологической аттестации (государственная или ведомственная)
с указанием порядка ее выполнения и организаций, проводящих
аттестацию.
Для организационного обеспечения приводят требования:
• к структуре и функциям подразделений, участвующих в
функционировании системы или обеспечивающих эксплуатацию;
• к организации функционирования системы и порядку взаимодействия
персонала АС и персонала объекта автоматизации;
• к защите от ошибочных действий персонала системы.
Для методического обеспечения САПР приводят требования к составу
нормативно-технической документации системы (перечень применяемых при ее
функционировании стандартов, нормативов, методик и т. п.).
Раздел «Состав и содержание работ по созданию (развитию) системы»
должен содержать перечень стадий и этапов работ по созданию системы в
соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций —
исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций
на участие в создании системы, или запись, определяющую ответственного
(заказчик или разработчик) за проведение этих работ.
В данном разделе также приводят:
• перечень документов по ГОСТ 34.201-89, предъявляемых по окончании
соответствующих стадий и этапов работ;
• вид и порядок проведения экспертизы технической документации
(стадия, этап, объем проверяемой документации, организация-эксперт);
• программу работ, направленных на обеспечение требуемого уровня
надежности разрабатываемой системы (при необходимости);
• перечень работ по метрологическому обеспечению на всех стадиях
создания системы с указанием их сроков выполнения и
организаций-исполнителей (при необходимости).
В разделе «Порядок контроля и приемки системы» указывают:
• виды, состав, объем и методы испытаний системы и ее составных частей
(виды испытаний в соответствии с действующими нормами,
распространяющимися на разрабатываемую систему);

8.1. Техническое задание на АС 149
• общие требования к приемке работ по стадиям (перечень участвующих
предприятий и организаций, место и сроки проведения), порядок
согласования и утверждения приемочной документации;
• статус приемочной комиссии (государственная, межведомственная,
ведомственная).
В разделе «Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие» необходимо привести перечень
основных мероприятий, которые следует выполнить при подготовке объекта
автоматизации к вводу АС в действие, и их исполнителей. В перечень основных
мероприятий включают:
• приведение поступающей в систему информации (в соответствии с
требованиями к информационному и лингвистическому обеспечению) к виду,
пригодному для обработки с помощью ЭВМ;
• изменения, которые необходимо осуществить в объекте автоматизации;
• создание условий функционирования объекта автоматизации, при
которых гарантируется соответствие создаваемой системы требованиям,
содержащимся в ТЗ;
• создание необходимых для функционирования системы подразделений
и служб;
• сроки и порядок комплектования штатов и обучения персонала.
В разделе «Требования к документированию» приводят:
• согласованный разработчиком и заказчиком системы перечень
подлежащих разработке комплектов и видов документов, соответствующих
требованиям ГОСТ 34.201-89 и НТД отрасли заказчика; перечень документов,
выпускаемых на машинных носителях; требования к микрофильмированию
документации;
• требования по документированию комплектующих элементов
межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
• при отсутствии государственных стандартов, определяющих
требования к документированию элементов системы, дополнительно включают
требования к составу и содержанию таких документов.
В разделе 4 Источники разработки» должны быть перечислены документы и
информационные материалы (технико-экономическое обоснование, отчеты о
законченных научно-исследовательских работах, информационные материалы на
отечественные, зарубежные системы-аналоги и др.), на основании которых
разрабатывалось ТЗ и которые должны быть использованы при создании системы.
В состав ТЗ на АС при наличии утвержденных методик включают
приложения, содержащие:
• расчет ожидаемой эффективности системы;
• оценку научно-технического уровня системы.
Приложения включают в состав ТЗ на АС по согласованию между
разработчиком и заказчиком системы.

150 Глава 8 • Разработка текстовой технической документации на АС
ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к текстовым
документам на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы, без рамки, основной надписи и
дополнительных граф к ней.
Номера листов (страниц) проставляют начиная с первого листа, следующего за
титульным листом, в верхней части листа (над текстом, посередине) после
обозначения кода ТЗ на АС.
Значения показателей, норм и требований указывают, как правило, с
предельными отклонениями или максимальным и минимальным значениями. Если
эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ
на АС следует приводить ссылку на эти документы или их разделы, а также
дополнительные требования, учитывающие особенности создаваемой системы.
Если конкретные значения показателей, норм и требований не могут быть
установлены в процессе разработки ТЗ на АС, в нем следует сделать запись о
порядке установления и согласования этих показателей, норм и требований:
«Окончательное требование (значение) уточняется в процессе ... и
согласовывается протоколом с ... на стадии ..>. При этом в текст ТЗ на АС изменений не
вносят.
На титульном листе помещают подписи заказчика, разработчика и
согласующих организаций, которые скрепляют гербовой печатью. При необходимости
титульный лист оформляют на нескольких страницах. Подписи разработчиков
ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении
проекта ТЗ на АС, помещают на последнем листе.
Форма титульного листа ТЗ на АС приведена в приложении 2
рассматриваемого стандарта. Форма последнего листа ТЗ на АС приведена в приложении 3.
При необходимости на титульном листе ТЗ на АС допускается помещать
установленные в отрасли коды, например: гриф секретности, код работы,
регистрационный номер ТЗ и др.
Титульный лист дополнения к ТЗ на АС оформляют аналогично
титульному листу технического задания. Вместо наименования «Техническое задание»
пишут: «Дополнение № ... к ТЗ на АС ... ».
На последующих листах дополнения к ТЗ на АС помещают основание для
изменения, содержание изменения и ссылки на документы, в соответствии
с которыми вносятся эти изменения.
При изложении текста дополнения к ТЗ следует указывать номера
соответствующих пунктов, подпунктов, таблиц основного ТЗ на АС и т. п. и применять
слова: «заменить», «дополнить», «исключить», «изложить в новой редакции».
Проект ТЗ на АС разрабатывает организация - разработчик системы с
участием заказчика на основании технических требований (заявки,
тактико-технического задания и т. п.).
Необходимость согласования проекта ТЗ на АС с органами государственного
надзора и другими заинтересованными организациями определяют совместно
заказчик системы и разработчик проекта ТЗ на АС.
Замечания по проекту ТЗ на АС должны быть представлены с техническим
обоснованием. Решения по замечаниям должны быть приняты разработчиком
проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС. Если при

8.1. Техническое задание на АС 151
согласовании проекта ТЗ на АС возникли разногласия между разработчиком
и заказчиком (или другими заинтересованными организациями), то
составляется протокол разногласий (форма произвольная) и конкретное решение
принимается в установленном порядке.
Согласование проекта ТЗ на АС разрешается оформлять отдельным
документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на
этот документ.
Утверждение ТЗ на АС осуществляют руководители предприятий
(организаций) разработчика и заказчика системы.
ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть
проверено службой нормоконтроля организации - разработчика ТЗ и, при
необходимости, подвергнуто метрологической экспертизе.
Согласование и утверждение дополнений к ТЗ на АС проводят в порядке,
установленном для ТЗ на АС. Изменения к ТЗ на АС не допускается
утверждать после представления системы или ее очереди на приемосдаточные
испытания.
Регистрацию, учет и хранение ТЗ на АС и дополнений к нему проводят в
соответствии с требованиями ГОСТ 2.501-88. Единая система конструкторской
документации. Правила учета и хранения.
Полезная информация по написанию ТЗ на АС содержится на веб-странице:
htfc://auttoritm^
34.htm&n=HTMUdd_g^^
Образец технического задания на АС представлен в приложении Т на
компакт-диске, основу которого составил шаблон, размещенный на веб-странице
Информационные источники
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание
автоматизированной системы.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
ГОСТ 2.501-88. Единая система конструкторской документации. Правила
учета и хранения.

152 Глава 8 • Разработка текстовой технической документации на АС
8.2. Описание информационного обеспечения
системы
Описание информационного обеспечения системы разрабатывается в
соответствии с требованиями подраздела 5.3 РД 50-34.698-90. Комплекс стандартов и
руководящих документов на автоматизированные системы.
Автоматизированные системы. Требования к содержанию документов. Методические указания.
Код документа — П5.
Документ содержит разделы:
• состав информационного обеспечения;
• организация информационного обеспечения;
• организация сбора и передачи информации;
• построение системы классификации и кодирования;
• организация внутримашинной информационной базы;
• организация внемашинной информационной базы.
В разделе «Состав информационного обеспечения» указывают
наименование и назначение всех баз данных и наборов данных.
В разделе «Организация информационного обеспечения» приводят:
• принципы организации информационного обеспечения системы;
• обоснование выбора носителей данных и принципы распределения
информации по типам носителей;
• описание принятых видов и методов контроля в маршрутах обработки
данных при создании и функционировании внемашинной и
внутримашинной информационных баз с указанием требований, на соответствие
которым проводят контроль;
• описание решений, обеспечивающих информационную совместимость
АС с другими системами управления по источникам, потребителям
информации, по сопряжению применяемых классификаторов (при
необходимости), по использованию в АС унифицированных систем
документации.
В разделе «Организация сбора и передачи информации» приводят:
• перечень источников и носителей информации с указанием оценки
интенсивности и объема потоков информации;
• описание общих требований к организации сбора, передачи, контроля и
корректировки информации.
В разделе «Построение системы классификации и кодирования» приводят:
• описание принятых для применения в АС классификации объектов во
вновь разработанных классификаторах и в тех действующих
классификаторах, из которых используется часть кода;
• методы кодирования объектов классификации во вновь разработанных
классификаторах.

8.2. Описание информационного обеспечения системы 153
В разделе «Организация внутримашинной информационной базы» приводят
• описание принципов построения внутримашинной информационной
базы, характеристики ее состава и объема;
• описание структуры внутримашинной информационной базы на уровне
баз данных с описанием характера взаимосвязей баз данных и указанием
функций АС, при реализации которых используют каждую базу данных,
характеристики данных, содержащихся в каждой базе данных.
В разделе « Организация внемашинной информационной базы» приводят
характеристики состава и объема внемашинной информационной базы,
принципы ее построения, в том числе основные положения по организации и
обслуживанию фонда нормативно-справочной информации во взаимосвязи с
автоматизированными функциями.
В приложениях к документу «Описание информационного обеспечения
системы» следует приводить справочные и другие дополнительные материалы и
сведения (систематизированный перечень наименований структурных единиц
информации с присвоенными им обозначениями и описаниями их сущности).
Оформление документа — в соответствии с требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к
текстовым документам на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы, с рамкой и основной надписью.
Документ удобно разрабатывать на базе шаблона, размещенного на
веб-странице: http://wvw.riigostCD^
Информационные источники
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.

154 Глава 8 • Разработка текстовой технической документации на АС
8.3. Описание программного обеспечения
Описание программного обеспечения разрабатывается в соответствии с
требованиями подраздела 6.1 РД 50-34.698-90. Комплекс стандартов и руководящих
документов на автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов. Методические указания. Код
документа - ПА.
Документ содержит вводную часть и разделы:
• структура программного обеспечения;
• функции частей программного обеспечения;
• методы и средства разработки программного обеспечения;
• операционная система;
• средства, расширяющие возможности операционной системы.
Во вводной части приводят основные сведения о техническом,
информационном и других видах обеспечения АС, необходимые для разработки программного
обеспечения, или ссылку на соответствующие документы проекта АС.
В разделе «Структура программного обеспечения» приводят перечень
частей программного обеспечения с указанием их взаимосвязей и обоснованием
выделения каждой из них.
В разделе «Функции частей программного обеспечения» приводят назначение
и описание основных функций для каждой части программного обеспечения.
В разделе «Методы и средства разработки программного обеспечения»
приводят перечень методов программирования и средств разработки программного
обеспечения АС с указанием частей программного обеспечения, при разработке
которых следует использовать соответствующие методы и средства.
В разделе «Операционная система» указывают:
• наименование, обозначение и краткую характеристику выбранной
операционной системы и ее версии, в рамках которой будут выполнять
разрабатываемые программы, с обоснованием выбора и указанием источников, где
дано подробное описание выбранной версии;
• наименование руководства, в соответствии с которым должна
осуществляться генерация выбранного варианта операционной системы;
• требования к варианту генерации выбранной версии операционной системы.
Раздел «Средства, расширяющие возможности операционной системы»
содержит подразделы, в которых для каждого используемого средства,
расширяющего возможности операционной системы, указывают:
• наименование, обозначение и краткую характеристику средства с
обоснованием необходимости его применения и указанием источника, где дано
подробное описание выбранного средства;
• наименование руководства, в соответствии с которым следует настраивать
используемое средство на конкретное применение;
• требования к настройке используемого средства.

8.3. Описание программного обеспечения 155
Оформление документа — в соответствии с требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к
текстовым документам на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы, с рамкой и основной надписью.
Документ удобно разрабатывать на базе шаблона, размещенного на
веб-странице: http://wvwv.Rigost.a
Информационные источники
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.

156 Глава 8 • Разработка текстовой технической документации на АС
8.4. Программа и методика испытаний
(компонентов, комплексов средств
автоматизации, подсистемы, систем)
Для грамотного составления программ и методик испытаний разработчик ТД
должен четко ориентироваться в видах, назначении, последовательности и
содержании различных испытаний автоматизированных систем, которые
определены требованиями ГОСТ 34.603-92. Информационная технология. Виды
испытаний автоматизированных систем, который гармонизирован с
требованиями ГОСТ Р 15.201-2000. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения.
Порядок разработки и постановки продукции на производство и ГОСТ 15.309-98.
Система разработки и постановки продукции на производство. Испытания и
приемка выпускаемой продукции.
ГОСТ 34.603-92. Информационная технология. Виды испытаний
автоматизированных систем устанавливает виды испытаний АС и общие требования
к их проведению.
Испытания АС проводят с целью проверки соответствия создаваемой АС
требованиям технического задания (ТЗ). Испытания представляют собой
процесс проверки выполнения заданных функций системы, определения и
проверки соответствия требованиям ТЗ количественных и (или) качественных
характеристик системы, выявления и устранения недостатков в действиях
системы и в разработанной документации.
Для АС устанавливают следующие основные виды испытаний:
• предварительные;
• опытная эксплуатация;
• приемочные.
В зависимости от взаимосвязей испытываемых в АС объектов испытания
могут быть автономные или комплексные.
Автономные испытания охватывают части АС. Их проводят по мере
готовности частей АС к сдаче в опытную эксплуатацию.
Комплексные испытания проводят для групп, взаимосвязанных частей АС
или для АС в целом.
Для планирования проведения всех видов испытаний разрабатывают
документ «Программа и методика испытаний». Разработчик документа
устанавливается в договоре или ТЗ.
Программа и методика испытаний должны устанавливать необходимый
и достаточный объем испытаний, обеспечивающий заданную достоверность
получаемых результатов.
Программа и методика испытаний может разрабатываться на АС в целом, на
части АС. В качестве приложения могут включаться тесты (контрольные
примеры).

8.4. Программа и методика испытаний 157
Предварительные испытания АС проводят для определения ее
работоспособности и решения вопроса о возможности приемки АС в опытную
эксплуатацию.
Предварительные испытания следует выполнять после проведения
разработчиком отладки и тестирования поставляемых программных и технических
средств системы и представления им соответствующих документов об их
готовности к испытаниям, а также после ознакомления персонала АС с
эксплуатационной документацией.
Опытную эксплуатацию АС проводят с целью определения фактических
значений количественных и качественных характеристик АС и готовности
персонала к работе в условиях функционирования АС, определения
фактической эффективности АС.
Приемочные испытания АС проводят для определения соответствия АС
техническому заданию, оценки качества опытной эксплуатации и решения
вопроса о возможности приемки АС в постоянную эксплуатацию.
Приемочным испытаниям АС должна предшествовать ее опытная
эксплуатация на объекте.
В зависимости от вида требований, предъявляемых к АС на испытаниях,
проверке или аттестации подвергают:
• комплекс программных и технических средств;
• персонал;
• эксплуатационную документацию, регламентирующую деятельность
персонала при функционировании АС;
• АС в целом.
При испытаниях АС проверяют:
• качество выполнения комплексом программных и технических средств
автоматических функций во всех режимах функционирования АС
согласно ТЗ на создание АС;
• знание персоналом эксплуатационной документации и наличие у него
навыков, необходимых для выполнения установленных функций во всех
режимах функционирования АС, согласно ТЗ на создание АС;
• полноту содержащихся в эксплуатационной документации указаний
персоналу по выполнению им функций во всех режимах функционирования
АС согласно ТЗ на создание АС;
• количественные и (или) качественные характеристики выполнения
автоматических и автоматизированных функций АС в соответствии с ТЗ;
• другие свойства АС, которым она должна соответствовать по ТЗ.
Испытания АС следует проводить на объекте заказчика. По согласованию
между заказчиком и разработчиком предварительные испытания и приемку
программных средств АС допускается проводить на технических средствах
разработчика при создании условий получения достоверных результатов испытаний.
Допускается последовательное проведение испытаний и сдача частей АС
в опытную и постоянную эксплуатацию при соблюдении установленной в ТЗ
очередности ввода АС в действие.

158 Глава 8 • Разработка текстовой технической документации на АС
Предварительные испытания АС могут быть:
• автономные;
• комплексные.
Автономные испытания АС следует проводить в соответствии с программой
и методикой автономных испытаний, разрабатываемых для каждой части АС.
В программе автономных испытаний указывают:
• перечень функций, подлежащих испытаниям;
• описание взаимосвязей объекта испытаний с другими частями АС;
• условия, порядок и методы проведения испытаний и обработки
результатов;
• критерии приемки частей по результатам испытаний.
К программе автономных испытаний следует прилагать график проведения
автономных испытаний.
Подготовленные и согласованные тесты (контрольные примеры) на этапе
автономных испытаний должны обеспечить:
• полную проверку функций и процедур по перечню, согласованному с
заказчиком;
• необходимую точность вычислений, установленную в ТЗ;
• проверку основных временных характеристик функционирования
программных средств (в тех случаях, когда это является существенным);
• проверку надежности и устойчивости функционирования программных
и технических средств.
В качестве исходной информации для теста рекомендуется использовать
фрагмент реальной информации организации-заказчика в объеме, достаточном
для обеспечения необходимой достоверности испытаний.
Результаты автономных испытаний частей АС следует фиксировать в
протоколах испытаний. Протокол должен содержать заключение о возможности
(невозможности) допуска части АС к комплексным испытаниям.
В случае, если проведенные автономные испытания будут признаны
недостаточными либо будет выявлено нарушение требований регламентирующих
документов по составу или содержанию документации, указанная часть АС
может быть возвращена на доработку и может быть назначен новый срок испытаний.
Комплексные испытания АС проводят путем выполнения комплексных тестов.
Результаты испытаний отражают в протоколе. Работу завершают оформлением
акта приемки в опытную эксплуатацию.
В программе комплексных испытаний АС или частей АС указывают:
• перечень объектов испытания;
• состав предъявляемой документации;
• описание проверяемых взаимосвязей между объектами испытаний;
• очередность испытаний частей АС;
• порядок и методы испытаний, в том числе состав программных средств
и оборудования, необходимых для проведения испытаний, включая
специальные стенды и полигоны.

8.4. Программа и методика испытаний 159
Для проведения комплексных испытаний должны быть представлены:
• программа комплексных испытаний;
• заключение по автономным испытаниям соответствующих частей АС и
устранение ошибок и замечаний, выявленных при автономных
испытаниях;
• комплексные тесты;
• программные и технические средства и соответствующая им
эксплуатационная документация.
При комплексных испытаниях допускается использовать в качестве исходной
информацию, полученную на автономных испытаниях частей АС.
Комплексный тест должен:
• быть логически увязанным;
• обеспечивать проверку выполнения функций частей АС во всех режимах
функционирования, установленных в ТЗ на АС, в том числе всех связей
между ними;
• обеспечивать проверку реакции системы на некорректную
информацию и аварийные ситуации.
Протокол комплексных испытаний должен содержать заключение о
возможности (невозможности) приемки АС в опытную эксплуатацию, а также
перечень необходимых доработок и рекомендуемые сроки их выполнения. После
устранения недостатков проводят повторные комплексные испытания в
необходимом объеме.
Опытную эксплуатацию проводят в соответствии с программой, в которой
указывают:
• условия и порядок функционирования частей АС и АС в целом;
• продолжительность опытной эксплуатации, достаточную для проверки
правильности функционирования АС при выполнении каждой функции
системы и готовности персонала к работе в условиях функционирования
АС;
• порядок устранения недостатков, выявленных в процессе опытной
эксплуатации.
Во время опытной эксплуатации АС ведут рабочий журнал, в который
заносят сведения о продолжительности функционирования АС, отказах, сбоях,
аварийных ситуациях, изменениях параметров объекта автоматизации,
проводимых корректировках документации и программных средств, наладке
технических средств. Сведения фиксируют в журнале с указанием даты и
ответственного лица. В журнал могут быть занесены замечания персонала по удобству
эксплуатации АС.
По результатам опытной эксплуатации принимают решение о возможности
(или невозможности) предъявления частей АС и системы в целом на приемочные
испытания.
Работа завершается оформлением акта о завершении опытной эксплуатации
и допуске системы к приемочным испытаниям.

160 Глава 8 • Разработка текстовой технической документации на AC
Приемочные испытания проводят в соответствии с программой, в которой
указывают:
• перечень объектов, выделенных в системе для испытаний и перечень
требований, которым должны соответствовать объекты (со ссылкой на
пункты ТЗ);
• критерии приемки системы и ее частей;
• условия и сроки проведения испытаний;
• средства для проведения испытаний;
• фамилии лиц, ответственных за проведение испытаний;
• методику испытаний и обработки их результатов;
• перечень оформляемой документации.
Для проведения приемочных испытаний должна быть предъявлена
следующая документация:
• техническое задание на создание АС;
• акт приемки в опытную эксплуатацию;
• рабочие журналы опытной эксплуатации;
• акт завершения опытной эксплуатации и допуска АС к приемочным
испытаниям;
• программа и методика испытаний.
Приемочные испытания следует проводить на функционирующем объекте.
Приемочные испытания в первую очередь должны включать проверку:
• полноты и качества реализации функций при штатных, предельных,
критических значениях параметров объекта автоматизации и в других
условиях функционирования АС, указанных в ТЗ;
• выполнения каждого требования, относящегося к интерфейсу системы;
• работы персонала в диалоговом режиме;
• средств и методов восстановления работоспособности АС после отказов;
• комплектности и качества эксплуатационной документации.
Проверку полноты и качества выполнения функций АС рекомендуется
проводить в два этапа. На первом этапе проводят испытания отдельных функций
(задач, комплексов задач). При этом проверяют выполнение требований ТЗ
к функциям (задачам, комплексам задач). На втором этапе проводят проверку
взаимодействия задач в системе и выполнение требований ТЗ к системе в целом.
По согласованию с заказчиком проверка задач, в зависимости от их
специфики, может проводиться автономно или в составе комплекса. Объединение
задач при проверке в комплексах целесообразно проводить с учетом общности
используемой информации и внутренних связей.
Проверку работы персонала в диалоговом режиме проводят с учетом
полноты и качества выполнения функций системы в целом.
Проверке подлежит:
• полнота сообщений, директив, запросов, доступных оператору, и их
достаточность для эксплуатации системы;

8.4. Программа и методика испытаний 161
• сложность процедур диалога, возможность работы персонала без
специальной подготовки;
• реакция системы и ее частей па ошибки оператора, средства сервиса.
Проверка средств восстановления работоспособности АС после отказов ЭВМ
должна включать:
• проверку наличия в эксплуатационной документации рекомендаций по
восстановлению работоспособности и полноту их описания;
• практическую выполнимость рекомендованных процедур;
• работоспособность средств автоматического восстановления функций
(при их наличии).
Проверку комплектности и качества эксплуатационной документации
следует проводить путем анализа документации на соответствие требованиям
нормативно-технических документов ТЗ.
Результаты испытаний объектов, предусмотренных программой,
фиксируют в протоколах, содержащих следующие разделы:
• назначение испытаний и номер раздела требований ТЗ на АС, по
которому проводят испытание;
• состав технических и программных средств, используемых при
испытаниях;
• указание методик, в соответствии с которыми проводились испытания,
обработка и оценка результатов;
• условия проведения испытаний и характеристики исходных данных;
• средства хранения и условия доступа к конечной, тестирующей
программе;
• обобщенные результаты испытаний;
• выводы о результатах испытаний и соответствии созданной системы или
ее частей определенному разделу требований ТЗ на АС.
Протоколы испытаний объектов по всей программе обобщают в едином
протоколе, на основании которого делают заключение о соответствии системы
требованиям ТЗ на АС и возможности оформления акта приемки АС в
постоянную эксплуатацию.
Работу завершают оформлением акта о приемке АС в постоянную
эксплуатацию.
Программы и методики испытаний (компонентов, комплексов средств
автоматизации, подсистемы, систем) разрабатываются в соответствии с требованиями
подраздела 2.14 РД 50-34.698-90. Комплекс стандартов и руководящих
документов на автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов. Методические указания. Код документа — ПМ.
Программа и методика испытаний комплекса средств автоматизации
проектирования на этапе опытного функционирования предназначена для
установления технических данных, подлежащих проверке при испытании компонентов
АС и комплекса средств автоматизации проектирования, а также порядка
испытаний и методов их контроля.

162 Глава 8 • Разработка текстовой технической документации на АС
Программа и методика испытаний системы (подсистемы) на этапе опытного
функционирования предназначена для установления данных, обеспечивающих
получение и проверку проектных решений, выявление причин сбоев,
определение качества работ, показателей качества функционирования системы
(подсистемы), проверку соответствия системы требованиям техники
безопасности, продолжительность и режим испытаний.
Программы испытаний должны содержать перечни конкретных проверок
(решаемых задач), которые следует осуществлять при испытаниях для
подтверждения выполнения требований ТЗ, со ссылками на соответствующие
методики (разделы методик) испытаний.
Перечень проверок, подлежащих включению в программу испытаний,
содержит:
• соответствие системы ТЗ;
• комплектность системы;
• комплектность и качество документации;
• комплектность, достаточность состава и качество программных средств и
программной документации;
• количество и квалификация обслуживающего персонала;
• степень выполнения требований функционального назначения системы;
• контролепригодность системы;
• выполнение требований противопожарной безопасности, промышленной
санитарии, эргономики;
• функционирование системы с применением программных средств.
Описание методов испытаний системы по отдельным показателям
рекомендуется располагать в той же последовательности, в которой эти показатели
расположены в технических требованиях.
Программа испытаний содержит разделы:
• объект испытаний;
• цель испытаний;
• общие положения;
• объем испытаний;
• условия и порядок проведения испытаний;
• материально-техническое обеспечение испытаний;
• метрологическое обеспечение испытаний;
• отчетность.
В документ включают приложения.
В зависимости от особенностей систем допускается объединять или
исключать отдельные разделы при условии изложения их содержания в других
разделах программы испытаний, а также включать в нее дополнительные разделы
(при необходимости).
В разделе «Объект испытаний» указывают:
• полное наименование системы, обозначение;
• комплектность испытательной системы.

8.4. Программа и методика испытаний 163
В разделе «Цель испытаний» указывают конкретные цели и задачи, которые
должны быть достигнуты и решены в процессе испытаний.
В разделе «Общие положения» указывают:
• перечень руководящих документов, на основании которых проводят
испытания;
• место и продолжительность испытаний;
• организации, участвующие в испытаниях;
• перечень ранее проведенных испытаний;
• перечень предъявляемых на испытания документов, откорректированных
по результатам ранее проведенных испытаний.
В разделе «Объем испытаний» указывают:
• перечень этапов испытаний и проверок, а также количественные и
качественные характеристики, подлежащие оценке;
• последовательность проведения и режим испытаний;
• требования по испытаниям программных средств;
• перечень работ, проводимых после завершения испытаний, требования к
ним, объем и порядок проведения.
В разделе «Условия и порядок проведения испытаний» указывают:
• условия проведения испытаний;
• условия начала и завершения отдельных этапов испытаний;
• имеющиеся ограничения в условиях проведения испытаний;
• требования к техническому обслуживанию системы;
• меры, обеспечивающие безопасность и безаварийность проведения
испытаний;
• порядок взаимодействия организаций, участвующих в испытаниях;
• порядок привлечения экспертов для исследования возможных
повреждений в процессе проведения испытаний;
• требования к персоналу, проводящему испытания, и порядок его допуска
к испытаниям.
В разделе «Материально-техническое обеспечение испытаний» указывают
конкретные виды материально-технического обеспечения с распределением
задач и обязанностей организаций, участвующих в испытаниях.
В разделе «Метрологическое обеспечение испытаний» приводят перечень
мероприятий по метрологическому обеспечению испытаний с распределением
задач и ответственности организаций, участвующих в испытаниях, за
выполнение соответствующих мероприятий.
В разделе «Отчетность» указывают перечень отчетных документов, которые
должны оформляться в процессе испытаний и по их завершении, с указанием
организаций и предприятий, разрабатывающих, согласующих и утверждающих
их, и сроки оформления этих документов.
К отчетным документам относят акт и отчет о результатах испытаний, акг
технического состояния системы после испытаний.

164 Глава 8* Разработка текстовой технической документации на АС
В приложения включают перечень методик испытаний, математических
и комплексных моделей, применяемых для оценки характеристик системы.
При проведении испытаний в несколько этапов программы испытаний
должны быть оформлены в виде единого документа.
Методики испытаний разрабатывают на основе ТЗ и утвержденных программ
испытаний с использованием типовых методик испытаний (при наличии).
При этом отдельные положения типовых методик испытаний могут уточняться
и конкретизироваться в разрабатываемых методиках испытаний в зависимости
от особенности системы и условий проведения испытаний. Содержание разделов
методик устанавливает разработчик.
Документ удобно разрабатывать на базе шаблона, размещенного на
веб-странице: ht^//www.rugost<x^
Информационные источники
ГОСТ 34.603-92. Информационная технология. Виды испытаний
автоматизированных систем.
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на
производство. Продукция производственно-технического назначения. Порядок
разработки и постановки продукции на производство.
ГОСТ 15.309-98. Система разработки и постановки продукции на
производство. Испытания и приемка выпускаемой продукции.
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.

8.5. Руководство пользователя АС 165
8.5. Руководство пользователя АС
Руководство пользователя АС разрабатывается в соответствии с требованиями
подраздела 3.4 РД 50-34.698-90. Комплекс стандартов и руководящих
документов на автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов. Методические указания. Код документа — ИЗ.
Документ содержит разделы:
• введение;
• назначение и условия применения;
• подготовка к работе;
• описание операций;
• аварийные ситуации;
• рекомендации по освоению.
В разделе 4 Введение» указывают:
• область применения;
• краткое описание возможностей;
• уровень подготовки пользователя;
• перечень эксплуатационной документации, с которым необходимо
ознакомиться пользователю.
В разделе «Назначение и условия применения» указывают:
• виды деятельности, функции, для автоматизации которых
предназначено данное средство автоматизации;
• условия, при соблюдении (выполнении, наступлении) которых
обеспечивается применение средства автоматизации в соответствии с назначением
(например, вид ЭВМ и конфигурация технических средств,
операционная среда и общесистемные программные средства, входная
информация, носители данных, база данных, требования к подготовке
специалистов и т. п.).
В разделе 4 Подготовка к работе» указывают:
• состав и содержание дистрибутивного носителя данных;
• порядок загрузки данных и программ;
• порядок проверки работоспособности.
В разделе «Описание операций» указывают:
• описание всех выполняемых функций, задач, комплексов задач, процедур;
• описание операций технологического процесса обработки данных,
необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
• наименование;
• условия, при соблюдении которых возможно выполнение операции;

166 Глава 8 • Разработка текстовой технической документации на АС
• подготовительные действия;
• основные действия в требуемой последовательности;
• заключительные действия;
• ресурсы, расходуемые на операцию.
В описании действий допускаются ссылки на файлы подсказок,
размещенные на магнитных носителях.
В разделе «Аварийные ситуации» указывают:
• действия в случае несоблюдения условий выполнения
технологического процесса, в том числе при длительных отказах технических средств;
• действия по восстановлению программ и (или) данных при отказе
магнитных носителей или обнаружении ошибок в данных;
• действия в случаях обнаружения несанкционированного
вмешательства в данные;
• действия в других аварийных ситуациях.
В разделе «Рекомендации по освоению» указывают рекомендации по
освоению и эксплуатации, включая описание контрольного примера, правила его
запуска и выполнения.
Оформление документа — в соответствии с требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к
текстовым документам на листах формата А4 по ГОСТ 2.301-68. Единая система
конструкторской документации. Форматы, с рамкой и основной надписью.
Прекрасный методический материал по разработке руководства пользователя
(и других документов на АС) размещен на веб-странице: http://authoritrv/?c=8.
Информационные источники
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.
Как писать руководство пользователя? Часть I. —
htty://authoritm/?c=8to=&t=H
htm n=HTMiyddj3ub/dd_write_manuals.htm.
Как писать руководство пользователя? Часть II. —
htty://authoritru/?c=88tb=&t=^
m&n=HTMiyddj3ub/dd_write_manuals_2.htm.

8.6. Инструкция по эксплуатации КТС 167
8.6. Инструкция по эксплуатации КТС
Инструкция по эксплуатации КТС разрабатывается в соответствии с
требованиями подраздела 4.19 РД 50-34.698-90. Комплекс стандартов и руководящих
документов на автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов. Методические указания. Код
документа -ИЭ.
Документ содержит разделы:
• общие указания;
• меры безопасности;
• порядок работы;
• проверка правильности функционирования;
• указания о действиях в разных режимах.
В разделе «Общие указания» указывают:
• вид оборудования, для которого составлена инструкция;
• наименование функций АС, реализуемых на данном оборудовании;
• регламент и режимы работы оборудования по реализации функций;
• перечень эксплуатационных документов, которыми должен
дополнительно руководствоваться персонал при эксплуатации данного оборудования.
В разделе «Меры безопасности» перечисляют правила безопасности,
которые необходимо соблюдать во время подготовки оборудования к работе и при
его эксплуатации.
В разделе «Порядок работы» указывают:
• состав и квалификацию персонала, допускаемого к эксплуатации
оборудования;
• порядок проверки знаний персонала и допуска его к работе;
• описание работ и последовательность их выполнения.
В разделе «Проверка правильности функционирования» указывают
содержание и краткие методики основных проверок работоспособности
оборудования и правильности выполнения функций системы.
В разделе «Указания о действиях в разных режимах» перечисляют действия
персонала при нормальном режиме работы, аварийном отключении
оборудования, предаварийном и аварийном состоянии объекта автоматизации, пусковом
и остановочном режимах объекта автоматизации.
Оформление документа — в соответствии с требованиями ГОСТ 2.105-95.
Единая система конструкторской документации. Общие требования к
текстовым документам на листах формата А4 по ГОСТ 2.301-68. Единая
система конструкторской документации. Форматы, с рамкой и основной
надписью.

168 Глава 8* Разработка текстовой технической документации на AC
Информационные источники
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
ГОСТ 2.301-68. Единая система конструкторской документации. Форматы.

8.7. Технологическая инструкция, формуляр, паспорт 169
8.7. Технологическая инструкция, формуляр,
паспорт
Технологическая инструкция разрабатывается в соответствии с требованиями
подраздела 3.3 РД 50-34.698-90. Комплекс стандартов и руководящих
документов на автоматизированные системы. Автоматизированные системы.
Требования к содержанию документов. Методические указания. Код документа — И2.
Документ «Технологическая инструкция» разрабатывают на операцию или
комплекс операций технологического процесса обработки данных.
В документе указывают наименование технологической операции
(операций), на которую разработан документ, и приводят сведения о порядке и
правилах выполнения операций (операции) технологического процесса
обработки данных. В инструкции приводят перечень должностей персонала, на
которые распространяется данная инструкция.
Номенклатуру технологических инструкций определяют, исходя из
принятого процесса обработки данных. Структуру документа устанавливает
разработчик в зависимости от содержания.
Документ удобно разрабатывать на базе шаблона, размещенного на
веб-странице: ht^://www.rugosta^
Формуляр разрабатывается в соответствии с требованиями подраздела 2.9
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания. Код документа — ФО.
Документ содержит разделы:
• общие сведения;
• основные характеристики;
• комплектность;
• свидетельство о приемке;
• гарантийные обязательства;
• сведения о состоянии АС;
• сведения о рекламациях.
В разделе «Общие сведения» указывают наименование АС, ее обозначение,
присвоенное разработчиком, наименование разработчика, дата сдачи АС в
эксплуатацию, общие указания персоналу по эксплуатации АС, требования по
ведению формуляра и месте его хранения, в том числе перечень технической
документации, с которой должен быть ознакомлен персонал.
В разделе «Основные характеристики» указывают:
• перечень реализуемых функций;
• количественные и качественные характеристики АС и ее частей;
• описание принципов функционирования АС, регламент и режимы
функционирования;
• сведения о взаимодействии АС с другими системами.

170 Глава 8 • Разработка текстовой технической документации на АС
В разделе «Комплектность» указывают:
• перечень технических и программных средств, в том числе носителей
данных;
• перечень эксплуатационных документов.
В разделе «Свидетельство о приемке» указывают:
• даты подписания актов о приемке АС и ее частей в промышленную
эксплуатацию;
• фамилии председателей комиссий, осуществлявших приемку АС.
В разделе «Гарантийные обязательства» указывают:
• гарантийные обязательства разработчиков АС по системе в целом и
частям, имеющим разные гарантийные сроки;
• перечень технических средств АС, имеющих гарантийные сроки
службы меньше гарантийных сроков для системы.
В разделе «Сведения о состоянии АС» указывают:
• сведения о неисправностях, в том числе дату, время, характер, причину
возникновения, и лицах, устранивших неисправность;
• замечания по эксплуатации и аварийным ситуациям, принятые меры;
• сведения о проведении проверок измерительных устройств и точностных
характеристик измерительных каналов (для АСУ ТП);
• сведения о ремонте технических средств и изменениях в программном
обеспечении с указанием основания, даты и содержания изменения;
• сведения о выполнении регламентных (профилактических, работ и их
результатах.
В разделе «Сведения о рекламациях» указывают сведения о рекламациях
с указанием номера, даты, краткого содержания рекламационного акта, а также
сведения об устранении замечаний, указанных в акте.
Паспорт разрабатывается в соответствии с требованиями подраздела 2.8
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания. Код документа — ПС.
Документ содержит разделы:
• общие сведения об АС;
• основные характеристики АС;
• комплектность;
• свидетельство (акт) о приемке;
• гарантии изготовителя (поставщика);
• сведения о рекламациях.
В разделе «Общие сведения об АС» указывают наименование АС, ее
обозначение, присвоенное разработчиком, наименование предприятия-поставщика и
другие сведения об АС в целом.

8.7. Технологическая инструкция, формуляр, паспорт 171
В разделе «Основные характеристики АС» должны быть приведены:
• сведения о составе функций, реализуемых АС, в том числе
измерительных и управляющих;
• описание принципа функционирования АС;
• общий регламент и режимы функционирования АС и сведения о
возможности изменения режимов ее работы;
• сведения о совместимости АС с другими системами.
В разделе «Комплектность» указывают все непосредственно входящие в
состав АС комплексы технических и программных средств, отдельные средства, в
том числе носители данных и эксплуатационные документы.
В разделе «Свидетельство о приемке» приводят дату подписания акта о
приемке АС в промышленную эксплуатацию и фамилии лиц, подписавших акт.
В разделе «Гарантии изготовителя» приводят сроки гарантии АС в целом и
ее отдельных составных частей, если эти сроки не совпадают со сроками
гарантии АС в целом.
В разделе «Сведения о рекламациях» регистрируют все предъявленные
рекламации, их краткое содержание и меры, принятые по рекламациям.
Формуляр и паспорт удобно разрабатывать на базе шаблонов, размещенных
на веб-страницах:
http://www.rogost.com/index.php?option=rom
и
http://www.mgostxom/index^
Содержание и оформление других видов ТД на АС определено
требованиями РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.
Образцы оформления многих видов ТД на АС размещены на веб-странице:
htty://vww.mgost.rom/ind^
308Jtemid=77.
Информационные источники
РД 50-34.698-90. Комплекс стандартов и руководящих документов на
автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов. Методические указания.

Перевод, локализация,
редактирование,
придание юридического статуса
и оформление переводов
иностранной технической
документации

174 Глава 9 • Перевод иностранной технической документации
9.1. Особенности перевода технической
документации и его качество
В современных отечественных разработках продукции высоких технологий
нередко используются комплектующие изделия и составные части зарубежного
производства. В комплект поставки такой продукции неотъемлемой частью
входит техническая документация, разрабатываемая ее производителем, в том числе
переводы технических документов зарубежных поставщиков составных частей
и комплектующих изделий. Разработчик продукции при этом несет
юридическую ответственность за соответствие технической документации (включая
переводы) поставляемой технике (вспомним известный случай с микроволновой
печью, в которой высушили кошку). Поэтому вопрос о квалифицированном
и качественном переводе технического документа, а также его легализации
является для современного российского производителя весьма актуальным.
Отечественный рынок технических переводов в настоящее время
представлен достаточно большим числом переводческих компаний. На наш взгляд, при
выборе исполнителя перевода следует отдавать предпочтение тем фирмам,
которые придерживаются непреложного принципа: квалифицированный перевод
технического документа на русский язык, его локализацию и редактирование
могут выполнять только специалисты в предметной области с отличным
знанием иностранного языка. При этом, как минимум, редактор должен быть знаком
с действующей в России системой разработки и постановки на производство
промышленной продукции. Данному принципу следуют, в частности, такие
известные компании, как НЕОТЕК, ИНТЕНТ и ЛОГРУС (Москва), которыми
разработаны весьма грамотные и подробные методические рекомендации
и справочные руководства для переводчиков и редакторов технических
текстов, ЛИТТЕРА (Москва), МУЛТИЛАЙЗ (Санкт-Петербург) и ряд других.
Особенности перевода технической документации и критерии его качества
наиболее ясно и доступно изложены в лекции директора переводческой
компании ИНТЕНТ И. С. Шалыта, прочитанной им 26 сентября 2007 г. на
практической конференции-семинаре «Современные системы автоматизации работы
переводчика». Процесс перевода технической документации, — считает он, —
это не замена предложений исходного текста на предложения целевого языка
в соответствии с грамматикой и лексикой, а ясная и точная передача смысла
документа в соответствии с традициями целевого языка вне зависимости от того,
каким образом эта мысль (информация) изложена в исходном тексте. И с этим
утверждением, на наш взгляд, нельзя не согласиться.
Говоря о качестве перевода технического документа, И. С. Шалыт вводит
десять критериев перевода высокого качества:
• перевод должен быть адекватным исходному тексту, то есть верно
передавать смысл, в том числе содержащийся и в достаточно явном подтексте;
• перевод должен быть изложен ясно, доходчиво и по возможности кратко;
• в переводе должны быть устранены все замеченные случаи
невразумительного и нелогичного изложения, а также ошибки исходного документа;

9.1. Особенности перевода технической документации и его качество 175
• при изложении переводного текста должны обязательно использоваться
стандартные словесные формулы, употребляемые в конкретной области
знаний;
• перевод должен быть свободен от стилистических дефектов текста
(смещения логического ударения, расщепленного сказуемого, тавтологии и т. п.);
• по стилю изложения перевод должен соответствовать жанровым
особенностям документа (то есть соответствовать стилю инструкции, или
нормативного документа, или рекламного проспекта, или научной статьи и т. д.);
• применяемая терминология должна соответствовать российским
нормативным документам, сложившейся практике их применения и, при
необходимости, согласована с заказчиком;
• в переводе должно быть соблюдено единство терминологии;
• в переводе не должно быть пропусков, опечаток, орфографических и
синтаксических ошибок;
• в переводе должны быть соблюдены правила редакционно-издательского
оформления, то есть правила, определяющие, где ставить точку, где не
ставить точку, где применять длинное тире, где дефис и т. д. и т. п.
При этом отмечается, что если требования к переводу высокого качества
сформулировать относительно легко, то к переводу обычного (приемлемого) —
сложно. Трудно формализовать уровень, до которого можно опуститься в
переводе, который нельзя назвать переводом высокого качества.
Некоторые специалисты считают, что у перевода серьезного технического
текста могут быть лишь два критерия оценки качества — «годится» и «не
годится», остальное же — дело вкуса и в обязательные требования качества
включению не подлежит. Перефразируя известный афоризм Козьмы Пруткова,
считают они, не нужно переводить хорошо, не нужно переводить плохо, нужно
переводить так, как этого требуют условия дальнейшего использования перевода.
С позиций редактора, являющегося специалистом в некоей предметной
области, качество перевода может быть также оценено числом внесенных в текст
редакционных правок, хотя и это может тоже оказаться субъективным.
Таким образом, вопрос качества перевода технического документа является
философским и трудно поддающимся формальной оценке. Тем не менее
сформулированные выше критерии перевода высокого качества, по нашему мнению,
следует считать существенными.
Предупредив возможное недовольство переводчиков-лингвистов такой
постановкой вопроса, отметим, что упомянутые критерии не являются
требованиями к переводчику. Перевод технического документа — результат
совместного труда переводчика и редактора.
Информационные источники
Шалыт И. С. Качество перевода технической документации. Лекция. —
Инженерная переводческая издательская компания ИНТЕНТ. М., 2007. — 18 с,
ht^://vvww.trwod<shop.neVlib/articles/qualityintent.pdf.

176 Глава 9 • Перевод иностранной технической документации
9.2. Рекомендации переводчику технической
документации
С позиций обеспечения должного качества конечной русскоязычной
технической документации основными правилами, которых должен придерживаться
переводчик таких текстов, являются следующие.
Переводчик технических текстов, прежде всего, должен изучить, знать и
применять на практике положения следующих нормативных документов.
• ГОСТ 7.36-2006. Система стандартов по информации, библиотечному
и издательскому делу. Неопубликованный перевод. Обилие требования
и правила оформления.
• Письменный перевод. Рекомендации переводчику и заказчику /
Составитель Н. Дупленский. — Союз переводчиков России. — М., 2004. — 24 с, 13
приложений, http://www.transiatDrs-union.ru
и http://www.russian-translators.ru/for-translators/ exp/exp-pract/wr-tr/.
• Требования к предоставлению текста внештатными переводчиками.
Рабочая инструкция РИ7.4-02-01/03. Разработчик Е. Рембовская. ООО «БТД
Неотек». - М., 2004. - 56 с.
• Методическое и справочное руководство по переводу на русский язык,
тематическому редактированию, литературной правке и редакционно-из-
дательскому оформлению инженерно-технической документации/
Составитель И. Шалыт. — Инженерная переводческая издательская компания
ИНТЕНТ. М., 2007. - 108 с, http://www.intent93.ru.
Переводчик должен ознакомиться с функциями редактора технического
перевода, выполняющего проверку и правку текста, чтобы представлять, на что
в первую очередь обратит внимание редактор и какими могут быть последствия
плохого перевода.
Переводчик должен обратить особое внимание на выполнение следующих
требований, несоблюдение которых наиболее часто встречается в переводах.
Текст перевода должен быть локализован.
Под локализацией понимается приведение текста перевода в соответствие
с национальными особенностями целевого языка.
Типичными задачами локализации являются использование национальных
символов валюты, применение принятых форматов представления даты и
времени, правил алфавитной сортировки текстов, использование в графическом
интерфейсе пользователя программного обеспечения принятой на целевом языке
терминологии, корректное выравнивание и размещение элементов интерфейса.
Текст перевода должен быть кратким, четким и не допускать различных
толкований. При изложении обязательных требований в тексте должны
применяться слова «должен», «следует», «необходимо», «требуется, чтобы»,
«разрешается только», «не допускается», «запрещается», «не следует». При
изложении других положений следует применять слова «могут быть», «как правило»,

9.2. Рекомендации переводчику технической документации 177
«при необходимости», «может быть», «в случае* и т. д. При этом допускается
использовать повествовательную форму изложения текста документа,
например, «применяют*, «указывают» и т. п.
Перевод заголовков разделов и подразделов не следует формулировать в
редакции: «О <...>», «Что Вы знаете о <...>>, «Как настроить <...>», а нужно
соответственно формулировать: «<...>», «<...>>, «Настройка <...>* и т. п.
Приводимые в тексте перевода числовые данные и единицы физических
величин следует применять в соответствии с ГОСТ 8.417-2002. Государственная
система обеспечения единства измерений. Единицы физических величин.
Ссылки на национальные и международные стандарты в переводе должны
быть приведены на языке оригинала, после чего содержать в скобках их
русскоязычный перевод.
Оформление перевода должно соответствовать оформлению оригинала.
В переводах должны применяться научно-технические термины,
обозначения и определения, установленные соответствующими стандартами, а при их
отсутствии — общепринятые в научно-технической литературе.
В тексте перевода не следует употреблять слова «Вы», «Вам» «Ваш»; фразы
следует строить в безличной форме.
В тексте перевода не допускается:
• применять обороты разговорной речи, техницизмы, профессионализмы;
• применять для одного и того же понятия различные научно-технические
термины, близкие по смыслу (синонимы), а также иностранные слова
и термины при наличии равнозначных слов и терминов в русском языке;
• применять произвольные словообразования;
• применять сокращения слов, кроме установленных правилами русской
орфографии, соответствующими государственными стандартами, а также
списком сокращений, приведенным в данном документе;
• сокращать обозначения единиц физических величин, если они
употребляются без цифр, за исключением единиц физических величин в головках и
боковиках таблиц и в расшифровках буквенных обозначений, входящих в
формулы и рисунки.
В тексте перевода, за исключением формул, таблиц и рисунков, не
допускается:
• применять математический знак минус (-) перед отрицательными
значениями величин (следует писать слово «минус»);
• применять знак 0 для обозначения диаметра (следует писать слово
«диаметр»);
• применять без числовых значений математические знаки, например: >
(больше), < (меньше), - (равно), ? (больше или равно), й (меньше или
равно), ф (не равно), а также знаки № (номер), % (процент);
В тексте перевода в качестве кавычек должны применяться не обычные знаки «
(кроме текстов программ), а шевроны « и » (Alt + 0171, Alt + 0187).
Следует четко различать знаки дефиса (-), минуса (-) (Ctr + Num-) и тире
(-) (Alt + 0151).

178 Глава 9 • Перевод иностранной технической документации
Перед названием продукта или органа управления следует всегда
приводить определяющее (описательное) существительное (например, не Microsoft
Windows, а операционная система Microsoft Windows; не Microsoft Excel, а
приложение Microsoft Excel; не Scheduler, а программа Scheduler; не нажмите Start, а
нажмите кнопку START (ПУСК); не модуль 3610, а модуль типа 3610 и т. п.).
Если в переводе приводятся поясняющие надписи, наносимые
непосредственно на изготовляемое изделие (например, на планки, таблички к элементам
управления и т. и.), их выделяют прописными буквами (без кавычек), например
ВКЛ., ОТКЛ., или кавычками, если надпись состоит из цифр и (или) знаков.
Наименования команд, режимов, сигналов и т. п. в тексте следует выделять
кавычками, например: «Сигнал +27 В включен».
В описаниях нелокализованного программного обеспечения и в описании
технических средств зарубежного производства, поставляемых с надписями и
табличками на языке оригинала, следует приводить сообщения системы и
надписи на языке оригинала. По всему тексту перевода после англоязычного термина
нужно приводить в скобках его перевод на русский язык с заглавной буквы.
В тексте документа числовые значения величин с обозначением единиц
физических величин и единиц счета следует писать цифрами, а числа без обозначения
единиц физических величин и единиц счета от единицы до девяти — словами.
Примеры
1. Провести испытания пяти труб, каждая длиной 5 м.
2. Отобрать 15 труб для испытаний на давление.
Если абзац перед перечислениями завершается двоеточием, в соответствии с
нормами русского языка элементы перечисления должны начинаться со строчной
буквы и отделяться точкой с запятой. Если абзац перед перечнем заканчивается
точкой, элементы перечня должны начинаться с прописной буквы и
заканчиваться точкой. Примеры правильного оформления перечислений приведены ниже.
Абзац: Абзац.
ххх хххххх ххххх; Хххх хххххх ххххх.
хххххх ххххх ххх. Хххххх ххххх ххх.
Если в тексте приводится ряд числовых значений, выраженных в одной и той
же единице физической величины, то ее указывают только после последнего
числового значения, например: 1,50; 1,75; 2,00 м.
Если в тексте документа приводят диапазон числовых значений физической
величины, выраженных в одной и той же единице физической величины, то
обозначение единицы физической величины указывается после последнего
числового значения диапазона.
Примеры
1. От 1 до 5 мм.
2. От 10 до 100 кг.
3. От плюс 10 до минус 40 °С.
4. От плюс 10 до плюс 40 °С.
Недопустимо отделять единицу физической величины от числового
значения (переносить их на разные строки или страницы), кроме единиц физических
величин, помещаемых в таблицах.

9.2. Рекомендации переводчику технической документации 179
Дробные числа необходимо приводить в виде десятичных дробей, за
исключением размеров в дюймах, которые следует записывать 1/2"; 1/4"(но не-;-).
2 4
Для написания значений величин следует применять обозначения единиц
буквами или специальными знаками (°,', "). В обозначениях единиц точку как
знак сокращения не ставят.
Между последней цифрой числа и обозначением единицы следует
оставлять пробел. Правильное написание — 100 кВт, 80 %, 20 °С. Исключения
составляют обозначения в виде знака, поднятого над строкой, перед которым
пробела не оставляют. Правильное написание — 20°, 10".
При наличии десятичной дроби в числовом значении величины обозначение
единицы следует помещать после всех цифр. Правильное написание — 423,06 м,
5,758° или 5°45'28,8".
При указании значений величин с предельными отклонениями следует
заключать числовые значения с предельными отклонениями в скобки и
обозначения единицы помещать после скобок или проставлять обозначения единиц
после числового значения величины и после ее предельного отклонения.
Правильное написание — A00 ± 1) кг, 50 г ± 1 г.
Буквенные обозначения единиц, входящих в произведение, следует отделять
точками на средней линии как знаками умножения. Правильное написание —
А'М2. Допускается буквенные обозначения единиц, входящих в произведение,
отделять пробелами, если это не приводит к недоразумению.
Приводимые ниже слова и термины необходимо переводить так, как это
рекомендовано в табл. 11.
Таблица 11
Англоязычиый
термин
dick button
Click command
Click icon
Define
Specify
Features
Option
Optional
Правильный перевод
Нажать кнопку
Выбрать команду
Щелкнуть пиктограмму
Задавать, определять
Возможности
Вариант, функция, настройка
параметра
Не обязательный,
дополнительный
Неправильный перевод
Щелкнуть кнопку (на кнопке)
Щелкнуть команду (на команде)
Щелкнуть иконку (на иконке)
Отображать
Свойства
Опция
Опциональный
Информационные источники
ГОСТ 7.36-2006. Система стандартов по информации, библиотечному
и издательскому делу. Неопубликованный перевод. Общие требования и
правила оформления.

180 Глава 9 • Перевод иностранной технической документации
9.3. Памятка редактору перевода технической
документации
Редактором технического перевода (далее — редактором) является
квалифицированный специалист в предметной области с отличным знанием
иностранного языка по переводимой тематике.
На редактирование принимается русскоязычный текст перевода и оригинал
переводимого документа. Перевод должен удовлетворять требованиям,
изложенным в действующих нормативных документах и памятке переводчику.
В стандартные задачи редактора входит проверка и приведение в
соответствие действующим нормативам следующих характеристик перевода:
• адекватности перевода исходному иноязычному тексту, то есть полноты
перевода, правильности передачи его смысла, соответствия перевода
технической сущности, реализуемости и работоспособности описываемого
изделия (программы, процесса, явления и т. п.), в том числе —
содержащегося в подтексте исходного текста;
• инженерной грамотности перевода, ясности, доходчивости и краткости
изложения текста;
• отсутствия нелогичности изложения текста, а также неточностей
вследствие ошибок в исходном документе;
• использования в переводе единых стандартных терминов и единиц
физических величин, используемых в конкретной области знаний, к которой
относится исходный документ;
• правильности ссылок на национальные и международные
нормативно-технические документы (стандарты);
• отсутствия стилистических дефектов текста (смещения логического
ударения, тавтологии и т. п.);
• соответствия стиля и формы изложения текста перевода жанровым
особенностям исходного документа (руководства, инструкции, рекламного
проспекта, научной статьи и т. п.).
В стандартные обязанности редактора не входит:
• перевод оставленных непереведенными фрагментов текста объемом
свыше одного предложения, поиск правильных наименований национальных
и международных нормативно-технических документов (стандартов);
• локализация приведенных в переводе числовых данных и приведение
их к метрической системе единиц физических величин;
• массовое исправление в тексте перевода ошибок и опечаток, связанных
с правописанием и пунктуацией, включая неправильное использование
знаков препинания при перечислениях;
• форматирование текста перевода, включая таблицы, а также вставка в текст
формул и иллюстраций из оригинала.

9.3. Памятка редактору перевода технической документации 181
По отдельной договоренности с заказчиком редактор может:
• привести содержание и оформление текста в соответствие с
требованиями действующей нормативной документации (стандартов ЕСКД, ЕСПД,
ЕСТД, ССИБИД и др.).
При обнаружении в тексте большого числа несоответствий перевода
требованиям нормативных документов, исправление которых не входит в
стандартные обязанности редактора, редактор должен сообщить об этом Заказчику и по
договоренности с ним принять одно из следующих решений:
• выделить цветом обнаруженные несоответствия в тексте без
комментариев и исправлений;
• исправить обнаруженные несоответствия (обычно по двойной расценке
редактирования объема текста, подлежащего исправлению).
При массовом несоответствии перевода требованиям нормативных
документов редактор вправе отказаться от его редактирования и вернуть
некачественный перевод на доработку и исправление.
Информационные источники
Обязанности и необязанности редактора технического перевода —
http://wvw.trwor1<shop.^

182 Глава 9 • Перевод иностранной технической документации
9.4. Придание юридического статуса переводу
технической документации
Перевод технического документа (паспорта, технических условий, руководства
по эксплуатации и др.), выполненного даже весьма квалифицированным
переводчиком, работающим в весьма уважаемой переводческой компании, не является
документом в юридическом смысле этого понятия до тех пор, пока юридически
не подтверждено полное соответствие его содержания и смысла оригиналу.
Сегодня в России может быть нотариально заверена лишь подпись переводчика,
выполнившего перевод. Также может быть нотариально заверена декларация
переводчика (переводческой компании) о соответствии перевода оригиналу. При
этом декларант принимает на себя ответственность только за лингвистическую
(но не содержательную) идентичность текстов перевода и оригинала,
поскольку переводчик технических текстов, как правило, не является
высококвалифицированным специалистом в предметной области перевода. Аналогичный
статус имеет оформляемый в соответствии с Гаагской конференцией апостиль на
перевод, не дающий гарантии идентичности перевода и оригинала.
В то же время перевод технического документа при определенных
обстоятельствах должен иметь юридический статус документа. Дело в том, что
паспорт, технические условия и руководство по эксплуатации обычно являются
теми документами, на основе которых определяется, в частности, степень
ответственности разработчика за возможные неблагоприятные последствия
использования изделия. И если в разрабатываемое изделие (систему) как
составная часть включается импортное изделие, то в комплект документации на
систему должны входить и документы на эту составную часть.
Автор попытался разобраться в вопросах придания юридического статуса
переводу технического документа, и вот что вышло из этой попытки.
Основными нормативными документами, регулирующими правоотношения в области
документации и перевода, являются:
• ГОСТ Р ИСО 15489-1-2007. Система стандартов по информации,
библиотечному и издательскому делу. Управление документами. Общие
требования.
• ГОСТ 7.36-2006. Система стандартов по информации, библиотечному
и издательскому делу. Неопубликованный перевод. Общие требования
и правила оформления.
В ГОСТ Р ИСО 15489-1-2007 приведена терминология и изложены
следующие положения, касающиеся документации (дословно, выделение
шрифтом сделано автором):
«3.3. Документ (document, records): зафиксированная на материальном
носителе идентифицируемая информация, созданная, полученная и сохраняемая
организацией или частным лицом в качестве доказательства при
подтверждении правовых обязательств или деловой деятельности.
7.2. Характеристики документа
7.2.1. Общие положения

9.4. Придание юридического статуса переводу технической документации 183
Документ должен правильно отражать то, что сообщено или решено...
7.2.2. Аутентичность
Документ является аутентичным, если он:
а) является тем, чем должен быть;
б) был создан ... лицом, уполномоченным на это....
Чтобы обеспечить аутентичность документов, организации должны внедрить
и документально зафиксировать политику и процедуры контроля над
созданием, получением, передачей, сохранением и отбором документов и тем самым
гарантировать, что создатели документов уполномочены на это и
идентифицированы, а документы защищены от несанкционированного дополнения, удаления,
изменения, использования и сокрытия (засекречивания).
7.2.3. Достоверность
Достоверным является документ, содержание которого можно считать
полным и точным представлением подтверждаемых операций, деятельности
или фактов и которому можно доверять в последующих операциях или в
последующей деятельности. Документы должны создаваться ... лицами,
достоверно знающими факты...».
В ГОСТ 7.36-2006 указано (дословно, выделение шрифтом сделано автором):
«4.1. Перевод должен быть идентичен по смыслу тексту
документа-оригинала. Идентичность перевода обеспечивают организации, выполняющие перевод».
Заметим, что в прошлой редакции этого стандарта данный пункт отсутствовал.
Из цитируемых документов следуют два тривиальных вывода, обычно
используемые в практике технических переводов:
• Достоверный перевод технического документа может быть выполнен
либо одним специалистом, обладающим знаниями как в области перевода,
так и в предметной области (каковым все же является технический
специалист со знанием языка), либо двумя специалистами —
профессиональным переводчиком и редактором — специалистом в предметной области с
отличным знанием иностранного языка. Второй вариант, на наш взгляд,
является более предпочтительным. Обычно переводческие компании
придерживаются именно этого варианта.
• Переводческие компании должны документально зафиксировать
принятую процедуру создания перевода технического документа, включая
отбор специалистов, и тем самым гарантировать профессионализм как
переводчика, так и редактора.
К сожалению, оба стандарта не дают прямого ответа на вопрос, как
оформляется удостоверение идентичности перевода оригиналу.
Ответ на него автор пытался найти в главе 4 «Подтверждение соответствия»
Федерального закона от 27 декабря 2002 г. № 184-ФЗ «О техническом
регулировании» (http://www.garantai/law/12029354-004.htm#21), где в п. 1 ст. 21
говорится (дословно):
«Добровольное подтверждение соответствия осуществляется по инициативе
заявителя на условиях договора между заявителем и органом по сертификации.
Добровольное подтверждение соответствия может осуществляться для
установления соответствия национальным стандартам, стандартам организаций,
сводам правил, системам добровольной сертификации, условиям договоров.

184 Глава 9 • Перевод иностранной технической документации
Объектами добровольного подтверждения соответствия являются
продукция, процессы производства, эксплуатации, хранения, перевозки, реализации и
утилизации, работы и услуги, а также иные объекты, в отношении которых
стандартами, системами добровольной сертификации и договорами
устанавливаются требования».
Автор полагал, что на основе положений этого закона заказчик в необходимых
случаях может потребовать от переводческой компании оформить в
аккредитованном органе по сертификации Ростехрегулирования сертификат
соответствия перевода технического документа требованиям ГОСТ 7.36-2006 в качестве
гарантии обеспечения компанией идентичности перевода оригиналу. Данный
сертификат соответствия мог бы придать переводу технического документа
юридический статус документа. Для подтверждения сделанного
предположения автором был послан запрос в Ростехрегулирование с просьбой подтвердить
правильность такого способа легализации перевода технического документа.
Приводим дословный ответ за подписью заместителя начальника Управления
технического регулирования и стандартизации Е. В. Белова:
4 В связи с Вашим электронным обращением от 20.10.2007 г. по вопросам,
относящимся к компетенции Федерального агентства, сообщаем следующее.
В соответствии со статьей 21 Федерального закона «О техническом
регулировании» (с изменениями) объектами добровольного подтверждения
соответствия являются продукция, процессы производства, эксплуатации, хранения,
перевозки, реализации и утилизации, работы и услуги, а также иные объекты,
в отношении которых стандартами, системами добровольной сертификации
и договорами устанавливаются требования. Система добровольной сертификации
может быть зарегистрирована федеральным органом исполнительной власти
по техническому регулированию. В едином реестре Федерального агентства
по техническому регулированию и метрологии систем добровольной
сертификации, осуществляющих подтверждение соответствия в области
переводческой деятельности, не зарегистрировано».
Это означает, что на сегодняшний день в России способов придания
юридического статуса документов переводам технической документации, определенных
законодательно, не существует. Поэтому переводы технических документов
сегодня следует рассматривать лишь как исходный материал для создания
предприятием-разработчиком, использующим импортные составные части и
комплектующие изделия, собственных документов на эти составные части, ответственность
за содержание которых несет это предприятие. В связи с этим центр тяжести
решения рассмотренных выше вопросов качества перевода перемещается от
переводчика к редактору.
Информационные источники
ГОСТ Р ИСО 15489-1-2007. Система стандартов по информации,
библиотечному и издательскому делу. Управление документами. Общие требования.
ГОСТ 7.36-2006. Система стандартов по информации, библиотечному
и издательскому делу. Неопубликованный перевод. Общие требования и
правила оформления.
Федеральный закон от 27 декабря 2002 г. № 184-ФЗ «О техническом
регулировании» — http://www.garant.ru/law/12029354-004.htm#21.

Основные программные
1нсгрументы, рекомендуемые jjj |h «^
1ля разработки текстовой it lit
¦ехнической документации, т
1ринцип «единого источника»
1ри создании связанных
документов

186 Глава 10 • Основные программные инструменты
Для создания текстовых документов, к которым, в частности, относится и
текстовая техническая документация, используются различные программные
средства работы с текстом, схемами и изображениями.
Программы, предназначенные для редактирования, форматирования,
сохранения и печати текстовой информации, называются текстовыми редакторами
(например, WordPad). Более совершенные текстовые редакторы, имеющие такие
возможности по созданию документов, как поиск и замена символов, средства
проверки орфографии, вставка таблиц и др., называются текстовыми
процессорами (примером текстового процессора является программное приложение MS
Word). Наиболее мощные программы для обработки текста называются
настольными издательскими системами (пример такой системы — программный
пакет Adobe PageMaker).
Известно множество имеющих право на существование мнений
относительно того, какое программное приложение наиболее целесообразно использовать
при разработке текстовой ТД. Обобщив эти мнения, можно сразу исключить
простейшие текстовые редакторы, не имеющие ряда необходимых сервисных
функций. Издательские системы обычно применяются в тех случаях, когда
требуется печать ТД типографским способом, что на практике встречается не
часто. Поэтому остановимся на рассмотрении текстовых процессоров.
Наиболее распространенным текстовым процессором является
программное приложение MS Word. Оно предназначено для создания, просмотра,
модификации и печати текстовых документов, предусматривает выполнение
операций над текстовой и графической информацией. С его помощью можно быстро
и с высоким качеством подготовить любой документ — от простой инструкции
до оригинала-макета сложного издания.
Приложение MS Word дает возможность выполнять все без исключения
традиционные операции над текстом, предусмотренные в современной
компьютерной технологии, включая:
• набор и модификацию неформатированной алфавитно-цифровой
информации;
• форматирование символов с применением множества шрифтов TrueType
разнообразных начертаний и размеров;
• форматирование страниц (включая колонтитулы и сноски);
• форматирование документа в целом (автоматическое составление
оглавления и разнообразных указателей);
• проверку правописания, подбор синонимов и автоматический перенос
слов;
• совместимость с другими полезными приложениями MS Office (Excel,
Binder, PowerPoint, Visio и др.).
В процессоре MS Word реализованы возможности новейшей технологии
связывания и внедрения объектов, которая позволяет включать в документ
текстовые фрагменты, таблицы, иллюстрации, подготовленные в других
приложениях ОС Windows.
Приложение MS Word — одна из первых общедоступных программ, которая
позволяет выполнять многие операции верстки, свойственные профессиональ-

Основные программные инструменты 187
ным издательским системам, и готовить полноценные оригиналы-макеты для
последующего тиражирования в типографии.
Приложение MS Word представляет собой уникальную коллекцию
оригинальных технологических решений, которые превращают нудную и
кропотливую работу по отделке текста иногда в увлекательное, а иногда даже в
успокаивающее занятие. Среди таких решений — система готовых шаблонов и стилей
оформления, изящные приемы создания и модификации таблиц, функции
автотекста и автозамены, копирование формата, пользовательские панели
инструментов, макроязык и многие другие.
К недостаткам приложения MS Word следует отнести:
• непригодность для изготовления полиграфической продукции особо
сложной структуры (атласов, альбомов, журнальных обложек), а также для
редактирования высококачественных иллюстраций;
• не всегда стабильное функционирование при создании сложных
документов большого объема с внедренными объектами;
• высокую трудоемкость при вводе сложных математических выражений
и химических формул.
С множеством полезных функций приложения MS Word можно
ознакомиться на веб-ресурсе: http://www.worxJexpert.ru.
Другим известным текстовым процессором является программное
приложение ТеХ: http://ofnine.computerra.ru/2003/481/24381/. В него входят средства для
секционирования документов, работы с перекрестными ссылками и для набора
сложных математических формул.
Документы набираются на собственном языке разметки в виде обычных
ASCII-файлов, содержащих информацию о форматировании текста или выводе
изображений. Эти файлы (обычно имеющие расширение .ТЕХ) транслируются
специальной программой в файлы с расширением .DVI (device independent —
«независимые от устройства»), которые могут быть отображены на экране или
напечатаны. DVI-файлы можно специальными программами преобразовать в
другой электронный формат.
Ядро приложения ТеХ представляет собой язык низкоуровневой разметки,
содержащий команды отступа и смены шрифта. Огромные возможности в этом
приложении предоставляют готовые наборы макросов и расширений.
Наиболее распространенными расширениями стандартного приложения (наборы
шаблонов, стилей и т. д.) являются LaTeX и AMS-TeX. При использовании
пакета расширения LaTeX можно превратить разросшийся документ в книгу
изменением одного слова в исходном файле, вставлять оглавление одной
командой, не задумываться о нумерации разделов и рисунков.
К недостаткам приложения ТеХ следует отнести его существенно меньшую
распространенность по сравнению с приложением MS Word и, как следствие
того, необходимость специального обучения методам работы с этой программой.
Еще один известный текстовый процессор — программный пакет OpenOffice:
http://ru.openoffice.org/. Он был разработан как альтернатива приложению MS
Word и базируется на открытом исходном коде StarOffice компании Sun
Microsystems. Приложение OpenOffice по многим (но не по всем) функциям
совместимо с приложением MS Word.

188 Глава 10 • Основные программные инструменты
Выбор текстового процессора для создания документации на АПК —
индивидуальное дело каждого разработчика. Из всего множества различных
текстовых редакторов рядовой пользователь обычно выбирает один-два, с которыми
постоянно работает. Он заучивает до автоматизма управляющие комбинации
клавиш, привыкает определенным образом, через пункты меню или при
помощи мыши, выполнять стандартные операции редактирования и, вообще,
приноравливается к среде редактора.
Тем не менее преобладающим принципом выбора текстового процессора, на
наш взгляд, следует считать его известность и распространенность, чтобы при
обмене документами в электронной форме не создавать дополнительные
сложности для их чтения и дальнейшей работы с ними. По мнению автора данного
пособия (с которым читатель вправе не согласиться), при сравнительно
небольших объемах текстовой ТД, не превышающих сотни страниц, наиболее
подходящим инструментом для создания такой документации следует
считать программное приложение MS Word в сочетании с другими
программными пакетами работы с графикой и сервисными пакетами. Объемные документы
(свыше 100 листов) удобнее создавать с помощью более мощных издательских
систем либо программных пакетов AuthorIT или Adobe FrameMaker, о которых
пойдет речь далее.
Для специалистов, более глубоко интересующихся подходом к
использованию текстовых процессоров, может быть рекомендована интересная статья
А. Коттрелл: Мф://тус1еЫапЬ1од.Ь1одДО
Что касается программных средств работы со схемами и изображениями, то
разработчику технической документации вряд ли придется самому
проектировать конструкторские документы (чертежи конструкции, изображения
различного рода и схемы принципиальные электрические). Поэтому здесь не имеет
смысла рассматривать такие чисто конструкторские программные пакеты, как
AutoCad, P-Cad, «Компас» и аналогичные, а также программные пакеты работы
с изображениями (CorelDraw, PhotoShop и аналогичные). Разработчик ТД
должен уметь вставлять чертежи, изображения и схемы, представленные в различных
специализированных форматах, в текстовый документ, что в текстовом
процессоре MS Word не представляет никакой сложности. Единственной проблемой здесь
может быть просмотр исходных файлов и их конвертация в нужный формат,
для выполнения которой могут быть использованы либо возможности
основных программных пакетов, либо специальные программы-просмотровщики
и конверторы форматов.
Тем не менее иногда разработчик ТД бывает вынужден при описании
работы различных устройств самостоятельно создавать функциональные и
структурные схемы, а также информационную графику. Для этой цели наиболее
подходящим программным пакетом является приложение MS Visio, входящее в
состав пакета MS Office. Впрочем, возможны и иные решения, подробно
описанные в следующем обзоре: http://www.a>mpress.ru/ArchivQ/CP/2005/7/38/.
Кратко остановимся на принципе 4единого источника», который в ряде
случаев удобно использовать при создании взаимно увязанных
документов. Данный принцип подробно изложен и проанализирован на ресурсе:
htty://authoritra/?c=8&b=№
n=HTMiyddjxib/dd_aw.htm.

Основные программные инструменты 189
Поскольку нормативные документы, применяемые при разработке ТД,
обладают рядом очевидных и полезных особенностей: взаимосвязью,
повторяемостью структуры и содержания большинства документов, типовым наполнением
большинства документов, взаимоувязанным на уровне его структурных
единиц — разделов, подразделов, пунктов и подпунктов и даже отдельных абзацев,
то данное свойство удобно использовать для автоматизации разработки
документации, основанной на принципе «единого источника».
Концепция единого источника предполагает возможность многократного
повторного использования данных — текстов, рисунков, гиперссылок с
последующей их «сборкой» и публикацией в файлы различных форматов.
Перечисленные элементы хранятся в виде модулей данных в едином централизованном
хранилище — базе данных (библиотеке). Модули текстовых фрагментов
образуют книжки. Служебные модули содержат структуру разделов документов
(table of contents), шаблоны разделов, стили, шаблоны разметки, требуемые при
публикации документов. Каждому модулю присваивается уникальный код.
С помощью механизма, подобного OLE, возможна организация связей
между модулями внутри библиотеки. Так, к примеру, в модуль текста можно
включить любой другой модуль текста, рисунок, объект мультимедиа. При внесении
изменений во внедренный объект изменения претерпят и все связанные с ним
модули.
Современные специализированные программные средства, основанные на
концепции единого источника, представлены как отечественными, так и
зарубежными разработками. К наиболее популярным из них следует отнести
AuthorIT от компании AuthorIT Software Corporation Ltd. и Adobe FrameMaker.
Указанные продукты близки по функциональности и доступны для
приобретения. Полезным учебником по использованию программного пакета AuthorIT
при разработке технической документации является книга, доступная по ссылке:
http://authoritru/pdf/book.pdf. Принцип единого источника может быть реализован
и с помощью программного приложения MS Word (функция «Главные и
подчиненные документы»). Следует, однако, заметить, что процесс создания
документов с использованием концепции единого источника весьма трудоемок и
оправдан при разработке большого числа достаточно объемных документов.
И в завершение данной темы — часто задаваемый вопрос об оптимальном
формате конечного документа. Здесь сложно давать какие-либо конкретные
рекомендации. Многое зависит от вариантов последующего использования этого
документа. На наш взгляд, можно рекомендовать два основных формата —
.DOC (.RTF) и .PDF, у каждого из которых есть свои плюсы и минусы. Следует
также продумать вопрос об унификации именования файлов. Удобно в имя
файла включать код документа по ЕСКД, наименование темы и дату версии,
например: «Ty_XXXXX__10__09_07.doc», но это — дело корпоративных
стандартов и личных симпатий.
Информационные источники
О программном приложении ТеХ — http://offline.computerra.nj/2003/481/24381/.
Русская страница веб-узла OpenOffice.org — http://ru.openoffice.org/.

190 Глава 10 • Основные программные инструменты
Текстовые процессоры: Глупые и Неэффективные —
http://mydebianblog.blogspot.com/2006/10/blog-post_30.html.
Пакеты для создания информационной графики —
htф://www.compress.ru/Archive/CP/2005/7/38^
Автоматизация разработки ТД с применением инструментария на основе
single source —
ht^//auttorit.m/?c=8&b=&t=H™
n=HTMl7ddjDub/dd_aw.htm.
Автоматизация разработки технической документации с применением
AuthorlT. Учебное пособие — http://authorit.ru/pdf/book.pdf.

Заключение
Вот и подошел к концу предложенный курс. Был ли он полным и полезным —
решать вам, уважаемые читатели. Во всяком случае, автор старался, чтобы это
было именно так. За любые критические замечания и советы, которые можно
направить по адресу: vadim.glagolev@gmail.com, автор будет благодарен и
постарается учесть их в последующих редакциях учебных материалов.
Нет предела совершенству, но где-то надо и остановиться. Автор уже сейчас
видит возможность дополнить материалы курса более подробным изложением
содержания и структуры основных программных документов и документов на
АС. Возможно, окажется полезным дополнение курса (в рамках разрешенных
для открытой публикации сведений) материалами, касающимися разработок
изделий и технической документации по заказам Министерства обороны.
Какие-то из имеющихся материалов, возможно, впоследствии окажется
целесообразным сократить, другие — наоборот, расширить. Время покажет.
Успехов вам, дорогие друзья, в освоении нелегкой, но нужной профессии
разработчика технической документации!

Глаголев Вадим Алексеевич
Разработка технической документации.
Руководство для технических писателей
и локализаторов ПО
Заведующий редакцией А. Сандрыкин
Руководитель проекта Л, Юрченко
Научный редактор Л. Пасечник
Корректоры И. Тимофеева» К Филатова
Верстка С.Волкова
Подписано в печать 14.03.08. Формат 70x100/16. Усл. п. л. 20,64. Тираж 2000. Заказ 8593
ООО «Питер Пресс», 198206, Санкт-Петербург, Петергофское шоссе, д. 73, лит. А29.
льгота — общероссийский классификатор продукции ОК 005-93, том 2; 95 3005 — литература учебна
Отпечатано по технологии CtP в ОАО «Печатный двор» им. А. М. Горького.
197110, Санкт-Петербург, Чкаловский пр., д. 15.


                

Книга «Профессия «Технический писатель»

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

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

Полное содержание книги «Профессия «Технический писатель»:

От автора

Глава 1. Введение в специальность или Рыцари клавиатуры

Кто работает с текстами?

Особенности работы технического писателя

Отличие «технического» писателя от «классического»

Почему навыки работы с текстами нужны всем?

Почему инженер или программист не может писать технические тексты?

Профессия технического писателя в РФ и за рубежом

Технический писатель и прогресс – заменят ли нас программы?

Глава 2. Как стать техническим писателем

Как определить, подойдёт ли мне эта профессия и что тут нужно уметь?

Несколько хитростей для успешного выполнения тестового задания

Глава 3. Юридические аспекты работы

Варианты занятости технического писателя

Территориальные варианты занятости. Офис и удалённая работа

Формирование портфолио специалиста по текстам

Глава 4. Производственные процессы

При работе по найму

При работе на подряде и фрилансе

Методика переговоров со специалистами, получение и анализ сведений

Глава 5. Приступая к работе: базовые сведения и понятия

Области, в которых присутствует работа с текстами

Классификация носителей информации

Типы пользователей документации

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

Глава 6. Формат документа и статьи

Формат и структура технического документа

Формат и структура статьи. Канон и отступления от него

Глава 7. Основы создания технической документации

Глава 8. Базовые приёмы работы с текстом

Лексические тонкости и основные ошибки в технических документах

Оценка объёма теста и графики при создании документации

Оценка времени, необходимого на разработку технического документа

Методология определения конечных сроков выполнения работы и контроль их соблюдения

Контроль оригинальности текстов

Корректировка и редактирование технических текстов

Глава 9. Применяемое программное обеспечение

Платное и бесплатное программное обеспечение

Microsoft Office и альтернативы

Важные возможности Microsoft Word

Приложения для совместной работы

Инструменты для создания видеоинструкций

Глава 10. Обзор дополнительных областей

ГОСТы и иные мировые стандарты документирования

Документирование API

Полезные ссылки и материалы

Цена одного экземпляра книги — 350 рублей, сумма заказа включает также стоимость доставки по России и Беларуси независимо от количества заказанных экземпляров — 300 рублей. То есть, сумма заказа одной книги — 650р., двух — 1000р, и т.д. Условия доставки в другие регионы уточняются индивидуально посредством наших каналов обратной связи.

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

Вы можете ознакомиться с рецензией одного из наших читателей здесь.

Чтобы заказать книгу, заполните, пожалуйста, форму и ожидайте письмо со ссылкой на оплату заказа:

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

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

Эта книга станет незаменимым помощником в работе технических писателей, специалистов по стандартизации и переводчиков-локализаторов программного обеспечения. Издание посвящено вопросам разработки текстовой технической документации на аппаратно-программные комплексы, автоматизированные системы и программные продукты, к которым относится большая часть современного рынка высоких технологий. Приведены общие сведения о промышленной продукции и технической документации, основные понятия о государственной системе обеспечения единства измерений (ГСИ), единых системах конструкторской, программной и технологической документации (ЕСКД, ЕСПД и ЕСТД), комплексе стандартов на автоматизированные системы (КСАС). Рассмотрен жизненный цикл технической документации. Значительное место отведено вопросам разработки основных видов текстовой технической документации на аппаратно-программные комплексы и автоматизированные системы – технического задания, технических условий, программы и методики испытаний, а также эксплуатационной документации – руководства по эксплуатации, руководства пользователя, инструкции по эксплуатации, формуляра, паспорта, этикетки ведомости эксплуатационных документов. Изложены рекомендации по переводу, локализации, оформлению и приданию юридического статуса технической документации на продукцию зарубежных производителей. Рассмотрены основные программные инструменты, предназначенные для разработки текстовой технической документации. Книга рассчитана как на получение начального образования молодыми специалистами, так и на углубление знаний опытных разработчиков текстовой технической документации. Будет представлять интерес для переводчиков и редакторов переводов иноязычной технической документации.

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

Как стать техническим писателем «с нуля» [5 базовых навыков + 5 курсов]

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

---

Содержание

• Коротко о профессии
• Знания и навыки технического писателя
• Как получить профессию технического писателя
• Как стать техническим писателем: чек-лист

Коротко о профессии

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

Основные задачи специалистов сводятся к двум моментам:

1. Сбор информации, ее компоновка и структурное изложение «на бумаге» по стандарту или шаблону.
2. Отслеживание актуальности текстов в библиотеке компании и внесение в них корректировок при необходимости.

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

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

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

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

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

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

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

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

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

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

ясность содержания;
полнота изложения;
доступность для понимания читателя;
соответствие профессиональным стандартам;
лаконичность.

Важным скилом техписа считается умение интервьюировать экспертов.

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

При трудоустройстве в компанию из IT-сферы одним из запросов работодателя может являться знание платформы DocBook/XML или ее аналога. Оно будет вам необходимо для автоматизированного создания стандартизированного контента по готовым макетам.

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

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

Например:

• Python;
• Java;
• JavaScript.

Автору в сфере информационных технологий как минимум необходим навык чтения кода. А знания HTML, CSS и Markdown станут еще более существенным преимуществом.

Как получить профессию технического писателя

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

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

Обучение в образовательных учреждениях

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

ВУЗЫ

Необходимые знания дают в высших учебных заведениях при подготовке по направлениям 09.03.01 «Информатика и вычислительная техника» или 09.02.07 «Информационные системы и программирование». Образовательная программа бакалавриата подразумевает знакомство с кодами и технической документацией в сфере IT.

Пример учреждений, в которых можно получить профессию:

• МАСИ;
• ВШЭ;
• РГСУ;
• РУТ (МИИТ);
• МГУПП;
• УГАТУ.

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

ССУЗЫ

За 36 месяцев профессиональную подготовку можно пройти в колледжах: НТИ НИЯУ МИФИ, РГСУ, КМПО РАНХиГС, КТ МТУСИ, «Синергия». Ссузы принимают абитуриентов по коммерческому договору и на бюджетные места. В качестве вступительных экзаменов засчитываются баллы по математике, русскому языку, информатике (ИКТ) и физике.

КУРСЫ

Стать техписом в рекордно короткие сроки позволят курсы, на которых студенты рассматривают и изучают в основном один главный предмет, а по остальным проходятся поверхностно. Учиться легче тем, кто хорошо владеет английским языком (B2 +) и знает компьютер на уровне уверенного пользователя.

Большое количество видеокурсов по бюджетным ценам можно найти на тематическом портале для технических писателей TechWriters.

Самообразование

Начинать самостоятельно карьеру в профессии непросто. Придется потрудиться. Освоить секреты авторского мастерства помогут книги:

1. «Разработка технической документации» Вадима Глаголева.
2. «Документирование программного обеспечения» Татьяны Макаровских.
3. «Профессия «Технический писатель» или «Рыцари клавиатуры»» Александра Михайлова.

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

Бесплатные курсы для технических писателей:

1. «Техническая документация в IT-проектах». Обучение проводит техдиректор бюро Documentat.io. Занятия проходят с апреля по июнь.
2. Easy Way to Technical Writing. Англоязычная программа Полины Гантман, закончившей МГУ по направлению «Перевод и лингвистика». Требуется знание English на уровне Pre-intermediate — Intermediate (В1-В2).
3. Technical Writing One и Two. Видеопроект Google Developers по освоению технического письма на английском языке.

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

Поиск работы

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

Теперь пора искать работодателей. В этом помогут известные job-сайты (hh.ru, superjob.ru, Работа.ру), а также телеграм-каналы. Актуальные вакансии периодически появляются на портале Yandex. Также можно попроситься на стажировку в агентства, которые специализируются на подготовке контента для заказчиков. Для поиска подходящей компании наберите в поисковике фразу «услуги технических писателей».

Хотите первыми получать вакансии с зарплатой от 80 000 рублей? Тогда подписывайтесь на наш Телеграм-канал Вакансии и стажировки от MyResume

Подведем итоги

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

Как стать техническим писателем: чек-лист

1. Изучить государственные и международные стандарты оформления документов.
2. Овладеть ПО для создания инструкций, графиков, чертежей и ведения библиотеки.
3. Научиться читать и понимать код на популярных языках программирования, например, Python, Java, JavaScript.
4. Приобрести навыки обработки массивов информации, структурирования данных, написания контента на понятном для аудитории языке.
5. Подготовить несколько образцов технического текста для портфолио и оформить резюме.
6. Найти работу на job-бордах, в телеграм-каналах или агентствах, специализирующихся на подготовке документации.

Автор статьи

Светлана Бебко

Карьерный консультант. Эксперт по созданию резюме и подготовке к интервью. Профориентатор.

Посмотрите на ситуацию под другим углом

5 инструкций по оформлению cover letter на русском и английском языках

Александр Владимирович Михайлов
ПРОФЕССИЯ «ТЕХНИЧЕСКИЙ ПИСАТЕЛЬ», или «РЫЦАРИ КЛАВИАТУРЫ»

Базовые сведения Приемы работы с текстом и программным обеспечением

Издание третье

URSS

МОСКВА

2022

Михайлов А. В. Профессия «Технический писатель», или «Рыцари клавиатуры» : Базовые сведения. Приемы работы с текстом и программным обеспечением. — Изд. 3-е. — М.: ЛЕНАНД, 2022. — 160 с.: ил. — ISBN 978-5-9710-5353-8

Иллюстрация на обложке: Designed by Freepik

От автора

Вы держите в руках книгу, которая познакомит вас с различными аспектами такой интересной и современной профессии как «технический писатель», © Капитан Очевидность.

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

Именно для тех, кто услышал о техписах совсем недавно и загорелся желанием пополнить стройные ряды специалистов по документированию, создано это пособие. В нём мы расскажем обо всём, связанном с профессией технического писателя, — где требуются такие сотрудники, как они работают, какие задачи выполняют, на что могут рассчитывать в плане карьеры и перспектив, рассмотрим не только возможность занятости в СНГ, но и странах дальнего зарубежья, ведь с навыками техписа можно работать буквально в любой точке планеты! Грамотный технический писатель, сидя под пальмой на Мадагаскаре (или в чуме на побережье Ледовитого океана, тут уж что душа больше желает), может одновременно работать с заказчиком из России, США и, к примеру, Голландии, сильно при этом не напрягаясь. Конечно, для этого нужен значительный багаж знаний и опыта, но это можно сказать про любую профессию — не уделив ей пресловутые десять тысяч часов, вы не станете профессионалом ни в документировании, ни в управлении станком, ни даже в подметании улиц (ладно, на освоение подметания надо поменьше времени, согласен).

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

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

Валерия Ивановича Дедовского, автора почти всей темы «Применяемое программное обеспечение»;

Анну Александровну Михайлову, автора раздела «Важные возможности Microsoft Word» и первого читателя и редактора этой книги;

Екатерину Николаевну Филичкину, автора хомячьих похождений.

Глава 1. Введение в специальность, или Рыцари клавиатуры

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

1) Как называется эта профессия?

2) Чем занимаются её представители?

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

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

Идём дальше. Чем мерить труд копателя траншей? Правильно! Глубиной и длинной траншеи. Чем измерять продуктивность продажника? Верно! Количеством сделанных результативных звонков и количеством денег от привлечённых клиентов.

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

• Тысяча знаков с пробелами (тыс. зн. с/п.) — тысяча печатных символов с учётом пробелов между ними;

• тысяча знаков без пробелов (тыс. зн. б/п) — тысяча печатных символов без учёта пробелов между ними;

• авторский лист (АЛ) — 40000 печатных символов с учётом пробелов между ними.

Оплата за сделанную работу, как правило, идёт за одну из указанных выше единиц текста (при сдельной работе), либо ставится фиксированное вознаграждение (когда сотрудник работает на штатной должности). Но в любом случае, все ориентировочные, а иногда и точные размеры требуемых текстов указываются заказчиком или работодателям в этих величинах. Естественно, инструкции пишутся по принципу «сколько получится», но шаг в сторону — и любая статья, любой пресс-релиз, «белила» (white papers) и прочие тексты имеют строгое ограничение на максимальный, а иногда и минимальный, размер.

Стоит заметить, что цена этих условных текстовых единиц колеблется очень сильно — от сотни рублей до тысячи и более, если говорить о стоимости тысячи знаков с пробелами. Разумеется, стоимость сильно зависит от объема подготовительной работы, которую требуется провести техпису, чтобы написать материал объёмом в несколько тысяч знаков, а также от сложности и доступности сведений, о которых идёт речь. Например: для написания руководства пользователя к несложной программе требуется установить приложение, изучить его функционал «методом тыка» и, собственно, написать текст руководства. Работа уместится в несколько десятков тысяч знаков с пробелами, а их цена будет небольшой. Другая ситуация, когда требуется сделать обзор продукции или услуг в какой-либо области или провести комплексный анализ IT-инфраструктуры предприятия.

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

1. Кто работает с текстами?

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

Корректор

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

Основных требований к корректору два: внимательность и грамотность. Этот человек должен вычитывать значительные объёмы текста и исправлять все ошибки в нём. Это достаточно сложно, учитывая, как быстро «замыливается глаз» при постоянной работе с большим количеством текста. А ослабление внимания даже на время чтения нескольких строк чревато тем, что в печать уйдёт документ с великолепным ляпом.

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

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

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

Рерайтер

 Если вам кто-то скажет, что он работает копирайтером и занимается рерайтом — вытяните вперед руку, покажите на него указательным пальцем, откройте рот и громко скажите: Ха-ха! Для отработки вам подойдёт товарищ по имени Нельсон из известных всем «Симпсонов».

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

Всем известно, что для качественной раскрутки сайта требуется уникальное содержимое (контент). Но где его взять, если количество интернет-магазинов, предлагающих, например, доставку суши на дом, исчисляется тысячами? Правильно. Написать. Но это дорого, нужен толковый человек, который сможет придумать описание к товарам и показать его потенциальному покупателю «во всей красе». Как решается задача? Правильно. Берется готовый текст и переделывается. Причем не перерабатывается целиком, а буквально переписывается методом замены слов. В итоге получается на 100% уникальный текст, для написания которого ни знаний, ни, пардон, ума, совершенно не требуется.

Профессии «рерайтер» не существует по названию (очень уж некрасивое), но она есть по факту: все фриланс-сайты и так называемые биржи контента просто лопаются от объявлений в стиле «Нужен копирайтер!». На самом деле, это поиск того самого рерайтера, который перепишет кучу текстов, которую его заказчик скопировал с чужого сайта, и отдаст эти «переделки» ему обратно. Никчемность задачи объясняет и планку вознаграждения для таких работников — стоимость их труда не превышает 20 рублей за написание тысячи знаков без пробелов, зачастую оказываясь и того ниже.

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

Обратите внимание, рерайтер — не копирайтер! Хотя его именно так все и называют. Видимо для солидности.

Копирайтер

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

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

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

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

Технический писатель

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

Например, полный набор текстов по самолёту компании Boeing содержит более тридцати тысяч страниц!

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

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

IТ-аналитик

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

Или иная ситуация: на предприятии кавардак в IТ-отделе. Ресурсы тратятся, толку мало. Надо оптимизировать работу, менять оборудование, а как все это делать — не понятно. За дело берётся аналитик: изучает ситуацию, собирает информацию о том, что нужно получить в итоге. На основе этих данных он продумывает схему оптимизации бизнес-процессов, а также проводит подбор необходимого оборудования. Что-то заменили, что-то добавили, кого-то уволили, кого-то наняли — и IT-инфраструктура заработала как часы!

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

IТ-обозреватель / Журналист

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

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

Редактор

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

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

Рис. 1. С таким вам придётся иметь дело, если вы редактор. Или не увидели ошибок?..

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

Технический коммуникатор

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

2. Особенности работы технического писателя

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

Ниже мы рассмотрим функционал, который вам придётся взвалить на себя, устроившись в какую-нибудь компанию техническим писателем. Эта вакансия на сайтах по трудоустройству может также превратиться в «Аналитик» (это нормально), «Копирайтер» (первый «звоночек»), «Инженер по ТД» (тоже нормально), a порой и вовсе в нечто монструозное вроде «Технический менеджер-писатель». Название не важно, и его излишняя забористость говорит лишь о безграмотности кадровика — чем оно заковыристее — тем больше у вас поводов задуматься, нужно ли вам именно это место работы: если уж товарищи название не знают, то можно ли от них ждать адекватных задач и достойной оплаты?

Направления деятельности

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

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

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

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

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

Рабочие задачи

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

1. Полное документирование программного продукта или оборудования. Если вы работаете в небольшой компании, то вам достаётся, как правило, целиком и полностью две задачи: составление пользовательской документации и составление руководства администратора / сервисного инженера. Этих двух документов (иногда ещё требуется набор бумаг по ГОСТ для сдачи продукта в эксплуатацию по государственному заказу) хватает для «бумажного» сопровождения большинства изделий и программ. Иногда требуется написать только одно из этих руководств, поскольку одни программы не имеют пользователей, а другие — администраторов. Например:

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

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

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

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

2. Документирование частей или компонентов продукта. Если вы работаете в крупной организации, то, скорее всего, делаете только часть работы по документированию, поскольку описать продукт целиком в одиночку не по силам никому. В таком случае вы описываете только определённые компоненты крупного программного комплекса или некоторые из входящих в его состав приложений. Остальные материалы пишутся вашими коллегами — во многих крупных компаниях есть целые отделы документирования или, как минимум, несколько не собранных в единое подразделение технических писателей, выполняющих одну крупную общую задачу. В качестве примера можно привести MS Office и другие программные комплексы его уровня — для описания таких пакетов требуется труд нескольких квалифицированных сотрудников.

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

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

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

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

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

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

6. Создание презентационных материалов. К ним относится разработка пресс-релизов, создание презентаций для выступлений на конференциях или размещения в СМИ, а также подготовка информационных брошюр и рекламных буклетов.

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

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

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

10. Специфическая работа с продуктами компании. Например, комментирование кода или описание внутренних структур баз данных (БД). Это делается для создания «преемственности» в среде разработчиков, чтобы увольняющиеся программисты не «уносили с собой» возможность дальнейшего развития созданных ими продуктов. Для выполнения таких задач вам придётся освоить программирование и разобраться с СУБД, зато эти навыки существенно повысят стоимость вас как специалиста по текстам.

11. Запрещённые тексты. Есть целый перечень документов, которые априори должен разрабатывать не сотрудник компании, а различные государственные органы. Браться за их написание не стоит, так как можно оказаться «крайним» при возникновении каких-либо проблем в будущем. Например, не стоит составлять протоколы и регламенты, которые потом просто отдадут на подпись государственным контролёрам. Есть риск, что они подпишут бумагу, не читая, а при ЧП всю вину попытаются свалить на кого-то другого. К сожалению, иногда это неизбежно — писать заставляют, особенно когда получают всякие разрешения «вчёрную», но если получится — всё же лучше отвертеться от такой работы. Одно же правило следует выполнять даже под страхом увольнения — текст должен ничем не выдавать ваше авторство, вплоть до значения полей статистики Word’a.

3. Отличие «технического» писателя от «классического»

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

1. Точность у технического писателя и образность, а порой недосказанность, у обычного. После прочтения текста техписа всё должно быть ясно и понятно, никаких вопросов по тексту оставаться не должно, в противном случае документ плох. Если где-то написано двусмысленно или нужно догадываться — тоже всё печально. В то же время, обычный писатель должен излагать мысли красиво, образно, в его произведении может — а временами и должна — быть загадка, ведь если с первой страницы всё ясно и угадывается конец — роман написан скучно. И произведения с «открытой концовкой» тоже имеют право на существование.

2. Лаконичность у техписа и «рулоны» классика. Задача технического писателя — донести максимум информации в минимуме текста. Сэкономить время пользователя, помочь ему быстро найти ответ. Именно поэтому важно чётко структурировать документ и делать качественное оглавление. Обычный же писатель может «смаковать» тему, сколько ему угодно, придумывая новые сюжетные ходы и вставляя длинные лирические отступления.

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

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

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

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

4. Почему навыки работы с текстами нужны всем?

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

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

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

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

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

Говорящие «на разных языках» программист и маркетолог, тестер и инженер поддержки, менеджер проекта и заказчик создают, порой, эдакое Вавилонское столпотворение, где все очень хотят понять собеседника и быть понятыми, но не всем и не всегда это удаётся. Стоит отметить, что благодаря развитию Интернета, появлению «распределённых» компаний и распространению модели труда «Home Office» всё чаще общение происходит не только и не столько в виде «живых» планёрок, сколько в формате общения в CRM-системе или трекере. То есть всем участникам процесса приходится излагать свои мысли и идеи в виде текста, причем, желательно, краткого и понятного. Это первая причина, почему умение писать качественные тексты будет полезно всем вообще, а не только техническим писателям.

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

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

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

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

5. Почему инженер или программист не может писать технические тексты?

 Стоп! А разве в прошлом разделе не говорилось о том, что навыки разработки текстов нужны всем, а значит и писать, в конечном итоге, могут все? А тут вдруг раз — и не могут, тем более — сами разработчики и программисты. Это как?

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

Как следует из предыдущего раздела, для большинства IT-специалистов (тестировщиков, программистов, системных аналитиков, инженеров и многих других) умение внятно и лаконично излагать свои мысли становится залогом облегчения коммуникаций внутри компании. Способность донести до коллег необходимую информацию, поставить задачу сотруднику, разработать понятное всем описание результатов тестирования, прокомментировать собственный код, чтобы его восприятие коллегами-программистами было максимально быстрым и полным — именно эти цели преследуются ими при освоении навыков документирования. В их профессиональные задачи не входит разработка непосредственно документации «от и до». Их основное занятие — писать программы, разрабатывать оборудование, проводить тестирование, внедрение — да что угодно, в зависимости от должности, но никак не создание пользовательских и прочих руководств.

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

играть ключевую роль — не тратится время на многочисленные переспрашивания и уточнения в попытке понять друг друга, не тратятся силы на исправление «косяков», возникающих потому что кто-то кого-то неправильно понял.

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

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

Но почему так важно делить эта два направления — внутреннее и внешнее? Почему нельзя отправить самого разработчика документировать собственное детище? Причин две.

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

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

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

А технический писатель, который сам изучает созданный продукт, без проблем поставит себя на место нового пользователя — ведь сам техпис был им, когда начинал описание продукта и общение с разработчиками. Кроме того, разработка текстов — профильное направление техписа, а значит его опыт и навыки в этом деле многократно выше, чем у других специалистов, которые связаны с этим «постольку-поскольку». Именно это и позволяет техническим писателям практически в полной мере избавиться от «проклятия знания» и доходчиво объяснять очевидные для них вещи даже самым неподготовленным пользователям.

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

6. Профессия технического писателя в РФ и за рубежом

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

1. Обучение. В СНГ, скажем коротко, его нет. Если точнее — то у нас невозможно получить высшее образование по профессии «Технический писатель», нет даже ничего похожего (заставить программиста отучиться на журналиста или наоборот — не предлагать). Из всех возможностей освоить профессию «с нуля» или повысить свою квалификацию остаются коммерческие курсы, например, проводимый ООО «Протекст» курс «Разработка технических текстов и документации» (https://protext.su/pro/kurs/), представляющий собой набор лекций и практических занятий. Он позволит начать работу по этой специальности, но не даст диплома по ней. Увы, сейчас его не даст никто и неизвестно, когда изменится эта ситуация.

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

2. Тип занятости. В СНГ по старинке превалирует полная занятость с обязательным присутствием в офисе «с девяти до шести». Количество компаний, пользующихся услугами фрилансеров или держащих сотрудников в режиме домашнего офиса, очень невелико, хотя, к нашей радости, достаточно быстро растёт.

В западных же странах количество компаний, пользующихся услугами удалённых сотрудников, очень велико, как и количество самих «надомников». Так, в США ещё в 2007-м году на дому работал каждый 6-й наёмный работник. А японцы пошли дальше всех — там, если человек трудится удалённо, он получает зарплату выше своего офисного коллеги. Причина проста: он не тратит ресурсы компании (рабочее место, бытовые потребности), поэтому сэкономленное он получает в виде доплаты. Кроме того, за рубежом очень хорошо развит рынок фриланса и аутсорсинга в плане документирования (да и во многих других направлениях тоже), что выводит значительную часть техписов из категории наёмных работников, превращая их в «самозанятых».

3. «Прозрачность» рынка труда. Для СНГ работа по найму, как правило, обозначает полную легальность — вы являетесь штатным сотрудником, работодатель платит за вас все необходимые налоги, а ваши права защищены законом. А вот когда речь заходит о проектной работе и фрилансе, то здесь совершенно другая картина — 90% всех взаимодействий здесь происходит на основе устного договора, когда фрилансер и заказчик договариваются обо всём в мессенджере или в электронных письмах, после чего один делает работу, а второй оплачивает её либо электронными деньгами, либо приватным переводом. При таком раскладе фрилансер не платит никаких налогов, по сути, занимаясь незаконной предпринимательской деятельностью, и на пару с заказчиком он не имеет никаких гарантий, что его не «кинут» после сдачи работы. Доказать что-то в суде будет невозможно, ибо нет никаких бумаг, зато можно будет «подставиться», по сути заявив во всеуслышание, что он работает «вчёрную».

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

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

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

5. Зарплата. Мериться доходами между СНГ и Западом — дело неблагодарное, ибо сразу понятно, кто окажется в плюсе. Поэтому лучше сравнить соотношение зарплаты техписа к средней зарплате специалиста в ИТ-отрасли. В СНГ технические писатели в среднем получают немногим меньше программиста (80-100% в зависимости от компании и квалификации), за рубежом — на одном уровне, опять же с учётом квалификации. То есть, в целом, рядовой технический писатель получает почти как рядовой программист, а ведущий техпис «стоит» как ведущий разработчик. При этом стоит отметить, что в СНГ на одного техписа может приходиться 10-20 программистов, а, к примеру, в США — 4-5.

7. Технический писатель и прогресс — заменят ли нас программы?

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

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

Итак, что мы имеем? С одной стороны, можно сказать, что все перечисленные выше профессии — это физический труд, не подразумевающий никакой квалификации и базирующийся исключительно на механической работе. Да, это так, и именно по ручному и неквалифицированному труду пришёлся (да-да, уже пришёлся) первый удар, оставив на улице большое количество ставших ненужными сотрудников. Так, в Китае, стране с исконно «дешёвой» рабочей силой, куда ещё недавно вывозили свои сборочные производства почти все технологические гиганты, вовсю набирает обороты процесс автоматизации, уже оставивший без работы миллионы (да, китайцев много) людей. Оборудование становится всё совершеннее и, зачастую, дешевле, что позволяет выгодно заменять им всё больше сотрудников даже с самой низкой зарплатой. Но у нас ведь интеллектуальный труд, штучный товар и всё такое, так что всё должно бы быть в порядке…

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

Так, в США активно используются приложения, сканирующие поисковые системы, анализирующие полученную информацию и на её основе генерирующие новостные тексты, статьи, практически по любой тематике. Пока что качество этих текстов не дотягивает до уровня качественного журналистского изложения, но и профессиональных журналистов не так много, как «жёлтых газетчиков», пишущих материалы сомнительной достоверности и невысокого качества. Особого успеха в плане генерации текстов добился продукт компании Narrative Science (https://www.narrativescience.com/), которым пользуются многие крупные корпорации (например, издание Forbes). Разумеется, в целом журналистика как творческая отрасль, сильно пострадавшая от всеобщей «интернетизации» (множество «бумажных» изданий просто не пережило переход в онлайн-форму, а пришедших на смену им интернет-изданий появилось гораздо меньше, что вызвало кризис рабочих мест) активно сопротивляется этим процессам, но прогресс, как известно, остановить нельзя.

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

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

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

Что ж, будем надеяться, что наступление машин не оставит нас за бортом профессиональной деятельности. А как оно будет на самом деле — увидим лет через тридцать!

Глава 2. Как стать техническим писателем

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

1. Как определить, подойдёт ли мне эта профессия и что тут нужно уметь?

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

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

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

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

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

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

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

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

И, наконец, в-седьмых — приготовьтесь к удивлённым взглядам собеседников, когда они услышат, кем вы работаете — наша профессия уже известна, но не особо на слуху. А значит ожидать, что вас будут считать таким же «крутым» как программист (или, наоборот, скучным и занудным…), или таким же «общественно полезным» как учитель или врач — не стоит.

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

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

2. Умение быстро печатать. В идеале — освоить слепой десятипальцевый метод — чем быстрее вы можете набирать текст, тем быстрее будет выполняться та часть работы, которая посвящена непосредственно его набору на клавиатуре. А тот момент, что во время печати смотреть вы будете на монитор, а не на клавиатуру, позволит избежать большинства опечаток и ошибок. В Интернете есть множество методик самостоятельного обучения, вам достаточно лишь выбрать себе одну из них и освоить. Достаточной для качественной работы считается скорость в 300-350 символов в минуту.

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

4. Знание профильного программного обеспечения. Чем большим инструментарием, помимо всеми любимого Word’a, вы владеете, тем проще вам будет найти хорошую работу. Умение пользоваться системами профессионального перевода (например, Trados), системами на основе единого источника (например, MadCap Flare), ПО для вёрстки (например, InDesign) будет вам очень полезным.

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

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

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

8. Навыки в программировании и работе с СУБД. Эти знания потребуются вам, если вы будете заниматься самой сложной (и самой высокооплачиваемой!) работой — документированием интерфейсов (API) и баз данных.

Что касается остальных моментов:

Зарплата. Тут всё просто, её уровень приблизительно соответствует уровню оплаты программиста и сильно отличается в зависимости от компании. За одну и ту же работу в Новосибирске могут платить 30-40 тысяч рублей, в Москве 90-100, а в США или Германии 8-9 тысяч долларов/евро. Поскольку такая картина характерна для практически любой профессии, говорить о конкретных цифрах без привязки к месту смысла не имеет. Но это не отменяет того факта, что наша профессия была, есть и будет весьма высокооплачиваемой по меркам того региона, где вы работаете.

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

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

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

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

2. Несколько хитростей для успешного выполнения тестового задания

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

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

С одной стороны, может показаться, что ТЗ — это скорее формальность, ведь когда по работе в дальнейшем вам придётся писать администраторские инструкции к сложнейшей вычислительной системе, то что сможет сказать о ваших навыках руководство к настольному будильнику или Калькулятору для Windows? С другой — не могут же все вокруг ошибаться и просто «от нечего делать» заставлять соискателей писать не нужные никому тесты.

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

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

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

1) стремление сделать материал качественно именно в понимании заказчика;

2) внимательность и заинтересованность в точном выполнении всех требований;

3) свою способность не молчать и гадать, а уточнять и задавать вопросы уже на начальном этапе работы, а не переделывать её потом целиком, потому что постеснялись уточнить какие-то моменты;

4) свою пунктуальность и умение планировать работу.

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

1) способность четко выполнять то, что от вас просят;

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

3. Собственно, напишите ТЗ целиком и вычитайте его на один-два раза. При этом:

1) обратите внимание, не слишком ли много в нём «воды», нет ли излишнего упрощения или усложнения в изложении материала, соответствует ли ТЗ своей целевой аудитории;

2) если в задании есть хотя бы намёк на обзор предметной области — непременно добавьте в текст соответствующий абзац, в котором кратко его и изложите;

3) если это не указано в явном виде — оформлять ТЗ нужно не по ГОСТ;

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

5) если нет указания по формату файла, то старайтесь использовать общепринятые стандарты — рисунки в JPG, тексты в DOC(X), презентации в РРТ(Х).

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

5. Ждите. Вам перезвонят! (нет, это не сарказм, если сделаете хорошо — и перезвонят, и на работу возьмут).

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

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

2. Инструкция должна быть 8-10 страниц, но содержать много скриншотов и описывать пусть и достаточно сложную, но уже существующую программу с имеющееся документацией (например, описать установку какого-нибудь антивируса по его демо-версии).

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

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

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

Теперь несколько слов о том, какие моменты в требованиях к тестовому заданию должны насторожить вас и склонить к варианту «Да пошли вы со своим ТЗ» в отношении потенциального работодателя:

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

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

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

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

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

Кстати, когда кто-то рассказывает, что его взяли на работу без тестового задания, стоит убедиться как минимум в трёх вещах:

1) он не врёт;

2) он трезв и не находится под кайфом;

3) он имеет опыт не меньше 10 лет в топовых IТ-компаниях России и зарубежья.

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

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

Глава 3. Юридические аспекты работы 

1. Варианты занятости технического писателя

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

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

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

Плюсы:

• Фиксированный оклад. Как правило, достаточно высокий, в крупных компаниях существенно превышающий среднюю зарплату по стране.

• Оплачиваемый отпуск. Как известно из бородатого анекдота, это второй (после обозначенного выше) пункт, за который любят своё место работы.

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

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

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

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

• Выходные и праздничные дни. Они у вас будут, несмотря ни на что, поскольку прописаны в Трудовом кодексе. «Сгорать» на работе вы будете исключительно по собственному желанию.

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

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

• «Не денежные бонусы». ДМС, курсы английского, фитнес — это лишь малая часть того перечня, который крупные компании предлагают своим сотрудникам. Но даже если это будет «всего лишь» медицинская страховка — дело хорошее.

• Различные корпоративные мероприятия. Без комментариев. Слетать куда-нибудь или даже просто хорошенько погулять за счёт компании всегда приятно! Стоит заметить, что о возможных мошенничествах и прочих «прелестях» недобросовестных работодателей, к сожалению, достаточно часто встречающихся в России, вы можете не беспокоиться: технический писатель — не мальчик на кассе и не грузчик, он слишком ценный специалист, чтобы работодатель даже просто подумал о том, чтобы обмануть или обсчитать его. Потому что если уйдёт — нового искать тяжело будет.

Минусы:

• Жёсткий график работы. Вы должны быть на рабочем месте «от и до», а все личные вопросы вы будете решать в нерабочее время. Зачастую это бывает очень неудобно (особенно когда дело касается каких-то длительных мероприятий вроде болезни маленьких детей или проведения долгих процедур с госструктурами). Вряд ли начальство будет радоваться, отпуская вас с работы десятый раз за месяц. В то же время, иногда техпису не обязательно всегда находиться в офисе — всё большую популярность набирает удалённая работа, когда штатный сотрудник выполняет свои задачи с домашнего ПК. При этом за его «отсидкой» никто не следит, показателем эффективности служит строгая выдержка всех сроков сдачи работ. Если вам повезло устроиться удалённым сотрудником, считайте, что этого минуса для вас нет.

• Необходимость изо дня в день ездить в офис. И чем больше город, и чем плотнее в нём пробки, тем больше времени у вас будет занимать дорога на работу и домой. И если для москвичей 2-3 часа дороги в одну сторону уже стали нормой, то жители других городов не готовы терять по 4-6 часов в сутки на поездку. И точно так же, если вы стали «удалёнщиком» — этот минус вас не коснётся.

• Привязка к городу. Работая в офисе, вы не сможете сменить город проживания, не сменив при этом работу. Это делает вас менее мобильным, но если вы не планируете переезжать, то значения этому пункту можно не придавать. Удалённые работники… Ну, вы поняли!

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

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

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

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

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

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

Плюсы:

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

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

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

Минусы:

• Постоянный поиск. До тех пор, пока фрилансер не станет настолько известным, что клиенты сами будут приходить к нему, очень много личного времени придётся тратить на поиск клиентов и общение с ними. А подобная «известность» иногда приобретается годами.

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

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

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

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

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

• Необходимость постоянного общения с заказчиками.

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

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

• Отсутствие стабильности. Стоит расслабиться или взять отпуск — и часть клиентов вы потеряете. А в эпоху бушующих в экономике кризисов и перепадов вы всегда можете остаться не у дел, потому что на вашей отрасли (кем бы вы ни были, это относится ко всем) начали повально экономить. Можно было бы сказать о массовых сокращениях, но, как показывает практика, когда фрилансеры уже голодают, штатные сотрудники ещё сидят на своих местах. Ведь первые работают только на себя, а вот из-за временного кризиса терять навсегда толкового сотрудника мало какой работодатель захочет.

• Неподтверждённые доходы. Взять кредит фрилансеру без теневых фирм-помощников практически невозможно — доходы не подтверждены.

• Нелегальное положение. Да, фрилансером быть незаконно! Если у вас нет ИП или вы не работаете по договору подряда, а получаете деньги напрямую, вы занимаетесь незаконной

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

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

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

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

2. Территориальные варианты занятости. Офис и удалённая работа

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

Немного остановимся на последней фразе: кроме, непосредственно, home office (собственно, надомная работа), фрилансерам предлагают свои услуги коворкинг-центры (co-working). В коворкинг-центрах любому желающему предоставляется рабочая зона в большом общем офисе, где работает ещё несколько таких же «свободных художников», как и он сам. Для общего пользования в таких центрах имеется вся необходимая офисная техника (принтеры, сканеры, проекторы и т. д.), а также комнаты для переговоров и необходимые бытовые удобства (кухня, туалет).

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

Поэтому облегчим выбор, сократив его до развилки: дом или офис?

Офисная работа

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

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

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

Удалённая (надомная) работа

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

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

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

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

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

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

При этом у человека будет два варианта действий: посвящать освободившееся время домашним и личным делам (на связи-то надо быть полный день, никуда не денешься), или устроиться на вторую работу.

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

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

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

Как не ходить на работу?

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

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

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

В-третьих, вам придётся убедить своего руководителя, что удалённая работа выгодна для самой компании. Основных аргументов у вас будет несколько:

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

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

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

• Некоторые болезни не будут мешать вашей работе — если дома остаётся офисный работник — он лечится, занимаясь своими делами. Если же дома болеет удалёнщик — он может выполнять часть, а то и все свои обязанности. Естественно, речь идёт о болезнях, при которых человек способен заниматься чем-то ещё, кроме поддержания дивана в горизонтальном положении.

• Вы всегда доступны — по телефону, почте и по любому виду интернет-связи. А если дела требуют совместного мозгового штурма — вы всегда можете приехать в офис и принять в нём участие.

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

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

3. Формирование портфолио специалиста по текстам

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

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

Существует несколько вариантов наращивания числа документов «для показа», вы можете использовать их по отдельности или заняться всем и сразу. Для простоты мы будем считать, что изначально у вас нет вообще ничего, но вам требуется в максимально короткие сроки обрасти примерами качественных работ. Вот основные способы:

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

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

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

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

Глава 4. Производственные процессы

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

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

1. При работе по найму

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

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

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

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

Дальше возможны два варианта:

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

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

Важно отметить также, что в каком бы формате ни делался документ, в итоге он, как правило, преобразовывается в html, pdf или chm-формат: для использования на сайте, для скачивания / распечатки или для включения в программу в виде файла справки соответственно. И нужно заранее определить, кто будет отвечать за итоговое оформление документа. Как правило, при наличии проверяющих сотрудников — этим занимаются именно они, в противном случае, постараться придётся самому техпису, чтобы на выходе получить не только качественный по содержанию, но и эстетичный внешне документ в требуемом формате. Для этого, возможно, придётся дополнительно освоить продукты Adobe, html-разметку и chm-редактор.

Также нужно обговорить организационные моменты, играющие важную роль в процессе коммуникации и анализе результатов работы:

1. Как будет происходить общение в компании. Вариантов может быть несколько:

• Постоянное неформальное общение — когда вы общаетесь с руководителем и остальными коллегами «на короткой ноге». То есть свободно можете поговорить как о погоде, так и обсудить важные рабочие вопросы.

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

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

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

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

Доступ к перечисленным коллегам у вас должен быть постоянный. Даже если нельзя отвлекать их лично, хоть и сидят они в соседнем кабинете — они всегда должны быть доступны вам хотя бы по электронной связи. В принципе, будет достаточно электронной почты, но лучше «более живое» онлайн-общение с помощью какого-нибудь IM-клиента типа Skype, Jabber или любого другого.

2. Критерии оценки работы или «кто прав?». Иными словами, как вести себя в конфликтной ситуации, когда у вас и руководителя или проверяющего сотрудника возникли разногласия по тексту. Разумеется, оптимальным вариантом является разумный компромисс, к которому вы придёте в ходе обсуждения возникшей проблемы. Но когда обе стороны «упираются рогом», разбираться приходится по одному из сценариев:

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

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

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

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

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

2. При работе на подряде и фрилансе

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

В этом случае вы сразу при получении заказа получаете и все необходимые для его выполнения материалы (дистрибутив программы, например, или доступ к серверу с развёрнутым ПО). Далее, вы пишете текст, возможно, консультируясь с предоставленным техническим специалистом. Через электронную почту или IM-клиент — не важно.

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

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

Важные организационные моменты такого типа сотрудничества:

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

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

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

4. Если согласовать ТЗ не получается, заказчик выставляет «туманные» требования и ни в какую не готов ответить письмом «Согласен» или «ТЗ считаем согласованным» — от работы лучше отказаться, ничем хорошим она не кончится.

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

3. Методика переговоров со специалистами, получение и анализ сведений

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

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

В обращении со специалистами есть несколько правил:

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

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

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

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

5. Основной принцип: вопросов должно быть как можно меньше и они должны быть предельно конкретными. Никаких «расскажите, как работает…» — быть не должно. Задав вопрос — слушайте и улавливайте. Если что-то не понятно — лучше переспросите или уточните сразу, потому как второй раз вылавливать специалиста по одному и тому же вопросу будет неудобно.

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

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

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

Глава 5. Приступая к работе: базовые сведения и понятия 

1. Области, в которых присутствует работа с текстами

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

• IT-отрасль в целом — здесь нужна аналитика, документация и ещё много всего.

• Наука — мало провести большое исследование, надо ещё грамотно его описать и представить.

• Журналистика — хороший, схватывающий на лету технический писатель после нескольких лет практики сможет описать что угодно и стать первоклассным журналистом.

• Любая сфера, связанная с применением электронного оборудования, энергетикой, бизнес-планированием, аналитикой и экономикой.

2. Классификация носителей информации

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

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

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

Тексты исключительно для чтения с экрана

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

У данного типа текстов есть преимущество в виде ряда возможностей:

• Использовать перекрёстные ссылки (перелинковку) внутри документа;

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

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

• добавлять картинки или схемы с увеличением «по щелчку», видеоролики, gif-файлы;

• делать слова-ссылки, не прописывая адреса в явном виде.

Тексты, предназначенные

для чтения исключительно с экрана, как правило, относятся к одной из категорий:

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

Рис. 2. База знаний на сайте http://wiki.7405405.ru

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

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

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

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

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

Рис. 3. Онлайн-документация на сайте Dr.ExpLain (www.drexplain.ru)

Тексты с возможностью распечатки

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

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

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

Ссылки на различные места в документе можно делать перелинковкой, но в виде «кликабельных» слов вида «См. Раздел 3».

Также нужно избегать вставки внешних ссылок, так как у пользователя, имеющего только распечатку, может не быть возможности открыть ссылку на ПК (например, компьютер не имеет доступа в Интернет). Вместо ссылок можно делать сноски, в которых и размещать весь важный материал. Если объём информации по ссылке слишком велик, то его можно либо целиком внести в основной текст документа, либо все же сделать ссылку, но уже в явном виде, не заменяя текст ссылки словом. Например: www.google.ru.

Тексты исключительно для печати

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

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

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

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

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

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

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

3. Типы пользователей документации

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

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

• сотрудник компании, в которой пишется документ;

• сторонние лица: пользователи, клиенты и т.д.;

• комиссии различного уровня, отвечающие за приём продукта в эксплуатацию.

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

Документы для внутреннего пользования

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

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

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

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

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

Поясним на примере: вы пишете внутреннюю документацию для программы Skype в тот момент, когда она только разрабатывается.

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

Руководство согласно, надо писать программу.

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

Естественно, приведённая схема упрощена до невозможности, но суть задачи по распределение текстов внутри компании она передаёт верно.

К документам для внутреннего использования относятся:

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

• рабочие регламенты и бухгалтерские документы (например, штатное расписание);

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

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

Документы общего пользования

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

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

Это как раз тот случай, когда немного здоровой паранойи не помешает — она убережёт вас от излишне полного (да-да, и такое бывает!) описания продукта.

К документам общего пользования относятся:

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

• ролевая документация для сотрудников компании-клиента (например, руководство оператора программы для внесения сведений о продукции на складе);

• обзоры и аналитика, рассчитанная на широкий круг лиц;

• пресс-релизы и вся PR-продукция компании.

Это наиболее распространённые тексты, с которыми приходится работать, на них приходится до 90% всех документов, выпускаемых компанией.

Документы для сдачи в принимающие государственные органы

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому просто напишите простую, качественную и понятную инструкцию и надейтесь, что её прочитают.

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

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

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

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

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

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

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

Чаще всего эта документация поставляется в печатном виде, что нужно учитывать при оформлении текста.

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

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

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

Если речь об описании баз данных (далее: БД), то описываются все таблицы БД, их поля, строится карта взаимодействия (графическая схема БД). Другие данные для описания таблицы не требуются — специалисту по работе с ней упомянутых сведений будет более чем достаточно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 6. Формат документа и статьи

Теперь, когда вы познакомились с азами профессии и получили представление о том, с чего начинается работа над техническим документом, мы перейдём непосредственно к тем приёмам и методам, которыми вы будете активно пользоваться в своей работе. Многие формулировки вам вначале придётся воспринять «как факт» — их освоение потребует практики, другие же будут понятны и очевидны сразу.

Исходя из полученного ранее материала, вы, готовясь к написанию технического документа, уже смогли ответить на основные вопросы: на каком носителей он будет поставляться пользователям, к какой глобальной категории относится его ЦА (внешние, внутренние, широкий круг и т. д.) и, собственно, кто именно является его основной аудиторией. Теперь же вам нужно разработать то, на чём будет базироваться ваш документ — его структуру.

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

1. Формат и структура технического документа

Вся руководящая документация (пользователя, администратора и т. д.), все инструкции и документы, описывающие то или иное устройство или программу, по сути своей имеют общую структуру. Её материальным и видимым воплощением является оглавление документа. И именно с него вам и потребуется начать свою работу. Стоит отметить, что браться за написание руководства к программе можно лишь тогда, когда вы уже изучили её вдоль и поперёк. При попытке описать продукт параллельно с его изучением (по принципу: «что вижу — то пою»), вы с очень высокой (примерно 146%) вероятностью сядете в лужу или, в лучшем случае, сделаете всю работу два раза подряд, поскольку вам придется постоянно возвращаться по тексту назад, чтобы исправить всплывшие в ходе дальнейшего изучения программы нюансы или неточности.

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

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

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

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

4.  Установка. Алгоритм действий по установке ПО на компьютер или установке в помещение и подключению к сети электронного оборудования.

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

6. Использование в работе. Часть, непосредственно посвящённая описанию приложения или устройства и работе с ним пользователя. Основной и самый крупный раздел документа.

7. Удаление. Для ПО в этом разделе описывается стандартная процедура удаления, для оборудования — демонтаж и условия утилизации, если они отличаются от типовых (вынести на помойку).

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

2. Формат и структура статьи. Канон и отступления от него

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

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

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

Статья-отчёт. Материал, посвящённый какому-либо мероприятию. Например, отчёт о проведённой некой ИТ-компанией конференции.

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

Статья-рассказ. В таком материале может быть повествование о чём и о ком угодно. О туристической поездке автора, о какой-то известной личности или историческом событии.

Статья-руководство. Эти статьи размещаются, как правило, на различных сетевых ресурсах, посвящённых IТ-тематике. Например, статья может содержать руководство по восстановлению повреждённых данных на жёстком диске.

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

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

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

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

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

3. Основная часть. Здесь сосредоточен основной материал — анализ, сравнение, описание или повествование — в зависимости от типа статьи.

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

5. Заключение. Во всех типах статей, кроме аналитики, авторские выводы (именно личные авторские) пишутся тут. Вместо личного мнения автора могут быть его размышления о дальнейшем развитии темы. Например, рассказывая в статье про обстановку в городском ЖКХ, он может упомянуть о планах по изменению законодательства и перспективах по внедрению каких-либо новых технологий. Заключение присутствует в тексте не всегда, поскольку автор имеет право оставить все выводы и мысли «на совести читателя», не вплетая в материал свою субъективную оценку или мнение.

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

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

Глава 7. Основы создания технической документации

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

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

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

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

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

1. Человек не знает ничего. По сути, это портрет домашнего пользователя. Ему нужно разжёвывать все действия подробно, сопровождая каждое скриншотом с дополнительными отметками (вроде подчёркивания кнопок, которые нужно нажать).

2. Человек знает систему, но не знает описываемое ПО. Портрет опытного пользователя. Вам нужно рассказать, как пользоваться программой, при этом можно значительно уменьшить размер документа за счёт скриншотов и описания однотипных действий. Но установку нужно описать подробно, можно со скриншотами, ибо ошибка в ней (например, пропуск важного компонента) чревата проблемами в дальнейшей работе. А многие остальные действия можно описывать уже только словами. Этот вариант подходит для руководств пользователей программного обеспечения, которое не требует мудрёной настройки и интеграции с системой (или требует, но для этого есть администратор со своей отдельной инструкцией).

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

4. Человек написал ПО, которое вы описываете, и тем же будет заниматься тот, кто придёт на его место и будет читать ваш текст. То есть это программист-разработчик. Здесь разъяснять не надо вообще ничего. Только комментировать краткими фразами, давая определения.

В нашем примере мы будем действовать по второму варианту.

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

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

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

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

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

Как и в прошлом пункте, в нашем примере мы будем действовать по второму варианту.

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

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

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

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

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

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

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

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

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

Как правило, используется формулировка «вы», поскольку она позволяет изъясняться более короткими фразами за счёт превращения безличной конструкции вида «необходимо сделать» в «сделайте».

3. Разработчики. В документах для этой ЦА вы вообще никак и ни с кем не разговариваете. Присутствует лишь сухое безличное изложение: это отвечает за то-то, это делает то-то. А уж что делать с этими штуками и как использовать — пусть сами разбираются.

В нашем примере лучше всего использовать форму «вы».

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

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

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

3. Для администраторов снабжать рисунками нужно только те фрагменты инструкции, где есть значительное количество настроек, которые требуется менять при вводе программы в эксплуатацию или в процессе её использования. Если процесс настройки и базовой установки сложен, его можно «проскринить» полностью, опуская только очевидные моменты. Также нужно отметить, что если какой-то процесс содержит много ветвлений, то это повод изложить его в виде блок-схемы с комментариями, а не описывать всё словами. При написании статей для этой ЦА будет полезно использовать графики и схемы, поскольку одной из задач этих статей зачастую является сравнение и анализ каких-либо данных.

4. Для разработчиков не требуется ни скриншотов, ни картинок. При этом графики в документах для них может быть достаточно много — это и структурные схемы баз данных, и схемы алгоритмов (иногда имеют просто огромный размер и распечатать их очень затруднительно, картинка может иметь размер 2×5 метров в масштабе распечатки 100%). Какие именно схемы и блок-схемы изображать — нужно согласовывать с консультантами, которых выделит вам отдел разработки. Это связано с тем, что только сами разработчики могут сказать, какие графические пояснения будут полезны их коллегам, а какие будут ненужным отчётом Капитана Очевидности.

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

Шестым шагом будет определение последовательности описания элементов программы и действий с ними.

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

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

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

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

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

Глава 8. Базовые приёмы работы с текстом

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

1. Лексические тонкости и основные ошибки в технических документах

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

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

• Использование буквы «ё» в корпоративных документах обычно регламентируется. Если чёткого указания нет — прочтите любой корпоративный текст и посмотрите, есть ли она в нём. Буква самостоятельная, но зачастую она не используется (краски на точки жалко, что ли?). Если пишете материал любого другого типа (статьи, новости и т. д.) — букву «ё» использовать нужно (осел и осёл передают привет на пару с многими другими).

• Нельзя путать дефис (как-то) и тире (осёл — это животное на четырёх ножках © Незнайка).

• Слово «Интернет» пишется с большой буквы и склоняется по падежам. Исключение составляют составные слова (интернет-кафе).

• В конце всех пунктов списка кроме последнего ставится знак «;» или ничего вообще.

• В конце последнего пункта списка всегда ставится точка.

• В документации просторечные обороты вида «кое-что» заменяются на вид «что-либо».

• В свою очередь «что-нибудь» превращается в «что-либо».

• Заранее определите, как будете выделять в тексте различные элементы, например: название клавиши, путь к файлу / имя файла. Обратите внимание, что стиль выделения должен быть сквозным по тексту, если выделения начнут путаться — это станет большим минусом.

• Имеет смысл вводить в текст блоки Внимание! — для акцента на важном моменте в описании и Примечание. — для сообщения дополнительных сведений или ссылки на них. Эти блоки визуально разнообразят текст и облегчают его восприятие.

• Блоков Внимание! не должно быть много.

• Если в тексте выделять какие-то важные моменты нужно достаточно часто, вместо вынесения их всех в блоки Внимание! Можно просто использовать полужирное начертание. Разумеется, в этом случае его нельзя будет использовать в этом документе для любых других типов выделения.

• Нумерация сносок всегда делается сквозной по документу.

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

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

Рис. 4. Флажки

• Название элемента, позволяющего переключаться между несколькими взаимоисключающими опциями — «переключатель». Имя переключателя — это название поля, объединяющего варианты положения переключателя (рис. 5).

Рис. 5. Переключатель «Ориентация»

• Полоса прокрутки — это полоса прокрутки, а не скролл, скроллинг или что-нибудь ещё.

• Описание последовательности действий по нажатию ряда экранных кнопок может осуществляться с помощью комбинации «—>». (Тире и символ «больше». Или просто ставьте стрелку из раздела Вставка → Символ.) Она помогает избежать многословного описания простого, как правило, процесса (например: Нажмите Пуск → Все программы → Калькулятор).

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

1) По возможности термин заменяется на указатель на него: местоимения «его», «её» и т.д. Основной подводный камень здесь — однозначность. Вы должны следить, чтобы было всегда понятно, кого «его» мы имеем в виду.

2) Также термин можно заменить на более общий. Например, чтобы часто не писать название программы, можно иногда называть её «программа».

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

1) Для скачивания дистрибутива перейдите по ссылке: *ссылка*;

2) …дополнительную информацию можно получить по ссылке: *ссылка*.

• Кроме wiki-страниц, адрес ссылки всегда указывается в явном виде, например, www.mail.ru. Использовать слова-ссылки недопустимо!

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

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

• Про мастера установки: Следуйте указаниям мастера установки… — не показаниям! Дело происходит не в суде. Глупая, но от этого не менее частая ошибка.

• Скобок не должно быть много, по возможности их лучше вовсе избегать.

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

• Названия компаний пишутся в кавычках, названия программ — без. Также важно обращать внимание, что к чему относится. Например, планировщик задач — относится к программе, функционал — тоже к программе. А вот служба поддержки относится к компании, а не к программе. И сама программа — это продукт компании. Например: «В службу поддержки компании «Microsoft» поступил вопрос от пользователя по функционалу программы MS Outlook».

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

• «Вода». Если текст напичкан лишними словами и сложными оборотами, это очень резко ухудшает его удобочитаемость и понятность. Текст должен быть максимально кратким!

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

2. Оценка объёма текста и графики при создании документации

 Приступая к работе над любым текстом, важно заранее оценить его объём. Это связано со всевозможными ограничениями: размер статей для публикации в бумажных изданиях всегда строго регламентируется, объём новостей на сайте, по правилу хорошего тона, должен помещаться на экране без прокрутки, тексты в социальных сетях также после определённого объёма скрываются ссылкой вида «читать далее». Причин для ограничения размера текста существует множество, поэтому способность хотя бы приблизительно оценить размер своего будущего творения — очень важный навык для технического писателя. Разумеется, с точностью до знака угадывать ничего не придётся, но в пределах 10-15 тыс. знаков для больших (150 и более тысяч знаков), 3-5 тыс. знаков для средних (от 50 тыс. знаков) и 500-1000 знаков для маленьких (до 20-30 тыс. знаков) ориентироваться придётся. Если текст планируется менее 10 тысяч знаков, то его объём можно поправить по факту, чуть нарастив или урезав.

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

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

В первом случае нужно оценить размер одного кейса (например, внесение товара в БД), после чего проанализировать программу и посчитать количество необходимых кейсов. После этого, применяя несложную математику, можно получить время работы над документом и его размер: умножить ориентировочное время написания кейса (или его объём в знаках) на количество кейсов — вуаля, сведения получены!

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

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

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

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

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

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

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

3. Оценка времени, необходимого на разработку технического документа

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

Виды технических текстов и уровень их базовой сложности

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

1. Если вы пишете руководство пользователя, то все элементы самой программы надо разжевать до предела, при этом вдаваться в технические нюансы её работы не нужно — достаточно показать как программа или устройство работают «снаружи», то есть с точки зрения самого пользователя. Иными словами, вы указываете, какие кнопки нажимать при необходимости совершить какое-либо действие в программе или за какой рычаг и зачем тянуть на установке.

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

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

2. При написании руководства администратора вам потребуется значительно глубже вникать в само программное обеспечение (до уровня продвинутого администратора, а не простого пользователя — потребуется разобраться во всех тонкостях настройки, использования и, возможно, борьбы с возникающими ошибками), зато не потребуется осваиваться в предметной области, так как пользователь-администратор работает только с программой, его задачей является её настройка, а не выполнение с её помощью каких-либо задач. Разумеется, в идеале техпис при написании любой инструкции должен владеть материалом чуть ли не на уровне разработчика, но здесь мы говорим о необходимом минимуме знаний и соответствующей им сложности текстов, которые вы сможете создавать. Иными словами, здесь вам придётся гораздо (в разы!) тщательнее изучить описываемое ПО, но не потребуется знать предметную область. Бывают исключения, и на уровне администратора приходится описывать ещё и часть производственных процессов, в которых участвует ПО, но это уже считается более «продвинутой» документацией и подобные задачи встречаются достаточно редко. В общем случае это второй по сложности тип документации.

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

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

Оценка времени на сбор материала, его обработку и систематизацию

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

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

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

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

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

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

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

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

4. Методология определения конечных сроков выполнения работы и контроль их соблюдения

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

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

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

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

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

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

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

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

3. При расчёте рабочего времени исходите из 5 (максимум 6) часов продуктивного труда каждый рабочий день. Конечно, если вы работаете сдельно, у вас много заказов, и вы остро нуждаетесь в деньгах, то вам выгоднее написать работу быстрее, в такой ситуации вы можете закладывать 9 или 10 рабочих часов на день. Превышать этот порог нельзя, да и не имеет смысла — труд с затуманенной от обилия информации и отсутствия отдыха головой приведёт к тому, что выдаваемые вами тексты будут иметь неудовлетворительное качество и изобиловать всевозможными ошибками и неточностями. Также стоит отметить, что держать подобный убийственный темп можно не более месяца подряд — труд технического писателя во многом творческий, требует активной и постоянной работы мозга, поэтому очень легко «выгореть», как и на других поприщах умственного труда. Потрудились на износ, заработали — дайте себе отдых хотя бы в виде «обычного» пятичасового графика или возьмите краткосрочный отпуск, чтобы дать голове отдохнуть.

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

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

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

Основные критерии для точной оценки сроков у вас теперь

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

5. Контроль оригинальности текстов

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

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

1) веб-сервис проверки уникальности на сайте www.text.ru;

2) настольный антиплагиатор Advego Plagiatus (скачать можно с сайта: www.advego.ru).

Рис. 6. Advego Plagiatus в действии

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

Достаточно качественным считается текст, оригинальный по оценкам этих сервисов на 90% и более. 85% являются минимумом, ниже которого опускаться недопустимо — текст будет плохо ранжироваться и, как следствие, потеряет всякую ценность. Горе-копирайтеров, по сотне раз переписывающих одну и ту же статью или новость для разных сайтов, как правило, заставляют выдавать текст, уникальный на 98-100%, но на самом деле эта перестраховка уже не критична. После 85% уникальность перестаёт играть решающую роль, уступая её ключевым словам и тематике сайта.

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

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

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

• Вырвите из памяти (не хватит — и из клавиатуры!) комбинации Ctrl + С и Ctrl + V — если вы отучите себя использовать даже маленькие фрагменты чужих текстов, вставлять их в свой текст и уже там исправлять — оригинальность ваших, работ вряд ли будет хромать. Подход «копировать — вставить» обычно проскакивает либо у совершенных неумех, либо при критически горящих сроках и работе второпях, у некоторых он встречается при незнании материала и отсутствии времени на его изучения. Эти два момента могут вас оправдать, но лишь отчасти — злоупотреблять этим нельзя и лучше иной раз посидеть ночь напролёт над текстом, чем сваять невесть что с низкими качеством и уникальностью (эдакий Франкенштейн мира техписов — материал из обрубков чужих текстов).

• Никогда не начинайте писать текст на основе только что прочитанного материала. В идеале нужно дать себе хотя бы сутки на его усвоение. Если же сроки горят и времени критически нет, то после вычитки всех текстов, которые лягут в основу вышей работы — хотя бы ненадолго отвлекитесь: попейте чайку, пройдитесь вокруг дома или офиса, думая о чём-нибудь другом. И лишь после этого хватайтесь за перо (то есть за клавиатуру). И разумеется о параллельной работе (читать материалы и писать по ним одновременно) — речи не идёт вообще, она недопустима!

• Учитесь! Всегда и всему! Чем шире ваш кругозор, чем больше вы знаете — тем больше у вас найдётся собственных слов для описания любой темы. А занимаясь чем-то одним, изучите свою область досконально, на уровне эксперта, чтобы ваши труды были не только оригинальными, но и интересными, и полезными.

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

6. Корректировка и редактирование технических текстов

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

Как правило, превращаться в редакторов / корректоров техпису приходится в четырёх случаях:

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

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

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

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

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

Итак, проработаем основные моменты редактирования и корректировки текста. Мы будем исходить из того, что как техпис вы уже многое можете, но сталкиваться с исправлением своих старых или чьих-то чужих текстов вам ещё не доводилось:

• Читать нужно именно то, что написано в тексте, а не то, что там должно быть написано. Это свойство нашего ленивого организма — если насильно не заставлять его работать — он будет отдыхать. Когда вы бегло читаете текст, наш мозг воспринимает слова целиком, не «прорабатывая» их по буквам. Зачастую это приводит к тому, что опечатки, не отмеченные, например, системой проверки правописания Word’a или иной программы, остаются без внимания. Чтобы понять, насколько на самом деле легко сесть в лужу с опечатками, достаточно прочитать этот текст:

«От Galaxy S5 ноыве девайсы пренеяли не только AMOLED. Они стали перымви плашнеатми Samsung, которые обалдают фуцкнией биометрического рапсонзавнаия отпчеатков пальцев».

Та лёгкость, с которой вы его восприняли — и есть тот стабильный, хоть и весьма нежелательный, гарант того, что без внимательности и скрупулёзности читать вы будете «как надо», а не «как есть». Стоит отметить, что опечатки этого типа легко находятся, только если слово начинается или заканчивается на ошибку, если же она в середине — выискивать её придётся весьма усердно.

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

• Вычитывать материал нужно сосредоточенно, ни на что не отвлекаясь. Вообще ни на что. Методом погружения, о котором мы говорили в главе про оптимизацию затрат времени. Поскольку вычитка изматывает мозг гораздо сильнее, нежели написание, поскольку она более монотонный и не имеющий творческой основы процесс — чтобы не спятить раньше времени, каждый час-два нужно делать перерывы по 10-15 минут. Конкретные значения времени вы со временем определите для себя самостоятельно, но для старта указанных периодов вполне достаточно. На время этой передышки — напрочь выкидывайте текст из головы!

Внимание! Бывают люди, которым трудно сосредоточиться, но при этом они могут долго выдерживать монотонную работу. Если вы относитесь к их числу, то лучше не делите день на вышеописанные «двухчасовки», а сразу, погрузившись в текст, отработайте запланированное количество часов и вместо перерыва просто заканчивайте свой рабочий день или переключитесь на другую задачу (если после 5-6 часов напряжённого и скрупулёзного редактирования вы ещё будете в состоянии связать два слова).

• Нельзя давать взгляду и мозгу «поплыть». Это означает, что вы не должны нагружать себя сверх меры даже при критических сроках. Максимум проверки даже для очень опытных редакторов составляет 90-100 страниц в день. Для начинающих же может быть невозможным внятно осилить даже 50 страниц. Ведь текст надо не просто прочитать, а именно проверить, оценить и проанализировать вдоль и поперёк.

• Если в ходе проверки вы понимаете, что текст слишком плох для редактирования, имеет смысл остановить этот бесполезный процесс и просто написать материал заново — будет быстрее и продуктивнее. Как говорится: «Лошадь сдохла — слезь».

Глава 9. Применяемое программное обеспечение

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

1. Платное и бесплатное программное обеспечение

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

Использование платного ПО, как правило, обладает рядом преимуществ:

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

• расширенная функциональность;

• более серьёзный уровень автоматизации рутинных операций;

• лучшая интегрируемость с другим ПО.

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

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

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

• получение обновлений безопасности и исправления ошибок;

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

При использовании платного ПО достаточно приобретать его лишь в том объёме, который вам действительно необходим. Например, если вы приобретаете Microsoft Office, и при этом работаете дома, то вам незачем покупать профессиональную версию, достаточно ограничиться версией «Для дома и учебы» или «Для дома и бизнеса».

2. Microsoft Office и альтернативы

 Что нужно знать о Microsoft Office. Версия 2003 снята с поддержки в апреле 2014 года. Сейчас поддерживаются версии 2007 (до октября 2017 г.), 2010 (до октября 2020 г.) и 2013 (до апреля 2023 г.) (+ в настоящее время актуальны версии Microsoft Office 2008/2011 для OS X). Начиная с 2007 SP2 есть возможность работать с форматом ODT (Open Office) без конвертеров и плагинов. Office 2010 может сохранять в PDF сам по себе (не нужны виртуальные принтеры).

Бесплатные альтернативы — Open Office (сейчас принадлежит Apache, раньше Oracle, ещё раньше свободное ПО) и ответвление под названием LibreOffice (разработчики, недовольные тем, что Oracle навязывает свою волю при разработке Open Office,

пошли своим, как им кажется, более прогрессивным путём). Существенный недостаток: эти продукты не поддерживают макросы Microsoft Office, что часто является определяющим фактором при отказе от этих продуктов.

Редактировать PDF (не создавать, а редактировать) логичнее всего в Adobe Acrobat X Professional. Но чаще всего требуется лишь предоставить заказчику документ в виде PDF-файла. Для этого достаточно делать его, например, в Microsoft Office, а затем сохранить (конвертировать) в PDF. Microsoft Office 2007/2010/2013 может это делать сам. Начиная с версии 2013 Microsoft Office может редактировать PDF-файлы самостоятельно, без использования стороннего ПО. Выводить информацию в PDF-формат можно также с помощью виртуальных принтеров, например, бесплатного виртуального принтера PDFCreator.

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

3. Важные возможности Microsoft Word

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

Подробные инструкции в виде уроков по использованию программы вы найдёте во встроенной справке или на сайте: http://office.microsoft.com/ru-ru/support/FX0100S6500.aspx

Здесь мы кратко расскажем о самых полезных и наиболее часто требующихся фишках MS Word.

Заголовки и оглавление

 Как ни странно, но то, что Word умеет автоматически создавать оглавление, знают не все. Для этого при написании текста заголовкам необходимо присваивать стиль требующегося уровня (Уровень 1, Уровень 2 и т.д.). После того, как все заголовки в документе оформлены соответствующим образом, достаточно нажать на кнопку Оглавление на вкладке Ссылки — и оглавление готово. Можно выбрать оформление и количество отображаемых в оглавлении уровней. При внесении изменений в документ не забывайте обновлять это поле. Также при присваивании стилей заголовков в документе мы получаем следующие преимущества: все заголовки в документе оформлены в едином стиле; на панели навигации мы получаем структуру документа, по которой удобно перемещаться во время работы с документом (вызывается нажатием Ctrl + F).

Перекрёстные ссылки на рисунки, таблицы и т.д.

 Если создаётся большой документ, в котором есть таблицы, рисунки и формулы, то вручную их нумеровать неудобно, при любых изменениях нумерация сбивается. Ссылки в тексте на объекты при изменениях тоже собьются. Чтобы избежать ручных исправлений, используются перекрёстные ссылки. Итак, перекрёстные ссылки позволяют автоматически присваивать и обновлять нумерацию рисунков, таблиц, формул и т. д. После любых изменений, как и при работе с оглавлением, необходимо обновить все поля. Для этого нужно выделить весь документ (Ctrl + А), кликнуть правой кнопкой мыши в любом месте, нажать Обновить поле.

Работа с рисунками

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

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

Горячие клавиши

 Чем реже при работе с текстовым редактором мы перемещаем руки с клавиатуры на мышку, тем больше мы экономим времени. Большинство команд мы можем производить с клавиатуры, без помощи мышки. Сочетания клавиш, которые часто пригождаются:

Ctrl + С — копировать;

Ctrl + V — вставить;

Ctrl + X — вырезать;

Ctrl + В — жирный шрифт;

Ctrl + I — курсив;

Ctrl + U — подчёркивание;

Ctrl + А — выделить всё;

Shift + стрелки влево (вправо) — выделить символ слева (справа) (удобно для выделения только что напечатанного слова, чтобы, например, форматировать его жирным или курсивом);

Shift + стрелки вверх (вниз) — выделить текст по строчкам вверх (вниз);

Ctrl + стрелки влево (вправо) — переместить курсор на слово влево (вправо);

Shift + Ноте — выделить всю строку влево от курсора;

Shift + End — выделить всю строку вправо от курсора;

Ctrl + – на цифровой клавиатуре — длинное тире;

Alt + PrtSc — скрин активного окна;

Ctrl + F — навигация и поиск по документу;

Ctrl + Z — отменить действие;

F4 — повторить отменённое действие;

Shift + F3 — меняет заглавные буквы на строчные, при следующем нажатии — первые буквы слов на заглавные, при ещё одном нажатии — снова на заглавные;

Ctrl + Enter — вставить разрыв страницы (зачем он нужен будет рассказано дальше);

Ctrl + колёсико мыши на себя / от себя — уменьшить / увеличить масштаб;

Ctrl + Shift + пробел — вставка неразрывного пробела (он нужен для того, чтобы на следующую строку не переносилось то, что нельзя разрывать);

Alt + 769 — вставить ударение над буквой, которая стоит перед курсором;

Ctrl + пробел — вернуть выделенному тексту исходное форматирование;

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

Назначение своих горячих клавиш

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

1) найти таблицу сочетаний Alt + цифры для вставки символов (или смотреть их в таблице символов в самом Word’e). Например, 0136 — €;

2) создать собственные сочетания. Как это сделать — описано ниже.

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

Открываем таблицу символов (меню Вставка →  Символ →  Другие символы), выбираем нужный символ и нажимаем Сочетание клавиш…

В открывшемся окне в поле Новое сочетание клавиш: нажимаем то сочетание, которое хотим использовать (допустим, Ctrl и 0 на цифровом блоке) и нажимаем Назначить.

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

Разрыв страницы

 Для чего нужен разрыв страницы?

Если его не использовать, то при любых изменениях (добавление/удаление текста) в документе, все разделы сбиваются, а нам хочется, чтобы новый раздел всегда начинался ровно с самого начала страницы. Поправлять каждый раз вручную неудобно. Чтобы этого избежать, после последнего абзаца раздела нужно вставить разрыв страницы. Есть два способа сделать это: 1) сочетание Ctrl + Enter, 2) меню Вставка →  Разрыв страницы. После этой вставки мы автоматически переходим к написанию текста уже со следующей страницы. После этого текст можно изменять, а расположение начала следующего раздела не изменится, он всегда будет начинаться с первой строчки страницы (если будет вставлено/удалено много текста, то изменится номер страницы).

Автозамена

 Два удобных способа использовать автозамену:

1) Если уже после написания текста обнаружилось, что есть какое-то слово, которое было написано с ошибкой, и оно повторяется много раз. Например, написали название программы «Frame Maker» или «Framemaker», а надо было «FrameMaker» (да, с заменой маленькой буквы на большую тоже работает).

Чтобы сделать автозамену, нужно нажать Ctrl + F, вписать в окошко слово, которое ищем (при этом сразу выполнится поиск), затем нажать на треугольник справа от окошка, выбрать там Заменить… и вписать в окошко Заменить на… верный вариант. Дальше нажать Заменить всё (или Заменить на главной вкладке справа или Ctrl + Н).

2) Чтобы сэкономить время написания текста. Чем меньше клавиш надо нажимать, тем быстрее печатается текст. Можно создать предустановленные автозамены некоторых частых сочетаний. Например, после точки в тексте всегда идёт пробел, соответственно, если создать автозамену «.» на «. », то мы в конце каждого предложения будем экономить одно нажатие. Единственное исключение, когда это неудобно — это когда мы пишем нестандартный текст, например, часто пишем дробные числа или формулы, где пробелы после точек и запятых ставить не нужно. В основном такое бывает не очень часто, но если это ваш случай, то очевидно, что такая автозамена только создаст лишние проблемы. Недостаток: некоторым людям нужно длительное время, чтобы привыкнуть не ставить пробел после точки. Плюс к этому, такая замена будет работать только в Word, а в других местах (почта, скайп и т. д.) — нет, поэтому это может быть неудобно. Но, как показывает практика, такой рефлекс (не ставить пробелы только в ворде) может достаточно легко выработаться.

Что можно заменять, например:

«.» на «. »

«,» на «, »

«!» на «! »

«?» на «? »

«;» на «; »

Настройка автозамены делается здесь: Меню Файл →  Параметры →  Правописание →  Параметры автозамены →  Вкладка Автозамена

Для русской и английской раскладки правила применяются отдельно.

Изменение стилей

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

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

Режим правки (режим исправлений)

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

Включается режим исправлений на вкладке Рецензирование, кнопка Исправления.

Основные настройки режима

1. Способ отображения исправлений. Удобнее всего — всё в выносках, тогда сам текст будет сразу отображаться без лишних элементов. Также есть вариант отображать в тексте, но он менее удобен. Чтобы вынести исправления на поля, а в самом документе видеть только изменённый текст, нажмите: Показать исправления →  Выноски →  Показывать исправления в выносках.

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

Нужные кнопки

1. Создать примечание — можно создать примечание как к выделенному тексту, так и к другому примечанию.

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

3. Назад и Далее — используются для автоматического перехода к предыдущему/следующему исправлению.

 Сравнение документов

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

Для этого нужно открыть один из этих документов и нажать в нем Рецензирование → Сравнить → Сравнить….

Выбрать в окошках Исходный документ и Изменённый документ соответствующие документы.

Откроется следующее окно (результаты сравнения) (рис. 7).

Слева будут перечислены изменения, а над списком изменений будет указано, сколько было внесено изменений (это окно включается/отключается кнопкой Область проверки). Справа вверху — исходный, внизу — изменённый. Эти окна включаются/отключаются кнопкой Сравнить →  Исходные документы. По центру — тот документ, который получается при сравнении. В нем можно применять или отклонять правки. (А если целью сравнения было только узнать, какие были внесены правки и какой документ является последней версией, то среднее окно, по сути, не нужно. Смотрим только на правые и делаем выводы.)

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

Рис. 7. Результаты сравнения двух документов в Microsoft Word

 Функция «Объединить»

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

Рецензирование →  Сравнить →  Объединить…

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

4. Приложения для совместной работы

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

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

Поэтому для совместной работы рекомендуется использовать либо веб-сервисы, установленные непосредственно на вебсайтах предприятий, либо использовать ПО для совместной работы, которое аккумулирует информацию на локальных серверах компании. Примером таких приложений может служить продукция MadCap Software (инструмент MadCap Flare), Индиго Байт (инструмент Dr. Explain) и другие.

5. Инструменты для создания видеоинструкций

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

Среди программ, ориентированных на создание видеоинструкций, можно отметить следующие: Camtasia Studio, Adobe Captivate, MadCap Mimic и Movavi Video Suite.

Глава 10. Обзор дополнительных областей

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

1. ГОСТы и иные мировые стандарты документирования

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

 ГОСТ

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

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

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

 Существует три основных единых стандарта: программной (ГОСТ 19), конструкторской (ГОСТ 2), технологической (ГОСТ 3) и руководящей (РД) документации. Также применяется ГОСТ 34 — на автоматизированные системы. Ознакомиться с ними подробнее можно в сети Интернет по соответствующим запросам, ибо на каждую область есть свой ГОСТ и на описание управления каждым оборудованием — своя РД. По сути, ГОСТ для техписа — это как таблицы Брадиса для математика — нужно знать как им пользоваться, но заучивать что-то наизусть смысла не имеет — всё необходимое чётко прописано в самом стандарте.

ISO и IEEE

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

IEEE 1063 — это стандарт, разработанный Институтом инженеров по электротехнике и электронике (IEEE) и содержащий все регламенты по документированию разработок в этих областях. К большому сожалению, разработок в этой отрасли в РФ очень мало (они есть, но их доля на рынке исчезающее мала), поэтому знание этих стандартов будут практически бесполезны для работы внутри РФ, но весьма ценны при написании документации для зарубежных компаний на основе, например, аутсорсинга.

ISO (ISO/IEC FDIS 18019:2004 и ISO/IEC 26514:2008) — собственно, это стандарт-руководство по написанию руководств. В отличие от IEEE, ISO может использоваться где угодно и поэтому порой встречается даже в РФ. Это связано с тем, что существуют компании, которые работают в том числе и для иностранных клиентов и, соответственно, вынуждены готовить русско- и англоязычные документы по международным стандартам.

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

Небольшую статью про эти стандарты можно прочитать здесь: http://habrahabr.ru/post/l16825/.

2. Документирование API

 API — интерфейс программирования приложений. В современном мире приложения и устройства общаются между собой на особых языках, которые и называются API того или иного устройства, веб-сервиса или приложения.

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

API technical writer пишет для других разработчиков, поэтому должен также владеть инструментами разработки.

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

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

Полезная статья о том, что такое API, для чего используется, зачем и как начать его документировать, какие инструменты использовать, как взаимодействовать с коллегами, какие существуют основные принципы: https://protext.su/pro/itak-vam-nuzhno-dokumentirovat-api/

Полезные ссылки и материалы

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

https://protext.su — сайт компании «ПроТекст». Блог о техническом документировании с полезными материалами, записи онлайн-конференций и вебинаров, курсы для технических писателей.

https://t.me/technicalwriters — Telegram-канал «Технические писатели», будет полезен для общения с коллегами и поиска работы.

https://yandex.ru/blog/x-plain — клуб технических писателей от команды Яндекс.

http://techwhirl.com/ (англ.) — портал, посвящённый управлению контентом и техническим коммуникациям. Содержит множество полезных статей и новостей на разные темы.

http://idratherbewriting.com/ (англ.) — блог технического писателя из США Тома Джонсона. Статьи в основном о документации для разработчиков. Основные темы: документирование API, визуальные коммуникации, видеодокументация, информационная архитектура, контент-стратегия.

http://thecontentwrangler.com/ (англ.) — портал с большим количеством материалов на тему контента, охватывает множество разных аспектов (управление, стратегия, коммуникации, локализация и другие).

https://ru.libreoffice.org/ — бесплатный аналог MS Office.

http://www.omegat.org/ru/omegat.html — бесплатный инструмент для автоматизации переводов.

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

Об авторе

 Александр Владимирович МИХАЙЛОВ

Родился в Новосибирске в 1987 г. В 2010 г. окончил Новосибирский государственный технический университет. С 2006 г. пишет статьи для различных изданий, по большей части — IT-обзоры и аналитические материалы. С 2007 по 2011 гг. опубликовал также несколько технических книг, посвященных интернет-технологиям и информационной безопасности. С 2011 г. — сооснователь и директор аутсорсинговой компании ООО «ПроТекст», специализирующейся на разработке технической документации и обучении технических писателей (в рамках курсов «Разработка технических текстов и документации», «Техническая документация в Atlassian Confluence» и других). Преподавал курс «Основы технического документирования» в НГТУ (Новосибирск) и БГУ (Минск).

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

Оглавление

От автора

Глава 1. Введение в специальность, или Рыцари клавиатуры

 
1. Кто работает с текстами?

 
2. Особенности работы технического писателя

 
3. Отличие «технического» писателя от «классического»

 
4. Почему навыки работы с текстами нужны всем?

 
5. Почему инженер или программист не может писать технические тексты?

 
6. Профессия технического писателя в РФ и за рубежом

 
7. Технический писатель и прогресс — заменят ли нас программы?

Глава 2. Как стать техническим писателем

 
1. Как определить, подойдёт ли мне эта профессия и что тут нужно уметь?

 
2. Несколько хитростей для успешного выполнения тестового задания

Глава 3. Юридические аспекты работы 

 
1. Варианты занятости технического писателя

 
2. Территориальные варианты занятости. Офис и удалённая работа

 
3. Формирование портфолио специалиста по текстам

Глава 4. Производственные процессы

 
1. При работе по найму

 
2. При работе на подряде и фрилансе

 
3. Методикапереговоров со специалистами, получение и анализ сведений

Глава 5. Приступая к работе: базовые сведения и понятия 

 
1. Области, в которых присутствует работа с текстами

 
2. Классификация носителей информации

 
3. Типы пользователей документации

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

Глава 6. Формат документа и статьи

 
1. Формат и структура технического документа

 
2. Формат и структура статьи. Канон и отступления от него

Глава 7. Основы создания технической документации

Глава 8. Базовые приёмы работы с текстом

 
1. Лексические тонкости и основные ошибки в технических документах

 
2. Оценка объёма текста и графики при создании документации

 
3. Оценка времени, необходимого на разработку технического документа

 
4. Методология определения конечных сроков выполнения работы и контроль их соблюдения

 
5. Контроль оригинальности текстов

 
6. Корректировка и редактирование технических текстов

Глава 9. Применяемое программное обеспечение

 
1. Платное и бесплатное программное обеспечение

 
2. Microsoft Office и альтернативы

 
3. Важные возможности Microsoft Word

 
4. Приложения для совместной работы

 
5. Инструменты для создания видеоинструкций

Глава 10. Обзор дополнительных областей

 
1. ГОСТы и иные мировые стандарты документирования

 
2. Документирование API

Полезные ссылки и материалы

Об авторе