Как запустить успешный блог на Хабре: кейс мобильного разработчика Redmadrobot

Какую пользу бизнес может получить от корпоративного блога на Хабре, о чем писать и почему это должны делать сами сотрудники компании.

В 2014 году я пришла в Redmadrobot, компанию по разработке мобильных решений для бизнеса, тогда PR-подразделение активно развивало направление контент-маркетинга, включая блог на Хабрахабре. В 2016 году блог стал лучшим в категории “Мобильная разработка” по версии самого Хабра. Чтобы добиться такого результата, мы по сути создали внутри компании мини-редакцию: за два года силами команды и штатного редактора было выпущено почти 90 статей, тексты для блога написали более 30 сотрудников и многие не по одному разу. Но чтобы научиться делать хороший контент для этой площадки и начать получать отдачу, пришлось поэкспериментировать. Ниже расскажу, как мы работали с блогом Redmadrobot, и какой это принесло результат.

Хабрахабр — крупнейший в рунете профессиональный ресурс для IT-специалистов с аудиторией более 8 миллионов уникальных пользователей в месяц. Хабр читают программисты, продуктовые менеджеры, аналитики, дизайнеры и другие люди, причастные к миру технологий. При этом как те, кто давно строит карьеру в отрасли, так и начинающие, например, студенты. Для компании Хабр — инструмент построения репутации в профессиональном сообществе, продвижения технической и продуктовой экспертизы и поддержания диалога с IT-комьюнити. Если бизнес связан с технологическими продуктами или сервисами, а компании важен вес в профессиональной среде, активность на Хабре может стать подходящим инструментом для приобретения этого веса. Спектр тем очень широк, от языков программирования до управления продуктом. Redmadrobot делает мобильные приложения, поэтому в своей контентной стратегии мы в первую очередь фокусировались на iOS- и Android-разработчиков, и во вторую на всех остальных.

У PR-службы компании был журналистский бэкграунд, и к запуску блога на Хабре мы подходили как к медиапроекту. За его развитие взялся редактор, на несколько месяцев вперед был составлен контент-план с разноплановыми блоками материалов. Первая версия плана преимущественно состояла из придуманных самим редактором тем: серьезные “технарские” тексты соседствовали с историями легкого околотехнологического характера — обзоры книг, интервью с людьми из мира технологий, отчеты с конференций.

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

По читательскому фидбэку мы быстро поняли, что для “легких” текстов без очевидной практической ценности Хабр не подходящая площадка — на них реагировали нейтрально, а порой и откровенно негативно. Однажды в блоге появился не совсем технический и не совсем полезный текст “Гэнгбэнг, белковое окно и покер с балеринами: офисный словарь Роботов”, который, по правде сказать, изначально писался для рубрики “Офисный словарь” на Look at Me, но она некстати закрылась. Итог — нулевой рейтинг поста и целый веер комментариев в стиле “Что и зачем я только что прочитал?“. Стало очевидно, что читатели ждут технического “хардкора”, а не развлечений, и главным критерием выбора тем должна стать практическая ценность для IT-специалиста.

Если редактор не является по совместительству программистом-практиком, вероятность того, что он сам сможет придумать и “раздать” разработчикам темы, стремится к нулю. Так мы взяли на вооружение планерки с участием редактора, iOS- и Android-разработчиков и других членов команды. На этих встречах в режиме мозгового штурма все вместе генерировали темы будущих статей. Иногда они появлялись ситуативно, например, в привязке к большим обновлениям мобильных платформ всегда выкатывается много нового для девелоперов, и это интересно разобрать по горячим следам. Но большая часть тем рождалась из боевого опыта — архитектурные подходы, собственные библиотеки, применение различных инструментов и технологий в конкретных проектах. Каждую идею, которая претендовала на воплощение в статье, разработчики выносили на обсуждение и совместно решали, достаточно ли она актуальна и интересна для сообщества. Впредь все контент-планы составлялись при непосредственном участии сотрудников.

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

Со временем у нас появилось несколько регулярных форматов: кейсы реализации собственных проектов, обзоры профессиональных инструментов, разбор новых технологий в разработке и советы по их практическому применению, отчеты с крутых профессиональных конференций, дизайн-концепты приложений и многое другое. В помощь сотрудникам мы написали памятку с советами по критериям выбора темы, этапам написания, структуре и тону статьи. Если вы подойдете к разработчику с предложением написать статью, то в ответ часто услышите “Я не знаю, о чем писать. Да мы же ничего необычного не сделали”. Крутой программист подходит и к чужой, и к собственной работе с супер высокими стандартами, и это хорошо. Но часто самыми полезными оказываются не тексты про написанный с нуля сложнейший алгоритм, а простая и внятная инструкция, как работать с существующими на рынке технологиями.

Например, две статьи с практическими советами по работе с системой сборки Android-проектов Gradle суммарно собрали более 66 000 просмотров. Обзор инструмента для мониторинга HTTP/HTTPS трафика Charles, который используют QA-инженеры компании, прочитали более 47 000 раз, а статью про рабочий инструментарий бизнес-аналитика 39 000 раз. Текст основателя Redmadrobot Макса Волошина о его собственном способе организации личной базы знаний в Evernote получил 70 000 просмотров. У текста креативного директора Redmadrobot Макса Десятых про Material Design более 285 000 просмотров, и их число продолжает расти. Ссылка стабильно выходит второй или третьей в выдаче Google по запросу “material design”, cтатью “украли” и перевели на английский язык, и английскую версию тоже уже прочитали 45 000 раз. Две статьи архитектора компании Егора Тафланиди про архитектурный дизайн мобильных приложений суммарно получили свыше 125 000 просмотров, и их по-прежнему читают каждый день. Тексты, опубликованные более двух лет назад, продолжают работать, так как они по-прежнему полезны.

