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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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