Пишу для тех, кто пытается в условиях ограниченного бюджета настроить в коллективе работу с техническим контентом. Расскажу о том, за что хвататься, если ваши разработчики отказываются писать статьи на Хабр за брендированные кружки и звездочки на доске почета. Волшебных ответов на все вопросы не дам. Но попробую подсказать, где может начинаться путь к недорогому корпоративному блогу.

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

Рассказывать о себе можно по-разному. Статьи и корпоративный блог - не единственный путь, но на фоне заказных статей в бумажных изданиях он кажется самым доступным.

С первого взгляда все элементарно: в штате есть толковые специалисты. Плоды их труда принадлежат компании. Почему бы им не написать об этом? Но в списках задач статьи имеют минимальный приоритет, а поэтому ждут своей очереди годами. Очень легко откладывать дело, к которому душа не лежит еще со времен школьных сочинений!

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

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

Смиритесь с тем, что заплатить за контент придется

Подготовка контента стоит денег. Как бы вы не экономили, как бы не привлекали имеющиеся ресурсы, если вы тратите время толкового разработчика на контент, в этот момент его основные задачи простаивают. Даже если вы заплатите ему всего-то брендированной кружкой, в терминах ресурсов компании на создание статьи уйдет приличная сумма - все время написания статьи вы платите ему зарплату.

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

Отталкивайтесь от интересов разработчика

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

Продавать лучше конкретную тему (“Вася, ты лучший в Kafka, расскажи, как ты ее прогнул”). Но на теме и целях я сейчас не буду останавливаться. Предположим, у вас давно что-то есть на примете.

Как именно “продать” - отдельный большой разговор. По факту надо ответить на молчаливый вопрос: “А зачем оно мне?”. Ответы могут быть такие:

• имя под текстом (признание в профессиональном сообществе и, что уж тут скрывать, строчка в будущем резюме);

• интересный пет-проект (если статья пишется на синтетическом примере, чтобы не показывать код реального проекта, его и в GitHub потом можно выложить);

• возможность высказаться на “больную” тему (если специалиста бомбит, но самостоятельно вытащить рассказ из под NDA он не может).

Кружки и футболки в этом контексте - хорошо, но не главное, особенно для занятого человека 30+ с семьей и хобби. Не факт, что и эти ответы помогут. Но они дают подсказку, в каком направлении копать.

Снимите с разработчика неинтересные задачи

Когда идея “продана”, не нужно все скидывать на разработчика. Наоборот, постарайтесь максимально упростить ему жизнь, не заставляя писать текст с нуля, думать над планом и заниматься прочими литературными экспериментами.

Редакции журналов давно научились не мучить экспертов, у которых не хватает времени на полноценные статьи. Вот как выглядит их рабочий процесс (отброшу все, что касается согласования тем и прочей бюрократии):

• интервьюер проводит беседу со специалистом;

• по записи беседы автор пишет текст;

• автор согласует текст с редактором (или заказчиком) - убеждается, что цели, поставленные перед статьей, учтены;

• автор или редактор согласует текст со специалистом;

• текст смотрит корректор.

Здесь всплыло пять ролей: специалист, интервьюер, автор, редактор, корректор. Это не значит, что надо нанять еще четырех человек. Разными наименованиями я лишь отражаю их роли. Возможно, отдельные таланты уже есть у вас в штате. И не обязательно их искать в одном лице.

Ищите того, с кем разработчик будет говорить без негатива

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

Основные усилия стоит направить на поиск специалиста, который в большей степени умеет строить отношения и разговаривать с разработчиками, а уже во вторую очередь работает с текстом. “Разговорить” технаря намного сложнее, чем потом по записи беседы сделать текст. А если вам крайне важно литературное качество, потом можно попросить поработать над ним человека с базой в литературе или журналистике.

Интервьюер (назовем нашего персонажа так, даже если в резюме у него указано “редактор” или “журналист”) должен быть на одной волне с разработчиком или уметь повести разговор так, чтобы его хотелось посвятить в детали. Большинству технарей не нравится, когда интервьюер пытается присвоить себе их знания, подписав итоговую статью своим именем или доказать в процессе беседы, что знает тему лучше. Не зайдет и превращение интервью в экзамен.

Как именно вести беседу и отрабатывать возражения технического специалиста против этого общения - отдельный навык где-то на грани с психологией. За простой образец “как надо” можно взять дружескую беседу в баре, когда один рассказывает другому про интересный проект, а второй подогревает повествование: “Ну ничего себе, вот как бывает? У меня на прошлом проекте было что-то похожее…” (это не единственная расстановка ролей, которая работает; у каждого есть свои любимые подходы).

Может у вас уже есть словоохотливый тестировщик или технический писатель, который уже хорошо контактирует с разработчиками? Из записи его беседы можно сделать неплохой текст.

Текст надо “продать” разработчику и только потом публиковать

Задачу подготовки текста логично кому-то отдать - самому интервьюеру, другому автору или талантливому HR-у. Варианты рабочего процесса могут быть разные. Но мне кажется удобным, когда проводит интервью и пишет статью один и тот же человек. Если опыта достаточно, уже во время беседы он будет понимать, что еще спросить, чтобы повествование получилось взвешенным и интересным.

Главное, что итоговый текст должен принять разработчик - ему же под ним подписываться. А чем ответственнее автор текста подойдет к правкам со стороны разработчика, тем с большей вероятностью последний согласится на повторение эксперимента в будущем.

Не ориентируйтесь на чужие цифры, накапливайте свои

Теперь поговорим о том, что от этой работы получает компания.

Результат проделанной работы должен быть измерим. Но нужно понимать, что и почему вы измеряете. Если вам нужно привлечь релевантных специалистов к своим вакансиям, измеряйте количество правильных откликов, а не просмотры статьи в первые дни. Автоматически такие цифры собирать сложно. Но иначе вы не увидите реальную картину.

Поясню на примере, о чем речь.

Предположим, вы хотите нанять спецов по редкому языку программирования.

Первый подход. Вы пишете статью про особенности найма, в конце которой указываете, что работаете с этим языком. В первые дни статью прочитает 5-10 тысяч пользователей - темы найма и карьеры популярны на Хабре. Статистика корпоративного блога будет “зеленой”. Но какая доля читателей будет знакома с этим языком? Пришлют ли они резюме? Без измерения количества откликов этой информации у вас не будет.

Популярная тема быстро “провалится” в хвост поиска. Если вы не раскрыли в тексте что-то принципиально новое (желательно с ключевыми словами), уже через пару недель поток читателей иссякнет. Если изначально поток входящих запросов кандидатов на вакансии все-таки был, он сократится.

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

Эти два случая специально немного утрированы. В реальном мире вам предстоит искать свой баланс между охватом и релевантностью аудитории. Но из сравнения подходов видно, что количество просмотров в первые дни слабо связано с тем, насколько хорошо решена первоначальная задача. Более того данные о просмотрах статей в первом и во втором случаях нельзя сопоставить между собой. Объективно сравнить подходы можно лишь через оценки количества откликов на вакансии и качества кандидатов, раз уж они были целью.

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

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

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