Всё для технического документирования
+7 (495) 001-40-42
Разработка технической документации
Курсы для технических писателей
Программное обеспечение

Как нанимать технического писателя (часть 1)

14.10.2013

01Представляем первую часть статьи специалиста канадской компании Docsymmetry с советами для работодателей по найму технического писателя. Несмотря на то, что упор в статье делается на технических писателей из Северной Америки, российские работодатели тоже найдут для себя полезные рекомендации.


Найм технического писателя может быть сложным, даже если вы являетесь одним из них. Где вы можете найти технического писателя? Какие характеристики должны в нём искать? Как можно определить, какой писатель хороший, а какой плохой?

Существует множество сайтов, посвящённых карьере, где вы можете нанять технических писателей. Например, один из них, Elance Find Technical Writers, позволяет писателям получать работу, которую предлагают там работодатели, по модели фриланса. По моему же мнению, однако, проще нанять технического писателя через ваше местное отделение Сообщества для технических коммуникаций (STC). Большинство, если не все, отделения STC имеют банки данных по работе, где вы можете публиковать предложения по трудоустройству. Члены STC в вашем регионе могут затем решить, имеют ли требуемую квалификацию, чтобы устроиться на работу.

Работодатели в Индии могут предпочесть использовать банк данных по работе в организации Технические писатели Индии.

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

Тогда на что вы должны обращать внимание, когда нанимаете технического писателя? Вы должны искать того, кто может:

  1. Разрабатывать документы, которые выглядят хорошо и на бумаге, и онлайн.
  2. Разрабатывать документы, которые легко обновлять.
  3. Писать инструкции, которые легко понять.

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

Разработка документа

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

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

Чтобы проиллюстрировать, что может случиться, когда не учитывается управление документацией, скажу, что однажды меня наняла компания, чтобы переделать документацию для их флагманского продукта. Никто в компании не знал, где в локальной сети можно найти существующую документацию. После поисков, которые заняли всё утро, я, наконец, нашёл исходное руководство пользователя. На самом деле я нашёл два – оба написаны в совершенно разных стилях двумя разными авторами и сохранены в двух различных местах локальной сети!

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

Чтобы проиллюстрировать это, допустим, что мой босс попросил меня написать, к примеру, лимерик, а затем позже попросил отредактировать его. Вы изменяете слово здесь, добавляете слово там и заканчиваете с этим через пару минут. Вы даже не должны уметь хорошо писать лимерики. Но допустим мой «лимерик» не выглядит или не звучит совсем как лимерик. На самом деле, допустим, у моего лимерика даже нет рифмы. Единственный способ сделать из него лимерик – переписать его. Конечно, вы можете просто сказать мне исправить его, но что, если я перейду на другой проект? Или в другую компанию? Вам потребуется исправить проблему самостоятельно и вам потребуется намного больше нескольких минут, чтобы сделать то же самое.

Типичный лимерик имеет структуру, более или менее похожую на следующую:

На душе у него лишь ненастье
Было раньше, и не было власти
Над словами в придачу,
А структуры – тем паче,
Ведь техписом не стать в одночасье.

(продолжение следует)

Источник: Hiring a Technical Writer

Тэги: , , ,

< Вернуться к списку публикаций

Облако тегов