Как стать автором
Обновить

Комментарии 2

Нальешь кружечку чая, откусишь печеньку — и оп, статья закончилась ))

Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.

Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.

Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?

Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
Я пока сфокусировался на том, чтобы писать понятно и не сложно. Как только у меня начнет это получаться — буду писать длиннее, может даже на несколько печенек хватит.

Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг.

Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.

Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.

Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.

Т.е. как происходит организация команд для реализации мега-продуктов?

Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий