☹️ Типовые факапы в интеграциях и как их избегать

🔴Интеграции штука вроде бы простая, но на деле часто подкидывает сюрпризы.🙏
Вот сидишь на груминге, всё выглядит максимально безобидно:

👉 взять данные из соседней системы
👉 другая команда даст апишку
👉 мы вызовем метод
👉 и нужные данные отобразятся

Звучит как задача на пару дней)
⚪️А потом (как обычно) оказывается, что у интеграции свои законы.

За несколько лет работы мы заметили, что большинство проблем возникает вокруг одних и тех же вещей ↘️

📌Факап №1.
Никто не договорился, кто за что отвечает

😔 Самый популярный сценарий:
одна команда считает, что поле должно заполнять другая команда,
вторая команда считает ровно наоборот.
Итог? Поле пустое, сроки уже горят,
а на созвоне человек десять судорожно пытается понять, чья же это, в конце концов, головная боль.😠

Поэтому на этапе проектирования полезно задавать скучные вопросы:
👉 кто владелец данных?
👉 кто отвечает за их хранение?
👉 а за актуальность кто?
👉 кто исправляет ошибки?
Чем раньше мы расставим все точки над "и", тем меньше потом будет сюрпризов.

📌 Факап №2.
Интеграцию проектируют по счастливому сценарию

😔 Очень часто обсуждается только вариант:
запрос отправился 👉 ответ пришёл 👉 пользователь счастлив.
😔 Но реальная жизнь почему-то любит другие сценарии:

👉 что если сервис вдруг недоступен?
👉 или ответ придёт не сразу, а через полминуты?
👉 а если вдруг статус вернётся совсем не тот, что мы ждали?
👉 что, если пришла пустая структура, хотя должна быть?
👉 или данные вроде есть, но заполнены как-то не полностью?

Именно поэтому один из самых полезных вопросов на обсуждении интеграции:
"а что будет, если всё пойдёт не по плану?"

📌 Факап №3.
Документация не совпадает с реальностью

😔 Любой аналитик хотя бы раз открывал документацию,
видел поле string, а потом получал в него целый массив объектов...😒
😔 Или спека обещала один набор данных, а реальный ответ АПИ принёс ещё двадцать полей сверху.😐
‼️Так что, если есть хоть малейшая возможность, проверяйте методы сами.
Постман в этом плане очень быстро помогает понять, где вы находитесь

📌 Факап №4.
Все считают, что данные всегда будут идеальными

👉 ИНН без ИНН
👉 дата без даты
👉 пустые строки вместо значений
👉 лишние пробелы
👉 неожиданные спецсимволы
👉 дубликаты
Если данные приходят из внешней системы, рано или поздно кто-нибудь обязательно пришлёт что-нибудь интересное.
Вопрос лишь в том, когда это случится)

📌 Факап №5.
Забыли про версионирование

😔 Пока интеграция новая, всё отлично.
Но пройдёт год, появится новая версия метода, а потом ещё одна.
Кто-то решит изменить структуру ответа.
😔Потом начинается археология:
"Ээ, а какой контракт сейчас используется в проде?"
📏📏📏📏📏📏📏📏

👌Поэтому все изменения в АПИ лучше обсуждать сильно заранее и обязательно где-то фиксировать,
иначе однажды можно узнать о новой версии метода прямо из упавших логов,
которые внезапно покраснели.☺️

🌱 А ещё - большинство проблем в интеграциях связаны не с кодом)
Они появляются на этапе, когда команды что-то не договорили, не уточнили или решили проверить потом.
🌱 Вот почему хорошая интеграция начинается совсем не с написания АПИ,
а с кучи, порой неудобных, вопросов.

🤪 Как проводить интервью с пользователями

❌Если дать аналитику документацию, он найдёт ответы.
❌Если дать аналитику доступ к базе, он найдёт ответы.
❌Если дать аналитику логи, он тоже найдёт ответы.
👉 А вот попробуй посадить аналитика напротив пользователя и скажи:
"разберись, как он работает" - тут-то и начинается совсем другая игра.⏳

Ведь пользователи редко говорят все как есть.
А бывает, что и вовсе рассказывают не то, чем занимаются на самом деле.😏

ℹ️Вот спросишь, скажем: "как часто этой функцией пользуетесь?",
а в ответ: "почти каждый день!"
Откроешь потом статистику, а там последний раз человек заходил три месяца назад...
и такие штуки происходят постоянно.
🤩Так что хорошее интервью – это не просто проход по списку вопросов.
Это, по сути, попытка вытянуть наружу, как человек реально себя ведет, что делает.

📌Ошибка №1: спрашивать, что пользователь думает, а не что он делает.

