Я давно пишу и редактирую технические статьи. Пять лет был главным редактором блога Онтико на Хабре. Делаю контент для научно-технических журналов, сайтов, рассылок, консультирую авторов и деврелов, и недавно меня попросили помочь с памяткой для авторов о том, как подготовить статью для корпоративного блога на Хабре. Я решил начать с открытых источников и очень удивился, когда понял, что структурированной информации на эту тему мало. Если загуглить, появляется несколько статей, но те, кто их писал, как будто нахватались по верхам: взяли переведённый опыт иностранных копирайтеров и разбавили правилами «Пиши, сокращай». Всё это, конечно, приносит пользу, но не даёт понимания того, с какой стороны подступиться к написанию статьи.

Например, если начать с самого начала и задуматься о том, где взять идею для технической статьи, то интернет даст следующие рекомендации:

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

2. Раскрыть рабочие процессы команды, технологии, инструменты и методы, поделиться полезными советами и рекомендациями, чтобы решить насущные проблемы целевой аудитории.

3. Проанализировать новости или тренды индустрии, сделать свои прогнозы, чтобы показать экспертный уровень.

4. Написать гайд для помощи пользователям или заказчикам компании.

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

Поскольку поиск идей — это некая абстракция, не ждите чёткой пошаговой инструкции. Попробуем просто нащупать направления, в которых можно двигаться, чтобы ухватить «идею за хвост».

Разбор рекомендаций

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

1. Свой рабочий кейс

Не все разработчики могут похвастаться крутыми кейсами. Большинство выполняет довольно однообразные задачи, похожие друг на друга от компании к компании. По крайней мере, так говорят сами авторы, когда им предлагаешь вспомнить лучший проект. Я провёл десятки интервью и всегда, чтобы завести разговор, спрашивал, в том числе про самые интересные кейсы. Чаще всего интервьюируемые отделывались общими фразами. Даже если такие проекты у них были. Кто-то боялся «сболтнуть» лишнего из-за NDA. Кто-то считал свои достижения незначительными. Кто-то не видел в них практического применения в других компаниях или другими разработчиками. Причин много, и они самые разные.

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

Поэтому, если автор хочет интересно описать проект, стоит начать с вопроса:

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

Ответы могут отличаться.

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

Автор мог прокачать свои софт скиллы, научиться объяснять и отстаивать своё мнение перед командой, переформатировать ТЗ или просто «слышать» коллег.

Вот пример интересного кейса и подхода к решению сложной задачи.

Как только вы найдёте пользу, несите идею статьи деврелу или тимлиду. Нужно удостовериться, что компания разрешит раскрывать внутренние детали проекта. Это очень важная часть. Ведь пытаться разрабатывать идею, делать план статьи и писать черновик абсолютно бессмысленно, если по соображениям безопасности (либо другим причинам) кейс описывать нельзя.

Самые вдумчивые читатели, конечно, спросят: а зачем тратить время на поиск пользы, если статьи в итоге может и не быть. По-моему, такая рефлексия в любом случае полезная штука и помогает лучше понять своё профессиональное развитие и ответить на терзающие всех вопросы: «Зачем я это делаю?», «На том ли месте я нахожусь?», «Тот ли выбор сделал?».

Вывод: ищите пользу. Если вы поняли, что изменилось для вас и коллег — это уже идея для статьи.

2. Рабочие процессы команды, технологии, инструменты и методы

С описанием внутренних процессов, технологий и инструментов всё почти то же самое, что и с кейсами. Разница лишь в том, что кейс должен быть выполнен…

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

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

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

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

Прямо противоположный пример, можно описывать инструмент со стороны большей гибкости и возможностей.

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

3. Новости или тренды индустрии

Сейчас всё слишком быстро меняется. Уследить за новостями, а тем более пропустить их через себя и составить своё мнение очень трудно. Пока вы будете работать над статьей, новость может устареть. Поэтому готовить такую статью надо максимально быстро, либо выбирать тему, «хайп» вокруг которой еще долго не утихнет. Например, обзоры трендов с плюсами и минусами. Такие материалы живут дольше и чаще вызывают дискуссию.

