Технический блог на Хабре без нагрузки на команду разработки
Для IT-компании Хабр может быть полноценным каналом работы с профессиональной аудиторией. Хабр читают разработчики, тестировщики, DevOps-инженеры, тимлиды, архитекторы, CTO и руководители технологических компаний.
Через технический блог можно работать с разными задачами бизнеса: рассказывать о сложном B2B-продукте аудитории, которая способна его оценить, привлекать специалистов в команду, показывать техническую экспертизу компании.
Но на практике быстро возникает другая проблема:
Обычно организацией блога занимается маркетинг. А дальше есть два распространённых сценария.
И оба требуют от технической команды гораздо больше времени, чем кажется в начале.
Сценарий 1. «Пусть пишут разработчики»
Логично попросить написать статью человека, который сам создавал продукт, строил архитектуру или решал описываемую проблему.
С технической экспертизой всё отлично.
У тимлида идёт спринт. У разработчика горит релиз. DevOps разбирается с инфраструктурой. У тестировщика свой бэклог.
А где-то рядом лежит задача «написать статью на Хабр».
Угадайте, какая задача будет переноситься первой.
Даже если инженер всё-таки садится писать, компания использует часы дорогого технического специалиста не для разработки продукта, а для производства контента.
Причём написать статью мало. Нужно придумать подачу, выстроить материал, объяснить контекст человеку, который не работал над проектом, убрать лишнее, оформить публикацию.
Техническая экспертиза сама по себе не делает человека техническим автором. Как и умение писать статьи не превращает автора в инженера.
Сценарий 2. Нанять копирайтера или агентство
Теперь писать будет профессиональный автор, а инженеры смогут заниматься своей работой.
По крайней мере, так выглядит план.
Проблема начинается, когда автору дают действительно техническую тему.
Чтобы написать материал, ему сначала нужно объяснить предмет. Потом рассказать, как устроена система. Потом ответить на дополнительные вопросы. Потом прочитать черновик.
А иногда ещё объяснить, почему написанное технически невозможно.
В результате CTO, архитектор или Senior-инженер получает вторую работу: быть техническим консультантом при авторе.
Компания платит за статью, а значительную часть работы над ней всё равно делает её технический специалист.
Можно сократить техническую проверку и публиковать материал как есть.
На Хабре это рискованный эксперимент.
Читатели быстро замечают, когда человек не понимает технологию, о которой пишет. Особенно хорошо это становится видно в комментариях, где за один вечер могут спросить обо всём, что автор предусмотрительно обошёл в статье.
И если публикация выходит от имени компании, вопросы возникают уже не только к автору.
Есть третий вариант
Найти человека, которому не нужно выбирать между умением писать и пониманием технологий.
Меня зовут Анна Гамгия. Я технический специалист и автор на Хабре.
Я беру на себя ведение технических блогов IT-компаний: от задачи и контент-плана до готовых публикаций и анализа того, как они работают.
Но главное отличие моей работы не в этом.
Мне не нужен инженер, который будет фактически писать статью моими руками.
Если материал строится на уникальном опыте компании, я разговариваю с вашим специалистом именно об этом опыте.
Что произошло? Почему выбрали такое решение? Какие варианты рассматривали? Где возникли проблемы? Что пришлось переделать? Что получили в результате?
Мне не нужно сначала объяснять, что такое API, зачем нужен CI/CD или чем микросервисная архитектура отличается от монолита.
Эксперт даёт мне то, чего нет больше ни у кого: опыт вашей компании.
А если эксперта можно вообще не отвлекать, я его не отвлекаю
Не каждая техническая статья требует интервью.
Если в теме можно разобраться самостоятельно, я разбираюсь самостоятельно: документация, код, окружение, инструменты, эксперименты.
Например, для статьи о тестировании готовых ML-моделей мне понадобилось разобраться, как QA вообще может тестировать модель, которую он не обучал.
Я нашла реальную обученную модель, датасет и сохранённые метрики. Разобралась с её артефактами. Нашла проблему: из самих данных невозможно восстановить часть требований, необходимых для нормального тестирования.
В результате я разработала собственный QA framework, написала автоматизированные тесты и проверила его на реальной модели.
Это мой обычный подход: сначала разобраться и проверить, потом рассказывать другим.
Кто я и почему могу работать с вашими инженерами
Начинала с технической поддержки бухгалтерского ПО. Работала в QA и аналитике. Получила профильное образование по специальности «Прикладная информатика в экономике» в СибГУТИ.
Сейчас занимаюсь техническими статьями и собственными проектами.
Мои основные темы — QA, разработка, инфраструктура и AI/ML.
Я могу читать техническую документацию, работать с API, базами данных и кодом, поднимать окружение, разбираться с CI/CD и инфраструктурой, тестировать системы и самостоятельно исследовать новую для меня технологию.
Мне не обязательно заранее быть экспертом именно в вашем продукте.
Мне нужно быть достаточно технически подготовленной, чтобы самостоятельно в нём разобраться.
Что я беру на себя
Сначала мы определяем, зачем компании вообще нужен Хабр.
Продажи сложного B2B-продукта требуют одного контента. Найм разработчиков — другого. Работа на узнаваемость среди определённой технической аудитории — третьего.
Под эту задачу я выстраиваю работу с блогом:
Стратегия и контент-план. Определяю направления, ищу темы и планирую публикации не сами по себе, а относительно задачи компании.
Работа с экспертами. Если для материала нужен внутренний опыт, провожу интервью и собираю необходимую техническую фактуру.
Самостоятельное исследование. Если тему можно исследовать без участия команды, работаю с документацией, кодом, инструментами и другими первичными источниками сама.
Подготовка статьи. Из собранного материала делаю полноценный технический текст для Хабра.
Публикация. Готовлю материал к выходу и публикую его на площадке.
Работа с комментариями. После публикации слежу за обсуждением и работаю с вопросами читателей.
Аналитика. Смотрю не только на просмотры, но и на то, как публикации работают относительно задачи, ради которой компания ведёт блог.
В результате компании не приходится каждый месяц заново решать:
«О чём писать? Кто напишет? Кого из инженеров опять отвлечь? Почему статья всё ещё лежит в черновиках?»
Примеры моих публикаций
«Протестировать ML? Чё-то слишком широко берём»: как я собрала QA framework для готовых моделей
Для материала я взяла реальную ML-модель и датасет, исследовала артефакты, сформулировала требования к тестированию и разработала собственный framework с автоматизированными проверками.
«Куда на самом деле попадает секрет при сборке Docker-образа: разбираем 8 способов»
Для статьи я собрала восемь Docker-образов, передала секрет разными способами и проверила, что в каждом случае остаётся в слоях и метаданных образа. Материал подготовлен для корпоративного блога FirstVDS.
«Личный CI/CD за один вечер: настраиваем GitLab Runner на собственном VPS»
Для материала я развернула GitLab Runner на VPS и собрала рабочий CI/CD-пайплайн с Docker Registry, кэшированием, настройкой безопасности и автообновлением. Статья подготовлена для корпоративного блога FirstVDS.
«Что на самом деле происходит в комнате с пирамидками и почему после неё не верят даташитам на микросхемы»
В статье я разобрала, как проходит тестирование радиоэлектроники в безэховой камере: что и как измеряют, откуда берутся расхождения с характеристиками из даташитов и какие проблемы обнаруживаются только во время реальных испытаний.
Обсудить технический блог
Я не беру одновременно много проектов: чтобы писать о продукте компании, в него приходится погружаться.
Если вашей компании нужен технический блог на Хабре, а превращать инженеров в штат авторов не хочется, со мной можно связаться:
Почта: a.gamgia@yandex.ru
Telegram: https://t.me/AriaDaTo