Системный аналитик, конечно, не дизайнер, но с макетами пользовательского интерфейса мы работаем постоянно ❗

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

Недавно наша подписчица София поделилась своей историей — как она работает с макетами, и почему это делает именно она 😉

Публикуем 👇

Привет, подписчики AnalystCore!
Я уже почти 2 года работаю системным аналитиком в заказной разработке на крупном госпроекте. В первый месяц работы мой наставник спросил меня: «А ты хорошо рисуешь? Как у тебя с фигмой?» 😉. Я ответила, что в принципе нормально, научусь, готова попробовать. У нас в команде нет закрепленного дизайнера, но есть подобие дизайн-системы, которой все пользуются.

Вначале он давал мне конкретные указания, что нужно добавить на макет «Добавь это поле на вторую строку, назови примерно так-то». Позже вводных становилось меньше, и моя работа изменилась:
Собираю у наставника требования, далее сама определяю, какие поля нужны, с каким типом они будут, ищу и потом согласовываю сколько символов можно вводить, какие и прочее. Если поле с выпадающим списком, прорабатываю справочники. После создания макета согласовываю его и описываю все элементы по шаблону в конфлюенсе. Вношу доработку в описания сервисов (так у нас называются методы апи), ставлю задачу, отдаю на ревью наставнику.

Практически через 3 месяца мне начали поручать все задачи, связанные с пользовательским интерфейсом) У наставника не очень с фигмой, а другой аналитик всегда описывал только сервисы. Так что я заняла свое место и получила ответственность за свой кусочек в системе)
На самом деле, мне очень нравится работать с UI. Мне изначально это было проще. Через продумывание макетов, мне проще понять, как должна работать система. И именно после макетов проще понять, как нужно доработать сервис.

А вы сталкивались с подобными задачами? Делитесь в комментариях, интересно узнать ваш опыт 😊

#requirements #mockups

Недавно я выкладывала пост с шаблоном описания элементов UI.
В продолжение этой важной темы - ловите подборку наших полезных постов про постановку на фронт.

Сохраняйте, пригодится 👇

📌 Юрий поделился, что разработчики хотят видеть в задаче на фронт?
📌 Пример описания страницы «Акция» в приложении для инвестиций
📌 Нет ничего лучше конструкции Если — То — Иначе при описании логики работы системы
📌 Пример плохой постановки на фронт и как исправить
📌 Фронт ждет проработку альтернативных сценариев
📌 Как работать с альтернативными сценариями
📌 Кэширование данных на фронтенде
📌 Single Page Application (SPA)
📌 Local Storage и Session Storage
📌 Насколько кэшировать данные?
📌 Пример разделения команд на: web, ios, android, сервисы

🛠 Сделайте чек-лист по своему проекту, чтобы не забыть все точки входа

Немного про организацию своей работы. Часто при проработке задачи мы забываем про какую-то часть системы. Решение — составить чек-лист по вашему проекту: «что не забыть учесть?»

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

✅ добавить поле в UI
✅ добавить поле в БД
✅ передавать параметр в контракте между фронтом и бэком
✅ учесть в контракте с внешней системой_А
✅ учесть в контракте с внешней системой_Б
✅ передаётся ли поле в отчёты?
✅ передаётся ли в письма?
✅ влияет ли поле на функциональность_А?
✅ влияет ли на функциональность_Б?
✅ если поле обязательное — чем заполнять для существующих записей?
...и так далее.

Такие чек-листы не только упрощают жизнь, но и делают ваши задачи намного качественнее.

💬 А у вас есть свои приёмы? Поделитесь, какие лайфхаки помогают вам не забыть ничего важного при проработке задачи?

#requirements #лайфхаки

🧠 Тема, которая часто вызывает вопросы: чем отличается бизнес-аналитик от системного и почему в вакансиях под "бизнес-аналитиком" часто на самом деле имеют в виду системного?

Я как-то писала короткую статью с моим мнением на этот счёт.

📌 Почитайте, если вы сейчас на распутье или хотите лучше понять свою роль:
https://analystcore.com/knowledge-base/differences-between-system-and-business-analyst

🧩 Как оформить задачу на разработку справочника?

Казалось бы, простая задача — сделать справочник. Но как оформить это в ТЗ?

Предлагаю такой вариант оформления 👇

1️⃣ Описываем значения
Создайте страницу в Confluence, где зафиксируете все значения справочника. В задаче на разработку в Jira дайте ссылку на эту страницу.

2️⃣ Уточняем ответственных
Кто будет отвечать за актуальность справочника? Узнайте, как часто он будет меняться, и зафиксируйте это прямо на странице в Confluence.

3️⃣ Если справочник будет меняться
Имеет смысл продолжать вести его значения в Confluence. Это упростит поддержку и добавление новых значений.

