Инструкция редактора сайта: что запросить у разработчика и как принять работу

Инструкция начинается с задачи редактора

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

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

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

Заказчику полезно назвать будущих пользователей документа и их исходный опыт. Если редактированием займётся сотрудник без знакомства с WordPress, выражение «обновить медиаблок» придётся раскрыть до последовательности видимых действий. Для опытного редактора важнее отличия конкретного сайта от обычной установки.

Из каких частей состоит описание одной операции

У операции есть вход и выход. В начале указывают, что подготовить: окончательный текст, разрешённое изображение, адрес ссылки или файл определённой версии; в конце — где увидеть результат и по каким признакам считать задачу завершённой.

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

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

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

Что объяснить о тексте, ссылках и изображениях

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

Файл, подпись и альтернативный текст

Для изображения важно разделить сам файл, его видимую подпись и текстовое описание. Документация блока Image в WordPress различает загрузку файла, выбор из медиабиблиотеки и вставку по внешнему адресу. Подпись под изображением и alt — разные поля: alt передаёт смысл изображения тем, кто не может его увидеть. Эти поля заполняют раздельно. В нашем руководстве их лучше описать в одной задаче «добавить иллюстрацию», но с понятным назначением каждого поля. Тогда слово «описание» не будет означать всё сразу.

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

Размер изображения и версия документа

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

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

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

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

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

Два сценария исправления

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

Когда обращаться за помощью

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

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

Как убедиться, что новый сотрудник справится

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

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

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

Что считать результатом приёмки

Для каждой задачи команда записывает один из трёх итогов:

• Сотрудник выполнил задачу самостоятельно — описание можно принять.
• Понадобилось пояснение — инструкцию дополняют в месте остановки и повторяют задание.
• Не хватает прав или функции — разработчику передают отдельную задачу, а приёмку откладывают до исправления.

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

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

Когда руководство пора расширять

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

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

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

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