Про работу и собеседования

Когда говоришь, что работаешь техническим писателем, со стороны собеседника неизменно следует шутка про чукчу. Обидно за профессию.

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

«А ты что за хрен?» — 9 лет как технический писатель, 2 года как руководитель группы технических писателей.

Картинок дальше не будет, только буковки.

Чем занимаются технические писатели:

  1. Оказывают помощь в формировании, оформлении и проверке документации, например, функциональных требований (ФТ), технических заданий (ТЗ), технорабочих проектов (ТРП), программ и методик испытаний (ПиМИ), описаний технических решений (ОТР), общих описаний системы (ООС), руководств пользователей/администраторов/технологов, какие там роли в системе есть. Если квалификация тех. писателя низкая, он может только проверить оформление и русский язык. Если высокая, и технический писатель способен анализировать и тестировать, то он может проверить логику построения ТЗ, ТРП, нарисовать функциональные макеты интерфейсов, а также самостоятельно (без предоставленных тестировщиками тест-кейсов) написать ПиМИ. Настоящие джедаи вообще умеют писать ПиМИ только по ТЗ и ТРП.
  2. Формируют разного рода вспомогательную документации, например, программу обучений пользователей и раздаточные материалы, презентации, инструкции для сотрудников колл-центров. Хороший технический писатель понимает, для кого и что он пишет. Поэтому, например, инструкция по работе с контентом сайта, который наполняют 20-летние маркетологини, должна быть построена одним образом, с одними акцентами. Инструкция для отдела 50-летних тётушек, которые до этого вообще редко видели компьютер — совсем другим образом.
  3. Поддерживают документацию в актуальном виде после сдачи системы в промышленную эксплуатацию. Обычно после окончания проекта, когда на всей документации стоит штамп «Согласовано», заказчик начинает генерировать «хотелки» — давайте тут кнопочку, давайте тут переделаем, тут вчера решили по-другому и прочее. Одновременно заказчик хочет иметь доступ к некой (всегда актуальной) версии документации. Обычная практика — на основе проектных документов сформировать некое описание системы (единое или разбитое на части) и далее документировать все хотелки заказчика по факту их реализации, например, на базе некой вики-подобной системы.

А теперь о том, какую роль играет технический писатель в проектной группе. Я рассматриваю работу по проекту в довольно крупной конторе, которая, например, на протяжении 5-7 лет разрабатывает, модифицирует и расширяет некий продукт, сторонний или свой.

Читать далее «Про работу и собеседования»