Бесплатная библиотека
Читайте книгу на сайте или телефоне
READ-E-BOOK » Прочая компьютерная литература » Профессия "Технический писатель", или "Рыцари клавиатуры"
Профессия "Технический писатель", или "Рыцари клавиатуры" - Читать Любимую Русскую Полную Книгу 👉 Read-E-Book.com

Профессия "Технический писатель", или "Рыцари клавиатуры"

Электронная книга - «Профессия "Технический писатель", или "Рыцари клавиатуры"». Краткое содержание книги:

В книге подробно рассматриваются основные аспекты работы специалиста по техническим текстам — от первых шагов и введения в профессию «технический писатель» до обзора применяемого программного обеспечения и организационных вопросов трудоустройства, включая взаимодействие с зарубежными заказчиками. Также описываются современные тенденции и изменения в профессии. Адресуется тем, кто уже работает «техписом» или ещё только собирается овладеть этой специальностью.
1 ... 36 37 38 39 40 41 42 43 44 ... 56
Перейти на страницу:

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

4. Для разработчиков не требуется ни скриншотов, ни картинок. При этом графики в документах для них может быть достаточно много — это и структурные схемы баз данных, и схемы алгоритмов (иногда имеют просто огромный размер и распечатать их очень затруднительно, картинка может иметь размер 2×5 метров в масштабе распечатки 100%). Какие именно схемы и блок-схемы изображать — нужно согласовывать с консультантами, которых выделит вам отдел разработки. Это связано с тем, что только сами разработчики могут сказать, какие графические пояснения будут полезны их коллегам, а какие будут ненужным отчётом Капитана Очевидности.

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

Шестым шагом будет определение последовательности описания элементов программы и действий с ними.

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

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

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

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

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

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

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

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

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

1 ... 36 37 38 39 40 41 42 43 44 ... 56
Перейти на страницу:
0
Сюжет
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Атмосфера
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Главный герой
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Общее впечатление
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
Итоговая оценка: 0.0 из 10 (голосов: 0 / История оценок)