SavePearlHarbor

Разработчики опять ничего не поняли:)

—

от автора

admin

Знакомая ситуация: задача ушла в работу, а через неделю выясняется, что сроки горят, фронтенд мычит, а результат вообще не то, что вы просили. Обычно в этом винят разработчиков. Но давайте честно: часто проблема начинается еще на этапе аналитики.

Мое глубокое убеждение: лучший аналитик — это разработчик. Или человек, который научился думать как разработчик. Любая дорога хорошего разраба в будущем ведет в аналитику или архитектуру, потому что без понимания системы на уровне кода делать качественные продукты невозможно.

Кстати, спойлер для тех, кто думает, что нейросети и вайбкодинг скоро заменят аналитиков и продактов. Не заменят. ИИ генерит код, но только если ему скармливать идеальные промпты. А идеальный промпт — это и есть грамотно написанная задача. Так что прокачка этого навыка — ваша личная страховка от вымирания. Сеньор, который пишет ТЗ так, что ИИ (или джун) собирает из него рабочий интерфейс без вопросов — это новая реальность.

Давайте соберем в кучу всё, что нужно знать, чтобы ваша задача не вызывала у фронта нервного тика, а бизнес в итоге заработал денег (а вы получили повышение, потому что причастны к этому успеху).

Шаг 0. Прежде чем открывать трекер

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

Затем декомпозируйте. Большая задача должна быть разбита так, чтобы части не пересекались и их можно было делать последовательно.

И еще: всегда объясняйте зачем мы это делаем. Разработчики видят код, а не бизнес‑ценность. Если они понимают, почему эта фича нужна юзеру, они сами могут предложить UX‑решение, о котором вы даже не думали.

Шаг 1. Название, по которому задачу легко найти

Забудьте названия вроде «Подключить экран к API» или «Цветовая индикация». Это мусор. Используйте четкую структуру: [Платформа/Версия] Раздел — Блок — Суть.

