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

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

Откуда брать темы: вопросы, которые звучат до договора

Самый надёжный источник — слова самих заказчиков. Возьмите входящие письма, заявки с формы, записи звонков и заметки после встреч. Выпишите 20–30 вопросов дословно, не переводя их на язык разработки. Заказчик спросит «можно ли не останавливать работу на время перехода», а не «как устроена миграция данных».

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

Какие типы тем подходят компании-разработчику

• Подготовка заказчика. Что нужно собрать и кого назначить ответственным до старта: описание процессов, примеры документов, доступы к действующим системам.
• Сравнение подходов. Готовое решение или заказная разработка, мобильное приложение или адаптивный сайт, доработка старой системы или переписывание. Важно показать, при каких условиях подходит каждый вариант.
• Из чего складываются срок и стоимость. Без цифр, но с перечислением факторов: число ролей пользователей, интеграции, миграция данных, требования к отчётам.
• Интеграции. Как проходит обмен данными с 1С, CRM, платёжными сервисами и какие вопросы нужно выяснить заранее.
• Жизнь после запуска. Поддержка, резервные копии, передача кода и документации, что происходит при смене подрядчика.

Какие темы лучше отложить

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

Пример: как превратить вопрос клиента в страницу

Условный пример. Допустим, в заявках повторяется вопрос: «Заказы у нас ведутся в таблицах Excel. Можно ли перейти на учётную систему, не останавливая отдел продаж?» Из него получается страница с заголовком «Переход с Excel на учётную систему: как не останавливать работу отдела продаж». Структура фрагмента может быть такой:

• Короткий ответ в первом абзаце: да, возможно, если сначала запустить систему параллельно с таблицами на одном потоке заказов. Это не готовые результаты, а описание подхода, который нужно сверить с вашими процессами.
• Что потребуется от заказчика: выгрузить текущие таблицы, назначить ответственного за данные, описать три типичных заказа от обращения до закрытия.
• Этапы перехода: разбор таблиц, пробный перенос части данных, параллельная работа, переключение.
• Что чаще всего мешает: дубли клиентов, разные форматы дат и телефонов, поля с примечаниями вместо отдельных данных.
• Когда переносить не всё: архив старых заказов иногда разумнее оставить в таблицах для чтения.
• Следующий шаг: форма с тремя вопросами (сколько сотрудников работают с таблицами, есть ли связанные системы, к какой дате нужен результат).

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

Как проверить тему, прежде чем писать

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

Проверочный список для каждой идеи

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

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

Все статьи блога