🎯 Мини-лайфхак №2

Пишите заголовок задачи в Jira так, чтобы суть задачи была понятна без описания.

❌ Доработать форму заявки (какую именно доработку делаем?)
✅ Добавить поле Цель кредита в форму заявки

Так на дейли вы смотрите на доску и сразу понимаете, о чём идёт речь. Экономите время всей команде.

❓А вы бы что посоветовали? Пишите в комментариях 💬

#лайфхаки #requirements

🎯 На собеседовании не обойтись без вопросов по теме требований, ведь это основа работы аналитика

Мы собираем требования, чтобы выявить ожидания пользователей, определить функциональность, спроектировать API, БД и пр. Неважно, за какую задачу берёмся — без требований ничего не получится.

Сохраняйте самые частые вопросы по требованиям 👇

1️⃣ Какие методы сбора требований знаете? Какие применяли на практике?
2️⃣ В каком виде вам приходят задачи на текущем проекте и на прошлых? С какими подходами сталкивались?
3️⃣ Как, по вашему мнению, выглядит идеальная задача, которая поступает к вам на анализ?
4️⃣ Какие виды требований знаете?
5️⃣ Прорабатывали ли нефункциональные требования? Что к ним относится?
6️⃣ Как понять, что требование хорошее? (ожидают услышать «критерии хороших требований»)
7️⃣ Использовали ли в работе User Story? Как работали по ним?
8️⃣ Для чего применяют User Story, а для чего Use Case?
9️⃣ Работали с Use Case? Что это такое? По какому шаблону описывали?
1️⃣0️⃣ Участвовали ли в декомпозиции задач? Знаете, как можно декомпозировать? Давайте попробуем: <дают задачу на декомпозицию>
1️⃣1️⃣ Как бы вы вели документацию на проекте? Какие разделы в ней были бы? Что для вас «идеальный шаблон»?

Если чувствуете, что пока не хватает кругозора, работали только в одной-двух компаниях, интересно, как бывает по-другому, или просто хотите подтянуть базу, приглашаем на наш курс «Системный аналитик.БАЗА»

Ваши Вера и Юрий, основатели AnalystCore
Удачи на собеседованиях 💪

#requirements #interview

☀️ Лето — идеальное время, чтобы...

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

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

💬 Обрести уверенность в себе и перестать бояться встреч с заказчиками и разработчиками
💪 Перестать полагаться на наставника и начать самостоятельно решать задачи
📚 Узнать best practices и начать применять их в работе, а не действовать по наитию
🌟 Стать классным специалистом, который реально помогает команде
💸 Получить повышение

Часто, чтобы прийти к этому, нужна именно БАЗА. И мы готовы вам её дать.

💡 У нас есть бесплатный ТЕСТ-ДРАЙВ курса.
Перейдите по ссылке, зарегистрируйтесь и посмотрите первый урок.
Проверьте, подойдёт ли вам наш подход: https://analystcore.com/system-analyst-base

🛠 Мини-лайфхак №3

Нашли баг, и нужно самому его завести без тестировщика? Опишите его по шаблону:
— Шаги воспроизведения (1, 2, 3, 4, 5)
— Фактический результат
— Ожидаемый результат

Описывайте все по этой структуре, даже если кажется, что «всё и так понятно».

Зачем?
✅ Чтобы через неделю вы сами вспомнили, в чём была проблема.
✅ Чтобы разработчик не додумывал за вас.
✅ Чтобы тестировщик понял, как проверять фиксы.


#лайфхаки #requirements

👵 Даже опытные аналитики часто не справляются с задачами по требованиям на собеседовании

Что это за задачи?
На собеседовании дают конкретное требование и просят продумать для него решение.

Пример реального задания:

«Хотим слать уведомления клиентам, которые сделали только один заказ».
Проработайте решение, соберите требования.

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

💡 Вот так одно требование может многое показать о вашем уровне и мышлении.
Чтобы действительно уверенно выполнять такие задания, нужно тренировать навык работы с требованиями и развивать системное мышление.

