✨ 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

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