🙌 Всем привет и ОСТОРОЖНО, СПОЙЛЕР!🚨
Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥
Первые два вопроса были после теоретических частей про бизнес- и функциональные требования. Поэтому начнём с них.
1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.
☝️ Условие сообщает, что из предложенных вариантов только один является ошибочным, его-то и необходимо определить.
Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.
Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)
Четвёртый вариант. И конечно идеальное бизнес-требование должно содержать метрику успеха (на сколько планируется изменить текущий показатель?), на основании которой можно понять, в каком случае изменение считается спроектированным успешно и интересы бизнеса достигнуты.
Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.
👌 Если по результатам выхода решения для требования обозначенный показатель будет достигнут, значит метрика оказалась достижимой, а реализация – успешной.
Бизнес-требования – это недетализированная формулировка, отражающая интересы бизнеса в изменениях, и этот тип требования не готов к передаче в разработку.
Теперь мы с вами понимаем, что одно бизнес-требование может породить множество различных вариантов решений в существующих процессах.
Например:
🔹 придумать систему лояльности для пользователей, которые приходят от партнёра;
🔹 упростить систему регистрации;
🔹 просить пользователей предоставлять необходимую для регистрации в нашей системе информацию партнёру и через согласие клиента получать эти данные, чтобы автоматически завершать регистрацию за лида.
Вариантов может быть множество, поэтому задача аналитика – найти решение поставленной бизнесом задачи. Именно поэтому бизнес-требование не годится для передачи в разработку – в нём нет конкретики реализации, а есть только цель.
Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️
🕺🏻 перерыв на победную ламбаду 💃🏻
2️⃣ Укажите верное высказывание о функциональных-требованиях
☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.
Первый вариант. Функциональные требования отражают задачу пользователя (что он хочет уметь делать), но точно не отражают цель, ради которой он ожидает выполнять это действие.
Давайте вспомним про шаблон пользовательской истории.
Как [роль], я хочу [задача], чтобы [цель].
Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.
Функциональное требование из этого пользовательского будет отражать ожидаемое действие пользователя – авторизация с помощью адреса почты. Часть с описанием цели в пользовательском требовании необходима для понимания мотивации для выполнения действия и для определения успешного выбора действия для достижения пользовательской цели.
Из-за того, что функициональное требование рождается из пользовательского, информация о том, для чего пользователю нужна эта функция, на этом уровне уже излишняя.
Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.
Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥
Первые два вопроса были после теоретических частей про бизнес- и функциональные требования. Поэтому начнём с них.
1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.
☝️ Условие сообщает, что из предложенных вариантов только один является ошибочным, его-то и необходимо определить.
Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.
Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)
Четвёртый вариант. И конечно идеальное бизнес-требование должно содержать метрику успеха (на сколько планируется изменить текущий показатель?), на основании которой можно понять, в каком случае изменение считается спроектированным успешно и интересы бизнеса достигнуты.
Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.
👌 Если по результатам выхода решения для требования обозначенный показатель будет достигнут, значит метрика оказалась достижимой, а реализация – успешной.
Бизнес-требования – это недетализированная формулировка, отражающая интересы бизнеса в изменениях, и этот тип требования не готов к передаче в разработку.
Теперь мы с вами понимаем, что одно бизнес-требование может породить множество различных вариантов решений в существующих процессах.
Например:
🔹 придумать систему лояльности для пользователей, которые приходят от партнёра;
🔹 упростить систему регистрации;
🔹 просить пользователей предоставлять необходимую для регистрации в нашей системе информацию партнёру и через согласие клиента получать эти данные, чтобы автоматически завершать регистрацию за лида.
Вариантов может быть множество, поэтому задача аналитика – найти решение поставленной бизнесом задачи. Именно поэтому бизнес-требование не годится для передачи в разработку – в нём нет конкретики реализации, а есть только цель.
Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️
🕺🏻 перерыв на победную ламбаду 💃🏻
2️⃣ Укажите верное высказывание о функциональных-требованиях
☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.
Первый вариант. Функциональные требования отражают задачу пользователя (что он хочет уметь делать), но точно не отражают цель, ради которой он ожидает выполнять это действие.
Давайте вспомним про шаблон пользовательской истории.
Как [роль], я хочу [задача], чтобы [цель].
Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.
Функциональное требование из этого пользовательского будет отражать ожидаемое действие пользователя – авторизация с помощью адреса почты. Часть с описанием цели в пользовательском требовании необходима для понимания мотивации для выполнения действия и для определения успешного выбора действия для достижения пользовательской цели.
Из-за того, что функициональное требование рождается из пользовательского, информация о том, для чего пользователю нужна эта функция, на этом уровне уже излишняя.
Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.