Практикуйтесь ежедневно!
Возьмите любое требование и раскрутите его дальше: что ещё нужно учесть, какие модули, сценарии, интеграции, бизнес-правила?

С нас подборка требований, на которых можете потренироваться:
❓Хотим напомнить клиентам о брошенной корзине через 2 часа
❓Хотим показывать на главной странице «персональные рекомендации»
❓Добавить возможность пользователю «заморозить» подписку на месяц

На нашем курсе «Системный аналитик.БАЗА» вы прокачаете навык работы с требованиями, научитесь задавать правильные вопросы, видеть подводные камни и докапываться до сути. Это та самая база, без которой не получится уверенно двигаться дальше.

С вами Вера и Юрий ❤️,
основатели AnalystCore

#requirements #interview

Когда говорим о требованиях, никуда без User Story и Use Case

Они помогают не только фиксировать требования, но и глубже прорабатывать логику работы системы.

Сохраняйте подборку наших постов 👇

📌 Ищем требования с помощью Use Case — идеальная техника для поиска альтернативных кейсов и анализа, что может пойти не так
📌 Альтернативные сценарии — не только ошибки
📌 В Use Case можно «свёртывать» ошибки — см. подробности
📌 Почему не рекомендуют писать детали пользовательского интерфейса в Use Case — смотрите минусы
📌 Use Case и User Story — это разные инструменты и их часто сравнивают. Одно из отличий — По User Story не написать документацию
📌 Считаю, что Use Case — это не про «писать», это про «мыслить»
📌 Альтернативные сценарии в процессе авторизации
📌 Шаблон Use Case на примере записи на приём к врачу
📌 Как называть Use Case?
📌 Use Cases для лифта — разбор задачи с собеседования
📌 Примеры плохих User Story и объяснение, почему они такие плохие
📌 Исправили плохие User Story
📌 User Story ≠ «просто пришёл на PBR»
📌 Почему истории от «Системы» — это плохо

Чтобы действительно научиться писать Use Case и User Story, недостаточно теории. Нужно тренировать насмотренность. Видеть кучу плохих примеров, получать разборы ошибок и предложения, как исправить.
За всем этим приходите к нам 😉 У нас есть отдельный курс User Story & Use Case.

#requirements

🛠️ Мини-лайфхак №4

В Use Case не пишите «если» в шагах сценария — для этого в данной технике есть «альтернативные потоки».

#лайфхаки #requirements

🛠️ Мини-лайфхак №5

Пишите «не делаем» явно. Если в задаче не делаем drag-and-drop — напишите это прямо. Иначе команда всё-равно спросит.

Чёткие границы задачи экономят время на обсуждениях и снимают лишние вопросы.

#лайфхаки #requirements

✨ Cамый любимый вопрос аналитика

Есть один вопрос, который помогает увидеть то, что обычно остаётся за кадром.
Он проверяет систему на прочность и открывает глаза на некоторые вещи.

Это вопрос — «А что будет, если…?» 🧠

📌 А что будет, если пользователь не заполнит обязательное поле?
📌 А что будет, если файл слишком большой?
📌 А что будет, если соединение с сервером прервётся?

Каждый такой вопрос — как краш-тест для вашей идеи. Он помогает предусмотреть сбои, ошибки, исключения. То, о чём часто забывают, но из-за чего потом всё ломается. 😅

🎯 Этот вопрос особенно важен в момент, когда задача вроде бы уже понятна, когда уже хочется бежать писать ТЗ. Вот тогда и надо притормозить и задать себе (и команде) вопрос:
А что будет, если…?

#requirements

💬 Какие бывают вопросы?

Не все вопросы одинаково полезны 😅
Иногда мы что-то спрашиваем, но получаем размытый или вообще не тот ответ.

Системному аналитику важно уметь задавать вопросы разного типа — в зависимости от того, какую информацию вы хотите получить.

