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

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

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

Если ТЗ для дизайнера изначально было не очень,
то даже самый красивый макет вряд ли вытянет ситуацию.

🔵Красиво это как? Современно это как?
🔵Кто вообще пользователь? Что он делает?
🔵Какие ограничения есть?
🔵Это новая страница или переделка существующей?
🔵Что обязательно должно остаться?
🔵Есть ли ошибки? Есть ли роли? Есть ли состояния?

📌Что делаем:
Не "новый экран".
А: страница регистрации для новых поставщиков

📌Зачем делаем
Не "так захотел бизнес".
А: "сейчас пользователи не понимают, какой вариант регистрации выбирать, из-за чего растёт количество ошибок".

📌Кто пользователь
Новичок? Опытный пользователь?

📌Какой сценарий проходит человек
Нажал кнопку → открыл страницу → ввёл данные → получил результат

📌Все состояния
Загрузка, Ошибки, Пустые данные, Успех, Ограничения

📌Что нельзя менять
Вот этот пункт почему-то регулярно забывают 🙂
А потом оказывается:
"Ой, этот блок нельзя трогать, он приходит из другого сервиса"
или
"Ой, здесь юридический текст обязателен"
или
"Ой, эта кнопка завязана на старую логику"

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

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

💭 ER диаграмма помогает разобраться с данными.
Вы смотрите на нее и понимаете, какие сущности есть в системе, как они связаны и где лежат.
✅ Это очень выручает, когда вы раскапываете новую для себя систему или проектируете изменения в базе данных.

💭 USM позволяет разложить крупную задачу на понятные пользовательские сценарии.
✅ С ней гораздо проще договориться, что реально нужно для первой версии продукта,
а что можно спокойно отложить на потом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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