Это интересно. Особенно в контексте работы аналитика в новой предметной области

Я бы ещё добавил, на каком этапе присутствие аналитика на проекте обязательно.

да, интересно

Всем привет.

Ну, надеюсь, вы понимаете, что А.серебряных пуль не бывает?

Одним из первых слайдов в этой презе идёт ограничение: не для исследовательских работ и работ с высокой долей неопределенности. Но конечно же, как-то нужно и такие работы планировать. Ответ есть.

Но он не однозначен.

Сделаю доклад, как за два месяца выступить с тремя докладами на разные темы : )

спам, только что забанил в личке

Atilla Watson

в чате нету

Может самовыпилился

Как аналитику получить направление в нужную клинику?

Это в копилку тем. Шутка)) . Триггер на фразу "хорошо бы получить направление". Занимаюсь вопросами здоровья у родителей, больная тема. Форма 057/у.

https://forms.gle/eJ9u8f28ybVJguFW6
Коллеги, пожалуйста, примите участие в опросе. Опрос нацелен на выяснение субъективных оценок адаптации ит-сотрудников при изменении различных условий.
Заранее спасибо.
ЗЫ. Репост приветствуется.

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

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

- Постановка и описание задачи.
- Обсуждение с командой
- Выделение минимальной полезности
- Участие в декомпозиция задачи
- Отслеживание выполнения/корректировка требований при необходимости
- Локализация
- Итоговое тестирование

Продукт: мобильное приложение для сотрудников, стартап внутри корпорации. 40к пользователей, по функционалу - вагон и тележка: начиная от соцсети, заканчивая цифровыми процессами и веб-порталом для администрирования. Scrum, 12 человек команда, считая PO и SM

Аналитик один, аля продакт менеджер, который занимается тремя стримами:
1. Аналитикой использования продукта: Amplitude, Matomo, Firebase
2. Помощью PO в проработке требований от бизнеса до уровня Тема, Epic, US
3. Помощь PO в приоритезации и систематизации беклога

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

Продукт существует уже два года, разросся сильно - сейчас приступают к полноценной web-морде, потребности в системном аналитике нет, но это во многом заслуга адекватного PO и процессов