Был я как-то на груминге, где аналитик 40 минут читал команде описание задачи из Jira
В конце спросил:
- Всё понятно?
- Да
А на следующий день началось:
- А что делать при ошибке?
- А эта система тоже меняется?
- А кто вообще может запускать процесс?
- А бизнес точно это согласовал?
И появился второй груминг под названием «давайте быстро созвонимся» 🤡
Проблема в том, что многие воспринимают груминг как презентацию готового ТЗ
Но его задача - проверить, одинаково ли аналитик, разработчики и тестировщики поняли будущую реализацию
Как я бы проводил груминг:
📍1. Объяснить цель
Не: «Добавляем параметр
deliveryType»
А: «Сейчас клиент не может выбрать курьерскую доставку, поэтому оператор оформляет её вручную. Хотим перенести этот сценарий в приложение»
Команда должна понимать не только что меняется, но и зачем
📍 2. Зафиксировать границы
Сразу проговорить:
- что входит в задачу
- что не входит
- какие системы меняем
- какие сценарии оставляем на потом
Иначе разработчик оценит один метод, тестировщик - весь процесс, а бизнес будет ждать ещё три экрана
📍 3. Показать основной сценарий
Например:
Выбор доставки → Проверка адреса → Расчёт стоимости → Создание заказа
Одна понятная схема часто полезнее пяти страниц текста
📍 4. Разобрать, где всё может пойти не так
- внешняя система не ответила
- адрес не обслуживается
- цена изменилась
- пользователь отправил запрос дважды;
- часть операции выполнилась, а часть упала
Именно на исключениях обычно находится половина пропущенных требований
📍 5. Вынести открытые вопросы
Не нужно делать вид, что всё известно
У каждого вопроса после встречи должны появиться:
- ответственный
- срок
- место, где будет зафиксировано решение
Иначе это не открытый вопрос, а будущий блокер
📍 6. Проверить, как команда поняла задачу
Вопрос «всем всё понятно?» не работает
Лучше спросить:
- Какие компоненты придётся изменить?
- Какие риски вы видите?
- Что будем тестировать?
- Чего не хватает для оценки?
Если команда может своими словами объяснить реализацию - значит, общий контекст появился
Перед встречей можно пройтись по простому шаблону:
Цель → Границы → Основной сценарий → Исключения → Открытые вопросы → Риски
Такой груминг помогает:
✅ точнее оценивать задачи
✅ находить дыры до разработки
✅ уменьшать количество внезапных созвонов
✅ снижать число переделок
И главное:
Хороший груминг - не тот, на котором не было вопросов
Хороший груминг - тот, на котором нужные вопросы задали до начала разработки, а не за день до релиза