Как я начинала собирать требования?

Привет! 👋
С вами Вера, основатель AnalystCore.

Моим первым местом работы был стартап в сфере страхования.

🗣️ На старте я работала с экспертами по страхованию, тех.поддержкой и ген.директором. В основном, проводила интервью — готовилась к совещаниям, оформляла свои идеи в виде схем и задавала вопросы.

📊 Перед интервью готовила прототипы UI, а прототипирование — это тоже метод сбора требований (но и метод анализа требований).

👀 Мы приглашали пользователей в офис! Наблюдали, как они используют продукт, что им нравится, а что раздражает.

📜 Без анализа документов тоже не обошлось. Изучала все, что попадалось: старые спецификации, схемы, презентации.

🔍 А еще проводила анализ аналогов — ходила по сайтам страховых компаний, регистрировалась и смотрела, как у них устроен процесс покупки страховки.
Кстати, отголоски этого опыта есть до сих пор. Мне до сих пор приходят предложения оформить ОСАГО на машину, которой у меня нет! 😂

#requirements #sa_dev

Не всегда очевидно, какие аналоги анализировать 🤔

Привет! 👋
С вами Вера, основатель AnalystCore.

В продолжение темы методов сбора требований хочу отметить «анализ аналогов».

В далёком 2020 у меня был опыт работы в довольно специфической сфере — мы делали судебную систему. Через неё сотрудники банков могли подавать обращения в суд о взыскании кредитной задолженности и пр.

Где найти аналог будущей системы? На что опираться? Есть ли уже подобные системы? Как получить к ним доступ, где взять логин и пароль?

Вне зависимости от предметной области стоит узнать у заказчика, а на какой продукт мы ориентируемся, есть ли конкуренты, какие системы нравятся?

💡 Так заказчик нам поможет и сам подскажет, какие системы нужно «пощупать» и взять за ориентир! Но помним, изучить аналоги недостаточно. Мы не знаем, как их система работает «под капотом», какие есть нюансы. Из такого метода нельзя понять все требования.

#requirements #sa_dev

Где может работать системный аналитик?

На самом деле, где угодно 👇

В IT-компаниях, банках, ритейле, страховании, маркетинге, логистике, госсекторе, медицине — и вообще везде, где разрабатывают цифровые продукты.

IT — это не только Яндекс, Сбер и Т-Банк.
Это тысячи компаний, которые делают сервисы, сайты, мобильные приложения, внутренние системы.

Лишь крошечная часть примеров, над какими приложениями могут работать системные аналитики:
✈️ Путешествия: Островок, Суточно.ру
🚆 Поездки: OneTwoTrip, Aviasales, РЖД
🛫 Авиакомпании: Аэрофлот, Победа
🎟️ Развлечения: Kassir.ru, Okko
🛒 Продукты: Лента, Самокат, Перекрёсток, Пятёрочка
📦 Маркетплейсы: Wildberries, Ozon
🛡️ Страхование: Росгосстрах, Ингосстрах, РЕСО
🏡 Жильё: ПИК, ЦИАН
📲 Объявления: Авито, Юла
🏦 Банки: Газпромбанк, Райффайзенбанк, Россельхозбанк
📡 Связь: МТС, Билайн
🧑‍💼 Поиск работы: hh.ru
🏛️ Госуслуги: госуслуги.ру, налог.ру

Везде, где нужно что-то разрабатывать, работают системные аналитики. Спрос на данную профессию только растёт. И это радует 💪

#dev_process

🏦 Что делает системный аналитик в банках?

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

1️⃣ Приложения для клиентов

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

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

💳 А ещё в банковских приложениях могут быть модули, связанные со страхованием, покупкой билетов на концерт, бронированием отеля и пр. — то есть всем тем, что мы привыкли видеть в современных финтех-сервисах.

В каждой команде требования разные, но в целом — необязательно до этого работать в банковской сфере, чтобы разрабатывать продукты для банков. 😉

2️⃣ Есть и другая категория систем — внутренние системы

👨‍💻 Например, системы для сотрудников, чтобы они могли онлайн подавать заявления на отпуска, больничные, видеть свою оргструктуру, инициировать повышение своего грейда и так далее. Для разработки таких систем тоже нужен системный аналитик!

❗ Управление рисками — тоже важный внутренний продукт, который есть во всех банках.

☎️ Также система для помощи сотрудникам с техническими проблемами — если что-то сломалось, отвалился доступ к программам, можно оставить заявку через систему, и сотрудник поддержки решит проблему.

💬 Корпоративный мессенджер — ещё один пример внутренней системы, которую поддерживает команда в банке. Здесь также важно собирать требования и ставить задачи разработчикам.

#dev_process

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

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

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

Публикуем 👇

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