Через технический блог можно работать с разными задачами бизнеса: рассказывать о сложном B2B-продукте аудитории, которая способна его оценить, привлекать специалистов в команду, показывать техническую экспертизу компании.

Но на практике быстро возникает другая проблема:

Кто будет всё это писать?

Обычно организацией блога занимается маркетинг. А дальше есть два распространённых сценария.

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

Сценарий 1. «Пусть пишут разработчики»

Логично попросить написать статью человека, который сам создавал продукт, строил архитектуру или решал описываемую проблему.

С технической экспертизой всё отлично.

Со временем хуже.

У тимлида идёт спринт. У разработчика горит релиз. DevOps разбирается с инфраструктурой. У тестировщика свой бэклог.

А где-то рядом лежит задача «написать статью на Хабр».

Угадайте, какая задача будет переноситься первой.

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

Причём написать статью мало. Нужно придумать подачу, выстроить материал, объяснить контекст человеку, который не работал над проектом, убрать лишнее, оформить публикацию.

Техническая экспертиза сама по себе не делает человека техническим автором. Как и умение писать статьи не превращает автора в инженера.

Сценарий 2. Нанять копирайтера или агентство

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

По крайней мере, так выглядит план.

Проблема начинается, когда автору дают действительно техническую тему.

Чтобы написать материал, ему сначала нужно объяснить предмет. Потом рассказать, как устроена система. Потом ответить на дополнительные вопросы. Потом прочитать черновик.

А иногда ещё объяснить, почему написанное технически невозможно.

В результате CTO, архитектор или Senior-инженер получает вторую работу: быть техническим консультантом при авторе.

Компания платит за статью, а значительную часть работы над ней всё равно делает её технический специалист.

Можно сократить техническую проверку и публиковать материал как есть.

На Хабре это рискованный эксперимент.

Читатели быстро замечают, когда человек не понимает технологию, о которой пишет. Особенно хорошо это становится видно в комментариях, где за один вечер могут спросить обо всём, что автор предусмотрительно обошёл в статье.

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

Есть третий вариант

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

Меня зовут Анна Гамгия. Я технический специалист и автор на Хабре.

Я беру на себя ведение технических блогов IT-компаний: от задачи и контент-плана до готовых публикаций и анализа того, как они работают.

Но главное отличие моей работы не в этом.

Мне не нужен инженер, который будет фактически писать статью моими руками.

Если материал строится на уникальном опыте компании, я разговариваю с вашим специалистом именно об этом опыте.

Что произошло? Почему выбрали такое решение? Какие варианты рассматривали? Где возникли проблемы? Что пришлось переделать? Что получили в результате?

Мне не нужно сначала объяснять, что такое API, зачем нужен CI/CD или чем микросервисная архитектура отличается от монолита.

Эксперт даёт мне то, чего нет больше ни у кого: опыт вашей компании.

Всё остальное — моя работа.

А если эксперта можно вообще не отвлекать, я его не отвлекаю

Не каждая техническая статья требует интервью.

Если в теме можно разобраться самостоятельно, я разбираюсь самостоятельно: документация, код, окружение, инструменты, эксперименты.

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

Я нашла реальную обученную модель, датасет и сохранённые метрики. Разобралась с её артефактами. Нашла проблему: из самих данных невозможно восстановить часть требований, необходимых для нормального тестирования.

В результате я разработала собственный QA framework, написала автоматизированные тесты и проверила его на реальной модели.

После этого написала статью.

Это мой обычный подход: сначала разобраться и проверить, потом рассказывать другим.

Кто я и почему могу работать с вашими инженерами

В IT я с 2006 года.

Начинала с технической поддержки бухгалтерского ПО. Работала в 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