Недавно я выкладывала пост с шаблоном описания элементов 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

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

У каждого свой путь. Кто-то стал системным аналитиком сразу после ВУЗа, кто-то сменил профессию, кто-то загорелся рассказами друзей из IT и решил тоже в это ввязаться)

У меня история достаточно стандартная — я устроилась на первую работу в роли СА после бакалавриата. Специальность была "Информационные системы и технологии". Дальше училась в магистратуре и параллельно работала.
А как у вас было?

👉 Опытные аналитики, расскажите, с чего начался ваш путь в IT.
👉 Новички, поделитесь, из какой вы области и почему выбрали системный анализ.

Давайте соберём коллекцию вдохновляющих историй ✨

Сегодня захотелось немного покритиковать «распиаренные плюшки» IT 😈
(ну те самые, которыми пытаются затащить человека в айти)

1️⃣ Работа прекрасна, потому что офис классный

В ленте часто вижу видео, где айтишники рассказывают о прекрасном офисе. Что работа в IT — сказка, посмотрите, какой у нас спортзал, массаж по записи, автомат Вкусвилл с едой, на кухне печеньки, кофемашина, психолог, чиллинг зоны. Можно работать лёжа, сидя, стоя. Есть капсулы для сна. Поработать сегодня на пуфике или в уединённой кабинке? А может пойти на крышу или в переговорку?

👉 Офис правда классный и комфортный. Сюда приятно приходить, наливать кофе, брать печенье и посидеть утром на пуфике.
НО! После дейли начинается череда созвонов, задачи, сроки, чаты с миллионом вопросов. Опомниться успеваешь только к обеду. А после обеда бешеный ритм продолжается.
До спортзала вообще доходят единицы (я ими искренне восхищаюсь 🤝, вообще всеми, кто может использовать офис на максимум).

2️⃣ Можно работать в кофейне и пить капучино на кокосовом. Можно работать у бассейна или прямо в бассейне

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

А какие «плюшки в IT» вам кажутся самыми забавными? 👇