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

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

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 страниц. Ведь текст надо не просто прочитать, а именно проверить, оценить и проанализировать вдоль и поперёк.

• Если в ходе проверки вы понимаете, что текст слишком плох для редактирования, имеет смысл остановить этот бесполезный процесс и просто написать материал заново — будет быстрее и продуктивнее. Как говорится: «Лошадь сдохла — слезь».