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

• Названия компаний пишутся в кавычках, названия программ — без. Также важно обращать внимание, что к чему относится. Например, планировщик задач — относится к программе, функционал — тоже к программе. А вот служба поддержки относится к компании, а не к программе. И сама программа — это продукт компании. Например: «В службу поддержки компании "Microsoft" поступил вопрос от пользователя по функционалу программы MS Outlook».

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

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

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

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

 Приступая к работе над любым текстом, важно заранее оценить его объём. Это связано со всевозможными ограничениями: размер статей для публикации в бумажных изданиях всегда строго регламентируется, объём новостей на сайте, по правилу хорошего тона, должен помещаться на экране без прокрутки, тексты в социальных сетях также после определённого объёма скрываются ссылкой вида «читать далее». Причин для ограничения размера текста существует множество, поэтому способность хотя бы приблизительно оценить размер своего будущего творения — очень важный навык для технического писателя. Разумеется, с точностью до знака угадывать ничего не придётся, но в пределах 10-15 тыс. знаков для больших (150 и более тысяч знаков), 3-5 тыс. знаков для средних (от 50 тыс. знаков) и 500-1000 знаков для маленьких (до 20-30 тыс. знаков) ориентироваться придётся. Если текст планируется менее 10 тысяч знаков, то его объём можно поправить по факту, чуть нарастив или урезав.

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

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

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

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

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

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

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