Привет! Меня зовут Паша Стрельченко, я — Android-разработчик в hh.ru. Впрочем, сегодня я буду выступать в качестве проджект-менеджера нашего техбренда. Официально, конечно, у нас такой должности нет, да и деврелов тоже. В общем, справляемся своими силами.
В этой статье расскажу о том, как мы создаем техбренд на примере нашего видеопроекта на YouTube “Охэхэнные истории”. Объясню, через какие стадии проходят наши выпуски, как мы их визуализируем, как управляем, а еще поделюсь парочкой кулстори. Запасайтесь чаем, контента будет много.
Что нужно знать для начала
Чтобы понять, как мы управляем нашим техбрендом, нужно понимать всего две вещи:
"Жизненный цикл" наших выпусков.
Как его визуализировать и как им управлять.
С позиции зрителя, вы можете наблюдать лишь три стадии, через которые проходят наши выпуски:
Релиз видео на крупные медиа-площадки: Youtube, Яндекс.Дзен, VK.
Выход статьи на Хабр.
Публикация перевода на Medium.
Первичным в большинстве случаев у нас является именно видеоконтент, затем на его основе мы пишем статью на Хабр, а потом делаем перевод этой статьи на Medium. Но иногда случаются некоторые перестановки, и сначала появляется статья, а уже потом видео.
А вот чего вы не видите, так это одиннадцать промежуточных статусов, про которые я сегодня и расскажу. Все они делятся на три больших флоу:
От идеи до релиза видео — самый долгий флоу.
От релиза видео до публикации на Хабр.
От публикации на Хабр до перевода на Medium, что считается конечной остановкой для выпуска.
От идеи до видео
Бэклог и согласование
Первый статус в этом флоу называется “бэклогом”. Сюда попадают не до конца оформленные идеи с туманным будущим: неясно кто и когда будет их воплощать.
Как выглядит такой бэклог?
Но в этом статусе у нас выпуски не задерживаются, потому что темп выхода новых эпизодов у нас довольно жесткий – мы публикуем новые выпуски раз в неделю, по пятницам. Следовательно, когда мы придумываем какую-то классную идею, то стараемся как можно скорее дотащить её до согласования и подготовки. Что и приводит нас ко второму статусу — “согласование доклада”.
Пример согласованных докладов
В этот статус попадают выпуски, у которых уже как минимум утверждена тема и известны ответственные — те, кто будет заниматься этим выпуском.
В этом статусе выпуски могут проводить долгие месяцы, поскольку мы считаем развитие техбренда рабочей активностью, которую нужно согласовывать. С интересами компании, с рабочей нагрузкой на команды, с личными особенностями участников и спикеров. В этом статусе я порой просто пингую людей в заранее оговоренное время, мол, мы вас ждем, давайте начинать полноценную подготовку доклада.
Пингуешь людей?
Мы всё ещё обсуждаем этот доклад, пытаемся вытащить на свет интересную тему для доклада.
Подготовка доклада
Если звёзды сошлись благоприятно, у команды появляется время на подготовку выпуска, а человеку выделяют время на техбренд, выпуск переходит на следующую стадию — "Подготовка доклада".
На этой стадии человек должен подготовить нам структуру будущего выпуска. Структура доклада — это просто хорошо расписанный каркас будущего выступления, из которого должно быть понятно о чём именно собирается рассказывать спикер.
Фишка структуры доклада заключается в том, что по ней в 90% случаев можно понять, насколько качественным получится будущий рассказ. А также есть ли в нем логические дыры, чего не хватает и сколько он будет длиться по времени.
Кроме того, по такой структуре легко готовить презентации, потому что она уже разбита на какие-то секции, блоки, подблоки и каждый из них может быть отдельным слайдом.
Чтобы оценить качество доклада и его логику, необязательно быть широко осведомленным в теме выпуска. Даже Android-разработчик способен понять, насколько адекватно выглядит рассказ про Data Science, чего не хватает в докладе про микрофронтенды и какие вопросы вызовет выпуск про GraphQL.
Пример структуры для рассказа о Compose-е
Вот пример плохой структуры:
Почему плохо – слишком мало деталей, неясно вообще о чём будет разговор, будет ли он последовательным, о чём вообще этот доклад?!
А вот пример структуры получше:
Здесь структура уже чуть более информативна, однако всё ещё недостаточно. Из неё вроде бы понятно, что за чем будет следовать, но содержание и смысл рассказа всё ещё ускользают. Для такой структуры просто нужно больше детализации внутри каждого раздела.
А теперь пример адекватной структуры, которую можно дальше брать в работу:
Здесь есть чёткие блоки рассказа, понятны логические переходы, рассказ не выглядит слишком долгим или коротким, каждый блок можно дополнительно раскрыть, чтобы получить более интересное повествование.
Структура не должна быть чересчур лаконичной, ведь тогда будет сложно оценить логическую связь между блоками, но в то же время она не должна быть и слишком подробной, чтобы человек не потратил неоправданно много времени на подготовку структуры. Самая лучшая структура — та, по которой можно рассказать всё выступление, не имея под рукой ничего, кроме неё.
На данном этапе мы вообще не трогаем "контент" доклада: картинки, скринкасты, презентации. Всё это нужно, чтобы не отпугнуть человека на самом старте подготовки. И когда наконец-то структура готова, можно двигаться к подготовке съемок.
Подготовка к съёмкам
Итак, структура выпуска готова и провалидирована кем-то кроме меня, и теперь нужно убедиться, что человек способен рассказать весь этот доклад на камеру. Для этого мы просим коллегу подготовить асинхронный прогон. Он открывает какую-нибудь программу, вроде Zoom или Microsoft Teams, рассказывает весь доклад “от и до”, записывает на камеру и отправляет нам.
Асинхронные прогоны
В моём календаре периодически можно увидеть такие вот встречи:
По таким записям многое становится понятно: где-то не хватает бодрости, где-то мемасика, тут нет логической связки между блоками, а вот здесь было бы здорово вставить какую-то картинку. При этом спикер действительно тренируется: впервые он произносит весь свой контент “от и до”, а это невероятно важно. Мы редко отправляем людей сразу на съемки после подготовки структуры. Довольно часто просим что-то доработать и доработки могут занять абсолютно разное время.
Обратная связь
После обратной связи спикеры корректируют свой рассказ и доклады получаются живее и интереснее! Или нет.
Как только мы понимаем, что кандидат готов, узнаем ближайшую дату съемки и отправляем человека записываться. Таким образом выпуск переходит в следующий статус — "Съёмка". Очень важно не затягивать переход из одного статуса другой, чтобы спикер не растерял энтузиазм и интерес к процессу.
Организация съёмок с моей стороны выглядит так
Мы стараемся подгадывать съемки сразу нескольких выпусков к одному и тому же дню. Вы даже не представляете, насколько спокойнее, когда после съемок у вас есть контент сразу на несколько недель вперед.
Монтаж видео
После окончания съёмок режиссёр присылает исходники видео, звукорежиссёр — черновые звуковые дорожки, а мы переводим выпуск в статус "Есть исходники".
Есть исходники
В этой колонке выпуски могут меняться местами: выпуск, который мы сняли раньше других, не обязательно выйдет раньше. Мы можем ротировать наши эпизоды, всё довольно гибко.
Наступает этап монтажа — последнего статуса перед релизом выпуска, и этот этап самый сложный. Монтажер присылает спикеру так называемый "черновик" — это просто весь отснятый нами материал со всеми дублями, косяками и прочими прелестями.
Файлы нарезок
В черновиках часто можно найти что-нибудь забавное: вот вы видели когда-нибудь коллегу-CTO, приговаривающего "По кочкам, по кочкам, по маленьким дорожкам, в ямку — БУХ!"? А я видел.
Этот черновик мы обычно отсматриваем в два этапа: сначала выкидываем всё лишнее, а затем наращиваем мясо на выпуск – добавляем картинки, надписи, анимации, код, скринкасты. Словом, всё то, что делает выпуск настоящим техническим докладом.
Файлы правок
Типичный файл с правками - большая excel-таблица с таймкодами, где мы указываем что надо вырезать, что надо добавить, где нужно вставить переходы.
Пока эпизод готовится, мы дополнительно делаем еще много разных вещей — готовим анонс, обложку, полезные ссылки и теги и превьюшку. Для анонса мы обычно берем вступление из самого доклада, отправляем его нашему редактору, тот всё красиво исправляет и получается хороший текст. Для упоротых картинок у нас есть специальный человек, которому мы накидываем свои идеи, кратко говорим о чём этот выпуск, а дальше вы видите то, что видите.
Анонсы и обложки
Наш редактор — очень креативный человек. Каждую неделю он ухитряется придумывать прикольные обложки, главное накидать ему идей:
И вуаля:
Для гифок-превьюшек нашему монтажёру нужна обложка и надписи, которые обязательно нужно вставить в небольшую анимацию. Дальше он уже сам развлекается и создает ту красивую превьюшку, которую вы можете увидеть у нас в телеге.
Гифки получаются сочными и красивыми
В каждом выпуске мы придумываем забавные подписи для спикера, которые вы, вероятно, видели в наших интро. По теме и тону выпуска обычно понятно, где можно скаламбурить. “Компоуз” – значит будет композитор, “готовим MVI” – повар, что-то связанное со скоростью – шумахер, дизайнер против разработчика – Саб-зиро и Скорпион. И так далее.
А покажи подписи!
Для полезных ссылок и тэгов мы напрягаем участников выпуска, потому что они точнее понимают релевантную аудиторию своего выпуска и знают, что ей может оказаться полезным.
Под каждым выпуском на YouTube можно увидеть что-нибудь полезное
Этап монтажа, пожалуй, самый нервный и долгий в подготовке нового выпуска, он практически всегда идет впритык к дате выхода. Очень часто мы получаем “голдовую” версию видоса ночью в пятницу, потому что правки прислали вечером в четверг, и у монтажера невероятно мало времени на подготовку. На моей памяти у нас было, кажется, только два или три выпуска, которые мы успели сделать сильно заранее.
Релиз видео
И вот, наконец, наступает последний этап первого флоу — непосредственно "релиз". У нас готовы видео, обложка, анонс, теги, превью, осталось только залить всё это дело на YouTube и добавить пост в отложку в Telegram.
У нас в wiki есть целая статья о том, как правильно готовить новый релиз, как залить новое видео на YouTube, какие кнопки нажимать, про что нельзя забывать.
Что у нас там в wiki
Говоря про целый гайд о создании выпуска "Охэхэнных историй", я ни капли не преувеличиваю, мы написали подробное руководство для тех, кто хочет участвовать в этом проекте:
И в последнем шаге у нас есть небольшая инструкция о том, как правильно заливать видео на YouTube. Это не так тривиально, как кажется!
Хорошо, что можно легко перетаскивать настройки из одного видео в другое.
В конце мы благодарим всех спикеров наших “Охэхэнных историй”. Люди самостоятельно проводят гигантскую работу, а мы обязательно предлагаем людям возвращаться. И многие приходят снова, с новыми докладами и идеями.
Всегда говорим "Спасибо"
Помимо обычной благодарности мы каждую неделю меняем аватарку нашего чатика, добавляем героев в "Аллею славы":
От релиза видео до статей
Здесь гораздо меньше этапов, чем в прошлом флоу. Сначала мы отправляем видео на расшифровку и переводим выпуск в статус "Идёт транскрибация".
Редактор получает расшифровку, формирует из этого связный текст, иногда добавляет свои фирменные мемасики и отправляет разработчику на валидацию (статус "Нужны правки"). Тот, в свою очередь, создает черновик на Хабре, исправляет технические термины, вставляет в статьи кусочки кода, в общем, делает всё необходимое, а затем отправляет черновик редактору.
Прислали черновик статьи, пора работать
Редактор финально вычитывает статью и ставит её в отложку. После этого мы пишем анонс в телегу. На этом флоу Хабра закончен и выпуск попадает в статус "Релиз на Хабре".
Примерно то же самое происходит и для релиза статьи на Medium, только мы добавляем этап перевода (статус "Идёт перевод"). Берем статью и отправляем переводчикам. Они скидывают нам переведенный текст (статус "Нужны ENG-правки"), мы его вычитываем, исправляем ошибки, создаем черновик на Medium, публикуем и снова пишем пост в отложку телеги. Для превью и обложки меняются только надписи. После этого выпуск завершает свой жизненный цикл и мы оставляем его в покое.
Работа с переводами
Визуализация жизненного цикла выпусков
Для визуализации всей информации о выпусках мы сделали большую доску в Miro, на которой есть два основных элемента – календарь и kanban-доска.
Наша большая доска в Miro
С непривычки разобраться непросто, зато когда разберёшься, всё становится удобным.
В календаре мы отмечаем все планы по нашим выпускам: когда выйдет видео, когда статья, перевод, даты слотов записи в офисе, митапы (домашние и гостевые), даты важных конференций и многое другое.
Чуть приблизим календарь
На календарике мы используем специальную цветовую схему для выделения интересующих нас статусов:
Красными стикерами помечаем планы на статьи для Хабра или Medium-а.
Синие стикеры – готовые статьи.
Оранжевые – планы на релизы видео.
Зелёные – готовые видео.
Жёлтые – публичные выступления на конференциях, митапах, etc.
Голубые – организация наших собственных митапов / активностей с аудиторией (например, розыгрыш билетов на Mobius).
Чёрные стикеры – слоты на запись в офисе, даты к которым нужно готовить спикеров.
Длинные полоски на календаре – интересующие нас конференции (их должно быть горааааздо больше!).
На kanban-доске отображаем статусы выпусков и перетягиваем карточки из одной колонки в другую. С каждой карточкой у нас связаны все полезные ссылки по текущему выпуску: на черновик сценария, правки, видео, статью на Хабр, черновик перевода и так далее. А еще на каждой карточке стоят теги, которые указывают, какое техническое направление готовило этот выпуск — Android, iOS, бэкенд, фронтенд, дизайн etc. Там же у нас тег человека в телеге, имя спикера, ответственного за выпуск.
Что за Kanban-доска?
Каждая колонка - это статус выпуска, в нужные моменты мы перетягиваем выпуски между статусами или меняем карточки местами, изменяя их приоритет.
Так у нас получилась удобная для визуализации схема, а при взгляде на доску можно легко охватить всю необходимую информацию.
На доске есть ещё много интересного
В левом нижнем углу всё ещё остались результаты брейншторма названия нашего подкаста, в нижней части доски - куча разрозненных идей разных выпусков, в правой части - блок со ссылками на все необходимые кусочки техбренда, и много-много ещё чего есть на этой доске.
Как мы управляем выпусками
Несмотря на то, что вся необходимая для управления информация находится в Miro, для каждого выпуска мы все равно создаём задачу в Jira. Это нужно не столько для меня, как проджект-менеджера, сколько для управления ожиданиями моих коллег, которые строят планы на разработчиков. Наш рабочий день обычно начинается с Jira, поэтому очень удобно на общей доске видеть связанную с техбрендом карточку, чтобы понимать: разработчик сегодня занимается новым выпуском, значит его лучше лишний раз не дергать.
Небольшой кусочек из Jira
Раз в две недели мы встречаемся с тимлидами основных направлений — QA, backend, frontend, mobile, data science. По итогам этой встречи мы наполняем календарик и колонку бэклога или согласования доклада. Далее мы стараемся работать по типичному kanban-у — стараемся вытаскивать верхние карточки до итогового состояния. Например, чтобы взять в перевод следующий статью, мы тащим самую верхнюю карточку, а не рандомную из середины.
Для всех обсуждений у нас есть специальный телеграм-канал, куда подключены все наши подрядчики — режиссер, монтажер, звукорежиссер, редактор и все спикеры.
Кусочек переписки нашего чата
Каждую пятницу мы пишем для них "ЦУ" — планы для монтажера и редактора, что им предстоит сделать на следующей неделе. Я персонально пингую коллег, ведь нужно знать заранее, готовы ли они заниматься на следующей неделе переводом, статьей или выпуском. И если нет – быстренько пытаемся переиграть планы, ведь всё довольно гибко. При необходимости также пингуем организаторов, чтобы нам запланировали съемки в офисе.
Как выглядят "ценные указания"
Каждую пятницу я смотрю на календарик и Kanban-доску. Благодаря тэгам и колонкам, я понимаю, кого именно мне надо пингануть, кто планирует готовить статью или видео на следующей неделе, так что мне остаётся только написать им и напомнить про те или иные вещи:
Перед релизом я уточняю статусы у всех участников процесса. Важно понимать, насколько готовы выпуск или статья. Если что-то не получается, мы оперативно связываем людей между собой, пытаемся исправить ситуацию, подхватываем и ищем решения возможных проблем. В этом чатике у всех выключены уведомления, потому что читать поток спама каждый день – просто нереально. Когда необходимо – пингуем всех персонально, чтобы сообщение точно достигло цели.
Персональные пингования
Всё это помогает нам поддерживать тот темп выпусков, который изначально казался нам просто нереальным.
А почему всё не в Jira?
Удобно ли нам хранить всю информацию в Miro, а часть из нее дублировать в Jira? Разумеется, нет. В самом начале работы над "Охэхэнными историями" мы задумывались о том, как будем визуализировать процессы и управлять всей этой информацией.
И так вышло, что в нашей Jira нет плагина с календарём, а иметь его очень хотелось, поскольку он позволяет легко визуализировать все будущие планы. Тогда я сразу подумал про Miro. К тому моменту мы уже сильно привыкли к этому продукту, строили там планы, схемы, брейнштормили, в общем, проводили довольно много времени. Решили там и остаться. Однако стоит заметить, что в самом начале процесс работы над выпусками был гораздо более хаотичным. До канбан-доски со статусами мы додумались далеко не сразу.
Изначально мы пытались переносить информацию о статусах выпуска в Jira. Вместо того, чтобы сделать отдельный проект бренда со своим флоу со всеми нужными статусами-колонками, мы пытались встроить флоу техбренда в флоу разработки.
Поэтому у нас появилась специальная задача-шаблон на выпуск влога с пятью подзадачами. Каждая из них обозначала статус, в котором находится выпуск. Идея заключалась в том, что человек копирует к себе эту задачу со всеми связями, меняет исполнителя на самого себя и по мере продвижения будет переводить подзадачи в статус “closed”. Так мы будем понимать, что очередной этап работы над выпуском закончен.
Как это выглядело
У нас до сих пор существует шаблон задачи на выпуск влога, хотя он и претерпел некоторые изменения:
Но буквально несколько месяцев назад эта задача включала в себя несколько подзадач, обозначающих статусы:
Но поскольку создавать задачу и переводить на себя все эти связи – неудобно, мы даже написали небольшую автоматизацию. Человек приходил на CI-сервер, нажимал кнопочку, вводил название своего выпуска и для него разом создавалось шесть стандартных задач.
Автоматизации? Серьёзно?..
Когда какая-то рутинная работа тебя отвлекает - пора писать автоматизацию!
Долгое время мы так и жили. Создавали задачи в огромных количествах, меняли статусы, но в какой-то момент я заметил, что единственный человек, который меняет статусы подзадач – это я сам. А разработчики этого не делают, потому что неудобно и вообще легко забыть.
Так что мы просто отпилили все подзадачи и теперь клонируем один единственный шаблончик, в котором надо просто написать тему выпуска, на кого он рассчитан и когда планируется съемка.
Есть подозрение, что рано или поздно мы совсем уйдем от Miro. Либо в Jira, либо в какой-нибудь другой сервис, потому что нам адски не хватает автоматизации. Хочется, например, не вручную пинговать народ по пятницам, а чтобы это происходило автоматически. Но пока что API у Miro не позволяет получить информацию о виджетах календаря, поэтому мы просто не можем достать всю необходимую информацию для пингования.
Немного о чемпионстве
В самом начале я сказал, что у нас нет отдельных проджекта и деврела, целенаправленно занимающихся техбрендом. Зато у нас есть ЧЕМПИОНЫ. Я вот, например, чемпион по техбренду.
Чемпионы в hh.ru – это разработчики, которые занимаются развитием определенного направления в компании. Оно может быть как техническим, например, внедрить или поресёрчить какую-то технологию, так и продуктовым, например, улучшить работу с аналитикой для всего проекта.
И вот чемпион по техбренду – это как раз проджект и деврел в одном флаконе. В роли проджект-менеджера я составляю графики выхода выпусков, статей, переводов, слежу за сроками, связываю нужных коллег друг с другом, вовремя пингую народ, оформляю симпатичные отчеты после каждого месяца работы техбренда, в общем, занимаюсь такой организаторской деятельностью.
А в роли деврела мотивирую людей выступать, помогаю с составлением структуры, просматриваю предварительные прогоны, редактирую черновики, сам нередко выступаю и пишу какие-то сценарии, подхватываю людей etc.
А действительно ли нужен какой-то отдельный человек, который будет этим заниматься? Вот само по себе оно может работать или нет? Мне кажется, кто-то точно должен быть ответственным. Без надежного бро-координатора и крепкого плеча многие разработчики просто забрасывают свои наработки по техбренду на полпути и не доводят их до конца. Либо делают не такой качественный контент, как хотелось бы.
И про проджект-менеджмент тоже не стоит забывать. Если вовремя не пингануть людей или не описать планы для подрядчиков, в какой-то момент можно просто остаться без выпуска или статьи.
Откуда берёте людей и темы?
Вопрос, который нам часто задают – “откуда у вас столько людей, которые хотят заниматься техбрендом?”
Здесь работа ведется по всем фронтам. Во-первых, мы сделали техбренд частью рабочего процесса. У каждого технического портфеля в чек-листе есть специальный пункт о том, чтобы разработчик хотя бы подумал, можно ли на основе этого портфеля сделать выступление на конференции или написать статью на Хабр. И если да — это потенциальный кандидат для нашего влога.
Кусочек описания портфеля
Каждый разработчик, декомпозируя задачу, как минимум задумывается, можно ли что-то рассказать о её результатах кому-нибудь вне компании.
Во-вторых, мы периодически ходим на демки к разным командам. И если видим там что-то интересное и крутое, обязательно убеждаем коллег выступить спикером наших “Историй”. Многие соглашаются.
В-третьих, тимлиды разговаривают с разработчиками и предлагают им выступать в техбренде. И, опять же, желающих довольно много!
В-четвертых, разработчики видят, что коллеги, у которых они и не подозревали блогерских талантов, неожиданно выступают на YouTube. Да не просто, а в классной студии со связным рассказом, всё это выглядит стильно, лайки сыпятся, комментарии пишутся. В общем, это работает.
К тому же, у нас хорошо налажены все процессы: за год накопился определенный опыт, поэтому все этапы подготовки выпуска стали гораздо более спокойными и стабильными. Многие разработчики просто приходят к нам сами.
Подводим итоги
Вот и всё, что я могу на данный момент рассказать вам о процессе работы над нашими выпусками. Я рассказал о том, какой путь проходят наши выпуски от идеи до релиза, как мы визуализируем нашу работу и как организуем весь процесс.
Если у вас будут какие-то вопросы к нам, не стесняйтесь, пишите в комментариях, обсудим.