📌 Открытые — чтобы собрать как можно больше информации:
→ «Расскажите, как сейчас работает этот процесс?»
→ «Что происходит после того, как пользователь нажимает кнопку?»

📌 Закрытые — чтобы уточнить детали:
→ «То есть сейчас файл загружается вручную, верно?»
→ «Пользователь должен быть авторизован, чтобы увидеть эту страницу?»

📌 Наводящие — чтобы направить собеседника к точному ответу:
→ «Получается, система должна отправлять уведомление только один раз?»
→ «Если данных нет, нужно показать пустой список, так?»

#requirements

🔍 Первый вопрос, который должен задать аналитик — «ЗАЧЕМ?»

К вам прилетела задача:
* Нужно добавить кнопку
* Сделайте возможность загрузки файла
* Добавьте новое поле в форму

Очень хочется сразу бежать и начать делать: нарисовать прототипы, описать ТЗ, поставить задачу разработчикам...
Но стоп. Сначала задайте вопрос: «А зачем вы хотите добавить кнопку?»
Какая причина?
Какую проблему мы решаем?

Это не просто теоретический совет. Это боль, которую прочувствовал наш подписчик и мы сами в начале карьеры в IT. 🙈

🙋 Сергей поделился своим кейсом:

Заказчик пришёл с требованием, я сразу поставил задачу на разработку. Задачу оценили в 5 рабочих дней, реализовали, пошли показывать, а заказчик остался недоволен. Хотя всё сделали «в лоб», как он и хотел!
На встрече опытный разработчик задал вопрос: «А зачем вообще это нужно?» — и выяснилось, что настоящую проблему можно было решить даже без разработки.
Это урок, который я запомню на всю жизнь. Надеюсь 😞

Вот почему «ЗАЧЕМ?» — это первый вопрос аналитика при проработке задачи.
Он помогает понять суть и найти самое эффективное решение, а не просто «сделать, как сказали».

#requirements

🔍 Хотите добраться до сути задачи? Используйте технику «5 почему»!

Бизнес часто приходит с готовым решением:
«Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться»

Очень хочется сказать «окей» и сразу бежать писать ТЗ… Но стоп!
Используем технику 5 «почему» — и докопаемся до сути.

Запрос: Нам нужно добавить кнопку «Позвонить менеджеру» в личный кабинет, чтобы клиентам было удобнее с нами связаться

1️⃣ Почему нужна эта кнопка?
→ Потому что клиенты часто звонят, чтобы уточнить, на каком этапе их заявка, но им трудно найти наш номер.

2️⃣ А почему клиенты не видят этап своей заявки в личном кабинете?
→ Потому что сейчас там просто написано «Заявка в обработке».

3️⃣Почему выводится общий статус?
→ Потому что статусов заявки в системе много, и они пока не отображаются клиенту.

4️⃣Почему не отображаются?
→ Потому что никто не описал, какие статусы понятны пользователю и как их показать.

5️⃣ Почему важно это показать?
→ Потому что тогда клиент поймёт, что заявка движется, и не будет нервничать.

📌 Вывод:
Проблема не в отсутствии кнопки, а в недостаточной прозрачности процесса.
Если просто добавить кнопку, звонков станет ещё больше.

✅ Лучшее решение:
- Показать клиенту понятные статусы заявки в интерфейсе: «что происходит с его заказом?»
- Также мы выяснили, что клиентам трудно найти номер телефона в ЛК — отдельной задачей подумаем, куда лучше разместить номер

Так работает техника «5 почему». Она помогает найти корень проблемы, а не просто реализовать первое предложенное решение.

📝❓ Маленькое задание:
Выберите что-то из своей жизни — бытовое или рабочее.
Например:
— «Хочу поменять работу / команду / проект»
— «Не могу начать учиться»

И попробуйте раскрутить это с помощью «5 почему».
Пишите свои выводы в комментарии, если захотите поделиться!

С вами Вера и Юрий,
основатели AnalystCore 🙌

#requirements

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

Привет! 👋
С вами Вера, основатель 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