Stevens / Ivan Issue Report

PR #846 — итоговая позиция

PR: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/846 Задача: IX-SIT67 — update header (parent ICUS-220) Период активности: 2026-04-22 → 2026-04-29+ (на момент скринов всё ещё активен) Статус: OPEN

🚨 Особый вес PR #846

Header прямо упомянут в письме Alexis Watson (29.04) как пример "deliverables that deviate considerably from spec and require revisiting". Этот PR — главный артефакт того тезиса.

Сводка комментариев (11 значимых)

#ТемаСерьёзностьСтатусSpec gap?
1Vercel deploy botслужебный
2"Info For" dropdown center-justified — не в спеке🟡Resolvedнет
3Меню в 2 строки на 1024–1091px (регрессия)⚠️Resolvedнет
4Text-only logo в expanded mobile не реализован🚨Resolvedнет
5Dark mode WCAG-контраст на жёлтых CTA🟡In researchнет
6CTA дублируются в mobile menu (UtilityMenu)⚠️Resolvedнет
7Sticky на 1024+ — спека двусмысленная🟡Уточнено + фикс✅ да
8После фикса — 3 sticky-issues (race / flash / hamburger)⚠️"I'll fix that"нет
94 search-проблемы (font / иконка / бордер / L-shape)🚨Resolvedнет
10Alignment лупы/X — нужно уточнение от designer Jay🟡Fixed✅ частично
11data-cta стабильность (sys.id vs title-slug)🟡TBD✅ да

11 значимых замечаний за 8 дней.

Что критично — таймлайн спеки и PR

ДатаСобытие
2026-04-16, 12:16 WarsawПриложен mockups v3.zip (Андрей)
2026-04-20, 14:24 WarsawПриложен Site_Header_User_Stories_v2.docx (Андрей)
2026-04-22 (ср)Иван открыл PR #846 (через 6 дней после v3 mockups, 2 дня после v2 user stories)
2026-04-22 — 04-29Поток замечаний от Michael (10 содержательных)
2026-04-29, 22:28Письмо Alexis с упоминанием header

→ К моменту открытия PR актуальная спека (v2 user stories + v3 mockups) была на руках. Аргумент "спека менялась" — слабый.

→ Задача "update header" подразумевает, что header уже был в проде. Alexis в письме говорит про "revisiting". PR #846 = и есть попытка revisiting. "Виновник" — какой-то предыдущий header PR, который надо отдельно найти, если по нему нужна позиция.

Распределение причин (по 11 замечаниям)

❌ Наши промахи (8 пунктов): self-QA / сверка с мокапом

  • #2: добавили центрирование, которого в спеке нет.
  • #3: регрессия 1024–1091px от добавления search-кнопки — не проверили промежуточные ширины.
  • #4: text-only logo в expanded mobile — не реализовали явное требование v3 мокапа (главный пример "deviate from spec").
  • #5: dark mode/WCAG-контраст не проверили.
  • #6: CTA дублируются — UX-баг, виден при открытии mobile menu.
  • #8: после фикса sticky остались race condition, flash при ресайзе, hamburger пропадает — фикс был неполным.
  • #9: 4 stylistic issues в search (font / иконка / бордер / L-shape) — все ловятся 30-секундным сравнением preview ↔ мокап.

Объединяющий паттерн: все ловятся 5-минутной сверкой с мокапом в DevTools (RWD-режим, ползунок ширины, dark mode, открыть expanded mobile menu, развернуть search). Не сделано.

✅ Пробелы в спеке (3 пункта)

  • #7: Sticky на 1024+ — Michael сам признал ("I was a little confused by the spec at first, but I asked the author of the spec, and he gave this clarification").
  • #10: Alignment magnifier/X — потребовалось уточнение от designer Jay.
  • #11: data-cta — спека прямо требует "agreed by dev, analytics, and QA before implementation begins"; согласования не было; Иван пошёл по примерам из спеки.

Объединяющий паттерн: спека приводит примеры с пометкой "to be confirmed", но согласование before implementation не делалось. Это процессный gap на стороне клиента (iX/Stevens).

