👍 Use Case: документ, который новички либо боятся писать,
либо пишут вообще на всё подряд

Аналитики могут проходить через стадию, когда Use Case кажется универсальным инструментом.
Стоит только разобраться, как он работает, и рука сама тянется описывать через него всё подряд:.
😔 авторизацию, поиск, кнопку "Сохранить", открытие модалки
и вообще на всё, что шевелится. 🤭

🤩Обычно это длится до первого серьезного разговора с тимлидом, который спрашивает, а зачем вообще здесь этот документ?
Чаще всего путаница возникает потому, что Use Case путают с обычными требованиями.

🤩Это не список всех возможных проверок, ошибок и ограничений, он решает другую задачу:
👉 показывает как пользователь взаимодействует с системой, чтобы достичь своей цели?

💙Например, взять регистрацию пользователя.
Именно зарегистрироваться ➡️ это и есть цель.
А дальше сценарий:

💙 открыл страницу регистрации
💙 заполнил поля
💙 нажал кнопку
💙 получил письмо
💙 подтвердил почту
💙 вошёл в систему

Вот и всё. Никаких требований вроде "поле должно быть обязательным", "длина пароля от 8 символов" и "ошибка 400" здесь быть не должно,
потому что это уже требования, а не Use Case.

🤩Понять, нужен ли Use Case, очень просто.
Задайте себе вопрос:

пользователь идёт к цели или просто нажимает кнопку?

💙 Если цель есть, то Use Case пригодится.
💙 Если же задача звучит как:
добавить чекбокс/переименовать поле/поменять цвет кнопки,
То писать ради этого Use Case примерно так же логично, как вызывать пожарных, чтобы зажечь свечку))

🤩Есть ещё одна крайность ➡️ попытка предусмотреть вообще всё.
Основной сценарий, куча альтернативных веток и исключений
превращают документ в бесконечный сериал, как будто пишешь сценарий к новому сезону Игры престолов))
На самом деле вполне достаточно описать главный путь и пару важных нюансов.
🤨 Документ, куда включено всё подряд, никто в здравом уме читать не будет.

✅ По сути, Use Case ➡️ это короткая история.
В ней есть герой, есть его цель и чёткая последовательность действий.
Если после прочтения и разработчик, и тестировщик, и заказчик понимают,
что будет происходить в системе, значит, документ сделали как надо.
Если же у каждого своё представление, то стоит готовиться к долгим и бесплодным созвонам)

📊 CRUD-матрица:
табличка, которая задаёт вопросы лучше некоторых аналитиков

Есть очень простой способ понять, нужна ли проекту CRUD-матрица:
😔 если на вопрос "кто может удалить договор?"
в комнате прозвучало хотя бы два разных ответа..поздравляю, она вам уже нужна 🌟

Вообще CRUD выглядит максимально скучно. Обычная табличка:
сверху роли, слева сущности, а внутри четыре буквы:
C, R, U, D.

⬇️Может показаться, что это очередной рутинный инструмент, чтобы аналитикам было чем заняться в пятницу вечером))
⬇️Но стоит заполнять её на практике и всё меняется:

Берёшь, например, сущность "Заявка" и видишь, что оператор может делать Update.
Тут думаешь: "а он случайно не может править любую заявку?".
Оказывается нет, может только свою, да и то если она в статусе "Черновик" и ещё на согласовании не была.

😔И вот одна буква U превращается в целый список условий, в этом и весь прикол ⭐️CRUD-матрицы⭐️

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

💥Если будете составлять её впервые,
не пытайтесь сразу нарисовать огромную таблицу на сто ролей и пятьдесят сущностей.
💥Начните с простого:

1️⃣Выпишите основные сущности.
именно те, с которыми работает система: заявки/договоры/пользователи/документы,
а не экраны или кнопки

2️⃣Затем добавьте роли, только реальные.
Очень хочется написать "Администратор", "Пользователь", "Менеджер" и закончить,
но лучше потратить две минуты и проверить, не забыли ли вы ещё какого-нибудь оператора или модератора.

