Профессия "Технический писатель", или "Рыцари клавиатуры" [Александр Владимирович Михайлов] (fb2) читать онлайн

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

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

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

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

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

Об авторе