Ошибка первая: описание цели в неверных единицах измерения
Больше всего впустую потраченных раундов в чате сборки возникает из-за прицеливания не на ту высоту, причём в двух противоположных направлениях. Некоторые просят меньше, чем имеют в виду — «улучши дизайн», «сделай лучше», «пока не то ощущение». Каждая такая фраза — это диагноз без цели, поэтому следующая версия становится догадкой: может, потемнеет шапка, может, сменится шрифт, может, перестроится навигация — и вы не поймёте, почему именно так, пока не увидите результат и не задумаетесь, что случилось. Другие впадают в противоположную крайность и просят больше, чем следует — называют сессионные куки или CSS grid, или компонент-скелетон загрузки, потому что немного разбираются и хотят помочь. Эта ошибка тише, но не менее затратна. В момент, когда вы указываете реализацию, вы, как правило, указываете её неверно — или в лучшем случае сужаете пространство решений до того, что уже знаете лично вы, а это, если только вы не работающий разработчик, уже, чем то, что попробовал бы билдер самостоятельно. И если названная вами библиотека или паттерн окажутся неверным выбором, это уже баг, который внесли вы, а билдер, отталкиваясь от результата, а не от механизма, его бы никогда не допустил.
Решение находится между этими двумя крайностями: называйте то, на что вы смотрите, и изменение, которое хотите увидеть, а не механизм, который его производит. «Посетители должны иметь возможность бронировать без создания аккаунта» лучше, чем абзац про сессионные куки, потому что на самом деле вам нужно устранение трения, а способов добиться этого, вероятно, три, о которых вы даже не подумали. «Таблица тарифов сбивает с толку» — всё ещё слишком расплывчато само по себе (чем именно сбивает?), но «люди не понимают, что годовой план экономит деньги, разместите скидку рядом с ценой, а не прячьте её в мелком шрифте» даёт билдеру что-то конкретное, от чего можно отталкиваться. Если вы не знаете, как должно выглядеть решение, это тоже нормально — скажите, что не так, и позвольте предложить форму решения. Что не работает — это расплывчатое недовольство без опоры, потому что оно превращает каждую следующую версию в угадайку.
| Вместо… | Скажите… |
|---|---|
| «Улучши это» | «Текст в шапке плохо читается на фото — добавь контраста» |
| «Исправь игровые ощущения» | «Прыжок длится слишком долго и «плавает»; сделай его более резким» |
| «Добавь авторизацию как-нибудь» | «Игрокам нужны аккаунты, чтобы результаты сохранялись» |
| «Сделай быстрее» | «Страница галереи заметно тормозит при загрузке изображений — покажи заглушку вместо пустого белого экрана» |
| «Этот блок плохой» | «Отзывы выглядят как второстепенный элемент — придай им такой же вес, как блоку с тарифами» |
Ошибка вторая: реакция на версию вместо взгляда на неё
Второй способ споткнуться — отвечать на резюме чата об изменении, а не на само изменение. Кто-то читает «перенёс расписание на отдельную страницу и затемнил шапку», формирует мысленную картинку и пишет отзыв, отталкиваясь от этой картинки, а не от реального сайта. Большинство жалоб «это сделали неправильно» на деле оказываются «я ещё не открыл предпросмотр» — результат был в порядке или почти в порядке, а претензия на самом деле касалась предположения. Открыть предпросмотр перед тем как печатать отзыв, стоит секунд тридцать, и пропуск этого шага — главный источник раундов, которых не должно было быть. Даже просматривая с телефона на встрече, сначала взгляните на предпросмотр — отзыв на описание описания быстро накапливает ошибки.
Связанная ошибка — объединять несвязанные запросы в одном сообщении и терять возможность понять, что именно к чему привело. Вы вполне можете сложить несколько просьб вместе и получить их все в одной новой версии — сборка, которая исправляет шапку, переносит расписание и подтягивает мобильную навигацию за один проход, проще для проверки, чем три отдельных диффа, потому что вы оцениваете одно цельное состояние сайта, а не три изменения относительно движущейся цели. Проблемы начинаются, когда запросы не связаны между собой. Объедините переработку страницы расписания с глобальным изменением цвета — и если что-то в результате покажется не так, вы действительно не сможете понять, что именно стало причиной: страницу стало сложно читать из-за новой раскладки или из-за новой палитры? Разобраться в этом обойдётся в дополнительное сообщение и ещё один полный раунд только ради того, чтобы изолировать переменную. Держите «всё, что касается страницы расписания» в одном сообщении, а «направление по цвету» — в следующем, хотя ничто не мешает объединить их; так каждая версия остаётся чистым сравнением, и вы сможете откатить или подправить именно то, что нужно, вместо того чтобы выбрасывать в целом хорошую версию из-за одного промаха.
Ошибка третья: отношение к каждой версии как к одноразовой
Третья ошибка — забывать, что карточка версии это не квитанция, а рабочий объект, и пропускать мимо то, что она реально предлагает. Каждый завершённый раунд создаёт карточку с живым Предпросмотром — реально работающим экземпляром, а не скриншотом, поэтому нажатие кнопки в нём делает то же, что и в продакшене. Есть вкладка Код для просмотра каждого изменённого файла, что важно, если вы достаточно технически подкованы, чтобы точечно проверить что-то конкретное (действительно ли эта форма отправляет данные на нужный адрес?), не дожидаясь подтверждения в чате. Скачивание даёт вам исходные файлы. А меню действий — это то место, где версия перестаёт быть черновиком: опубликуйте её вживую, соберите нативные установщики, если это приложение, отправьте её в магазин, сохраните всё как шаблон для будущих сборок или разверните отдельно.
Те, кто пропускает всё это, в итоге пытаются вспомнить, была ли кнопка синей в старой версии, вместо того чтобы просто открыть старую версию и посмотреть — потому что последствия отношения к карточкам как к одноразовым именно в этом: полагаться на память в том, что до сих пор находится в одном клике. Версия 4 не архивируется и не замораживается, когда выходит версия 7. Её предпросмотр всё так же работает, вкладка кода всё так же просматривается, меню действий всё так же функционирует — навсегда. Сравнение двух версий — это не чтение диффа, а открытие обоих предпросмотров рядом и клики по каждому из них. Карточка также хранит запись верификации сборки — автоматическую проверку, подтверждающую, что всё действительно работает, прежде чем она будет передана вам как готовая, — привязанную именно к этой версии, и это ещё одна причина, почему важно, что старые карточки остаются живыми: если версия 6 прошла верификацию чисто, а версия 7 нет, у вас есть обе для сравнения вместо сообщения в чате «исправлено», которое приходится принимать на веру.
Тот же инстинкт — воспринимать рабочий процесс как то, что нужно проскочить, а не использовать — проявляется и в игнорировании предложений по доработке, которые чат предлагает после каждой сборки. Это не общий наполнитель; они формируются на основе самой сборки, поэтому часто замечают то, что вы могли бы упустить при собственном просмотре: пустое состояние, которое никто не проектировал, форму, которая не подтверждает отправку, страницу, нормальную на десктопе и тесную на мобильном. Принимать их не обязательно, но просмотреть их ничего не стоит, и они являются разумной заменой QA-проверки, если у вас нет времени пройтись по каждой странице самостоятельно.
