речь о том, что чем интенсивнее тренировки физические, тем сильнее мышца, чем интенсивнее тренировка мозга, тем больше шансов потерять человека

Чушь. Если мышцу валить тренировками она сдохнет. Нужны периоды расслабления и восстановления  и чем выше интенсивность тем длиннее. После базовой работы легкой мало. А после соревновательной нагрузки 2*time лежать. С мозгом так же

Тем кто не согласен про мышцу предлагаю пойти в зал и сделать присед 4*50 раз просто с грифом но без остановок. Отдых между подходами 3 минуты. Если кто крутой в приседе делайте 4*70 или повесьте чуток блинов (много не надо 20 30кг хватит). Это будет примерно то, что делает с мозгом команды скрам.

Так и он об этом. Не?

Откуда знаешь, что делает с мозгом команды скрам?

у комментирующий тезис проверяется не об работу, в контексте которой речь шла, а про спорзал и упражнения математикой

в физ. труде - строитель работает всегда на 2 часа больше, и 1 лишний раз в неделю - ничего не случится

в интеллектуальном - случится

так проще надеюсь :)

Вобщем, что я вынесла из подкаста, кратко, то что полезно для меня. Но на самом деле вопросов в подкасте освещено больше. Если что не так поняла, поправляйте 😊

Мой проект подходит под внутреннюю продуктовую разработку, где продукт - это ИС для внутренних нужд, но при этом нет заказчика, который знает что хочет. Поэтому команда идёт к внутреннему клиенту и предлагает решения, тестируя на пользователях (внутренние клиенты). У нас вроде все именно так.

В данном случае в роли владельца продукта и менеджера проекта может быть один человек, и не важно, как его назвать, у него две роли, скорее всего. При этом одинаковая для обеих ролей ответственность (но функции разные из-за того, что накладывает скрам на PO).

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

Этот вопрос проясняет Dual-track agile, который предусматривает две Стадии работы над продуктом:

1. Product Discovery. Дискавери-команда (продакт менеджер, аналитик, дизайнер и тд) ищет и тестирует гипотезы, за какую ценность клиент готов платить.

2. Product Delivery. Скрам-команда разрабатывает фичи, поданные на вход из дискавери стадии. В скрам команду входят инженеры, которые особо не нужны на Дискавери стадии, а также продакт менеджер.

Продакт менеджер работает на всех уровнях, стратегически охватывает воронку.

Спринты по каждой стадии могут быть разными, или задачи каждой стадии могут входить в один спринт. (Вот тут не совсем уловила, но нашла выступление Кузнецова, ещё не смотрела, может там прояснит).

Бывают также команды, которые способны делать все - и Дискавери, и Деливери. Это зрелые команды, в которых продуктовые обязанности распространяются на всю команду. При этом формальную ответственность несёт все же владелец продукта.

Для заказной разработки Роль владельца продукта может выполнять спокойно обычный аналитик (со стороны заказчика или подрядчика, не важно) или аккаунт менеджер, или руководитель проекта. То есть тот человек, который непосредственно общается с заказчиком, встречается с ним. Функционал - владеть беклогом, сортировать его, может дропать спринты.

Вобщем, что я вынесла из подкаста, кратко, то что полезно для меня. Но на самом деле вопросов в подкасте освещено больше. Если что не так поняла, поправляйте 😊

Мой проект подходит под внутреннюю продуктовую разработку, где продукт - это ИС для внутренних нужд, но при этом нет заказчика, который знает что хочет. Поэтому команда идёт к внутреннему клиенту и предлагает решения, тестируя на пользователях (внутренние клиенты). У нас вроде все именно так.

В данном случае в роли владельца продукта и менеджера проекта может быть один человек, и не важно, как его назвать, у него две роли, скорее всего. При этом одинаковая для обеих ролей ответственность (но функции разные из-за того, что накладывает скрам на PO).

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

Этот вопрос проясняет Dual-track agile, который предусматривает две Стадии работы над продуктом:

1. Product Discovery. Дискавери-команда (продакт менеджер, аналитик, дизайнер и тд) ищет и тестирует гипотезы, за какую ценность клиент готов платить.

2. Product Delivery. Скрам-команда разрабатывает фичи, поданные на вход из дискавери стадии. В скрам команду входят инженеры, которые особо не нужны на Дискавери стадии, а также продакт менеджер.

Продакт менеджер работает на всех уровнях, стратегически охватывает воронку.

Спринты по каждой стадии могут быть разными, или задачи каждой стадии могут входить в один спринт. (Вот тут не совсем уловила, но нашла выступление Кузнецова, ещё не смотрела, может там прояснит).

Бывают также команды, которые способны делать все - и Дискавери, и Деливери. Это зрелые команды, в которых продуктовые обязанности распространяются на всю команду. При этом формальную ответственность несёт все же владелец продукта.

Для заказной разработки Роль владельца продукта может выполнять спокойно обычный аналитик (со стороны заказчика или подрядчика, не важно) или аккаунт менеджер, или руководитель проекта. То есть тот человек, который непосредственно общается с заказчиком, встречается с ним. Функционал - владеть беклогом, сортировать его, может дропать спринты.

Чего добились?! Рост ROI на 30% за 5 лет, маркет шер вырос, стикнес, расходы на user acquisition упали, запуск внутренних инициатив вырос с года до 3 месяцев (усреднённое)

А за счёт чего? Выросла эффективность работы каждого исполнителя, стало меньше накладных расходов, стало меньше расходов труда, которые под итогу просто выбрасываются?