Клуб технических писателей

Technical Writing 101: как общаться с разработчиком

Пономарева Вера
11 марта 2015, 15:54
Технический писатель — профессия многогранная. Тут нужно не только уметь писать, разбираться в предмете, но еще и много общаться, чтобы добыть необходимую информацию. Иногда именно эта часть работы оказывается самой кропотливой.
Несколько советов о том, как найти подход к разработчику, от авторов уже знакомой книги "Technical writing 101":
  1. Учитывайте график разработчика. Звоните и приходите в удобное время. Если разработчик предпочитает общаться по почте, пишите письма (даже если сидите в одной комнате).
  2. Не задавайте вопросы по одному. Накапливайте и отправляйте списком.
  3. Научитесь читать код и извлекать из него информацию.
  4. Не задавайте глупых вопросов — сначала попытайтесь найти ответ самостоятельно.
  5. Облегчите жизнь разработчику: вставляйте ваши вопросы в текст документа крупным жирным шрифтом.
  6. Оставаясь вечером на работе, поделитесь пиццей!
  7. Организуйте вычитку таким образом, чтобы каждый разработчик вычитывал свою часть документа.
  8. Кексы. Много кексов!
  9. Посещайте регулярные встречи проекта, чтобы быть в курсе происходящего.
  10. Если ничего не помогает, выходите за него замуж! (Хотя, и это вряд ли поможет.)
На самом деле, в книжке опубликован список из 29 пунктов, я привожу сокращенную версию.
Интересно, а как по вашему опыту — что помогает лучше всего? Предлагаю поделиться собственными наблюдениями и историями.
9 комментариев
Подписаться на комментарии к посту

Если разрабочик избегает разговора систематически и целенаправленно, то на него можно натравить руководство.

Я бы рекомендовал не прибегать к этому способу вообще. Ибо можно получить в лице этого разработчика врага на всю жизнь :)

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

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

При чем, как показывает опыт, это делать одинаково удобно и эффективно, как с разработчиками, находящимися за несколько тысяч километров от тебя, так и с теми, кто сидит в соседнем кабинете )

Практика показывает, что живое общение существенно эффективнее скайпа/видеосвязи. Например, с точки зрения фокусировки внимания собеседника или возможности совместно посмотреть код/распечатку. Я бы рекомендовал прибегать к искуственным способам коммуникации только в случае крайней необходимости. 

Ну и никто не мешает записывать разговор (разумеется, заранее предупредив об этом собеседника) и во время очной ставки.

Каждому свое. Моя интровертская натура отлично справляется со скайп-интервью уже более 3 лет. "И не единого разрыва" :) Кому-то, конечно, будет проще и удобнее общаться лично.

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

Пометки по тексту удобно, но такая форма общения может очень на долго затянуться. 

Я обычно делаю пометки и формирую список вопросов со ссылкой на эти пометки (Дока в Conflunce). 

Беседу с разработчиком записывайте на диктафон. Если, конечно, разработчик не возражает. Тогда будет возможность еще раз в спокойной обстановке прослушать ответы и не задать "глупых вопросов" в следующем заходе беседы.