Год агентство ловило то, что должны были ловить мы.

Не архитектура — мелочи, которые стыдно сдавать

У агентства есть свой QA: после нашей сдачи, на тестовой среде, до того как что-то уйдёт клиенту. Делают они это хорошо. И первый год партнёрства их QA находил что-нибудь в каждом нашем проекте.

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

Телефон обычным текстом, без ссылки tel:. Внутренняя ссылка на старый домен клиента вместо нового. Серый силуэт из стандартного шаблона в блоке «Наша команда». Заголовок строчными буквами — разработчик скопировал его из брифа, а не из согласованного стиля. Пункт меню, всё ещё названный «Sample Page», потому что эта уборка была в списке и выпала из него на финальном рывке.

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

«Они продолжают присылать нам что-то недоделанное». Вывод напрашивается сам. Мы и сами приходили к нему изнутри — и нам было неловко.

Что на самом деле происходило

Разработчик, который две недели строит сайт, к концу уже не видит его ясно.

Это не про нехватку навыка — это обычное свойство человека. Когда долго смотришь на незаконченную работу, перестаёшь видеть её свежим взглядом. Разработчик, открывавший главную пару сотен раз за две недели, картинку-заглушку уже не замечает: она стала частью обстановки, и взгляд проскакивает мимо неё к тому, что он сейчас на самом деле проверяет.

Свежий рецензент видит её сразу.

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

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

Как мы сделали барьер

Мы написали плагин для WordPress. Внутреннее имя — Site Checker. Перед тем как ссылка на тестовую среду уйдёт агентству, он прогоняет по всему сайту набор проверок и выдаёт отчёт «прошёл / не прошёл». Хоть одна непройденная проверка — сдача заблокирована.

Состав проверок менялся от версии к версии, но в устоявшемся виде это около сорока правил в шести группах:

# Site Checker — категории проверок (упрощённо)

phone_format:
  rule: все номера телефонов должны использовать tel:+1XXXXXXXXXX
  scope: все страницы, все виджеты, шапка, подвал
  fail_on: номера в обычном тексте, tel: без кода страны

internal_links:
  rule: нет ссылок на предыдущие домены клиента или домены-заглушки
  scope: все страницы, навигационные меню, подвал
  fail_on: внешние href, не являющиеся намеренными исходящими ссылками

content_language:
  rule: нет кириллических символов в опубликованном контенте
  scope: весь отображаемый текст, метки виджетов, значения своих полей
  fail_on: любой кириллический символ за пределами строк wp-admin UI

placeholder_assets:
  rule: нет неизменённых изображений-заглушек из шаблона
  scope: использование медиатеки на опубликованных страницах
  fail_on: известные имена файлов-заглушек, известные размеры заглушек без alt-текста

page_titles:
  rule: регистр заголовков соответствует соглашению сайта (Title Case)
  scope: элементы H1 и H2 на всех опубликованных страницах
  fail_on: заголовки полностью в нижнем регистре, непоследовательная капитализация внутри страницы

standard_pages:
  rule: образцовая страница WordPress и дефолтный пост «Hello world!» удалены
  scope: все страницы и записи
  fail_on: slug "sample-page", slug "hello-world" присутствует и опубликован

Правило про кириллицу нужно пояснить.

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

Агентство поймало это на двух сайтах. Оба раза русский текст сидел в подписи виджета, которую клиент рано или поздно увидел бы; один — прямо в блоке контактов. Мы добавили правило. Теперь Site Checker проверяет на кириллицу весь выводимый текст, включая сериализованные поля Elementor. Он находит то, что глазами пропустишь.

Что изменил барьер

В первом же квартале после запуска Site Checker замечаний агентства по мелочам соглашений стало резко меньше.

Не до нуля. QA агентства идёт по более широкому фронту, чем наш: точность контента, соответствие бренду, требования со стороны клиента, которых мы целиком не видим. Эти замечания шли и дальше — и правильно. Но десятиминутные находки — телефоны обычным текстом, картинки-заглушки, образцовые страницы — практически прекратились.

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

Разработчику, которого мы подключили в середине спринта, мы дали ссылку на отчёт Site Checker вместо устного пересказа правил. Для ввода в курс дела этот отчёт оказался чище всего, что мы писали раньше, — потому что он был про реальное состояние того сайта, который человеку предстояло доделать. «Две непройденные проверки: телефоны на странице контактов и один H2 строчными буквами в блоке услуг». Полезнее любого общего контрольного списка: говорит ровно, куда смотреть.

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

Чего барьер не делает

Site Checker не заменяет QA агентства. Он и не должен.

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

Site Checker — структурный барьер для узкой, чётко очерченной категории: ошибок, которые неловко сдавать, которые явно относятся к нашему слою работы и которые надёжно проверяются программой. И только.

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

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

Когда барьер выключать

Есть стадии, где барьер надо обходить. Раннее прототипирование, показ прототипов клиенту, исследовательские ветки, где цель — разобраться, а не сдать: гонять строгий барьер здесь контрпродуктивно. В прототипе картинки-заглушки и должны быть. В прототипе и не должно быть финальных телефонов.

Мы отключаем Site Checker в средах, помеченных как прототип, и снова включаем в момент, когда проект готовят к сдаче на тестовую среду. Флаг ручной: разработчики могут его снять и сами понимают, когда это уместно. Барьер — не способ контроля, а способ держать дисциплину. Команде важно эту разницу не терять.

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

Урок для агентства

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

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

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

Неловкие ошибки — картинки-заглушки, телефоны обычным текстом, образцовые страницы — не говорят о том, что команде всё равно. Они говорят о том, что команда не выстроила процесс так, чтобы ловить их до отправки. А выстроить его недорого: первая версия Site Checker — двести строк PHP. Отдача — меньше нагрузки на рецензию и лучше рабочие отношения — проявилась уже в первом квартале.

Будь у нас этот барьер с первого дня — весь первый год прошёл бы иначе.