✖️Плохой вопрос: "Вам удобно работать с системой?"
👌Хороший вопрос: "Покажите, как вы выполняли эту задачу в последний раз."

В первом случае человек начнет рассуждать, давать оценку.
Во втором – покажет, что происходит на практике.
А практика, как правило, намного интереснее, чем любые рассуждения..

📌Ошибка №2: самому подсказывать ответы.

⭐Пример диалога:
- Вам было сложно найти эту кнопку?
- Наверное, да.
- А если бы мы перенесли её наверх, стало бы удобнее?
- Наверное, да.
Через пять минут такое интервью превращается в игру, где надо угадать правильный ответ, который ждет аналитик.
Чем меньше подсказок в вопросе, тем лучше. 👀

📌Ошибка №3: говорить больше, чем пользователь.

Парадоксально, но иногда аналитик занимает процентов восемьдесят времени интервью.
Объясняет, уточняет, рассказывает про будущие доработки, делится идеями.
А потом встреча заканчивается, и оказывается, что про пользователя почти ничего нового не узнали.👊

📌Ошибка №4: искать подтверждение своей идеи.

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

📌Ошибка №5: не попросить показать.

Самые полезные фразы на интервью:
"Покажите, пожалуйста"/"А можете продемонстрировать?"/"Как это выглядит в системе?"

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

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

📄 Файловые интеграции: старо, но работает

🤩 Многие начинающие аналитики представляют свою работу как проектирование современных систем с REST API, Kafka и т.д.
Кажется, что весь айти мир 🤩 это сплошной поток данных в реальном времени.

🤩 А потом такой специалист попадает на реальный проект
и слышит от коллег:

Значит так, раз в пятнадцать минут мы забираем XML-ку с того FTP-сервера, а после обработки кладем ответ в папку рядом.

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

🤩Почему это до сих пор живет? Все дело в простоте.
Эта схема настолько элементарна, что может стабильно работать десятилетиями.
Одной стороне нужно просто создать файл, другой его забрать и прочитать.
Не нужно поддерживать постоянное соединение, не нужно переживать, доступна ли вторая система прямо в эту секунду.
👌Принцип "положил и забыл" в определенных условиях работает идеально.

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

🪵 как система должна реагировать на дубликаты файлов?
🪵 можно ли обработать документ, если из нескольких тысяч записей в нем некорректна только одна?
🪵 каким образом подтверждать успешное получение данных или сообщать об ошибках?

🤩 Особое внимание здесь уделяется схеме данных.
Если в REST можно открыть Swagger, быстро дернуть запрос и посмотреть ответ, то здесь весь контракт зашит в структуру файла.
Лишний атрибут, не тот формат даты или какой-то странный символ в строке - и процесс встанет.

🙆‍♂️ Для опытного специалиста файлы ➡️ это не устаревшая технология, а прагматичный инструмент.
В нем нет хайпа или сложной событийной архитектуры, но есть стабильность.

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

🗂 Логи - это то место, куда аналитик приходит после того, как закончились версии.

Расследование любой проблемы в интеграциях обычно начинается одинаково:
кто-то пишет: "не работает" и всё...😳
Нет подробностей, ошибок, нет картинок с экрана. Просто не работает.😒

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

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

💙 И вот тут открываются логи. В логах видно:
💙запрос даже не ушёл вовне, потому что его не пустила внутренняя проверка
💙или всё ушло, но там вернулась ошибка
💙или же всё прошло как надо, а проблема в показе данных
Хорошо запоминаются случаи, когда уже нашли, кто, кажется, виноват.

✔️ Почти написано письмо, приготовлены слова, люди ждут на звонок
и в голове готово объяснение, почему проблема у соседей.
😥 Но логи показывают, что ошибка у нас...
Становится неловко, но зато время сэкономлено.

🤩Со временем понимаешь: логи - это не только для тех, кто пишет код.
Для аналитика - это один из самых быстрых путей найти, что случилось:
🤩пользователи могут ошибиться,
🤩люди на звонке могут только гадать
🤩документация может быть устаревшей

🤩А логи обычно всё честно показывают и рассказывают:
когда пришёл запрос, что было внутри, куда всё ушло, что вернулось назад
и где именно всё пошло не так.

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

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

❔ Зачем аналитику нужны юнит-тесты и стоит ли лезть в код

💀 Братва, у меня плохие новости..кажется, я начал читать код.

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

Потом открывается метод..в методе вызывается другой метод, в другом методе ещё один..
какой-то Helper, потом AbstractManager, потом ProviderFactory, потом ManagerProviderFactoryExecutor.
Уже начинает казаться, что разработчики соревнуются между собой, кто придумает название класса страшнее.😋
😔 Через сорок минут ты уже сидишь в таких дебрях, что сама система смотрит на тебя с уважением.

