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

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

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

1. При работе по найму

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

Взаимодействие технического писателя с работодателем и руководителем на месте постоянной занятости

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

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

Дальше возможны два варианта:

1. В отделе или компании есть редактор, корректор или копирайтер, которые могут и должны проверить вашу работу. Им документ и попадает из рук вашего руководителя. Это самый простой и оптимальный для новичков случай — есть кому указать на ваши ошибки. При этом ваша задача — постоянно общаться с этими товарищами, чтобы они могли помочь вам, а вы, в свою очередь — выслушав и запомнив их советы, научиться писать качественнее.

2. Сотрудников, отвечающих за вычитку и проверку текстов, нет. В итоге новый документ проверяется либо непосредственным руководителем техписа (при условии, что это не редактор, а просто начальник отдела или кто-то ещё), либо только оценивается техническими специалистами на фактическую точность. Это очень плохой вариант, особенно если речь идёт о начинающем техническом писателе, так как некому проверить качество текста — все перечисленные способны оценить лишь соответствие описаний реальной программе. Увы, в такой ситуации вам придётся самостоятельно «полировать» качество своего текста. Как это делать — описано в разделе «Завершающий этап работы с текстом».

Важно отметить также, что в каком бы формате ни делался документ, в итоге он, как правило, преобразовывается в html, pdf или chm-формат: для использования на сайте, для скачивания / распечатки или для включения в программу в виде файла справки соответственно. И нужно заранее определить, кто будет отвечать за итоговое оформление документа. Как правило, при наличии проверяющих сотрудников — этим занимаются именно они, в противном случае, постараться придётся самому техпису, чтобы на выходе получить не только качественный по содержанию, но и эстетичный внешне документ в требуемом формате. Для этого, возможно, придётся дополнительно освоить продукты Adobe, html-разметку и chm-редактор.

Также нужно обговорить организационные моменты, играющие важную роль в процессе коммуникации и анализе результатов работы:

1. Как будет происходить общение в компании. Вариантов может быть несколько:

• Постоянное неформальное общение — когда вы общаетесь с руководителем и остальными коллегами «на короткой ноге». То есть свободно можете поговорить как о погоде, так и обсудить важные рабочие вопросы.

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

• Совещания — когда все вопросы, за исключением экстренных, решаются на периодических совещаниях, в остальное же время все сотрудники заняты своими задачами и отвлекать их не рекомендуется.

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

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

Доступ к перечисленным коллегам у вас должен быть постоянный. Даже если нельзя отвлекать их лично, хоть и сидят они в соседнем кабинете — они всегда должны быть доступны вам хотя бы по электронной связи. В принципе, будет достаточно электронной почты, но лучше «более живое» онлайн-общение с помощью какого-нибудь IM-клиента типа Skype, Jabber или любого другого.

2. Критерии оценки работы или «кто прав?». Иными словами, как вести себя в конфликтной ситуации, когда у вас и руководителя или проверяющего сотрудника возникли разногласия по тексту. Разумеется, оптимальным вариантом является разумный компромисс, к которому вы придёте в ходе обсуждения возникшей проблемы. Но когда обе стороны «упираются рогом», разбираться приходится по одному из сценариев:

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

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

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

Разумеется, если вашу работу никто особо не проверяет, то и спорить будет не с кем. Но это вариант скорее негативный, так как единственный способ получить внятный отзыв о качестве своей работы — мониторить запросы в службу техподдержки, чтобы буквально «на ощупь» выявить вопросы, по которым чаще всего обращаются и подробнее осветить их в документации (и добавить раздел FAQ на сайт, например).

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

2. При работе на подряде и фрилансе

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

В этом случае вы сразу при получении заказа получаете и все необходимые для его выполнения материалы (дистрибутив программы, например, или доступ к серверу с развёрнутым ПО). Далее, вы пишете текст, возможно, консультируясь с предоставленным техническим специалистом. Через электронную почту или IM-клиент — не важно.

Написав документ, техпис самостоятельно вычитывает его, корректирует, дорабатывает, оформляет в виде файла в требуемом формате (чаще всего pdf, но зачастую передаются и исходные материалы, например в *.docx).

Заказчик проверяет полученную работу и либо принимает её, либо указывает на недочёты, которые нужно устранить.

Важные организационные моменты такого типа сотрудничества:

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

2. При работе с заказчиком на чистом фрилансе, то есть в условиях лишь устной договорённости, мало просто обсудить условия работы и потребовать предоплату (в идеале — 100%, минимум — 50%, известные компании — без аванса, но желательно с устной гарантией разрешения указания их в списке ваших заказчиков). Нужно пообщаться с потенциальным клиентом как можно больше и хотя бы «на глаз» определить, кто перед вами — адекватный человек, желающий получить результат и готовый платить за него, или невнятное создание, толком не знающее, чего ему надо.

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

4. Если согласовать ТЗ не получается, заказчик выставляет «туманные» требования и ни в какую не готов ответить письмом «Согласен» или «ТЗ считаем согласованным» — от работы лучше отказаться, ничем хорошим она не кончится.

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

3. Методика переговоров со специалистами, получение и анализ сведений

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

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

В обращении со специалистами есть несколько правил:

1. Связь только напрямую. Вы должны сами прийти к нужному вам программисту или конструктору, лаконично описать ситуацию и попросить о помощи. Ни в коем случае не действуйте через своего или его начальника!

2. Если не знаете, к кому обратиться по возникшему вопросу — уточните у своего руководителя, он скажет, кого и где искать. После этого идите напрямую к нужному человеку и общайтесь с ним.

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

4. К моменту, когда коллега согласился вас выслушать и помочь, у вас уже должен быть готовый список вопросов и либо готовый ответ (если надо просто уточнить, когда вы в чём-то сомневаетесь), либо полная готовность воспринять сведения (записать или как-то иначе зафиксировать).

5. Основной принцип: вопросов должно быть как можно меньше и они должны быть предельно конкретными. Никаких «расскажите, как работает...» — быть не должно. Задав вопрос — слушайте и улавливайте. Если что-то не понятно — лучше переспросите или уточните сразу, потому как второй раз вылавливать специалиста по одному и тому же вопросу будет неудобно.

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

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

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