- PVSM.RU - https://www.pvsm.ru -
Первую часть статьи ищите тут [1]. Во второй части рассказываю о том, какие я использую инструменты при взаимодействии со спикерами.
Если сильно упростить, то задача технического журналиста — достать некий уникальный опыт (понимание в определенной технической области) из головы профильного специалиста и представить его в простой для освоения определенной читательской аудиторией форме. Можно долго рассуждать о публикациях по открытым источникам и из головы, но в реальности технический журналист за редким исключением не является специалистом в той области, о которой пишет. А даже если он специалист, то некоторые моменты неплохо бы пойти и у кого-то уточнить. Значит в любом случае нужна чья-то экспертиза. Степень простоты последующего изложения зависит от читателей. И я, кстати, искренне считаю, что в авторские права на тот самый опыт должны оставаться за специалистом, иначе он второй раз просто откажется общаться с журналистом…
Общение — далеко не первая стадия подготовки текста. Поэтому вначале небольшое лирическое отступление о рабочем процессе.
При создании почти любого текста моего профиля можно выделить такие вехи:
Выше прописан некий идеализированный процесс. По факту он иногда выворачивается наизнанку, но в целом те же шаги остаются, даже если они не формализованы.
К примеру, если работаешь с корпоративным блогом, одна из основных задач — обеспечить входящий поток внутренней экспертизы, т.е. очередь желающих “написать” статью (поучаствовать в ее написании в роли спикера). Как это делается — разговор отдельный, но по факту редактор блога (а иногда и технический журналист, если все в одном лице) выстраивает какие-то отношения с техническими специалистами — источниками экспертизы. Если процесс идет хорошо, с идеями приходят сами специалисты. И тогда работа стартует где-то в районе 4 пункта, а первые 3 редактору/журналисту приходится додумывать на ходу, чтобы выбранная спецом тема оказалась полезна для заказчика.
Допустим приходит к тебе лучший переворачивальщик пингвинов и говорит, что выявил тенденцию, что хромых пингвинов с желтым пятном на ноге приходится переворачивать чаще. И это революция в отрасли, потому что проще им сразу маячки повесить, чем каждый раз обход устраивать. Задача редактора / журналиста — придумать, как эта тема может быть “наложена” на ранее заявленные высокоуровневые задачи и на какой площадке ей лучше появиться. То есть 1-3 пункты списка не отсутствуют, просто они реализуются несколько в ином порядке.
Обычно работа идет над десятком статей параллельно. Каждая из них находится на своем этапе. И каждая из статей у меня — это ровно одна запись в RTM, которая со временем просто эволюционирует. У записи меняются теги, добавляются ссылки и текстовая информация в заметки и т.п. Когда статья выпущена, задача в RTM закрывается, а статья переходит в архив, о котором буду говорить в следующий раз.
Возвращаясь к сегодняшней теме — мы говорим о пункте 5 и о том, что здесь получилось или не получилось автоматизировать.
С выбором времени для интервью мы разобрались в прошлый раз. После устной договоренности создается встреча в Календаре, которая заранее отрабатывает напоминаниями и копируется куда следует. В половине ситуаций (в зависимости от стиля общения со спикером) я стараюсь подтверждать разговор примерно за сутки до назначенного времени, а то всякое бывает.
Я много сталкивалась с редакциями, которые отдают интервью на аутсорсинг — пишут список вопросов и отправляют кого-то менее “дорогого” (в терминах “рубли в час”) по этому списку говорить. На мой взгляд, интервью в технических статьях — та вещь, которую нельзя отдавать на сторону. Предварительные вопросы почти всегда плохо раскрывают тему. Сами посудите: вам надо спросить о том, о чем вы пока знаете только из общих публикаций в Интернете… при этом надо вытащить уникальный опыт конкретного человека, о котором точно нигде ничего не написано. В ходе беседы приходится использовать весь свой предыдущий опыт, чтобы прямо на ходу уточнить тему, раскрыть те интересные моменты, которые вдруг всплыли. Иначе к спикеру придется возвращаться не один раз, а не все специалисты это любят.
Детали общения важны, поэтому я стараюсь записывать 100% интервью и совещаний. Арендованное облако особо “карман не тянет” и место в квартире не занимает, так что я могу хранить аудиозаписи чуть ли не всей своей трудовой деятельности. Естественно, я стараюсь предупреждать спикеров о том, что ведется запись. Иногда они и сами спрашивают, кто из нас будет писать.
Главная сложность записи заключается в зоопарке инструментов общения. Команды и отдельные спикеры, с которыми я работаю, используют для созвонов Slack, Hangouts, Telegram, Skype (или Skype for Business, который мне доступен только через веб-плагин), Zoom, Viber, WhatsApp и даже ВКонтакте с Facebook. Некоторые до сих пор пользуются обычным телефоном. Далеко не все из перечисленных инструментов позволяют “из коробки” писать звонки.
Для подстраховки возможных неприятных ситуаций у меня настроена запись везде, где только можно — это и есть основная часть автоматизации:
До недавнего времени у меня даже была арендована виртуальная АТС с городским номером — тоже ради записи звонков. Пользовалась ей, когда Skype отключил внешние плагины для записи, а свой еще не запустил. Большая часть звонков у меня в тот период была по Skype Out на межгород, так что по сути я просто временно сменила поставщика услуг.
Одно время я пыталась целиком перейти на эту АТС, чтобы “отвязаться” от мобильного номера. Но ни одно из опробованных смартфонных приложений не показало себя хорошо в условиях плохой связи — а я в таких местах иногда бываю. Плюс мобильный номер мой знает слишком много рабочих контактов. Поэтому арендованный номер дорабатывает последние дни. А вот виртуальная АТС осталась (на всякий случай).
Полностью автоматизировать сбор записей в хранилище мне пока так и не удалось.
Каждый из инструментов для записи сохраняет информацию по-своему. Это вдвойне усложняет жизнь, когда в процессе разговора приходится переключаться между инструментами (сбой интернета — перезваниваешь по телефону). Казалось бы, можно настроить автоматическое копирование всех звонков, но тонны телефонного спама, звонки о переносах интервью и прочие сопутствующие записи быстро наполнят хранилище мусором, так что смысл в нем потеряется.
Со смартфона записи важных разговоров приходится сразу отправлять вручную на Яндекс.Диск или себе же на почту (в зависимости от количества и размера файлов). Из Skype, опять же, вручную приходится скачивать записи на комп и заливать в нужную папку на Яндекс.Диске. Skype вообще не позволяет автоматизировать процесс.
Софт для записи экрана со звуком сам складывает записи в нужное место, и это единственная доступная мне автоматизация.
Интервью, которые сейчас в работе, я сваливаю в папку Dropbox внутри Яндекс.Диска. Яндекс.Диск я использую уже пару лет для передачи файлов между всеми рабочими местами. А “облако в квадрате” (Dropbox внутри Яндекса) нужно, чтобы обеспечить протоколирование работы. Яндекс.Диск не умеет интегрироваться с IFTTT, но не отказываться же от него из-за этого. Года 2 назад я и так почти месяц перевозила терабайт данных с зарубежного облака на Яндекс… тогда задачи протоколирования еще не было, но я не хочу повторять переезд только из-за нее (и в остальном Яндекс меня устраивает). Dropbox же у меня был зарегистрирован для взаимодействия с одним из заказчиков, так что я задействовала его для настройки протоколирования.
Зачем нужно протоколирование?
Когда количество дел не зашкаливает, ссылку на файл я прикрепляю к задаче в RTM — в центре хранения таких сущностей, как “статьи в работе”. Если по каким-то причинам я этого сразу не сделала, потом приходится разыскивать нужные файлы. Я настроила все свои средства записи так, чтобы они добавляли в название файлов дату и время звонка, а также контакт собеседника (например, номер мобильного телефона). Так что поиск сводится к выявлению даты звонка. Контакт собеседника использовать получается не всегда, поскольку иногда мы переключаемся между инструментами. Но дата и время при этом остаются те же.
Чтобы упростить поиск, я сделала через IFTTT отдельный календарь-журнал, в который автоматом пишется:
Несмотря на эти “протокольные сложности”, я все же стараюсь вручную подвязывать интервью к RTM сразу после разговора. Это быстрее, чем потом вести “поиск с собаками”.
Кстати, мне приходилось работать в командах, где информацию об интервью сливают в большую Google Таблицу. И это в моем случае неудобно. В командах дополнительная бюрократия оправдывалась тем, что интервью проводили одни, а тексты писали совсем другие люди. Мне же пришлось построить хранилище иначе. О том, как это у меня работает, расскажу в следующий раз.
Автор: ekatarios
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/kontent/351153
Ссылки в тексте:
[1] тут: https://habr.com/ru/post/489650/
[2] Источник: https://habr.com/ru/post/494644/?utm_source=habrahabr&utm_medium=rss&utm_campaign=494644
Нажмите здесь для печати.