Тут, конечно, возникает огромный соблазн спереть статью из иностранных источников: перевести, обработать ChatGPT, добавить пару предложений «отсебятины» и гордо выпустить в блог. Конечно, вы получите свою «минуту славы». Цель оправдывает средства, если целью было заткнуть дыру в контент-плане или привлечь новых читателей в блог. Но в долгосрочной перспективе постоянные публикации из ворованных новостей пользы не принесут.

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

Конечно, разбор новости требует определенной проработки и погружения в материал. Нужно проверять факты и объективно их описывать, но это всё равно быстрее и проще написания полноценной статьи. А полезную информацию по трендам можно посмотреть на специализированных сайтах. Например, на  TechCrunch (новости стартапов и инноваций), платформа для обсуждения технических новшеств и исследований, информация о новинках компьютерной техники, на том же Хабре.

Вывод: новости — рискованный источник идей, но критика и обзоры трендов приносят больше пользы и дольше сохраняют актуальность.

4. Гайд

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

Статья подразумевает некую историю, состоящую из двух основных частей: проблема — решение проблемы.

А гайд — это правильная последовательность действий, которая приводит к заранее известному результату.

Поэтому, сколько ни описывай, как сделать «вечный двигатель», не прикладывай схемы и состав несуществующих материалов — это не поможет написать гайд по созданию вечного двигателя. А когда вы внедряете инструмент внутри, остаётся ТЗ и куча другой полезной документации, которую можно использовать в статье. Вы на личном опыте утыкаетесь в «подводные камни» и находите свой путь, которым можете поделиться.

Вот пример удачного гайда.

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

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

Где черпать идеи

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

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

У каждого в телефоне есть приложение с заметками, но не все им пользуются. Откройте своё и посмотрите, что там записано. Если пусто, то его можно заполнить прямо на работе.

«Курилка»

Я имею в виду не только огороженное место с пепельницей. Это может быть столовая, куда вы приходите на обед с контейнером или кафешка, угол с кулером или кофемашиной, переговорная, кабинет или комната отдыха. Это может быть общий чат или любое реальное и виртуальное место, где вы собираетесь, чтобы поболтать не только по рабочим вопросам. Там всегда обсуждаются самые «страшные» факапы всех проектов всех отделов, все кривые и нелепые процессы всех подразделений компании. Самые последние новости, в том числе, как быстро и просто установить не работающую на территории РФ нейросеть. Там вам выложат идеи из всех перечисленных выше рекомендаций и порой под таким углом, о котором вы никогда не задумывались. Останется их только зафиксировать и сделать статью. Главное, взять привычку всё записывать, чтобы не забыть. И тогда, пару дней в «курилке» обеспечат вас материалом на полгода.

Обратная связь

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

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

Плагиат

Ещё один неисчерпаемый источник идей, как ни странно — чужие статьи. Если, читая про чужой кейс, вы думаете, что сделали то же самое по-другому и не хуже, а то и лучше. Поздравляю! Считайте, что у вас есть готовая статья. Не надо стесняться брать её за основу, особенно если она хорошо структурирована и логически прописана. Кладите на готовый «костяк» свой собственный путь решения аналогичной проблемы. И можете не волноваться, вы ничего не воруете, вы же описываете свою историю. В литературной среде давно бытует мнение (автор цитаты доподлинно не установлен), что существует всего два сюжета: «незнакомец приезжает в город и герой отправляется в путешествие/на поиски». Всё остальное — интерпретации. Поэтому не стоит придумывать необычную схему, намного продуктивнее взять чужой добротный план статьи и расписать по нему свой путь решения проблемы. Пользы от этого не убавится, скорее наоборот, она только увеличится. Ведь вы не будете тратить время на поиск идеи и проработку плана, а посвятите его самому главному — пользе.

Вывод: идеи вокруг нас. Их много, если привыкнете их записывать и переосмысливать услышанное.

Вместо заключения

Конечно, это не всё. Есть много других вариантов поиска идей: в кулуарах конференций и митапов, в спорах на созвонах и ретро, на форумах и в соцсетях. Идеи можно генерировать из фильмов, передач и музыки. У каждого свой подход. Главное, не забывать их записывать и обдумывать. Возможно, для кого-то (в противовес тому, что писал я) идеи статей могут рождаться даже в маркетинговых показателях… хотя их тоже надо будет провести через свой опыт и практическую пользу.

Делитесь своими вариантами и путями, а я постараюсь подготовить всю памятку для авторов статей от идеи до публикации. В следующей статье напишу, как из идеи составить план статьи.