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

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

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

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

Оценка времени на сбор материала, его обработку и систематизацию

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

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

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

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