3️⃣И главное - не ставьте CRUD-операции на автомате как шаблон.
Каждую букву лучше мысленно заменить вопросом.
😔Не просто "Update", а "когда именно он может изменить?"
😔Не просто "Delete", а "точно удалить, а не архивировать?"
😔и не "Read", а "просмотр всех записей или только своих?"
Вот на этих вопросах обычно и всплывают ограничения, про которые никто не вспомнил на обсуждении.

🔖 Ещё совет:
Если в вашей CRUD-матрице почти везде стоят одинаковые буквы ➡️ не спешите радоваться)
Скорее всего, вы просто ещё недостаточно глубоко покопались,
потому что реальные системы очень любят фразы вроде:
"можно, но.." ➡️ эти самые "но" потом становятся требованиями, тест-кейсами и багами.

🔖 По сути, CRUD - это инструмент,
который помогает вытащить на свет скрытые ограничения и разобраться, где система прячет свои нюансы.

📄 Vision Document - документ,
который отвечает на вопрос: "а что мы вообще строим?"

📎Про такой документ некоторые слышали, но мало кто реально понимает, зачем он нужен и думают, что это очередной документ "для галочки". Типа написали, положили в Confluence и забыли.
Но представьте ситуацию: команда начинает новый проект.
😔продакт уже делится идеями
😔дизайнер рисует первые макеты
😔разработчики обсуждают архитектуру
😔а аналитик ещё даже требования не написал

Кажется, что рановато думать о документации,
но именно сейчас Vision Document приносит больше всего пользы.

🤨 Что такое Vision Document?
По сути, это документ, который описывает проект с высоты птичьего полёта,
никаких деталей, бизнес-правил или технических моментов.

Он нужен, чтобы любой человек, открыв документ, за пять минут понял:
💙какую проблему решает продукт
💙кто его пользователи
💙какие цели у проекта
💙что входит в первую версию
💙а что специально оставили за рамками
и недооценивают именно последнее

🤨 Что обычно там пишут?
Набор разделов может отличаться от компании к компании, но чаще всего встречаются:

📌 цель проекта
📌 описание проблемы
📌 целевая аудитория
📌 бизнес-цели
📌 ключевые возможности продукта
📌 ограничения
📌 границы проекта (Scope/Out of Scope)
📌 критерии успеха

✔️ После такого документа уже гораздо проще переходить к требованиям.

🤨 Чем Vision отличается от ТЗ?
🌼 Vision отвечает на вопрос "что мы хотим получить?"
➡️ А требования отвечают: "как именно это должно работать?"

Например,
в Vision может быть написано, что пользователь должен быстро восстановить доступ к аккаунту,
а в требованиях уже опишут, что ссылка для восстановления действует 24 часа, её нельзя использовать повторно и после смены пароля токен становится недействительным.
Разница очевидна.

🤨 Когда Vision особенно полезен?
💙если запускается новый продукт,
💙если проект большой и в нём много команд, много заинтересованных лиц
💙или если есть риск, что каждый понимает цель по-своему.

📌 Ведь чем больше людей работает над продуктом,
тем ценнее становится единое понимание того, что вообще строится.
Потому что плохие проекты редко разваливаются из-за неправильно написанного требования
и гораздо чаще проблема начинается раньше - когда команда с самого начала представляла конечный результат по-разному.
И вот здесь Vision Document становится не просто документом, а отправной точкой для всех дальнейших решений.

📑 SRS: шпаргалка, которую стоит сохранить каждому аналитику

➖Когда впервые слышишь аббревиатуру SRS (Software Requirements Specification),
в голове могут возникнуть две крайности:
😑 либо думаешь, что это какой-то сверхсекретный документ из NASA,
😳 либо просто обычное техническое задание с модным названием))
Но на самом деле ни то, ни другое.

➖SRS - это подробный документ, который описывает все требования к системе так,
чтобы и разработчики, и тестировщики, и аналитики, и заказчик смотрели в одну сторону.

Если простыми словами, то
➡️ Vision отвечает на вопрос "что мы строим?",
➡️ а SRS на "как это должно работать?".

В нем собирают все ключевые моменты в одном месте:
🫡 ФТ и НФТ
🫡 ограничения
🫡 бизнес-правила
🫡 сценарии использования
🫡 диаграммы
🫡 API (если нужно)
🫡 словарь терминов
всё, что поможет разработать систему без гадания.

