Пишу для тех, кто пытается в условиях ограниченного бюджета настроить в коллективе работу с техническим контентом. Расскажу о том, за что хвататься, если ваши разработчики отказываются писать статьи на Хабр за брендированные кружки и звездочки на доске почета. Волшебных ответов на все вопросы не дам. Но попробую подсказать, где может начинаться путь к недорогому корпоративному блогу.
Кто я и почему говорю на эту тему?
Привет! Я помогаю компаниям писать статьи на Хабр.
Я физик по образованию, но уже 15 лет работаю в технической журналистике. Сотрудничаю с небольшими компаниями, поэтому не могу похвастаться громкими именами партнеров. Зато в бизнесе такого масштаба ты многое решаешь сам. Ты не зажат жесткими корпоративными политиками и схемами работы - можешь экспериментировать и делать выводы.
За это время я успела посмотреть на рынок с разных сторон. Исполняла обязанности пресс-службы и вела сообщества. На фоне этого 12 лет отработала в действующей редакции профиздания. И уже лет пять тесно сотрудничаю с Хабром.
Обычно выступаю от чьего-либо имени, но сегодня говорю от себя, потому что все чаще сталкиваюсь с вопросами от бизнеса, вроде “с чего начать” и “кого нанять” для ведения корпоративного блога. Мой тезис - для небольшой компании в условиях ограниченного бюджета не обязательно бежать в студию. Может у вас уже есть все необходимые специалисты, им просто надо подсказать, в каком направлении двигаться?
Миром правит информация. Если вы запускаете ракеты в космос, но никто об этом не знает, сложно будет нанять лучших инженеров. Непросто будет и клиентов искать.
Рассказывать о себе можно по-разному. Статьи и корпоративный блог - не единственный путь, но на фоне заказных статей в бумажных изданиях он кажется самым доступным.
С первого взгляда все элементарно: в штате есть толковые специалисты. Плоды их труда принадлежат компании. Почему бы им не написать об этом? Но в списках задач статьи имеют минимальный приоритет, а поэтому ждут своей очереди годами. Очень легко откладывать дело, к которому душа не лежит еще со времен школьных сочинений!
Некоторым компаниям удается выстроить внутри процесс подготовки публикаций или находить деньги на содержание собственной редакции. А что делать, если это не про вас?
Ниже я дам несколько советов, которые помогут переосмыслить ситуацию и понять, с какого конца подойти к решению этой задачи.
Смиритесь с тем, что заплатить за контент придется
Подготовка контента стоит денег. Как бы вы не экономили, как бы не привлекали имеющиеся ресурсы, если вы тратите время толкового разработчика на контент, в этот момент его основные задачи простаивают. Даже если вы заплатите ему всего-то брендированной кружкой, в терминах ресурсов компании на создание статьи уйдет приличная сумма - все время написания статьи вы платите ему зарплату.
Нанять кого-то, чтобы он сформулировал технически сложную концепцию вместо разработчика, не получится. Нельзя просто открыть чужой код и волшебным образом сообразить, что произошло и какие можно сделать выводы. Настолько же глубоко погруженный в тему сторонний человек будет стоить соизмеримо с разработчиком, а то и дороже. Помножьте это на риски ошибок найма и сложности шаринга знаний. Встает вопрос - зачем платить за стороннюю экспертизу, если есть своя?
Отталкивайтесь от интересов разработчика
Признайтесь себе в том, что хотите построить маркетинг или стратегию найма на экспертизе конкретного человека. Можно долго спорить о том, кто имеет право ее использовать, но нужные знания лежат в его голове. Придется плясать под его “дудку”. Поэтому начать придется с “продажи” идеи написания статьи.
Продавать лучше конкретную тему (“Вася, ты лучший в Kafka, расскажи, как ты ее прогнул”). Но на теме и целях я сейчас не буду останавливаться. Предположим, у вас давно что-то есть на примете.
Базовый совет про выбор темы
Если нет четкой стратегии последовательных касаний аудитории и бюджет ограничен, ориентируйтесь на долгоиграющий контент. Хорошая статья съест много времени на подготовку. Чтобы эти вложения принесли максимальную пользу, надо пытаться продлить жизнь контента. Тут многое определяет выбор темы. Не стоит гнаться за сиюминутным хайпом. Выбирайте то, что будет интересно через месяц или год. Рассказывайте об интересных внутренних проектах, о нестандартных решениях проблем, о подходах.
Как именно “продать” - отдельный большой разговор. По факту надо ответить на молчаливый вопрос: “А зачем оно мне?”. Ответы могут быть такие:
имя под текстом (признание в профессиональном сообществе и, что уж тут скрывать, строчка в будущем резюме);
интересный пет-проект (если статья пишется на синтетическом примере, чтобы не показывать код реального проекта, его и в GitHub потом можно выложить);
возможность высказаться на “больную” тему (если специалиста бомбит, но самостоятельно вытащить рассказ из под NDA он не может).
Кружки и футболки в этом контексте - хорошо, но не главное, особенно для занятого человека 30+ с семьей и хобби. Не факт, что и эти ответы помогут. Но они дают подсказку, в каком направлении копать.
Снимите с разработчика неинтересные задачи
Когда идея “продана”, не нужно все скидывать на разработчика. Наоборот, постарайтесь максимально упростить ему жизнь, не заставляя писать текст с нуля, думать над планом и заниматься прочими литературными экспериментами.
Редакции журналов давно научились не мучить экспертов, у которых не хватает времени на полноценные статьи. Вот как выглядит их рабочий процесс (отброшу все, что касается согласования тем и прочей бюрократии):
интервьюер проводит беседу со специалистом;
по записи беседы автор пишет текст;
автор согласует текст с редактором (или заказчиком) - убеждается, что цели, поставленные перед статьей, учтены;
автор или редактор согласует текст со специалистом;
текст смотрит корректор.
Здесь всплыло пять ролей: специалист, интервьюер, автор, редактор, корректор. Это не значит, что надо нанять еще четырех человек. Разными наименованиями я лишь отражаю их роли. Возможно, отдельные таланты уже есть у вас в штате. И не обязательно их искать в одном лице.
Ищите того, с кем разработчик будет говорить без негатива
Первый порыв - найти человека, который хорошо работает с текстом. Но из воздуха он текст взять не может. Если разработчики сами не бегут к вам с набросками статей, считайте, что редактировать этому персонажу нечего.
Основные усилия стоит направить на поиск специалиста, который в большей степени умеет строить отношения и разговаривать с разработчиками, а уже во вторую очередь работает с текстом. “Разговорить” технаря намного сложнее, чем потом по записи беседы сделать текст. А если вам крайне важно литературное качество, потом можно попросить поработать над ним человека с базой в литературе или журналистике.
Литературная обработка нужна, но не критична
Нужно всегда понимать, для какой аудитории вы пишите. Задайте себе вопрос: для чего вы заставляете разработчика выкладывать экспертизу в статью (а ведь мы говорим только об этом узком случае писательства)? Чтобы повысить узнаваемость компании среди таких же разработчиков и клиентов от бизнеса? Для этой аудитории суть важнее литературной красоты. Начиная с определенного уровня качества текста затраты на литературную обработку уже не окупятся.
Интервьюер (назовем нашего персонажа так, даже если в резюме у него указано “редактор” или “журналист”) должен быть на одной волне с разработчиком или уметь повести разговор так, чтобы его хотелось посвятить в детали. Большинству технарей не нравится, когда интервьюер пытается присвоить себе их знания, подписав итоговую статью своим именем или доказать в процессе беседы, что знает тему лучше. Не зайдет и превращение интервью в экзамен.
Как именно вести беседу и отрабатывать возражения технического специалиста против этого общения - отдельный навык где-то на грани с психологией. За простой образец “как надо” можно взять дружескую беседу в баре, когда один рассказывает другому про интересный проект, а второй подогревает повествование: “Ну ничего себе, вот как бывает? У меня на прошлом проекте было что-то похожее…” (это не единственная расстановка ролей, которая работает; у каждого есть свои любимые подходы).
Может у вас уже есть словоохотливый тестировщик или технический писатель, который уже хорошо контактирует с разработчиками? Из записи его беседы можно сделать неплохой текст.
Текст надо “продать” разработчику и только потом публиковать
Задачу подготовки текста логично кому-то отдать - самому интервьюеру, другому автору или талантливому HR-у. Варианты рабочего процесса могут быть разные. Но мне кажется удобным, когда проводит интервью и пишет статью один и тот же человек. Если опыта достаточно, уже во время беседы он будет понимать, что еще спросить, чтобы повествование получилось взвешенным и интересным.
Главное, что итоговый текст должен принять разработчик - ему же под ним подписываться. А чем ответственнее автор текста подойдет к правкам со стороны разработчика, тем с большей вероятностью последний согласится на повторение эксперимента в будущем.
Не ориентируйтесь на чужие цифры, накапливайте свои
Теперь поговорим о том, что от этой работы получает компания.
Результат проделанной работы должен быть измерим. Но нужно понимать, что и почему вы измеряете. Если вам нужно привлечь релевантных специалистов к своим вакансиям, измеряйте количество правильных откликов, а не просмотры статьи в первые дни. Автоматически такие цифры собирать сложно. Но иначе вы не увидите реальную картину.
Поясню на примере, о чем речь.
Предположим, вы хотите нанять спецов по редкому языку программирования.
Первый подход. Вы пишете статью про особенности найма, в конце которой указываете, что работаете с этим языком. В первые дни статью прочитает 5-10 тысяч пользователей - темы найма и карьеры популярны на Хабре. Статистика корпоративного блога будет “зеленой”. Но какая доля читателей будет знакома с этим языком? Пришлют ли они резюме? Без измерения количества откликов этой информации у вас не будет.
Популярная тема быстро “провалится” в хвост поиска. Если вы не раскрыли в тексте что-то принципиально новое (желательно с ключевыми словами), уже через пару недель поток читателей иссякнет. Если изначально поток входящих запросов кандидатов на вакансии все-таки был, он сократится.
Второй подход. Вы пишете статью про использование конструкций этого языка на практике. В первые несколько дней после публикации такой текст на Хабре прочитает от силы тысяча человек - только те, кого интересует сам язык. Статистика в корпоративном блоге автоматом покажет, что это плохой результат. Но если статья действительно полезна, релевантная аудитория будет приходить по поисковым запросам не один год. На статью можно будет ссылаться в разговорах с кандидатами. Возможно, она же обеспечит поток входящих резюме в течение длительного времени (пока язык “на коне”).
Эти два случая специально немного утрированы. В реальном мире вам предстоит искать свой баланс между охватом и релевантностью аудитории. Но из сравнения подходов видно, что количество просмотров в первые дни слабо связано с тем, насколько хорошо решена первоначальная задача. Более того данные о просмотрах статей в первом и во втором случаях нельзя сопоставить между собой. Объективно сравнить подходы можно лишь через оценки количества откликов на вакансии и качества кандидатов, раз уж они были целью.
Аналогично не стоит сравнивать свои данные о просмотрах с чьими-то еще или со средней статистикой площадки. В первом случае неизвестно, какая задача решалась и какие получены результаты (данные никто не публикует). А во втором цифра - лишь средняя температура по больнице.
Из этого можно сделать вывод, что цифры по одной единственной опубликованной статье дадут вам мало информации. Поэтому совершенствуя корпоративный блог, готовьтесь к пути экспериментов - к постоянному соревнованию не с чужими, а со своими результатами.
Напоследок напомню, что речь идет о блогах, а не о создании профессионального контента. Крупные компании вкладывают в это много сил и времени, поднимая планку ожидаемого читателем качества. Но совершенно не обязательно с ними соревноваться. Главное, чтобы в создаваемом контенте был смысл.
