🥳 Друзья, спасибо большое за участие в КВИЗе!

Очень надеемся, что тема требований стала чуть-чуть понятнее, но если есть вопросы – смело задавайте их в комментариях, будем разбираться вместе 💪

Как вы думаете, нужно ли подробнее разобрать, почему правильные ответы правильные?

Если пальцев вверх будет больше 10 👍, то следующим постом разберём подробнее каждый из вопросов КВИЗа (в том числе те, что были после теоретических частей про требования).

Наша задача разобраться в теме так, чтобы вы интуитивно решали кейсы, а не зубрили теорию 🤓😎

Всем отличных выходных!
Гордимся нашими крутыми участниками сообщества GetAnalyst 🖤💥

🙌 Всем привет и ОСТОРОЖНО, СПОЙЛЕР!🚨

Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥


Первые два вопроса были после теоретических частей про бизнес- и функциональные требования. Поэтому начнём с них.


1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.

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

Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.

Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)

Четвёртый вариант. И конечно идеальное бизнес-требование должно содержать метрику успеха (на сколько планируется изменить текущий показатель?), на основании которой можно понять, в каком случае изменение считается спроектированным успешно и интересы бизнеса достигнуты.

Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.

👌 Если по результатам выхода решения для требования обозначенный показатель будет достигнут, значит метрика оказалась достижимой, а реализация – успешной.

Бизнес-требования – это недетализированная формулировка, отражающая интересы бизнеса в изменениях, и этот тип требования не готов к передаче в разработку.

Теперь мы с вами понимаем, что одно бизнес-требование может породить множество различных вариантов решений в существующих процессах.

Например:
🔹 придумать систему лояльности для пользователей, которые приходят от партнёра;
🔹 упростить систему регистрации;
🔹 просить пользователей предоставлять необходимую для регистрации в нашей системе информацию партнёру и через согласие клиента получать эти данные, чтобы автоматически завершать регистрацию за лида.

Вариантов может быть множество, поэтому задача аналитика – найти решение поставленной бизнесом задачи. Именно поэтому бизнес-требование не годится для передачи в разработку – в нём нет конкретики реализации, а есть только цель.

Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️


🕺🏻 перерыв на победную ламбаду 💃🏻


2️⃣ Укажите верное высказывание о функциональных-требованиях

☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.

Первый вариант. Функциональные требования отражают задачу пользователя (что он хочет уметь делать), но точно не отражают цель, ради которой он ожидает выполнять это действие.

Давайте вспомним про шаблон пользовательской истории.
Как [роль], я хочу [задача], чтобы [цель].

Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.

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

Из-за того, что функициональное требование рождается из пользовательского, информация о том, для чего пользователю нужна эта функция, на этом уровне уже излишняя.

Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.

Третий вариант. Функциональные требования отражают интересы заказчика в лице бизнеса и/или пользователей. Если проектная команда будет создавать систему только исходя из интересов бизнеса, лояльность пользователей к продукту будет снижаться. А ноу юзерс, ноу ханей, ю ноу? 🍯🐝

Продуктом пользуется человек и платит за этот продукт бизнесу. Поэтому необходимо учитывать обе стороны.

Четвёртый вариант. CRUD-модель работы с данными (создание, чтение, изменение и удаление) действительно упрощает первичный сбор требований с заказчика. Тут действует принцип Парето (Vilfredo Federico Damaso Pareto), где 20% усилий в виде четырёх вопросов к функциональным возможностям внутри решения дают 80% результата. Пробуйте применить в работе – будете приятно удивлены 😊

Кстати, четвёртый вариант будет верным высказыванием. Пикачу, выбираем тебя ☑️


А сейчас перерыв на чашечку чая (или что там у вас в субботу?🙃) и через пару часов продолжаем.

Продолжаем с разбором КВИЗа 🚀

Переходим к серии вопросов по всей теме типов требований.


1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?

Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁


2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?

Эбсолютли райт! 🎉 Чтобы подготовить систему к новому состоянию, можно ещё до выхода функциональности в продакшн внести изменения в существующие процессы.

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

Вот вам и плавный переход между состояниями системы.

3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?

Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.

Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.

Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:

Пользователь должен иметь возможность привязывать банковскую карту к личному профилю.