Реактивность Ивана

  • На 7 из 8 содержательных замечаний — фикс в день получения или на следующий.
  • На #5 (dark mode) — честно сказал "in research".
  • На #8 (sticky после фикса) — "I'll fix that".
  • На #11 (data-cta) — корректный технический диалог, нашёл sys.id, обоснованно усомнился в читаемости.

Реактивность хорошая. Проблема не в том, что не исправляет, а в том, что слишком много вещей доходит до ревьюера, которые должны были быть пойманы до отправки PR.

Language barrier (отдельный наблюдаемый момент)

В Comment #10: вопрос Ивана "Are you sure that equal line by icon and link will be better desition?" — Michael не понял, попросил переформулировать. Ответ Ивана пришёл через ~3 дня.

Что это:

  • Не вопрос навыка английского — Иван пишет понятно по сути.
  • Но в коммуникации с клиентским ревью формулировки иногда теряются → лишние циклы ревью.
  • Процессно: можно подключить менеджера/тимлида в качестве "second pair of eyes" перед публикацией крупных вопросов.

Что обсуждать с Иваном

  1. Как выглядит твой self-QA до открытия PR? Каким чеклистом пользуешься?
  2. Открывал ли expanded mobile menu и сравнивал с мокапом v3 до открытия PR? (Comment #4 — text-only logo)
  3. Тестировал ли responsive behavior на промежуточных ширинах (768–1023, 1024–1091)? (Comment #3, #8)
  4. Проверял ли dark mode / WCAG-contrast? (Comment #5)
  5. Использовал ли side-by-side сравнение мокап ↔ preview? (Comment #9 — 4 issues одного блока)
  6. По data-cta (Comment #11) — заметил ли в спеке требование "agreed before implementation"? Поднял ли это до старта?

Что обсуждать с Антоном

  1. Есть ли у нас self-QA чеклист для frontend / header / responsive PR? Если нет — нужно завести.
  2. Кто и когда делает internal validation pass перед отправкой PR на Stevens?
  3. По pre-agreement (data-cta): кто на нашей стороне следит за фразами "agreed before implementation begins" в спеке и поднимает их в Jira до старта работы?
  4. Language barrier в общении Ивана с ревьюерами — нужна ли помощь (менеджер/тимлид перечитывает большие вопросы)?
  5. Размер батча — header — это месячная работа или 2 недели? Можно ли делить?

Что обсуждать со Stevens / iX (через Tom)

  1. Признать обоснованность письма Alexis в части header — обоснованных замечаний действительно много.
  2. Подсветить, что часть проблем — пробелы в спеке (3 из 11 замечаний). Не как контратаку, а как факт для совместного процесса:
    • Sticky на 1024+ был неоднозначным даже для самого Michael.
    • Alignment лупы/X потребовал отдельного уточнения у designer Jay.
    • data-cta — спека прямо требует "agreed before implementation", чего не было сделано на стороне клиента.
  3. Предложить совместный процесс:
    • Acceptance Criteria checklist в Jira до старта работы.
    • Все TBD/exact-value-to-be-confirmed места — закрываются ДО старта работы (через звонок с дизайнером/аналитиком, не через ревью PR).
    • Internal validation pass на нашей стороне (responsive / mobile / dark mode / mockup-overlay).
  4. План для конкретно header'а:
    • Закрыть 3 открытых пункта (#5 dark mode, #8 sticky-issues, #11 data-cta).
    • Договориться о финальной валидации с дизайнером Jay overlay/Figma.
    • Срок merge.

Ключевой вывод

PR #846 — это и есть header из письма Alexis. Замечания обоснованы в большинстве своём (8 из 11 — наши промахи self-QA). 3 пункта показывают, что и спека требовала доработки.

Позиция для встречи: не оправдываться "спека менялась" (она была на руках за 6 дней до PR). Не отрицать "deviate from spec" — оно реально. Но и не отдавать всю вину — у клиента тоже есть процессные пробелы (TBD-значения без pre-agreement, неоднозначное sticky-поведение, отдельные уточнения через designer Jay).

Главный практический ответ: ввести self-QA checklist на нашей стороне (mockup-overlay, responsive, dark mode, accessibility, data-attributes pre-agreement) — это закрыло бы большую часть замечаний этого PR.