🤩 Но тут есть одна ловушка,
многие считают, что SRS должен быть гигантским документом на сотни страниц, который нужно заполнять строго по шаблону.
🤩 Но на практике всё проще и зависит от проекта.
➡️ для маленькой задачи SRS может быть всего на 10-15 страниц,
➡️ а для крупной банковской системы или маркетплейса легко перевалит за сотню.

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

Вот что на самом деле делает SRS хорошим.

✅ Приёмка задачи: что проверить аналитику, прежде чем сказать "выглядит норм"

😔Задача прошла разработку, тестировщик всё проверил, статус торжественно переехал в "Приёмку".
Казалось бы, осталось открыть результат, потыкать пару кнопок и написать заветное "принято". 👍

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

📎 Чтобы не смотреть задачу по принципу "ну вроде работает", держите чек-лист

📌 Сверить результат с требованиями

Пройдитесь по каждому функциональному требованию и критерию приёмки.
Не по памяти, а прямо буквально рядом с документом:
пункт требования 🌼 действие в системе 🌼 фактический результат.

Особое внимание стоит уделить формулировкам вроде "только", "обязательно", "не должен", "при условии".
Именно в таких словах обычно сидят ограничения, которые легко потерять при реализации.

📌 Проверить основной пользовательский сценарий

Попробуйте пройти путь целиком глазами пользователя: от входа в функцию до ожидаемого результата.
Прям весь сценарий, а не отдельную кнопку или один запрос.

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

Иногда каждый кусочек работает идеально, а вместе они собираются в очень странного Франкенштейна.

📌 Посмотреть ограничения и пограничные случаи

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

📌 Проверить роли и права доступа

Кто видит функцию?
Кто может создать, изменить, удалить или только посмотреть данные?
Что увидит пользователь без необходимых прав?

Очень обидно обнаружить после релиза, что кнопку "Удалит"» аккуратно выдали вообще всем.
Получился не доступ, а щедрый подарок от системы.

📌 Сверить тексты и данные

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

Функция может работать правильно, но надпись "Ошибка выполнения операции" вместо понятного объяснения способна превратить пользователя в участника квеста без карты.

📌 Проверить интеграции и связанные изменения

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

Любимый жанр интеграций: бэк уже передаёт новое поле, фронт пока смотрит в другую сторону, а все по отдельности уверены, что задача готова.

📌 Сравнить с макетом и договорённостями

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

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

📌 Убедиться, что документация актуальна

Если реализация отличается от первоначального описания по согласованной причине,
то требования нужно обновить.

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

〰️〰️〰️〰️〰️〰️
✳️ После успешной приёмки должно быть понятно три вещи:
🔸требования выполнены,
🔸бизнес-сценарий работает целиком,
🔸а результат можно спокойно показывать заказчику и выпускать дальше.

Потому что "я нажал - оно открылось" ещё не приёмка,
это просто очень короткое знакомство с функционалом. 😌

🧼 Валидация данных: система тоже имеет право сказать
"не принимаю"

➖Сегодня выясним, какие данные система должна принимать, какие разворачивать у входа и как всё это описать в требованиях.

🤩 Допустим, пользователь заполняет форму доставки и в поле "количество квартир" уверенно пишет "Котик".
Человек, возможно, просто устал...😴
Но система теперь должна решить, что делать с этой информацией:
💙сохранить как есть,
💙попытаться посчитать котика ,
💙или всё-таки вежливо попросить число.

Вот за такие моменты и отвечает ✨ валидация ✨

📌 Что вообще проверяем
Она нужна, чтобы в базу не улетали даты рождения из будущего, телефоны из трёх цифр и пароли формата "пароль123"
💥Обычно проверяют:

➡️ Обязательность - поле нельзя оставить пустым.
➡️ Тип данных - в количестве ожидается число, а не «много».
➡️ Формат - почта содержит @, дата выглядит как дата.
➡️ Длину и диапазон - пароль не короче восьми символов, количество товаров больше нуля.
➡️ Допустимые значения - статус только new, paid или cancelled.
➡️ Связь между полями - дата окончания не может быть раньше даты начала.

