Добрый день, добавила ответы на Ваш комментарий курсивом ниже.
На чьей стороне будет реализована логика: фронта, middleware, бэка?
А бизнес-аналитика каким образом это касается, простите? Плюс забыли БД. К тому же логика будет везде, смотря какая вас интересует. Ну и фронт/бек дублируют друг друга во многом.
Это касается бизнес-аналитика, потому что вынос логики с фронта на бэк упрощает задачу именно команды фронта, что влияет на оценку времени и трудозатрат.
Как определять нужное состояние элемента?
Что такое элемент и зачем вам его состояние?
Подразумевается любой элемент пользовательского интерфейса, который, например, может скрываться или показываться в зависимости от приходящего параметра.
Как и где получать и обрабатывать нужные параметры?
Опять же, бизнес-аналитик?
Имеется в виду верхнеуровневое описание API с пониманием, потребуется ли запрашивать новые запросы и поменяется ли ответ в уже используемых
Примерный макет дизайна, потому что он наглядно показывает, что именно должно быть реализовано, — проще воспринимать требования.
Дизайн до аналитики? Должно быть наоборот. И нет, на дизайн опираться можно только с большой осторожностью.
Соглашусь, что на дизайн нужно опираться с осторожностью. Но иногда фичи настолько запутанные и многоуровневые, что без дизайна дать верхнеуровневую оценку достаточно сложно.
Каждый продакт видел UI по-своему: договориться было достаточно трудно. Тогда пришлось «столкнуть их лбами».
Вы простите но это жесть. Клиент понятия не имеет как сделать хорошо, он хочет кнопку «сделать хорошо» а вы и команда разработки как раз с той стороны, которая делает эти кнопки. Ну и тут как минимум UX специалист нужен.
Почему PO у одного продукта несколько мне тоже не совсем понятно.
Продукт оунер должен понимать, чего он хочет от продукта.
У одного продукта — много больших фич, за которые отвечают разные продукты.
Приглашаем на код-ревью iOS-проектов в прямом эфире
Добрый день, эфир прошел вчера по московскому времени, но сегодня мы опубликуем запись в канале: https://t.me/surf_ios
Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1
У облачного провайдера (ya cloud) как раз последняя версия 1.23. Чтобы сопоставить версии стендов, ставил 1.23
Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1
Теперь можно :)
А вот и не подерётесь: как организовать работу команды аналитиков на проекте
Никакой иронии не подразумевали: там действительно есть скриншот таблицы :) Вот он:
Бенчмарк реальных Android-проектов на современных MacBook
<>
Google I/O: что нового представили Android-разработчикам
Какие ошибки совершает аналитик в первые полгода работы и как их избежать
Это касается бизнес-аналитика, потому что вынос логики с фронта на бэк упрощает задачу именно команды фронта, что влияет на оценку времени и трудозатрат.
Подразумевается любой элемент пользовательского интерфейса, который, например, может скрываться или показываться в зависимости от приходящего параметра.
Имеется в виду верхнеуровневое описание API с пониманием, потребуется ли запрашивать новые запросы и поменяется ли ответ в уже используемых
Соглашусь, что на дизайн нужно опираться с осторожностью. Но иногда фичи настолько запутанные и многоуровневые, что без дизайна дать верхнеуровневую оценку достаточно сложно.
Продукт оунер должен понимать, чего он хочет от продукта.
У одного продукта — много больших фич, за которые отвечают разные продукты.
Курс Flutter от Surf: успеть за технологиями будущего