4️⃣ Если справочник фиксированный
После реализации укажите, что актуальные значения будут храниться, например, в таблице some_table в БД. Добавьте: «За данными обращаться к [имя/роль]».
А страницу в Confluence после этого можно перенести в архив.

💬 Если у вас есть свои приёмы или шаблоны оформления справочников — делитесь в комментариях.

#requirements #documentation

🛠 Давно не было мини-лайфхаков — ловите!

Описывайте логику обработки ошибок подробнее.
Не пишите в ТЗ обтекаемо: «если ошибка — показать сообщение».
Уточняйте детали. Это важно и для фронта, и для бэка, и для тестирования.

Что стоит уточнить:
— при каком HTTP-коде или бизнес-коде ошибки выводим сообщение
— какое именно сообщение должно быть показано (желательно с текстом или ключом из ресурс-файла)
— ссылка на макет, если отображение нестандартное
— сколько секунд показывать сообщение (особенно если это toast-уведомление)
— любые другие нюансы, важные для вашего проекта

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

#лайфхаки #requirements

В последнее время мы обсудили много интересного!

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

📌 Как вести историю изменений в требованиях?
📌 Короткие советы по тому, как описывать логику обработки ошибок
📌 Как оформить задачу на разработку справочника?
📌 Техника «5 почему» для сбора требований
📌 Чек-лист по своему проекту, чтобы не забыть все точки входа
📌 Подборка постов, как качественно описать задачу на фронт
📌 Чем отличается бизнес-аналитик от системного аналитика
📌 Где может работать системный аналитик?
📌 Что делает системный аналитик в банках?

Как сочетать Use Case с другими артефактами и разделами в документации?

Предлагаю один из вариантов, как можно включить Use Case в вашу документацию👇

1️⃣ Шаблон предполагает ведение большинства функциональных требований в формате Use Case.

2️⃣ Если в Use Case предполагается использование экранной формы, то в шаги включается отображение этой формы со ссылкой на отдельную страницу с её описанием (GUI). Ранее я давала шаблон описания элементов интерфейса.

3️⃣ Если к Use Case вы хотите добавить диаграмму, это тоже возможно. Просто на странице этого Use Case создайте внизу раздел «Детализация требований» и добавьте диаграмму туда.

4️⃣ Если в Use Case предполагается отправка запроса, добавьте шаг, описывающий этот момент, и дайте ссылку на страницу с описанием API (метод, сценарий, входные/выходные параметры, коды ответа и т.д.)

5️⃣ Как сочетать User Story и Use Case при таком подходе?
В задаче в Jira укажите формулировку User Story, а затем добавьте раздел «Вспомогательные материалы». Сюда входят все связанные требования из Confluence: ссылки на Use Case, GUI, требования в произвольном формате и пр. Это и будут критерии приёмки вашей User Story.

#requirements

Часто бывает так, что один и тот же кусок логики используется в нескольких требованиях. Классический способ избежать дублирования — вынести общее описание на отдельную страницу и в других требованиях написать: «см. Общие требования такие-то».
Это работает, и всех это устраивает. Но бывают случаи, когда не хочется уводить читателя документа со страницы, и хочется показать ему всё описание здесь и сейчас. Для таких случаев в Confluence есть макросы «Excerpt» и «Excerpt Include».

Пример использования смотрите на картинке 👆

#requirements

Про названия параметров в документации 🤔

В последнее время я часто замечаю, что у многих названия параметров в документации и в реализации сильно отличаются. Да, такое бывает, не уследили, или просто не успели обновить. Но это объясняют тем, что в документации у нас «требования», а в сваггере «реализация». Это 2 разных мира, и мы не обязаны синхронизироваться.

Я думала над этим вопросом, и всё-таки, не могу это принять.
У меня вопрос, а что делать командам, которые являются потребителями вашего контракта?

Представьте, системному аналитику кидают в Confluence контракт с описанием параметров: как они называются, какой тип, какие правила валидации. Для нас это источник правды.
Мы же дальше несём это описание в свою команду и гарантируем, что параметр будет называться именно discountPercent и означает размер скидки в процентах, целое число.
А в реализации вдруг другое название. Что теперь?

Вижу три выхода из ситуации:

1️⃣ Синхронизировать названия. Если параметры описаны и в документации, и в сваггере, они должны совпадать.

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

3️⃣ После реализации удалить параметры из доки и оставить ссылку на сваггер. В документации останется только логика работы метода, примечания, интеграционный use case, а параметры и коды ответа будут в сваггере. Но этот вариант работает, только если сваггер оформлен нормально.

Мы, как аналитики, не должны вводить в заблуждение коллег из смежных команд. Давайте следить за актуальностью документации. Выходы есть. 😉

#requirements