Штатный редактор в IT-компании — это еще и глубоко интегрированный в команду менеджер-коммуникатор, который должен помогать “вынимать” контент из недр компании и превращать экспертизу коллег в качественные тексты. В целом редактор отслеживал каждый материал на трех этапах: тема, план, готовая статья. Но так как тексты писали не профессиональные авторы, работа с каждым строилась индивидуальным образом. Кто-то пишет идеальные статьи, которые вообще не требуют правок, а с кем-то нужно засесть на несколько часов, чтобы вместе продумать план и содержание каждого пункта. Добрых 90% постов в блоге Redmadrobot — глубоко технические. С одной стороны, разработчики отлично понимают в предмете, о котором пишут, не склонны “лить воду”, и это в некотором смысле облегчает работу редактора. Усложняет ее то, что редактор-гуманитарий априори не сможет разобраться в теме так же глубоко, как автор-технарь. Тем не менее, редактор должен быть способным въехать в текст на таком уровне, чтобы помочь с корректировкой плана, указать на недостаток фактуры, дать советы и внести правки по форме, не исказив смысл. Залог успеха технического текста на выходе — очень плотная коммуникация редактора и автора.

В определенный момент необходимость в специальных встречах по придумыванию тем по сути отпала — сотрудники стали сами регулярно приходить и предлагать идеи статей. Для IT-специалиста (да и в принципе любого профессионала) написание статьи — это challenge, возможность разложить накопленный опыт по полочкам в собственной голове, донести его до команды, представить на суд коллегам по цеху, обменяться с ними мнением и заполнить раздел “Публикации” в своем CV. А постинг на Хабре это еще и автоматом прямой доступ к многотысячной аудитории. В мире мобильной разработки технологии обновляются с огромной скоростью, и обмен практическим опытом — один из драйверов развития глобального девелоперского сообщества. Каждый разработчик чувствует свою причастность к этому сообществу, что само по себе является мотивацией делиться экспертизой, поэтому почти все писали для Хабра с большим энтузиазмом.

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

Читатели Хабра придирчивые и требовательные — если на многих площадках “недокрученный” материал простят, на Хабре на это можно даже не надеяться. За “воду”, бесполезную или плохо поданную информацию вас тут же заминусуют и засыпят уничижающими комментариями. Большую часть потенциальных конфликтных ситуаций с аудиторией можно избежать на этапе подготовки: если текст полезный и написан нейтральным тоном, он будет принят положительно. Впрочем, решив рассказать на Хабре о собственном проекте, надо быть готовым к тому, что в нем будут искать баги, задавать хитрые вопросы и придираться к коротким тире вместо длинных.

Посты даже про такие проекты, которыми разработчики могут по праву гордиться, почти всегда собирали сколько-то критических комментариев — и по делу, и нет. Тут на помощь приходят здравый смысл и юмор. Хабр — это про профессиональную дискуссию и обратную связь. Мы не “кормили троллей”, но конструктивную критику или вопросы никогда не оставляли без ответа. В конечном счете именно в читательском фидбэке ключ к тому, как сделать блог максимально интересным.

За два с лишним года посты Redmadrobot набрали более 1,5 млн просмотров, и их число продолжает расти. Построение репутации и продвижение экспертизы компании — дело не одного дня, и эффект для бизнеса тоже можно оценить не сразу. Подтверждение такого отложенного эффекта пришло в недавнем исследовании об известности российских iOS- и Android-команд, которое особенно ценно, поскольку проводилось разработчиками среди разработчиков. В нем по силе девелоперских команд впереди только Яндекс, по интересности задач Redmadrobot оставил позади Тинькофф, Рокетбанк, Mail.ru Group, Касперского, Avito, СберТех и Rambler&Co, и компания оказалась третьей по привлекательности работы в ней после Яндекса и Avito.

Заработанное в сообществе доверие мы конвертировали в программу стажировок для разработчиков, которые анонсируются эксклюзивно через Хабр. При среднем наборе в 15 слушателей на каждую стажировку приходит от 200 до 400 заявок в первые 2-3 дня. Лучшие стажеры получают приглашение на работу.

Для Redmadrobot блог на Хабре вышел за рамки технического пиара и стал, во-первых, открытой площадкой, где сотрудники могут попробовать себя в роли авторов и поделиться знаниями и опытом с IT-сообществом, а во-вторых, лицом в клиентской среде. Ведь экспертиза компании — это не нечто абстрактное, она складывается из компетенций конкретных людей, которые в ней работают. От клиентов часто приходит фидбэк в стиле “Видели ваш кейс про разработку чат-бота для ‘Открытия’. Запилите нам такой же?”

Конечно, Хабр — только один из каналов коммуникации, который подходит не каждому бизнесу. Вы постоянно развиваете свои технологии и продукт? У вас есть экспертиза, которая будет ценной для IT-сообщества? Вы сможете обеспечить регулярное наполнение блога? Вы готовы инвестировать в него денежные и человеческие ресурсы? Если ответ на все вопросы утвердительный, то пробуйте и экспериментируйте.