📌 Где должна работать валидация
На фронте она помогает пользователю быстро исправить ошибку:
подсвечивает поле и пишет, что именно пошло не так.
😔Это удобно, но фронту нельзя доверять как единственному охраннику,
т.к. запрос можно отправить напрямую, обойдя интерфейс.
😔Поэтому бэкенд проверяет данные повторно и принимает окончательное решение.

Фронт как бы говорит: "похоже, тут ошибка",
а бэк: "Да, и в базу это точно не поедет".

📌 Как описывать валидацию в требованиях
✖Фразы вроде "проверить корректность значения" лучше сразу отправлять в мусорку.
Непонятно, что считается корректным и какой результат ожидается при ошибке.

👌Нормальное требование выглядит конкретно:

➖поле quantity обязательно.
➖допускаются только целые числа от 1 до 99.
➖при пустом значении возвращается ошибка REQUIRED_FIELD,
➖при значении вне диапазона ошибка INVALID_QUANTITY.

То есть для каждого поля полезно зафиксировать:
➖ что разрешено передавать
➖ что запрещено
➖ можно ли передать null или пустую строку
➖ применяется ли значение по умолчанию
➖ какая ошибка возвращается
➖ какое сообщение увидит пользователь

📌 Хорошая валидация не просто блокирует плохие данные,
она объясняет пользователю, что именно нужно исправить,
а систему избавляет от записей вроде "стоимость заказа: сырный соус".

Потому что данные должны быть свободными, но не настолько. 😌

🧠 Как объяснить разработчику бизнес-логику

😎 Сегодня поговорим о том, как донести логику задачи так, чтобы разработчик понял не только что сделать,
но и зачем система должна вести себя именно так.

😏 Есть коварная штучка в работе аналитика:
тебе задача уже понятна настолько, что кажется - ну тут вообще всё очевидно:

➡️ пользователь нажимает кнопку
➡️ система делает проверку:
потом
🌱 сохраняет данные
либо
🌱 показывает ошибку

😐 Что тут объяснять-то? А потом разработчик задаёт один вопрос,
и ты такой: "а кстаааати…"

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

💙Начинай не с кнопки, а со смысла
🙅‍♂️ Плохое объяснение:

При нажатии на "Подтвердить" отправляем запрос и меняем статус.

Разработчик такое реализует.
Вопрос только: на какой статус, при каких условиях и почему вообще его меняем?
👍 Лучше сначала дать контекст:

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

И вот теперь дальнейшая логика уже не выглядит набором случайных if.

💙 Рассказывай сценарий целиком
Не "вот тут проверка, тут запрос, тут статус", а нормальной последовательностью:

➡️ пользователь нажимает "Подтвердить"
➡️ проверяем, что в заказе есть хотя бы один товар
➡️ проверяем, что выбран адрес доставки
➡️ если всё ок - фиксируем заказ и меняем статус на confirmed
➡️ после этого редактирование недоступно
➡️ если проверка не пройдена - заказ остаётся в прежнем статусе, пользователь получает понятную ошибку.

😎😎 Всё. Уже видно начало, конец и что происходит по дороге.

А не классика:

🪵 а если адреса нет?
🪵 ой...
🪵 а заказ тогда сохраняем?
🪵 ой...
🪵 а статус какой?
🪵 щааас 😭

💙 Обязательно проговаривай "почему"
Вот это сильно упрощает жизнь. Например:

повторно подтвердить заказ нельзя, потому что после первого подтверждения он уже передаётся в ресторан.

Теперь разработчик понимает, что это не случайное ограничение, которое можно "немножко упростить", а часть бизнес-процесса.
🤩Когда понятна причина, гораздо проще принимать технические решения и замечать противоречия.

💙Не забывай про всякие "а если.."
Именно здесь обычно живёт весь сок.
Основной сценарий почти всегда простой, веселье начинается дальше:

➡️ а если пользователь нажал кнопку два раза
➡️ а если данные уже изменились
➡️ а если внешний сервис недоступен
➡️ а если поле пустое
➡️ а если у пользователя нет прав
➡️ а если запись вообще уже удалили

