бизнес-аналитики есть далеко не во всех компаниях. но вообще основная задача бизнес-аналитика заключается в том, чтобы помочь компании понять свои бизнес-процессы и найти возможности для улучшений
Вы приводите пример работы аутсорсной команды, которая делает сайты на заказ, если я правильно поняла. В таком случае, я бы рассматривала все через призуму проектов: cделать сайт - проект, тк сделали и отдали, а заказчик уже дальше сам думает, что ему с сайтом делать, какая будет стратегия развития продукта и тд. Для них готовый сайт = продукт. Но если они хотят какую-то фичу, а своей команды у них нет и они снова решили сотрудничать с аутсорс командой, то для команды фича = проект. Они сделали фичу и отдали заказчику. Пример про то, сколько человек работали над проектом, а сколько работают над продуктом, не очень поняла. В любом случае, здесь нет смысла искать универсальное определение для продакта и для проджекта, так на практике эти роли совершенно по разному могут работать.
Если суммировать связь продукта и проекта, то это звучит примерно так:
Продукт может постоянно развиваться через ряд проектов, направленных на его обновление и адаптацию к меняющимся требованиям рынка и клиентов.
хороший вопрос, но я не уверена, что здесь существует какой-то универсальный ответ тк в каждой компании свои представления об этих ролях. я бы сказала, что разница зависит в широте зоны ответственности каждого, например, продакт оунер отвечает за весь продукт целиком, а продакт менеджер может отвечать за часть воронки, метрику, часть продукта, за один из продуктов в портфеле и т.д.
чем на самом деле продакт отличается от проджекта?
если кратко, то у проекта есть начало и конец, а продукт можно развивать бесконечно. я вижу разницу так:
продакт-менеджер думает про то, как растить показатели и метрики бизнеса + делать пользователей счастливыми, генерит гипотезы, думает, как их можно быстро проверить и т.д. дальше часть этой работы может уйти проджекту, например: чтобы лучше понимать наших пользователей, хотим реализовать сбор обратной связи. Решили, что сначала попробуем сделать это через рассылку опроса. Вот в этот момент проджект может забрать эту задачку и помочь спроектировать решение: кому будет делать рассылку, как, какие там будут вопросы, куда будут падать ответы, что потом с этими ответами будем делать и т.д. Как только весь флоу будет реализован и мы получим ответы от пользователей, можно считать, что проект завершен.
у меня в команде нет проджектов, поэтому весь цикл таких работ делаю сама, но знаю, что в других продуктах они есть и часто на них ложится такая вот операционная работа.
Вряд ли тестировщик может выполнять задачи бекендера. Или бекендер задачи фронта.
да, тут не всегда получается именно так, но есть ребята, которые хотят развивать и другие компетенции, поэтому иногда сценарии могут писать беки и фронты вместо тестировщика (вот буквально делали на этой неделе тк тестировщик в отпуске), а иногда разработчики или дизайнер могут сходить пообщаться со стейкхолдерами и дособрать контекстов вместо менеджера
Как по мне дейли существует для двух вещей: поболтать и обозначить проблему, вдруг кто знает решение. Для всего остального есть жира/любой трекер задач.
в том числе, но нам также важно поглядывать на цель спринта и анализировать, успеваем мы ее выполнить или нет. если нет - думаем, а реально ли убрать что-то из совсем необязательного или такой опции нет и нужно будет брать доработки в след спринте
Имхо, на PBR должен присутствовать только заинтересованные лица и тимлид/продукт. Иначе это превращается в "я есть на встрече, но замьючин, смотрю на котиков или в код, что там происходит на самой встречи - хз"
К примеру, бэкендеру находиться на встречи по фронту на 90% бессмысленно после фиксации контрактов
согласна, на PBR именно такой состав, но когда разбираем бизнесовый контекст задачи обычно присутствует вся команда разработки, потому что важно понимать что мы делаем и зачем + ребята сами любят задавать вопросы и уточнять
в продуктовых компаниях тоже есть проджекты)
бизнес-аналитики есть далеко не во всех компаниях. но вообще основная задача бизнес-аналитика заключается в том, чтобы помочь компании понять свои бизнес-процессы и найти возможности для улучшений
Вы приводите пример работы аутсорсной команды, которая делает сайты на заказ, если я правильно поняла. В таком случае, я бы рассматривала все через призуму проектов: cделать сайт - проект, тк сделали и отдали, а заказчик уже дальше сам думает, что ему с сайтом делать, какая будет стратегия развития продукта и тд. Для них готовый сайт = продукт. Но если они хотят какую-то фичу, а своей команды у них нет и они снова решили сотрудничать с аутсорс командой, то для команды фича = проект. Они сделали фичу и отдали заказчику. Пример про то, сколько человек работали над проектом, а сколько работают над продуктом, не очень поняла. В любом случае, здесь нет смысла искать универсальное определение для продакта и для проджекта, так на практике эти роли совершенно по разному могут работать.
Если суммировать связь продукта и проекта, то это звучит примерно так:
Продукт может постоянно развиваться через ряд проектов, направленных на его обновление и адаптацию к меняющимся требованиям рынка и клиентов.
хороший вопрос, но я не уверена, что здесь существует какой-то универсальный ответ тк в каждой компании свои представления об этих ролях. я бы сказала, что разница зависит в широте зоны ответственности каждого, например, продакт оунер отвечает за весь продукт целиком, а продакт менеджер может отвечать за часть воронки, метрику, часть продукта, за один из продуктов в портфеле и т.д.
спасибо за отзыв!
если кратко, то у проекта есть начало и конец, а продукт можно развивать бесконечно. я вижу разницу так:
продакт-менеджер думает про то, как растить показатели и метрики бизнеса + делать пользователей счастливыми, генерит гипотезы, думает, как их можно быстро проверить и т.д.
дальше часть этой работы может уйти проджекту, например: чтобы лучше понимать наших пользователей, хотим реализовать сбор обратной связи. Решили, что сначала попробуем сделать это через рассылку опроса. Вот в этот момент проджект может забрать эту задачку и помочь спроектировать решение: кому будет делать рассылку, как, какие там будут вопросы, куда будут падать ответы, что потом с этими ответами будем делать и т.д. Как только весь флоу будет реализован и мы получим ответы от пользователей, можно считать, что проект завершен.
у меня в команде нет проджектов, поэтому весь цикл таких работ делаю сама, но знаю, что в других продуктах они есть и часто на них ложится такая вот операционная работа.
видела еще статью от Практикума на эту тему https://practicum.yandex.ru/blog/chem-otlichayutsya-product-i-project-manager/ , но нужно понимать, что от компании к компании видение проджекта и продакта может отличаться)
да, тут не всегда получается именно так, но есть ребята, которые хотят развивать и другие компетенции, поэтому иногда сценарии могут писать беки и фронты вместо тестировщика (вот буквально делали на этой неделе тк тестировщик в отпуске), а иногда разработчики или дизайнер могут сходить пообщаться со стейкхолдерами и дособрать контекстов вместо менеджера
в том числе, но нам также важно поглядывать на цель спринта и анализировать, успеваем мы ее выполнить или нет. если нет - думаем, а реально ли убрать что-то из совсем необязательного или такой опции нет и нужно будет брать доработки в след спринте
согласна, на PBR именно такой состав, но когда разбираем бизнесовый контекст задачи обычно присутствует вся команда разработки, потому что важно понимать что мы делаем и зачем + ребята сами любят задавать вопросы и уточнять
спасибо)