Comments 7
На чьей стороне будет реализована логика: фронта, middleware, бэка?
А бизнес-аналитика каким образом это касается, простите? Плюс забыли БД. К тому же логика будет везде, смотря какая вас интересует. Ну и фронт/бек дублируют друг друга во многом.
Как определять нужное состояние элемента?
Что такое элемент и зачем вам его состояние?
Как и где получать и обрабатывать нужные параметры?
Опять же, бизнес-аналитик?
Примерный макет дизайна, потому что он наглядно показывает, что именно должно быть реализовано, — проще воспринимать требования.
Дизайн до аналитики? Должно быть наоборот. И нет, на дизайн опираться можно только с большой осторожностью.
Каждый продакт видел UI по-своему: договориться было достаточно трудно. Тогда пришлось «столкнуть их лбами».
Вы простите но это жесть. Клиент понятия не имеет как сделать хорошо, он хочет кнопку «сделать хорошо» а вы и команда разработки как раз с той стороны, которая делает эти кнопки. Ну и тут как минимум UX специалист нужен.
Почему PO у одного продукта несколько мне тоже не совсем понятно.
Хотя про противоречивые требования конечно важно, но именно на верхнем уровне.
Вот и всё, мои маленькие хоббиты. Я поделилась с вами своей мудростью, теперь вы сами по себе.
После вышеуказанного примера "юмора" Вам что-то ещё в этой статье разбирать захотелось ?
Это же классический случай:
Была я мотористкой
И шила гладью
Но вот пошла в актрисы
И стала ... примой
Служила я в театре
Была звездою
Как трудно заработать
На жизнь ... искусством
Добрый день, добавила ответы на Ваш комментарий курсивом ниже.
Это касается бизнес-аналитика, потому что вынос логики с фронта на бэк упрощает задачу именно команды фронта, что влияет на оценку времени и трудозатрат.
Подразумевается любой элемент пользовательского интерфейса, который, например, может скрываться или показываться в зависимости от приходящего параметра.
Имеется в виду верхнеуровневое описание API с пониманием, потребуется ли запрашивать новые запросы и поменяется ли ответ в уже используемых
Соглашусь, что на дизайн нужно опираться с осторожностью. Но иногда фичи настолько запутанные и многоуровневые, что без дизайна дать верхнеуровневую оценку достаточно сложно.
Продукт оунер должен понимать, чего он хочет от продукта.
У одного продукта — много больших фич, за которые отвечают разные продукты.
На чьей стороне будет реализована логика: фронта, middleware, бэка?
А бизнес-аналитика каким образом это касается, простите? Плюс забыли БД. К тому же логика будет везде, смотря какая вас интересует. Ну и фронт/бек дублируют друг друга во многом.
Это касается бизнес-аналитика, потому что вынос логики с фронта на бэк упрощает задачу именно команды фронта, что влияет на оценку времени и трудозатрат.
Как определять нужное состояние элемента?
Что такое элемент и зачем вам его состояние?
Подразумевается любой элемент пользовательского интерфейса, который, например, может скрываться или показываться в зависимости от приходящего параметра.
Как и где получать и обрабатывать нужные параметры?
Опять же, бизнес-аналитик?
Имеется в виду верхнеуровневое описание API с пониманием, потребуется ли запрашивать новые запросы и поменяется ли ответ в уже используемых
Примерный макет дизайна, потому что он наглядно показывает, что именно должно быть реализовано, — проще воспринимать требования.
Дизайн до аналитики? Должно быть наоборот. И нет, на дизайн опираться можно только с большой осторожностью.
Соглашусь, что на дизайн нужно опираться с осторожностью. Но иногда фичи настолько запутанные и многоуровневые, что без дизайна дать верхнеуровневую оценку достаточно сложно.
Каждый продакт видел UI по-своему: договориться было достаточно трудно. Тогда пришлось «столкнуть их лбами».
Вы простите но это жесть. Клиент понятия не имеет как сделать хорошо, он хочет кнопку «сделать хорошо» а вы и команда разработки как раз с той стороны, которая делает эти кнопки. Ну и тут как минимум UX специалист нужен.
Почему PO у одного продукта несколько мне тоже не совсем понятно.
Продукт оунер должен понимать, чего он хочет от продукта.
У одного продукта — много больших фич, за которые отвечают разные продукты.
>А бизнес-аналитика каким образом это касается, простите?
Вы не поверите, какие дивные обязанности порой навьючивают на человека, получившего звание бизнес-аналитика.
От документирования древнего кода (хвала богам, удалось отбиться от этой тягомотины) до вёрстки прототипов страниц продукта в чём боги послали.
Как в одной из свежих статей на эту тему было подмечено, именование должностей не формализовано и соответствие названия набору обязанностей не гарантировано…
Вы не поверите, какие дивные обязанности порой навьючивают на человека, получившего звание бизнес-аналитика.
От документирования древнего кода (хвала богам, удалось отбиться от этой тягомотины) до вёрстки прототипов страниц продукта в чём боги послали.
Как в одной из свежих статей на эту тему было подмечено, именование должностей не формализовано и соответствие названия набору обязанностей не гарантировано…
Какой-то бред сумасшедшего хипстера, который выучил слова product owner и friendly remainder
Хм... В некоторых моментах читала и вспоминала свои примеры, когда в ходе аналитики (а паралленьно уже началась и разработка) требования менялись и дополнялись не один раз только потому, что заказчик не выдал всю историю сразу, а вспоминал какие-то детали процесса по ходу пьесы.
Дополнила бы, пожалуй, тем, что аналитик должен учиться читать между строк, чтобы замечать мелочи (они же нестыковки). А для этого помогает читать получившееся описание требований e2e.
Sign up to leave a comment.
Какие ошибки совершает аналитик в первые полгода работы и как их избежать