Comments 3
"дерево текущей реальности" (TOC)
может CRT?
Вопросик. Схемка выше построена по мотивам какого-то подхода или это чисто ваше? Хотелось бы почитать подробнее.
Это чисто мое, исходя из опыта построения нескольких команд. Опираюсь на ЖЦ требования (блоки), и декомпозирую движение по разным стадиям. За основу декомпозиции беру артефакты, которыми обменивается команда.
Немного уточню. У меня точно не было цели изобрести велосипед. Скорее я искала и пробовала разные подходы, какими объектами удобнее оперировать, чтобы был понятно, с чего начать и что должно быть на выходе.
Чаще всего у нас основной объект внимания - это задача, сбор и приоритезация бэклога. Я тоже пишу о том, что управление требованием - ключевой процесс. Но работа с задачами - это не подход к улучшению взаимодействия. Если продакт супер молодец, умеет принимать решения, то и работа будет комфортной. Но это сложно масштабируется.
Пробовали строить кросс-функциональную RACI-матрицу, задачи вроде все понятны. В итоге подняли большой пласт спорных областей влияния, закопались в детализацию, ни к чему не пришли.
Была попытка сразу оттолкнуться от процесса. Хорошо работает на малых масштабах, но если команда разрастается и в кросс-функцию, и численно, от процесса тяжелее идти, более трудозатратно. Также был подход рассмотреть систему продуктового управления как набор объектов менеджмента. Достаточно сложно, если не иметь четко структурного мышления.
Короче, после разных плясок с бубнами, вроде удалось привести к какому-то алгоритму, который понятен всем участникам и помогает достаточно быстро формализовать сложную область.
Вышел на Head of Product? Welcome to total chaos