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

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

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

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

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