🤩 У аналитиков есть страшилка о том, что если открыл код, то всё, приехали...
теперь нужно срочно учить Java, писать микросервисы и спорить в комментариях про архитектуру.

✋ Да нет же!
Никто не ждёт, что ты будешь переписывать бэк по вечерам вместо просмотра сериала))
Но вот понимать, что происходит внутри системы, иногда бывает очень полезно.
Потому что:
🤩документация говорит одно,
🤩разработчик на созвоне говорит второе,
🤩тестировщик говорит третье.
А код тем временем:
🤩Хаю хай, кожаные, сейчас расскажу, как тут что работает. 😔

🤩И знаете, что я обнаружил?
Самая интересная штука часто вообще не код.
Самая интересная штука это юнит-тесты.

🧐 Я раньше относился к ним примерно как к брокколи:
вроде полезно, но добровольно не полезу))
➡️ А потом открыл несколько тестов и понял, что это буквально шпаргалка от разработчика самому себе.

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

Иногда один тест рассказывает о системе больше,
чем документ, который последний раз обновляли во времена,
когда Internet Explorer ещё считался браузером.😬

Более того,
именно в тестах часто находишь всякие приколы, например:
💙 в требованиях про ограничение никто не написал.
И документации про него ни слова, и на демо его никто не показал.
Зато в тесте гордо лежит проверка на этот кейс.
И ты сидишь такой:
- ах вот где ты прятался, маленький засранец))

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

А это, между прочим, две очень разные лиги 😏

🚨 Тот самый аналитик, который всех бесит на созвонах

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

Например, ситуация ➡️ вы обсуждаете⏭новую фичу⏮
😔разработчик говорит, что все понятно и они сделают,
😔тестировщик подтверждает готовность,
😔продакт уже хочет закрывать встречу и бежать дальше.
Все мысленно уже вышли из звонка. 🤤

🌱 И тут наш красавец⏮аналитик⏭:

🤔 А что будет, если пользователь откроет сразу две вкладки?

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

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

🤦‍♂️ Остальные участники начинают смотреть на него так, будто он лично решил испортить им вечер..

🤩Но на самом деле это обычная профдеформация.
Там, где все видят просто новую фичу, аналитик видит потенциальное место катастрофы.

🤩Можно сравнить это с тем, что внутри аналитика живет такой маленький тревожный хомяк:
Пока команда радуется, как все круто получилось,
этот хомяк в голове аналитика носится в колесе и паникует:

😱 А ЕСЛИ ПОЛЬЗОВАТЕЛЬ СДЕЛАЕТ КАКУЮ-ТО ДИЧЬ???

И ведь пользователь эту дичь обязательно сделает)) причем в первый же день после релиза.

😒 У пользователей будто есть какой-то секретный чат,
где они договариваются проверять самые дебильные сценарии, которые нормальному человеку в голову не придут.

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

🚨🚨 КОЛЛЕГИ, У КОГО ЕСТЬ ИНФОРМАЦИЯ? 🚨🚨

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

🤩 Так что, когда в следующий раз аналитик снова начнет докапываться до мелочей на созвоне, не спешите закатывать глаза.
Возможно, прямо сейчас он предотвращает ваш будущий созвон в 8 утра с темой:
"Разбираем последствия вчерашнего релиза" 😒

😵‍💫 Рабочий день аналитика, или как не словить выгорание раньше дедлайна

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

🔫 Обычно эта уверенность живет минут семь.
🤩Потом пишет разработчик,
🤩следом прилетает вопрос от продакта про старые задачи,
🤩а там и внезапный созвон подоспел + созвон после созвона

И вот ты уже полдня честно работаешь,
но документ, который открыл утром, всё ещё грустно смотрит на тебя с первой строчки.😞
🫠 Я долго думал, что со мной что-то не так.
Ну не может же человек четыре часа работать и за это время написать...примерно ничего.

❗️Но потом стало понятно, что работа аналитика в реальности устроена иначе.
Чаще это не тишина и глубокая концентрация, а наоборот...
постоянные попытки собрать мысли в кучу, пока тебя дёргают с "есть 5 минуток?".😳
И ведь никто ведь не врёт, у всех реально "на пять минут",
просто существует закон айти, по которому пять минут автоматически конвертируются в сорок))

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

💡 И в итоге я сделал вещь, за которую прошлый я бы меня не понял:
перестал отвечать на каждое сообщение сразу. 
Да, да)) дал себе правило сначала закончить текущую фразу или мысль, а уже потом лезть в чаты.