В первом случае пользователь будет иметь возможность указывать банковскую карту каждый раз для проведения оплаты (что не решает его проблему, которая не указана), а во втором – сможет указать её единожды и постоянно оплачивать с помощью неё доставку.

Именно поэтому пользовательские требования лучше формулировать по шаблону User story.

4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?

Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤

🏎💨 Ну и последние два вопроса КВИЗа (финишная прямая, ребята! )


5️⃣ Укажите бизнес-требование в представленном перечне

Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).

Проанализируем варианты ответов.

Первый вариант. Описание содержит конкретную функциональную возможность внутри решения и совсем не сообщает, какую цель преследует бизнес. Больше похоже на детализацию требования до функциональной возможности.

Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️

Третий вариант. Непонятно, для каких целей планируем создать платформу. А как мы уже знаем, для достижения бизнес-цели можно найти множество путей с различной стоимостью и затратами.

6️⃣ Укажите функциональное требование в представленном перечне

Начнём со второго варианта. Функциональное требование не должно содержать информацию о том, как именно нужно достичь поставленной цели. Никаких названий полей в требовании быть не должно – разработчик имеет бОльшую экспертизу в написании кода.

☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.

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

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



Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤

Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉

Отличных выходных, друзья!

Встречаются как-то на планёрке в ZOOM бизнес-аналитик, системный аналитик и аналитик данных. Еще, конечно, владелец бизнеса и руководитель проекта 😄

Владелец бизнеса говорит:
- Надо создать новый онлайн-магазин с украшениями.

🌟 Бизнес аналитик пойдёт проводить исследование: изучит конкурентов, проанализирует целевую аудиторию, текущие тенденции в отрасли. ОБЯЗАТЕЛЬНО разберётся в законодательстве: посмотрит законы и правила, регулирующие онлайн-торговлю, чтобы убедиться, что новый онлайн-магазин будет соответствовать всем требованиям.

После всё структурирует, опишет бизнес-процессы и определит требования к функциональности магазина, чтобы затем передать их системному аналитику.

🌟 Теперь в игру вступает системный аналитик

СА рассмотрит информацию от БА и проанализирует бизнес-процессы, чтобы понять, как пользователь будет себя вести, зайдя на сайт. На какие кнопки будет нажимать: что ему нужно, чтобы товар добавился в избранное. Решать, какие должны быть инструменты, чтобы клиент совершил целевое действие — зарегистрировался или купил.

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

В процессе разработки системный аналитик будет следить за тем, чтобы все требования были учтены и решать возникающие проблемы. Он также поможет с тестированием системы и может обучить пользователей её использованию.

Весь процесс очень интересный, насыщенный, кропотливый.

🌟 Теперь поприветствуем аналитика данных

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

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

Или, что пользователи добавляют в корзину товары, но не переходят к оплате. Значит что-то у нас с процессом не так.

Все три роли — бизнес-аналитик, системный аналитик и аналитик данных нередко работают ВМЕСТЕ для успешной реализации проекта 🌟🌟🌟

Порой, когда мы смотрим какое-то приложение, заказываем еду, или кладём в корзину онлайн-магазина классную футболку, мы даже не догадываемся, какая огромная работа аналитиков и команды разработчиков стоит за этим.

И именно IT-аналитики помогают сделать эти системы и превратить их в реальность 🙌

Если вы только ищете себя в IT и хотите получить ответ на вопрос "В чем разница между аналитиками?", то новая статья поможет вам 😉

Системный аналитик - это такой навигатор в команде, который смотрит на всю карту IT-проекта целиком и понимает, как сделать путь разработки от точки А до точки B максимально эффективным 🌍

У нас в сообществе GetAnalyst важен опыт. Я хочу рассказать про IT-проекты, на которых работают системные аналитики, обсудить зону ответственности и границы между бизнес-анализом и системным анализом.

⚡️ Почему в IT нужны системные аналитики:
про опыт работы в IT-проектах
🗓 22 июня в 19:00 Мск

🟢 Расскажу, что делать со скилами системного аналитика в Европе и США, что такое проекты на фриланс для аналитиков и как их искать.

🟢 Как начать карьеру с позиции системного аналитика.

🟢 Какие тренды сейчас с учетом развития AI и ML, и как быть востребованным на рынке труда.


Регистрируйся по ссылке, чтобы не пропустить!

Когда системный аналитик хорошо проработал Use Cases 😎