Бесплатная библиотека
Читайте книгу на сайте или телефоне
READ-E-BOOK » Прочая компьютерная литература » Профессия "Технический писатель", или "Рыцари клавиатуры"
Профессия "Технический писатель", или "Рыцари клавиатуры" - Читать Любимую Русскую Полную Книгу 👉 Read-E-Book.com

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

Электронная книга - «Профессия "Технический писатель", или "Рыцари клавиатуры"». Краткое содержание книги:

В книге подробно рассматриваются основные аспекты работы специалиста по техническим текстам — от первых шагов и введения в профессию «технический писатель» до обзора применяемого программного обеспечения и организационных вопросов трудоустройства, включая взаимодействие с зарубежными заказчиками. Также описываются современные тенденции и изменения в профессии. Адресуется тем, кто уже работает «техписом» или ещё только собирается овладеть этой специальностью.
1 ... 23 24 25 26 27 28 29 30 31 ... 56
Перейти на страницу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 ... 23 24 25 26 27 28 29 30 31 ... 56
Перейти на страницу:
0
Сюжет
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Атмосфера
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Главный герой
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
0
Общее впечатление
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
Итоговая оценка: 0.0 из 10 (голосов: 0 / История оценок)