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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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