Полностью с вами согласен - зачастую архитекторы спускают в продукты/команды задачи, без объяснения их глобального смысла. На мой взгляд, задача скрам мастера в команде архитекторов (о чем идет речь в статье) стоит в том числе в том, чтобы помочь им сформулировать задачи не в конкретных action items, а наполнить их продуктовым смыслом, чтобы команды их могли "купить".
Большое количество участников действительно в большинстве своем не эффективно, если не использовать техники фасилитации встреч. В примере, который описан выше, в рамках этого дня участники основную часть времени работали в мини-группах до 10 человек, разбирая зависимости друг от друга. Хорошим показателем успешности встречи можно назвать значение ROTI (Return of Time Investment), который сами участники оценили более, чем в 3,5/5, где 3 - результаты полностью соответствовали ожиданием, затраченное время = полученная польза.
Если брать конкретные примеры, то это задачи, связанные с переходом на целевые экосистемные платформы, переходом на cloud native архитектуру, повышением скорости поставки, обеспечением надежности и т.п.. При этом во главе угла ставятся текущие показатели конкретного продукта (в том числе его технологическая зрелость) и каждый продукт сам принимает решение, какие из задач запланировать на ближайщий квартал. Что касается КПЭ, то в них учитываются не только бизнес, но и ИТ составляющая.
Это не так, в статье написано, что конкретно у команды архитекторов много как входящих, так и исходящих зависимостей и визуализация процесса работы помогает как раз избежать лишних совещаний, достаточно просто посмотреть статус.
Я думаю, что вы согласитесь, что правила нужны. Другой вопрос в том, что их количество должно быть минимальным. Ваш пример про 4 статуса - классический, только вот задача хорошего скрам мастера не звонить/ругаться (это один из антипаттернов его работы), а помочь с устранением препятствий, мешающих эффективной работе команды. В вашем случае - разобраться, зачем нужны эти 4 статуса и помочь с упрощением workflow.
Полностью с вами согласен - зачастую архитекторы спускают в продукты/команды задачи, без объяснения их глобального смысла. На мой взгляд, задача скрам мастера в команде архитекторов (о чем идет речь в статье) стоит в том числе в том, чтобы помочь им сформулировать задачи не в конкретных action items, а наполнить их продуктовым смыслом, чтобы команды их могли "купить".
Большое количество участников действительно в большинстве своем не эффективно, если не использовать техники фасилитации встреч. В примере, который описан выше, в рамках этого дня участники основную часть времени работали в мини-группах до 10 человек, разбирая зависимости друг от друга. Хорошим показателем успешности встречи можно назвать значение ROTI (Return of Time Investment), который сами участники оценили более, чем в 3,5/5, где 3 - результаты полностью соответствовали ожиданием, затраченное время = полученная польза.
Если брать конкретные примеры, то это задачи, связанные с переходом на целевые экосистемные платформы, переходом на cloud native архитектуру, повышением скорости поставки, обеспечением надежности и т.п.. При этом во главе угла ставятся текущие показатели конкретного продукта (в том числе его технологическая зрелость) и каждый продукт сам принимает решение, какие из задач запланировать на ближайщий квартал. Что касается КПЭ, то в них учитываются не только бизнес, но и ИТ составляющая.
Это не так, в статье написано, что конкретно у команды архитекторов много как входящих, так и исходящих зависимостей и визуализация процесса работы помогает как раз избежать лишних совещаний, достаточно просто посмотреть статус.
Я думаю, что вы согласитесь, что правила нужны. Другой вопрос в том, что их количество должно быть минимальным. Ваш пример про 4 статуса - классический, только вот задача хорошего скрам мастера не звонить/ругаться (это один из антипаттернов его работы), а помочь с устранением препятствий, мешающих эффективной работе команды. В вашем случае - разобраться, зачем нужны эти 4 статуса и помочь с упрощением workflow.