Плохо: «Сделать профиль». Хорошо: `[Web] Профиль — Блок истории заказов — Реализовать пагинацию и обработку ошибок«.»

Шаг 2. Точка входа и права доступа

С чего начинается экран? С ссылки или кнопки. Где она находится? Какой URL? И самое главное: кто имеет право туда смотреть? Если у юзера нет прав, фронтенд не должен гадать. Пишите сразу: «Показываем заглушку с текстом Х» или «Делаем редирект на главную». Фронт не экстрасенс.

Шаг 3. Матрица состояний (Самое важное!)

Страница открылась. В 99% случаев мы дергаем API. Что мы видим, пока данные грузятся? Спиннер? Скелетон? Что если API вернуло ошибку? А если вернуло 204 (пустоту)?

Все эти состояния (Loading, Error, Empty) нужно расписать текстом и приложить скриншоты из Figma. Фронтенд не знает, что «пустой список» нужно оформлять с милой иллюстрацией, если вы ему это не сказали.

Шаг 4. Данные и API: фронтенд не умеет читать мысли

Данные пришли. Как их рендерить? Не ленитесь нарисовать хоть в Paint таблицу маппинга.

  • «Поле А выводим всегда».

  • «Дату из поля Б форматируем в ДД.ММ.ГГГГ».

  • «Статус из поля В: если „active“ — зеленая плашка, если „blocked“ — красная».

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

И обязательно прикладывайте ссылки на документацию бэкенда (Swagger/Postman). Фронтенд не должен догадываться, готов ли бэк и какие там эндпоинты. Если бэк еще не готов, ставьте задачу на мок‑данные и явно укажите это.

Шаг 5. Формы и поля: дьявол в деталях

Жмем кнопку — открывается модалка. Если юзер заполнил форму, случайно обновил страницу — данные должны сохраниться в черновик? Описываем.

Теперь сами поля. Разберем на примерах, чтобы вы поняли глубину:

  1. ФИО. Не пишите просто «валидация ФИО». Распишите: разрешаем ли дефисы? Обязательно ли отчество? Что делать, если ввели на английском? Если поле автозаполняется из профиля — укажите, из какого поля API брать и в какое поле запроса класть.

  2. Год рождения. Забудьте фразы вроде «ограничено текущей датой». Пишите как для роботов: min: 1920, max: текущий год.

  3. Количество токенов. Это Number. Укажите жесткие границы: минимум 100, максимум 10000.

  4. Загрузка файлов. Формат (pdf, png), лимит (не более 3 штук), макс размер (до 5 Мб).

Какие поля обязательны? Как ведем себя при клике на «Сохранить»? Если есть ошибки — подсвечиваем поля красным и показываем текст ошибки. Кнопка «Сохранить» в это время задизейблена.

Шаг 6. Отправка и краевые случаи

Юзер нажал «Сохранить». Что происходит? Сразу вешаем Loading на кнопку, дисейблим всю форму, блокируем закрытие модалки по клику вне ее. Что если бэк упал по таймауту? Что если бэк вернул 200 ОК, но структура ответа вообще не та, что мы ждали? Пропишите и эти пограничные случаи.

Шаг 7. UX и чек‑лист на прочность

Фронтенд — это лицо приложения. Не забывайте про базовый чек‑лист, который нужно добавить в конец задачи:

  • Как это выглядит на мобилке (адаптив)?

  • Как это выглядит в темной теме?

  • Что будет, если текст не помещается в одну строку (многоточие или перенос)?

🛠 Шпаргалка: Готовые шаблоны

Теория — это хорошо, но давайте к суровой реальности. Чтобы не изобретать велосипед, я давно собрал готовые шаблоны. Копируйте, адаптируйте под свой трекер и используйте.

📝 Шаблон 1: Задача на разработку (Фича)

Название: [Web/Mobile] Раздел — Блок — Суть задачи

1. Контекст и ценность

  • Цель: Сократить время поиска прошлых заказов.

  • Бизнес‑ценность: Увеличить повторные покупки.

2. Точка входа и права

  • Где: Раздел «Профиль» → вкладка «Заказы».

  • Права: Только авторизованным. Если нет — редирект на логин.

3. Макеты и UX

  • Figma: [ссылка]

  • Стейты:

    • Loading: Скелетон.

    • Empty: Иллюстрация + текст «Нет заказов».

    • Error: Плашка «Не удалось загрузить» + кнопка «Повторить».

4. Данные и API

  • Эндпоинт: GET /api/v1/orders

  • Маппинг:

    • created_at → DD.MM.YYYY

    • status → new = синяя плашка, done = зеленая.

  • Доки API: [ссылка на Swagger]

5. Формы и взаимодействие

  • Кнопка «Отменить»: Открывает модалку. При успехе — тост «Отменено», обновляем список. При ошибке — тост с текстом от бэка.

6. Чек‑лист для Dev

  • Адаптив (320px — 428px).

  • Темная тема.

  • Обработка всех стейтов.

🐞 Шаблон 2: Баг‑репорт

Название: [Раздел] Краткая суть бага

1. Окружение

  • Платформа: Web, Chrome 114 (Win 11).

  • Билд: v.2.4.1.

  • Аккаунт: test@example.com / 12345.

2. Шаги воспроизведения

  1. Авторизоваться.

  2. Перейти в «Профиль».

  3. Ввести в ФИО: Иванов-Петров.

  4. Нажать «Сохранить».

3. Ожидаемый результат: Данные сохранились, тост «Успешно».

4. Фактический результат: Ошибка валидации «Некорректный формат».

5. Доказательства

  • Видео/Скрин: [прикрепить]

  • Console/Network: Запрос PUT /profile, статус 400, ответ {"error": "invalid_regex"}.

Trust, but verify (Доверяй, но проверяй)

Когда разработчик ставит эстимейт, и он сильно отличается от ваших ожиданий — не молчите. Обсудите это до начала разработки. Возможно, он не учел переиспользование компонента, а возможно, вы забыли описать сложный краевой случай.

И мой личный совет: не верьте разработчикам на слово на приемке. Если есть время — тыкайте кнопку сами, проверяйте краевые случаи, смотрите в консоль. Разработчики тоже люди, они могут случайно пропустить ваш пункт из ТЗ или сделать «по умолчанию». Устные договоренности в курилке ничего не значат — если нет задачи, баг не будет найден тестировщиком.

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

Экономьте их время и нервы, и они сэкономят ваши. А когда бизнес увидит, что продукт работает четко и приносит деньги, ваша ЗП тоже скажет вам спасибо))

ссылка на оригинал статьи https://habr.com/ru/articles/1063716/