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

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

Какие материалы нужны сайту софтверной компании

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

• описание продукта: для кого он, какую задачу решает, чем отличается от ручной работы или от «таблиц»;
• функции в формулировках пользователя («формирует акт за пять минут»), а не названиях модулей из техзадания;
• системные требования, поддерживаемые платформы и браузеры, способы развёртывания (облако, установка у заказчика);
• интеграции: с чем продукт обменивается данными и каким способом;
• условия приобретения в том виде, в каком вы готовы их публиковать: тарифы, модель лицензирования или «цена по запросу»;
• скриншоты, видео, ссылка на демо-доступ;
• документация и API: что остаётся на отдельном ресурсе, а что переносится на сайт;
• кейсы внедрения, реквизиты, команда, каналы поддержки.

Как организовать передачу: один пакет вместо переписки

Заведите общую папку, структура которой повторяет структуру будущего сайта: «Главная», «Продукт А», «Продукт Б», «Цены», «Внедрение», «Поддержка», «О компании», «Контакты». Внутри каждой папки — один текстовый файл на страницу (документ в редакторе, а не PDF или слайды) и подпапка с изображениями.

Назначьте одного ответственного со стороны компании. Он собирает ответы у разработчиков, менеджеров и юристов и отдаёт студии единую версию. Когда правки приходят от пяти людей по отдельности, они часто противоречат друг другу. В названиях файлов указывайте дату, а слово «финал» оставьте только за одним актуальным документом.

Как описать продукт, чтобы студии не пришлось гадать

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

• Заголовок: «Заявки.Про — учёт обращений клиентов для небольших служб поддержки».
• Одно предложение под заголовком: «Собирает письма и сообщения из мессенджеров в одном окне и показывает, кто за что отвечает».
• Блок «Что умеет»: 5–7 пунктов, каждый начинается с действия: «Распределяет заявки по сотрудникам», «Напоминает о просроченных обращениях».
• Блок «Для кого»: типы команд и задач, без перечисления отраслей «на всякий случай».
• Блок «Как внедряется»: шаги от заявки до запуска и то, что требуется от вашего заказчика.
• Технические данные: облако или установка, поддерживаемые браузеры, список интеграций.
• Главное действие: «Запросить демо» или «Попробовать бесплатно» — одно, и с указанием, что произойдёт после нажатия.

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

Скриншоты, видео и документация: что подготовить

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

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

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

Актуальность, согласования и пробелы

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

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

Проверочный список перед отправкой студии

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

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