Помилка перша: опис мети в неправильних одиницях виміру
Найбільше даремних раундів у чаті збірки виникає через прицілювання на неправильну «висоту», і відбувається це в двох протилежних напрямках. Одні просять менше, ніж мають на увазі, — «покращ дизайн», «зроби краще», «щось тут не так». Кожна така фраза — це діагноз без мети, тож наступна версія стає здогадкою: можливо, потемніє шапка, можливо, зміниться шрифт, можливо, перебудується навігація, — і ви не зрозумієте чому, доки не подивитеся на результат, дивуючись, що сталося. Інші, навпаки, перестараються і просять більше, ніж варто, — називають cookie сесії, CSS grid чи компонент скелетона завантаження, бо трохи знають і хочуть допомогти. Ця помилка тихіша, але не менш затратна. У момент, коли ви вказуєте реалізацію, ви зазвичай вказуєте її неправильно, або в кращому разі звужуєте простір рішень до того, що знаєте особисто, — а це, якщо ви не працюючий розробник, вужче, ніж те, що спробував би білдер самостійно. І якщо названа вами бібліотека чи патерн виявляться неправильним вибором, це стає багом, який ви внесли самі, — тим, якого білдер ніколи б не допустив, працюючи від результату, а не від механізму.
Рішення лежить між цими двома крайнощами: назвіть те, на що ви дивитеся, і зміну, яку хочете побачити, а не механізм, що її створює. «Відвідувачі повинні мати змогу бронювати без створення облікового запису» краще за абзац про cookie сесії, бо насправді вам потрібне усунення тертя, а способів досягти цього, ймовірно, є три, про які ви ще не подумали. «Таблиця цін заплутана» — усе ще занадто розмито саме по собі (заплутана чим?), але «люди не розуміють, що річний план економить гроші, розмістіть знижку поруч із ціною, а не ховайте у дрібному шрифті» дає білдеру конкретну задачу. Якщо ви не знаєте, як має виглядати рішення, це теж нормально — скажіть, що не так, і дайте білдеру запропонувати форму. Що не працює — це розмите незадоволення без жодної опори, бо тоді кожна наступна версія перетворюється на гру у вгадування.
| Замість… | Скажіть… |
|---|---|
| «Покращ це» | «Головний текст важко читати на фото — додай контраст» |
| «Виправ відчуття гри» | «Стрибок триває задовго — зроби його різкішим» |
| «Додай авторизацію якось» | «Гравцям потрібні облікові записи, щоб рахунки зберігалися» |
| «Зроби швидше» | «Сторінка галереї трохи довго завантажує зображення — покажи заглушку замість білого порожнього місця» |
| «Цей розділ поганий» | «Відгуки виглядають як щось другорядне — дай їм таку ж вагу, як розділу з цінами» |
Помилка друга: реакція на версію замість погляду на неї
Другий спосіб, яким люди самі собі шкодять, — реагувати на опис зміни в чаті, а не на саму зміну. Хтось читає «переніс розклад на окрему сторінку і затемнив шапку», формує уявну картинку і пише відгук проти цієї картинки, а не проти реального сайту. Більшість скарг «тут щось не так» насправді означають «я ще не відкривав попередній перегляд» — результат був нормальним чи майже нормальним, а заперечення насправді стосувалося припущення. Клацнути й переглянути перед тим, як писати, займає секунд тридцять, і пропуск цього кроку — найбільше джерело раундів, яких взагалі не мало бути. Навіть переглядаючи з телефону на нараді, спершу гляньте на попередній перегляд — відгук на опис опису швидко накопичує помилки.
Пов'язана помилка — об'єднувати непов'язані запити в одному повідомленні і втрачати можливість зрозуміти, що спричинило що. Ви цілком можете об'єднати кілька прохань і отримати їх усі в одній новій версії — збірка, яка виправляє шапку, переносить розклад і покращує мобільну навігацію за один прохід, легша для перегляду, ніж три окремі diff'и, бо ви оцінюєте один цілісний стан сайту, а не три зміни відносно рухомої цілі. Проблеми починаються, коли запити не пов'язані між собою. Об'єднайте перероблення сторінки розкладу зі зміною глобальної кольорової палітри, і якщо щось у результаті здається не так, ви справді не зможете зрозуміти, що саме це спричинило — сторінку було важко читати через новий макет чи через нову палітру? Розплутування цього коштує додаткового повідомлення і ще одного повного раунду лише для того, щоб ізолювати змінну. Тримайте "все про сторінку розкладу" в одному повідомленні, а "напрямок кольорів" — у наступному, навіть якщо ніщо не заважає об'єднати їх; кожна версія залишається чистим порівнянням, і ви можете відкотити чи скоригувати лише те, що потребує цього, замість того щоб викидати в цілому вдалу версію через те, що одна деталь не вдалася.
Помилка третя: ставлення до кожної версії як до одноразової
Третя помилка — забувати, що картка версії — це не квитанція, а робочий об'єкт, і пропускати повз те, що вона насправді пропонує. Кожен завершений раунд створює картку з живим Попереднім переглядом — реальним працюючим екземпляром, а не скриншотом, тож натискання кнопки в ньому робить те саме, що й у продакшені. Є вкладка Код для перегляду кожного зміненого файлу, що важливо, якщо ви достатньо технічно підковані, щоб перевірити щось конкретне (чи справді ця форма надсилає дані на правильний ендпоінт?) не чекаючи на відповідь у чаті. Завантаження дає вам вихідні файли. А меню дій — це момент, коли версія перестає бути чернеткою: опублікуйте її наживо, зберіть нативні інсталятори, якщо це застосунок, відправте в магазин, збережіть усе як шаблон для майбутніх збірок або розгорніть окремо.
Люди, які все це пропускають, зрештою намагаються згадати, чи була кнопка синьою в старій версії, замість того щоб просто відкрити стару версію і подивитися — бо наслідки ставлення до карток як до одноразових саме в цьому: покладатися на пам'ять для того, що все ще на відстані одного кліка. Версія 4 не архівується і не заморожується, коли виходить версія 7. Її попередній перегляд все ще працює, вкладка коду все ще переглядається, меню дій все ще функціонує — назавжди. Порівняння двох версій — це не вправа з читання diff'ів, а відкриття обох попередніх переглядів поруч і клацання по кожному з них. Картка також містить запис перевірки збірки — автоматичний прохід, що підтверджує її працездатність перед тим, як передати вам як готову — прив'язаний саме до цієї версії, і це ще одна причина, чому важливо, щоб старі картки залишалися живими: якщо версія 6 пройшла перевірку чисто, а версія 7 — ні, у вас є обидві для порівняння замість повідомлення в чаті "виправив", яке доводиться сприймати на віру.
Та сама звичка — ставитися до робочого процесу як до того, що можна пропустити, а не використовувати — проявляється в ігноруванні пропозицій продовження, які чат надає після кожної збірки. Це не загальний наповнювач; вони беруться з самої збірки, тому зазвичай вловлюють те, що ви могли б пропустити при власному перегляді: порожній стан, який ніхто не спроектував, форма, яка не підтверджує надсилання, сторінка, що добре виглядає на десктопі, але затиснута на мобільному. Приймати їх не обов'язково, але переглянути їх нічого не коштує, і вони є розумною заміною QA-перевірці, якщо у вас немає часу пройтися по кожній сторінці самостійно.
