Про продуктовые команды 🤝
(Часть 2 - Кросс-функциональные команды)
SG декларирует, что команда должна быть способна производить на свет инкремент, независимо от внешних ресурсов. То есть, должна обладать всеми компетенциями, необходимыми для разработки всех компонентов необходимых для реализации фичи.
Agile coach'и любят рассказывать сказки про то, как "нужно на Ruby - открываем учебник и садимся писать на Ruby". На деле это дорого и неэффективно, а кросс-функциональность чаще достигается унификацией технологического стека.
Мои наблюдения говорят, что этим Sbergile проигрывает Яндексовой вариации Scrum.
✦ В Яндекс Маркете повсюду Java и React. Поэтому для ддоработки соседнего сервиса для реализации конкретной фичи разработчику просто нужна консультация или нормальная дока. К тому же, в случае смены приоритетов бизнеса это даёт возможность быстрее перераспределить ресурсы.
✦ В Сбере (не смотря на унифицированный стек) команды привязаны к системам. И даже в случае потребности редко лезут дорабатывать системы соседей, чтобы избежать ответственности за факапы. Это приводит к чудовищным затратам ресурсов и времени на синхронизацию планов и частому "переводу стрелок" в случае факапов.
Когда команда, действительно, может производить на свет функционал независимо от окружающих, это позволяет намного быстрее деливерить фичи ⇒ быстрее получать обратную связь ⇒ делать большие итераций за то же самое время ⇒ добиваться лучших результатов.
Поэтому я не верю в SAFe и LESS. Это всё попытки выдать желаемое за действительное, без реальной автономности. Только микросервисность, только независимые команды, только хардкор. 🤘
#product_team #product_management #Scrum
Post #227
830