Первую часть статьи ищите тут. Во второй части рассказываю о том, какие я использую инструменты при взаимодействии со спикерами.
Если сильно упростить, то задача технического журналиста — достать некий уникальный опыт (понимание в определенной технической области) из головы профильного специалиста и представить его в простой для освоения определенной читательской аудиторией форме. Можно долго рассуждать о публикациях по открытым источникам и из головы, но в реальности технический журналист за редким исключением не является специалистом в той области, о которой пишет. А даже если он специалист, то некоторые моменты неплохо бы пойти и у кого-то уточнить. Значит в любом случае нужна чья-то экспертиза. Степень простоты последующего изложения зависит от читателей. И я, кстати, искренне считаю, что в авторские права на тот самый опыт должны оставаться за специалистом, иначе он второй раз просто откажется общаться с журналистом…
Общение — далеко не первая стадия подготовки текста. Поэтому вначале небольшое лирическое отступление о рабочем процессе.
При создании почти любого текста моего профиля можно выделить такие вехи:
Выше прописан некий идеализированный процесс. По факту он иногда выворачивается наизнанку, но в целом те же шаги остаются, даже если они не формализованы.
К примеру, если работаешь с корпоративным блогом, одна из основных задач — обеспечить входящий поток внутренней экспертизы, т.е. очередь желающих “написать” статью (поучаствовать в ее написании в роли спикера). Как это делается — разговор отдельный, но по факту редактор блога (а иногда и технический журналист, если все в одном лице) выстраивает какие-то отношения с техническими специалистами — источниками экспертизы. Если процесс идет хорошо, с идеями приходят сами специалисты. И тогда работа стартует где-то в районе 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 Таблицу. И это в моем случае неудобно. В командах дополнительная бюрократия оправдывалась тем, что интервью проводили одни, а тексты писали совсем другие люди. Мне же пришлось построить хранилище иначе. О том, как это у меня работает, расскажу в следующий раз.
Если сильно упростить, то задача технического журналиста — достать некий уникальный опыт (понимание в определенной технической области) из головы профильного специалиста и представить его в простой для освоения определенной читательской аудиторией форме. Можно долго рассуждать о публикациях по открытым источникам и из головы, но в реальности технический журналист за редким исключением не является специалистом в той области, о которой пишет. А даже если он специалист, то некоторые моменты неплохо бы пойти и у кого-то уточнить. Значит в любом случае нужна чья-то экспертиза. Степень простоты последующего изложения зависит от читателей. И я, кстати, искренне считаю, что в авторские права на тот самый опыт должны оставаться за специалистом, иначе он второй раз просто откажется общаться с журналистом…
Общение — далеко не первая стадия подготовки текста. Поэтому вначале небольшое лирическое отступление о рабочем процессе.
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 Таблицу. И это в моем случае неудобно. В командах дополнительная бюрократия оправдывалась тем, что интервью проводили одни, а тексты писали совсем другие люди. Мне же пришлось построить хранилище иначе. О том, как это у меня работает, расскажу в следующий раз.