✳️ Сначала казалось, что это подставит команду,
но знаете, что на самом деле произошло? Да ничего))
Никто не уволился, процессы не встали, разработчики не начали писать код на салфетках в ожидании моего ответа.
✳️ Зато я перестал переписывать один и тот же абзац требований по четыре раза,
потому что меня дёрнули ровно в тот момент, когда я наконец-то понял, как его сформулировать.

⏭В общем, мысль такая⏮
выгорание часто берется не от самого объема работы, а от этого бесконечного переключения между контекстами.
Поэтому иногда самая полезная задача на день - это... дать себе спокойно закончить хотя бы одну мысль. 
Звучит как читерство, но работает. 😌

📝 Методы сбора требований: почему выучить названия вообще не самое сложное.

⬇️Когда начинаешь в системном анализе,
⬇️то кажется, что самое важное - выучить теорию:
интервью, воркшопы, анкетирование, наблюдение.
🫦 Звучит солидно, на собеседовании помогает,
но на первой же реальной задаче все эти знания часто рассыпаются. 😫

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

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

🤩Описание API, старые постановки, документация - все это уже может лежать в базе.
Порой проект знает о себе больше, чем люди, которые над ним работают,
стоит сначала поискать ответы внутри системы, а не бежать сразу к людям.
🤩И может случиться так, что документация оказывается куда разговорчивее участников встречи)

🔖 Другая история: когда пользователь жалуется, что ему неудобно работать.
✳️ Можно долго засыпать его вопросами о том, когда именно это началось и что конкретно не так.
✳️ А можно просто попросить показать, как он выполняет свои задачи.
И вуаля, через пять минут наблюдения понимаешь больше, чем за час интервью.

🔖 И любимый момент: когда на встрече собираются пять человек и каждый по-своему описывает один и тот же процесс.
Спустя время оказывается, что общего понимания нет ни у кого.
✳️ Тут и спасают воркшопы, т.к. иногда полезнее всего просто собрать всех в одной комнате и дать им возможность поспорить друг с другом.
В таких дискуссиях требования выкристаллизовываются гораздо быстрее, чем в серии одиночных бесед за неделю.

💡 Вообще со временем понимаешь, что методы сбора требований - это просто инструменты, как молоток или отвертка.
Никто же не режет хлеб отвёрткой. Хотя...наверняка кто-то и так делает. 😅

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

📝 User Story:
почему фраза "Как пользователь, я хочу..." ещё ничего не значит

Когда впервые слышишь про User Story, думаешь, что это элементарная штука:
➡ достаточно взять шаблон:

Как <роль>, я хочу <действие>, чтобы <ценность>

➡ подставить нужные слова
➡ и пойти пить кофе.
Кажется, что работа сделана. 😎
Но потом приходит разработчик, читает это предложение и спрашивает: "а делать-то что конкретно?" 🤨

Проблема здесь в том, что User Story порой путают с техническими требованиями.
На самом деле она их не заменяет, её задача ➡ объяснить, зачем эта фича вообще нужна.
➖Возьмём пример:

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

Класс, но...
Какой формат? Кто может скачать? Есть ограничения по размеру? Что делать, если отчёт ещё не сформировался?
➖Получается, что User Story ответила только на один вопрос: "зачем?"
➖А вопросы "что?" и "как?" всё ещё лежат и грустят. 😢

🤩 Хорошая User Story ➡ это не попытка впихнуть все требования в одно предложение, это скорее заголовок фильма:
вы понимаете, о чем пойдет речь, но самого сюжета еще не видели.

💡 И тут важно вспомнить про
➿acceptance criteria➿
Именно они превращают красивую хотелку в понятную задачу.
⬇️Например, если мы пишем User Story:

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

⬇️И сразу рядом критерии:
🔵 ссылка действует 24 часа
🔵 повторно использовать её нельзя
🔵 после смены пароля старый перестаёт работать
🔵 если токен просрочен - показываем ошибку

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

Вообще есть очень простой способ проверить свою User Story.

⬇️
⬇️
⬇️
➡️ Закройте всё, кроме одного предложения, и задайте себе вопрос:
"Если убрать все остальные требования, разработчик сможет реализовать фичу?"

✅Если ответ "да" - скорее всего, вы случайно написали не User Story, а полноценное ТЗ))
✅Если ответ "нет" - всё нормально, значит, User Story выполняет свою работу)

📎Она объясняет ценность, а детали живут рядом и именно так с ней работать гораздо приятнее,
потому что User Story перестаёт быть формальностью ради Скрама
и становится нормальной отправной точкой для обсуждения фичи. 😉

👍 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 и переделку половины страницы.
🤩В таком случае полезно спросить:

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

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

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

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

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

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

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