🤩 Очень полезный вопрос перед передачей задачи:

что может пойти не по основному сценарию?

Потому что если этого нет в требованиях, разработчик либо придёт спрашивать, либо выберет поведение сам.
И оба варианта могут привести совсем не туда, куда хотелось..😏

💙Мини-шпаргалка
Перед тем как отдавать задачу разработчику, проверь:

💙понятна цель изменения
💙описан основной сценарий от начала до конца
💙объяснены ключевые бизнес-правила
💙есть негативные и пограничные сценарии
💙понятно, что происходит с данными и статусами
💙нет важных решений, которые существуют только у тебя в голове

💡 Хорошо объяснённая бизнес-логика - это когда после прочтения разработчик не должен угадывать, что имел в виду аналитик.
Потому что "ну я думал, это и так понятно" - это не совсем требование,
а маленькая производственная ловушка с очень милым лицом))

🖥 Как собрать требования к UI,
чтобы форма не жила своей лучшей жизнью отдельно от требований

✨ Сегодня препарируем обычную форму регистрации
и смотрим, сколько вопросов аналитик способен найти там, где нормальный человек видит три поля и синюю кнопку.

🎨 Представим макет:
😔поле Имя,
😔поле Телефон,
😔поле Дата рождения,
😔чекбокс ☑️ Согласен с правилами,
😔кнопка [Зарегистрироваться]

Ну всё вроде? Можно отдавать в разработку?
☺️ хе-хе.

👤 Поле "Имя"
С виду буквально прямоугольник.
Но аналитик смотрит на него и начинает свой допрос:

Можно написать Аня? Конечно.
а Анна-Мария?
а Ёжик?
а А?
а ?
а Анна228!!!?
А если вставить 400 символов?

И вот у бедного поля "Имя" появляется целая биография:

🤩обязательность,
🤩допустимые символы,
🤩минимальная и максимальная длина,
🤩обработка пробелов,
🤩текст ошибки

То есть вместо:

Поле для ввода имени.

получаем что-то полезное:

Обязательное поле, от 2 до 50 символов.
Допускаются буквы, пробел и дефис.
Пробелы в начале и конце удаляются.

Теперь поле хотя бы знает, кем хочет стать, когда вырастет))

📱 Поле "Телефон"
Тут отдельная вечеринка:

➡️ Какой формат показываем?
➡️ Есть маска?
➡️ Пользователь вводит 8 или +7?
➡️ Можно вставить номер из буфера?
➡️ Что произойдёт с буквами?
➡️ А иностранный номер можно?

И очень важный вопрос: когда показываем ошибку?

🤩Пока человек ещё печатает номер?
🤩После ухода из поля?
🤩После нажатия кнопки?

Потому что интерфейс, который после первой введённой цифры
начинает орать красным "НЕКОРРЕКТНЫЙ НОМЕР", немного тревожный товарищ.

🎂 Дата рождения
Здесь можно дать календарик и успокоиться.
А можно вспомнить, что пользователь способен выбрать:
09.08.2037
🤡 Поздравляем, зарегистрирован человек из будущего.
Значит, нужно определить допустимый диапазон, формат даты и, возможно, возрастные ограничения.
А ещё решить, разрешён ручной ввод или только календарь.
Такие мелочи на макете почти не заметны, зато потом именно из них состоит половина вопросов фронтенда.

☑️ Чекбокс "Согласен с правилами"

➡️ По умолчанию отмечен? Надеюсь, нет 😭
➡️ Текст кликабельный?
➡️ Слово "правила"" ведёт куда-то?
➡️ Ссылка открывается в новой вкладке?
➡️ Без согласия кнопку блокируем или позволяем нажать и показываем ошибку?

Один маленький квадратик, а уже требует собственного менеджера.

🔵 И наконец - кнопка
Вот она стоит красивая:
⏭Зарегистрироваться⏮
Но в каком состоянии?

➡️ Активна сразу?
➡️ Или только когда обязательные поля заполнены?
➡️ Что происходит после нажатия?
➡️ Показываем лоадер?
➡️ Можно нажать пять раз подряд и зарегистрировать пятерых одинаковых Анн?
➡️ При успехе куда отправляем пользователя?
➡️ А если сервер ответил ошибкой?
➡️ А если интернет умер ровно в момент отправки?

