Автоматизация журналиста. Часть 2. Работаем со спикерами30.03.2020 07:33

Первую часть статьи ищите тут. Во второй части рассказываю о том, какие я использую инструменты при взаимодействии со спикерами.

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

Общение — далеко не первая стадия подготовки текста. Поэтому вначале небольшое лирическое отступление о рабочем процессе.

Timeline подготовки статьи

При создании почти любого текста моего профиля можно выделить такие вехи:

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

Выше прописан некий идеализированный процесс. По факту он иногда выворачивается наизнанку, но в целом те же шаги остаются, даже если они не формализованы.

К примеру, если работаешь с корпоративным блогом, одна из основных задач — обеспечить входящий поток внутренней экспертизы, т.е. очередь желающих «написать» статью (поучаствовать в ее написании в роли спикера). Как это делается — разговор отдельный, но по факту редактор блога (а иногда и технический журналист, если все в одном лице) выстраивает какие-то отношения с техническими специалистами — источниками экспертизы. Если процесс идет хорошо, с идеями приходят сами специалисты. И тогда работа стартует где-то в районе 4 пункта, а первые 3 редактору/журналисту приходится додумывать на ходу, чтобы выбранная спецом тема оказалась полезна для заказчика.

Допустим приходит к тебе лучший переворачивальщик пингвинов и говорит, что выявил тенденцию, что хромых пингвинов с желтым пятном на ноге приходится переворачивать чаще. И это революция в отрасли, потому что проще им сразу маячки повесить, чем каждый раз обход устраивать. Задача редактора / журналиста — придумать, как эта тема может быть «наложена» на ранее заявленные высокоуровневые задачи и на какой площадке ей лучше появиться. То есть 1–3 пункты списка не отсутствуют, просто они реализуются несколько в ином порядке.

Обычно работа идет над десятком статей параллельно. Каждая из них находится на своем этапе. И каждая из статей у меня — это ровно одна запись в RTM, которая со временем просто эволюционирует. У записи меняются теги, добавляются ссылки и текстовая информация в заметки и т.п. Когда статья выпущена, задача в RTM закрывается, а статья переходит в архив, о котором буду говорить в следующий раз.

Возвращаясь к сегодняшней теме — мы говорим о пункте 5 и о том, что здесь получилось или не получилось автоматизировать.

Инструменты общения

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

Я много сталкивалась с редакциями, которые отдают интервью на аутсорсинг — пишут список вопросов и отправляют кого-то менее «дорогого» (в терминах «рубли в час») по этому списку говорить. На мой взгляд, интервью в технических статьях — та вещь, которую нельзя отдавать на сторону. Предварительные вопросы почти всегда плохо раскрывают тему. Сами посудите: вам надо спросить о том, о чем вы пока знаете только из общих публикаций в Интернете… при этом надо вытащить уникальный опыт конкретного человека, о котором точно нигде ничего не написано. В ходе беседы приходится использовать весь свой предыдущий опыт, чтобы прямо на ходу уточнить тему, раскрыть те интересные моменты, которые вдруг всплыли. Иначе к спикеру придется возвращаться не один раз, а не все специалисты это любят.

Детали общения важны, поэтому я стараюсь записывать 100% интервью и совещаний. Арендованное облако особо «карман не тянет» и место в квартире не занимает, так что я могу хранить аудиозаписи чуть ли не всей своей трудовой деятельности. Естественно, я стараюсь предупреждать спикеров о том, что ведется запись. Иногда они и сами спрашивают, кто из нас будет писать.

Главная сложность записи заключается в зоопарке инструментов общения. Команды и отдельные спикеры, с которыми я работаю, используют для созвонов Slack, Hangouts, Telegram, Skype (или Skype for Business, который мне доступен только через веб-плагин), Zoom, Viber, WhatsApp и даже ВКонтакте с Facebook. Некоторые до сих пор пользуются обычным телефоном. Далеко не все из перечисленных инструментов позволяют «из коробки» писать звонки.

Для подстраховки возможных неприятных ситуаций у меня настроена запись везде, где только можно — это и есть основная часть автоматизации:

