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