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

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

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

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

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

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

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

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

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

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

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

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

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

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

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