Смартфон пишет звонки по нажатию кнопки (с некоторых номеров, откуда мне чаще всего «прилетают» задачи, пишет всегда — проще раз в 3–4 месяца очистить хранилище, чем потом вспоминать детали задачи, сформулированной где-то в середине разговора на отвлеченную тему).
Skype в прошлом году наконец-то реализовал запись созвонов внутри системы, и я ей активно пользуюсь. Жаль, нельзя писать Skype Out.
Для прочих мессенджеров у меня настроен софт, который пишет все, что происходит на компьютере. Софт запускается вручную, иногда глючит, поэтому советовать конкретный инструмент не буду.
При личных интервью использую диктофон на телефоне.

До недавнего времени у меня даже была арендована виртуальная АТС с городским номером — тоже ради записи звонков. Пользовалась ей, когда Skype отключил внешние плагины для записи, а свой еще не запустил. Большая часть звонков у меня в тот период была по Skype Out на межгород, так что по сути я просто временно сменила поставщика услуг.

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

Сбор записей

Полностью автоматизировать сбор записей в хранилище мне пока так и не удалось.

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

Со смартфона записи важных разговоров приходится сразу отправлять вручную на Яндекс.Диск или себе же на почту (в зависимости от количества и размера файлов). Из Skype, опять же, вручную приходится скачивать записи на комп и заливать в нужную папку на Яндекс.Диске. Skype вообще не позволяет автоматизировать процесс.
Софт для записи экрана со звуком сам складывает записи в нужное место, и это единственная доступная мне автоматизация.

Интервью, которые сейчас в работе, я сваливаю в папку Dropbox внутри Яндекс.Диска. Яндекс.Диск я использую уже пару лет для передачи файлов между всеми рабочими местами. А «облако в квадрате» (Dropbox внутри Яндекса) нужно, чтобы обеспечить протоколирование работы. Яндекс.Диск не умеет интегрироваться с IFTTT, но не отказываться же от него из-за этого. Года 2 назад я и так почти месяц перевозила терабайт данных с зарубежного облака на Яндекс… тогда задачи протоколирования еще не было, но я не хочу повторять переезд только из-за нее (и в остальном Яндекс меня устраивает). Dropbox же у меня был зарегистрирован для взаимодействия с одним из заказчиков, так что я задействовала его для настройки протоколирования.

Зачем нужно протоколирование?

Когда количество дел не зашкаливает, ссылку на файл я прикрепляю к задаче в RTM — в центре хранения таких сущностей, как «статьи в работе». Если по каким-то причинам я этого сразу не сделала, потом приходится разыскивать нужные файлы. Я настроила все свои средства записи так, чтобы они добавляли в название файлов дату и время звонка, а также контакт собеседника (например, номер мобильного телефона). Так что поиск сводится к выявлению даты звонка. Контакт собеседника использовать получается не всегда, поскольку иногда мы переключаемся между инструментами. Но дата и время при этом остаются те же.

Чтобы упростить поиск, я сделала через IFTTT отдельный календарь-журнал, в который автоматом пишется:

информация обо всех дальних выездах. Фиксируется момент выезда из определенного периметра и въезда в него при помощи Android-смартфона. Забыть о заранее запланированных визитах в чей-то офис сложно, тем более эта встреча остается в обычном календаре. Так что информация сохраняется с другой целью: часто на выезды накладываются созвоны, и я это хорошо запоминаю. Т.е. я помню, что мне с пару недель назад пришлось экстренно искать тихое кафе для беседы или парковаться в неожиданном месте, чтобы поговорить из машины, и по календарю-журналу могу восстановить точную дату и время. По этим параметрам легко найти нужный файл записи.
отметки о разговорах, сохраненных в Dropbox. Когда файл добавляется в папку, IFTTT делает отметку в календаре и кидает ссылку на этот файл. Так если смотреть на основной календарь и календарь-журнал одновременно, можно установить однозначное соответствие файла записи и прошедшего в определенный день созвона.

Несмотря на эти «протокольные сложности», я все же стараюсь вручную подвязывать интервью к RTM сразу после разговора. Это быстрее, чем потом вести «поиск с собаками».

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