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

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

📌 Почитайте, если вы сейчас на распутье или хотите лучше понять свою роль:
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» вам кажутся самыми забавными? 👇

Аналитики с опытом 1–3 года часто критикуют себя такими мыслями:
- Я тупой.
- Когда же я наконец почувствую уверенность в себе?
- Когда же я наконец пойму, что мне делать по задачам?
- Почему опять пришла задача, с которой я не сталкивался раньше?
- Настанет вообще момент, когда я буду всё знать?

Если честно, такой момент не настанет 😅, и это просто нужно принять.

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

Просто это суть работы айтишника. Мы должны понимать, что всё постоянно меняется, мир меняется. Нельзя всё выучить, нельзя знать всего. Это не минус, а часть профессии.
Разбираемся по мере поступления проблем. И это касается не только джунов и мидлов, но и сеньоров, и даже руководителей.

Просто выдыхаем и учимся спокойно к этому относиться ☘️.
Я тоже учусь.

Корпоративный этикет: когда хочется кричать 🥲

Этикет — это, конечно, хорошо. Но:

- Сообщение от коллеги в корпоративном мессенджере «Привет! как дела?» — просто давай ближе к делу... Мы не друзья, да и будем откровенны, тебе всё равно, как у меня дела.

- 5 минут приветствий и благодарностей в начале встречи на большое число людей. «Спасибо, что подключились!», «Спасибо всем, кто…» — ладно, может это и приятно, если хватят тебя, но что делать остальным? 😅

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

- 15 минут пишешь письмо, ещё 15 проверяешь его на ошибки, ещё 5 нужно, чтобы сделать текст вежливым, ещё 5 на то, чтобы решиться отправить — лучше бы поработали, честное слово. В итоге всё равно находишь какую-то дурацкую опечатку.

- Вопросы на собеседовании вроде «Как вы относитесь к переработкам?» — все понимают, что нужен «правильный ответ», что вы за проект горой, да и личная жизнь подождёт. Попробуй скажи честно — опрокинут (у меня был такой опыт 😬).

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

Кто пополнит список? 😂