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