Кнопка на макете одна. Состояний у неё - маленький сериал.

🫠 А теперь главный прикол
Требования к UI - это в основном описание не того, что нарисовано, а того, чего на статичном макете вообще не видно.
Как выглядит пустая форма - видно.
А вот:
💙 что доступно разным пользователям
💙 что происходит при вводе
💙 когда элементы активируются
💙 какие есть ограничения
💙 что показываем при ошибке
💙 что происходит во время загрузки
💙 куда пользователь попадает после действия
это уже должен принести аналитик

😋 Иначе разработчик всё равно ответит на эти вопросы. Просто сам.
А потом на приёмке случится:

- А почему кнопка активна?
- Ну а где написано, что она должна быть неактивна?

И знаешь что…справедливо 😭

💡 Так что, когда смотришь на макет,
полезно мысленно не спрашивать "что здесь есть?", а мучить каждый элемент вопросами:
"Когда? Для кого? Что можно сделать? Что нельзя? Что будет, если всё пойдёт не по плану?"

После этого макет перестаёт быть красивой картинкой и наконец становится интерфейсом)

🧹 Что делает аналитик на груминге

🤔 Сегодня разбираемся, зачем аналитик приходит на груминг задачи
и почему после хорошего груминга задача должна стать скучной (в хорошем смысле)

➖Груминг выглядит примерно так:
открывается задача, команда читает описание, и через тридцать секунд начинается прекрасное:

- А если пользователь уже сделал это раньше?
- А откуда берём данные?
- А если сервис не ответил?
- Это точно входит в эту задачу?
- А дизайн вообще знает об этом?

И аналитик понимает, что задача, которая утром казалась "ну тут всё готово", обзавелась лором на три сезона...😱

🧠 Перед встречей - перечитать задачу как чужую
Главная ловушка ➡️ аналитик сам собирал требования
и поэтому автоматически достраивает недостающие куски в голове.
Перед грумингом полезно открыть задачу с настроением человека, который видит её первый раз:

🤩понятно ли, зачем это делаем?
🤩понятен ли сценарий?
🤩есть ли все условия и ограничения?
🤩описаны ли ошибки?
🤩приложены ли макеты и нужные ссылки?

🤩Если для понимания пункта надо вспомнить созвон двухнедельной давности ➡️ пункт ещё не готов.

🗣 На груминге не зачитывать ТЗ вслух
Разработчики умеют читать) Задача аналитика ➡️ быстро дать контекст:
какая проблема, что меняется и где самые важные места.
А дальше уже обсуждать вопросы команды. Особенно полезно ловить формулировки типа:

Я бы тогда просто…

🤩Вот после "просто" иногда начинается новая бизнес-логика,
о существовании которой никто пять минут назад не подозревал. 😱

🔍 Ловить дырки, а не защищать требования до последней капли крови
Если разработчик спрашивает "А что делать, если запись уже удалена?"
и ответа нет ➡️ это не нападение на честь аналитика, а отличный вопрос, который почему-то не пришёл в голову раньше.

📌Груминг как раз и нужен, чтобы разработка не начиналась с десятком таких неизвестных.
Поэтому нормальный исход встречи иногда звучит как:

Так, вот это уточню и вернусь

🤩И это намного полезнее, чем уверенно придумать правило на месте,
а вечером обнаружить, что бизнес хотел ровно наоборот.

📝 Следить за границами задачи
Очень легко начать с "добавим фильтр"
и через сорок минут обсуждать новый справочник, три метода API и переделку половины страницы.
🤩В таком случае полезно спросить:

Это точно часть текущей задачи или мы сейчас случайно родили ещё одну?

Если изменение отдельное ➡️ фиксируем и выносим.
Иначе маленькая задачка постепенно превращается в чемодан, который уже не закрывается, но команда продолжает сверху садиться...

✍️ После груминга - самое важное
Все договорённости должны переехать обратно в требования,
а не оставаться в формате "Ну мы же на груминге решили"

