Пословица гласит: скупой платит дважды, глупый трижды, а дурак платит всегда. Сегодня расскажу, как обезопасить бизнес от потерь денег и не платить за повторяющиеся ошибки на сайте.
Суть проблемы
Представьте: вы добавили новую функцию, разработчик все переделал, и вдруг — раз! Сломалось что-то критичное... Или хуже: заказы перестали приходить в CRM, но вы об этом узнали только через неделю. Сталкивались с подобным? Я видел такие ситуации не раз.
Я работал администратором сайтов и диджитал-директором в разных компаниях — от e-commerce до маркетинговых агентств, встречал разные конфигурации бизнесов и команд, работающих над сайтами. И довольно часто я видел одну и ту же картину: провели работы на сайте, вместо или вместе с улучшением получили ошибку или не одну. Еще хуже, когда эта ошибка уже была ранее.
Сразу оговорюсь, что речь про малый бизнес, когда нет своего отдела тестирования. Речь именно о молодых компаниях, как правило это ecom или сайты услуг, есть несколько сотрудников в штате или на аутсорсе, которые занимаются сайтом. Распределение может быть любым, но как правило это разработчик, администратор, контент-менеджер, копирайтер. Страшнее всего, если это один человек. )
Дежавю или ошибка Матрицы
После таких повторных ошибок периодически начинаешь ловить себя на мысли:
Стоп, мы же это уже исправляли.
Поднимаешь выполненные задачи в таск-трекере (кстати, хорошо, если он у вас есть; если еще нет, задумайтесь) — действительно уже была задача такая у разработчика.
Отлично, если при этом у вас есть Git, резервные копии, а весь функционал задокументирован. Но в малом бизнесе очень часто не так. Даже если все знают, что так надо, часто не хватает ресурсов, чтобы все это сделать — есть куча более приоритетных задач и так далее. Поделитесь в комментариях, если у вас было что-то похожее.
Обычно в такие моменты думаешь:
А как бы так сделать, чтобы больше на одни и те же грабли не наступать.
Потому что, если разработчик в штате на окладе, это еще ок, а если на аутсорсе а бюджет жестко фиксирован и найти причину появления ошибки не представляется возможным? Придется за её исправление заплатить повторно.
Так у нас в свое время появился новый циклический бизнес-процесс по проверке сайта на типовые ошибки, такое тестирование на минималках. В таск-трекерах удобно для этого создать повторяющуюся задачу, допустим, раз в неделю, раз в месяц или с привязкой к завершению каких-то задач разработчика.
Как реализовать
Формат не сильно важен. Опишу, как было у нас, и из этого примера поймете, что важно учитывать, а дальше адаптируете под свои инструменты. У нас была Google-таблица с тремя вкладками: ПК, Android, iPhone.
В таблице буквально две колонки: «Пункт проверки» и «Устройство, браузер и дата».
В строках перечисляются пункты проверок и группируются по каким-то вашим критериям, например «Шапка», «Меню», «Карточка товара», «Категория» и т.д.
Выглядело это примерно так (шутка):
На самом деле выглядело примерно так:
Даже из этого небольшого примера видно, что в конце июля еще не было проблем, а к концу августа проблема появилась. Дальше это можно сопоставить с работами и выявить вероятную причину. Чем чаще проводятся проверки, тем быстрее найти причину. Также рекомендую договориться с разработчиком, если он на аутсорсе, а не на окладе, что он дает гарантию на работы и, если в процессе проверки выявится повторное появление проблемы, он бесплатно её исправляет.
У вас будут свои нюансы, так как может быть сквозная аналитика и подменные номера, тогда нельзя указывать конкретный номер. Выше просто пример, как оформляется таблица. При желании вы можете разделить «Пункт проверки» на две колонки: «Действие» и «Ожидаемый результат», но мы писали все в одну ячейку для простоты. Например:
Перейти по ссылке ххх в карточку товара, проскроллить в самый низ до видео. Видео должно показываться с превью, не должно быть обрезано с какой-либо стороны, должно воспроизводиться со звуком.
То есть описывали и действие, и ожидаемый результат.
Кому поручить заполнение таблицы, решайте сами. В разное время у нас этим занимались совершенно разные люди и я в том числе. Важно, чтобы периодически проверки кем-то перепроверялись.
Можно проверять каждый раз, но выборочно, например 5–10% пунктов. Проверяющий должен знать, что за ним будет перепроверка. Без перепроверок у проверяющего будет соблазн просто все заполнить плюсиками, и вы не узнаете о проблемах.
Также можно назначить пунктам разные приоритеты и в зависимости от приоритета назначить частоту проверки. Например:
- критичные пункты проверять раз в неделю,
- менее критичные — раз в месяц,
- малозначимые — раз в квартал.
Теперь к самому главному. Какие пункты наиболее важные для проверки и чек-лист по ним. Я затрону только некоторые пункты; по остальным поясню принцип, а касательно вашего сайта вы сами решите, что под него подходит.
Самые критичные участки — это элементы, от которых зависит выручка и лиды
Это в целом очевидно, но в ежедневной запаре не все над этим задумываются.
Чек-лист по проверке наиболее важных участков на сайте:
- Переход из корзины в оформление заказа
- Оформление заказа
- Оформление заказа в 1 клик
- Добавление в корзину
- Корректная работа всех форм заявок
- Квизы
- Работа телефона (корректный номер, звонок проходит)
То есть любые формы, кнопки, ссылки, виджеты, через которые приходят заявки или оформляется заказ.
Проверяйте формы не просто до момента отправки, а именно до появления карточки в CRM, ERP или куда они у вас должны приходить (почта, телеграм и т.д.). Так как может появиться надпись "Отправлено", но из-за каких-то проблем в интеграции, работе сайта, сервера и так далее, кнопка отправки отработала, отправка произошла, а прием нет.
⚠️ Не пропускайте эти проверки из-за того, что видите заказы в CRM. Легко может быть так, что один тип заказов передается, а другой нет. Например, заказы через полное оформление заказа передаются, а в 1 клик нет. А они могли составлять 30% от всех заказов, например. Если критичные проверки у вас раз в неделю и вы пропустите такую проверку, то при выручке в 1 000 000 рублей в неделю вы потеряете 300 000 рублей. А сама проверка могла стоить вам, например, 100 рублей на условной Воркзилле.
Что еще можно и нужно проверять
Постоянно пополняйте базу тестирования
Если какая-то ошибка появилась повторно — сразу в список на регулярную проверку. Повторилась 2 раза, может повториться и 3.
Проверьте участки, за которые потенциально можно получить большие штрафы
На данный момент актуальные темы — это закон о персональных данных и о маркировке рекламы. Например, вы добавили нужные чек-боксы с согласием на правила обработки персональных данных и обновили саму страницу с правилами, а потом в результате восстановления бэкапа у вас все изменения откатились к предыдущей версии, которая не соответствовала закону. Согласитесь, получить несколько сотен тысяч рублей штрафа за отсутствующую галочку — обидно.
Проверяйте актуальность бэкапов
С правильной ли частотой создаются бэкапы, за нужные ли числа, нет ли ошибок?
Автоматизируйте то, что легко автоматизируется
Например, проверку доступности сайта, важных страниц, срок действия SSL сертификата или дату продления домена можно проверять через Monitorus. Стоит копейки, польза невероятная. Уведомления на почту, в Телеграм и так далее. Можно даже проверять текст на страницах — например, у вас есть 10 топ-товаров, которые должны быть всегда в продаже. Можно настроить проверку нахождения текста "В наличии" на указанных страницах. Сценариев довольно много можно придумать.
Вы даже не представляете, как часто бывает ситуация, что не продлили домен или не продлился автоматически сертификат SSL в пятницу и сайт висел в ауте два дня. Это же касается продления хостинга.
Не надейтесь на уведомления Яндекс Метрики или Яндекс Вебмастера. Они приходят с сильным опозданием. Сервисы мониторинга позволяют получать информацию максимально быстро.
Пожалуй, на этом все и так слишком много текста вышло.
Делитесь в комментариях, какие ошибки ловили вы повторно и как с этим боролись или не боролись )