Зачем пересматривать план запуска с точки зрения клиента
Многие планы запуска сайта пишутся по техническому процессу: настройка домена, развёртывание сервера, установка программы, применение шаблона, импорт контента, тестирование и запуск. Для исполнителей эта последовательность понятна, но клиент, получив такой план, часто не может ничего возразить и просто отвечает «хорошо». В результате в день запуска выясняется, что на главной странице стоит картинка-заглушка, описание услуг осталось в старой редакции, а в контактах указан номер уволившегося сотрудника.
Пересмотр с точки зрения клиента — это не попытка написать план вежливее, а перевод каждого этапа на язык вопросов, на которые клиент может дать чёткий ответ: для кого эта страница, актуален ли контент, открывается ли ссылка, кто будет вносить изменения после запуска. Если клиент может ответить на каждый пункт плана, количество доработок на этапе выполнения заметно снижается.
Сначала определите, для кого этот план
У плана запуска обычно две категории читателей: те, кто отвечает за техническое развёртывание, и те, кто отвечает за контент и бизнес. Их интересы различаются. Техническая сторона заботится о единообразии среды, полноте переноса данных и доступности резервных копий. Сторона контента — о том, все ли страницы заполнены, верны ли цены на продукты, обновлены ли контактные данные.
При составлении плана можно разделить его на две колонки: в одной — «действия исполнителя», в другой — «что нужно подтвердить клиенту». Например, «импорт данных о продуктах» — это действие исполнителя, а соответствующее подтверждение — «совпадают ли названия, характеристики и изображения продуктов с текущим прайсом». Так клиент видит, что именно от него требуется, а не просто набор технических терминов.
Замените предстартовую проверку на список, который клиент может пройти сам
Если в предстартовой проверке написано просто «полное тестирование», это равносильно отсутствию проверки. Лучше перечислить шаги по реальному маршруту клиента и дать ему самому пройти по ним. Предположим, компания продаёт оборудование. Типичный путь посетителя: с главной страницы перейти к основным продуктам, затем в категорию, открыть карточку конкретной модели и найти контакты или форму обратной связи. Проверка идёт по этому маршруту:
- На первом экране главной страницы — актуальное ли направление бизнеса, нет ли просроченных баннеров с акциями;
- Совпадают ли названия категорий продуктов с тем, как их обычно называет клиент (например, клиент говорит «комплектующие», а на сайте написано «периферийные расходники»);
- Чёткие ли изображения на страницах товаров, нет ли пропущенных картинок, соответствуют ли таблицы характеристик последним данным;
- Обновлены ли на странице контактов телефон, адрес и часы работы, есть ли ответственный за обработку заявок из формы;
- Совпадают ли в подвале сайта название компании и место отображения регистрационных данных с текущими реквизитами.
Этот список не должен быть длинным, но клиент должен иметь возможность по каждому пункту ответить «да» или «нет». Пункты с ответом «нет» — это то, что обязательно нужно исправить до запуска.
Работа с контентом: что оставить, что объединить, что убрать
Когда на старом сайте много страниц, самый неясный пункт плана запуска — «что делать со старым контентом». С точки зрения клиента важно: останутся ли страницы, которые находили через поиск; не превратятся ли ссылки, отправленные клиентам, в пустые страницы.
Работу можно разбить на три шага: сначала выгрузить список всех адресов старого сайта, затем по каждому решить — оставить, объединить или убрать. Критерии можно свести к трём вопросам к клиенту: смотрят ли ещё эту страницу, точен ли её контент, нет ли другой страницы с той же информацией. Если содержание дублируется, страницы объединяются в одну. Если информация устарела и не представляет ценности, страница убирается, при этом нужно убедиться, что на неё не ведут ссылки с других страниц.
Для сохраняемых страниц по возможности оставляйте прежние адреса. Если адрес всё же меняется, отметьте это в плане, чтобы клиент знал, какие старые ссылки перестанут работать. Этот шаг не требует сложных правил поисковой оптимизации — он лишь снижает путаницу для клиента и посетителей.
Включите в план пункт «кто поддерживает сайт после запуска»
Многие планы запуска заканчиваются на «публикации сайта», но реальное использование начинается после запуска. В плане стоит предусмотреть раздел о распределении задач по текущей поддержке: кто обновляет статьи, кто меняет цены на продукты, кто следит за заявками, к кому обращаться, если страница не открывается.
Если клиент сам управляет административной панелью, можно приложить к плану краткую инструкцию: какие поля нужно заполнить для публикации статьи, какие требования к именованию изображений. Имена файлов изображений лучше делать понятными — на русском или транслитерации с датой, например «2024-цех-оборудование-вид-спереди.jpg», чтобы потом было легко искать в медиатеке. Именование файлов кажется мелочью, но при большом объёме контента оно экономит много времени на поиск.
Если поддержку осуществляет исполнитель, также стоит указать периодичность обновлений и способ связи, чтобы после запуска сайт не остался без внимания. Это раздел о распределении обязанностей, а не о конкретных гарантиях обслуживания — заполняйте его в соответствии с фактической договорённостью сторон.
Что проверять в день запуска и через неделю после него
В день запуска основное внимание уделяется двум вещам: «открывается ли сайт нормально» и «финальная ли это версия контента». Можно поочерёдно открыть основные страницы и убедиться, что нет пустых блоков, смещённых элементов и текста-заглушки. Формы, обратная связь, загрузка файлов — такие интерактивные элементы лучше проверить, отправив реальный запрос и убедившись, что он доходит до адресата.
Через неделю после запуска фокус смещается на «удобно ли клиенту пользоваться». Можно предложить клиенту самостоятельно обновить одну запись и посмотреть, не возникает ли затруднений. Также стоит проверить статистику посещений: какие страницы смотрят часто, а какие почти не посещают. Эти наблюдения сами по себе не являются выводами для оптимизации, но помогают понять, что менять в первую очередь.
Если включить эти проверки в план запуска, клиент поймёт, что запуск — не финальная точка, а начало периода поддержки.
Как должен выглядеть пересмотренный план
План запуска, пересмотренный с точки зрения клиента, обычно включает: список того, что клиенту нужно подтвердить, пункты проверки в порядке маршрута посетителя, решения по старому контенту, распределение обязанностей по поддержке после запуска, а также проверки в день запуска и через неделю. Он не должен быть объёмным, но каждый пункт должен позволять клиенту дать чёткий ответ.
Если у вас уже есть план, составленный по техническому процессу, начните с одного простого действия: обведите все термины, которые клиент не понимает, и замените их на вопросы, на которые он может ответить. Отправьте клиенту обновлённый вариант — и эффективность общения заметно изменится.