🤩Через месяц никто не вспомнит, что именно решили,
а разработчик, тестировщик и аналитик будут помнить три немного разные версии одного разговора.

🤩 После нормального груминга задача должна выглядеть так,
чтобы её можно было отдать человеку, которого на встрече вообще не было.

Потому что задача аналитика на груминге ➡️ не ответить вообще на каждый вопрос Вселенной,
а сделать так, чтобы к моменту разработки команда одинаково понимала,
что строим, как это должно вести себя и где заканчивается задача.

А если после встречи вопросов стало чуть больше, чем до неё - ничего страшного.
Иногда это буквально признак того, что вы наконец начали смотреть на задачу внимательно. 🙂

🧰 Agile-артефакты:
шпаргалка, чтобы не кивать на созвоне с умным лицом

📝 Сегодня разберём, какие штуки постоянно мелькают в Agile-командах и что за ними вообще стоит,
потому что в какой-то момент Backlog, DoD, Epic и Increment начинают звучать как состав очень дорогого шампуня)).

Сразу важное: Agile не выдаёт команде обязательную папку документов толщиной с диплом.
Набор артефактов зависит от процесса, а часть привычных вещей вообще приходит из Scrum, Jira и внутренних правил компании.
💥Но есть база, которую аналитику полезно узнавать в лицо 👀

🗃 Product Backlog

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

🤩Если совсем по-простому - очередь хотелок продукта.
Причём это не гранитная плита с вечными письменами.
Бэклог постоянно меняется: задачи появляются, уточняются, двигаются по приоритету и иногда тихонечко умирают где-то на 487-м месте))

🏃 Sprint Backlog

А это уже то, что команда забрала в конкретный спринт.
То есть:
Product Backlog: "когда-нибудь было бы славно сделать".
Sprint Backlog: "ребзя, вот с этим живём ближайшие две недели".

Внутри будут выбранные задачи + план работы команды для достижения цели спринта.

🐘 Epic

Большая функциональность, которую за одну задачу нормально не сделать.
Например: "Сделать интернет-магазин"
Спасибо, конечно 😭

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

📝 User Story

Короткое описание потребности пользователя:
"Как покупатель, я хочу сохранять товары в избранное, чтобы вернуться к ним позже"

Она помогает держать фокус на том, кому и зачем нужна функция.
Но User Story сама по себе не обязана содержать вообще всю логику, иначе получается:
"Как пользователь хочу кнопку"

Класс. Аналитика окончена, всем спасибо))
Поэтому рядом обычно появляются детали, бизнес-правила и критерии приёмки.

✅ Acceptance Criteria

Условия, по которым можно понять: задача действительно сделана как надо.
Например:
➡️ Пользователь может добавить товар в избранное.
➡️ Повторное добавление не создаёт дубликат.
➡️ Неавторизованному пользователю предлагается войти.

Чем понятнее критерии, тем меньше потом чудесного:
- Ну технически оно работает…
- ТЕХНИЧЕСКИ КАК ИМЕННО 👁

🏁 Definition of Done

Общее командное понимание, когда работу вообще можно назвать завершённой.
Не "разработчик закончил кодить", а, например:
разработка завершена ➡️ code review пройден ➡️ тесты зелёные ➡️ документация обновлена ➡️ задача проверена.
То есть DoD защищает от легендарного статуса:
"У меня готово, только на тест пока не выкатывается".

📦 Increment

Результат работы, который уже добавляет ценность продукту и соответствует Definition of Done.

🤩По-человечески:
кусочек продукта после выполненной работы, который реально готов,
а не существует в форме "ну ещё чуть-чуть допилить".

⏭И чтобы всё уложилось в голове⏮
➖Backlog ➡️ что можем делать
➖Sprint Backlog ➡️ что делаем сейчас
➖Epic ➡️ большая часть продукта
➖User Story ➡️ потребность пользователя
➖Acceptance Criteria ➡️ как поймём, что сделали правильно
➖Definition of Done ➡️ когда вообще считаем работу законченной
➖Increment ➡️ что в итоге готово

Вот теперь на фразу "сторю из эпика забрали из бэклога в спринт, осталось свериться с DoD"
можно не просто уверенно кивать, а даже понимать, о чём они))