Здравствуйте. Возможно выше уже обсуждали, надеюсь, вопрос не сдетонирует :-)

У нас на внутреннем совещании (очень большая корпорация, ИТ-продукты все внутренние) возник спор, откуда должен быть Владелец продукта, от бизнес-заказчика или от исполнителя - внутреннего ИТ-интегратора. Лично мое убеждение, что от бизнеса, но мне приводили убойные доводы, что в идеальном мире да, а в реальном ни один бизнес не найдет столько времени на ИТ-продукт (вспоминаем 60 часов в неделю Марти Кагана), да и разбираться даже поверхностно в разработке для общения со всей командой не будет. Что думаете?

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

Он может отследить как точно дается оценка по задаче и были ли причины (учитывая сложность) почему та или иная задача делалась определенное время

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

МОЖЕТ - это ключевое :)

Привет! Сергей, отвечая по сути твоего вопроса - я встречал оба варианта. Я бы искал людей в ИТ с нормальным пониманием бизнеса и желанием быть кем-то выше проджект менеджера. Люди из бизнеса обязательно должны быть заинтересованы в сотрудничестве с ИТ, даже если они ни в зуб ногой в процессах разработки. Основной вопрос, на самом деле в том, кому больше всего нужен результат. Если результат нужен бизнесу, они видят в этом ценность, то они будут уделять время (по практике 10 часов в неделю достаточно). Если результат нужен ИТ, то есть большой вопрос авторизации этого результата у бизнеса даже если они выберут PO из ИТ. Есть вероятность, что он будет прокси

Добрый день! У нас в компании в этом кейсе создана дирекция по цифровой трансформации. Как прослойка между бизнесом и ИТ. Ребята из трансформации фактически PO и подкованные в айти но в первую очередь думают о том как сделать работу бизнеса эффективнее и говорят с ним на бизнес языке, а во внутреннюю команду ИТ уже приходят с решениями выявленных болей. В каждой компании свой кейс, имхо, и находИтся в команде можно до определённых масштабов размера компании. Недавно мы перешли в SAFe и модель когда PO были внутри команд показала себя не жизнеспособной на данном этапе развития.

>Какова ценность того, что ВП, не входящий в состав разрабов, будет разбираться в разработке? Как минимум, чтобы общаться в команде на одном языке (ВП уже в одной команде и команды разрабов в новом гайде нет, т.е. "слияние" ВП и разрабов еще более плотное). Марти Каган даже рекомендует ВП пойти на курсы программирования :-)

Я так и написала: если ВП сам является разрабом в команде, его знания имеют смысл, а если нет - зачем ему так уж сильно разбираться в разработке? Первоочередная задача ВП - максимизировать ценность Тут ещё вопрос, что такое "поверхностно разбираться"... Критерии у всех разные

Так это стандартная ситуация. Обе стороны здесь правы, но по-своему. Поэтому в достаточно больших продуктовых коммандах есть разделение на Product Manager и Product Owner. С одной стороны да, главный продакт таки должен иметь отношение к бизнесу, с другой придется много операционки делать. Если и то и то не не получается из-за размера проекта, то стои разделить

Правильные вопросы, спасибо >Я бы искал людей в ИТ с нормальным пониманием бизнеса Так нередко делаем, но ощущение, что бизнес не делегирует таким людям должного количества полномочий. Помните, ВП расставляет в Бэклоге приоритеты, а такой ВП от ИТ не может и ходит с вопросами к бизнес-заказчику. И потом часто, когда ИТ находит у себя "разбирающегося в бизнесе", то все равно от него скрывается внутренняя кухня бизнеса, которая в регламентах не прописана или которая работает по принципу "у нас так сложилось" >Основной вопрос, на самом деле в том, кому больше всего нужен результат. Если результат нужен бизнесу, то они будут уделять время Вот и странно, результат точно нужен бизнесу, даже в годовых КПЭ с бонусом их висит, а все равно говорят, некогда нам, у нас на первом месте текущие бизнес-процессы, Run-деятельность, мы вам детальные требования дали, на вопросы отвечаем, что вы от нас еще хотите, какой еще продуктовый менеджмент. Вот и возникают ВП в ИТ, но они не совсем себя прокси чувствуют, тк хоть и приоритеты не расставляют, но приходят с предложениями по приоритетам к бизнесу. Мда...

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

Не, крайне не советую так делать. Enablers про которые ты пишешь не имеют прямой связи с решением сиюминутных юзерских проблем, поэтому ВП будет их хронически деприоретизировать. Тут нужно подумать а что является природой Enablers и как понять их приоритет. В общем случае Enablers имеют внутренюю природу, их ценность определяется теми KPI которые они оптимизируют. Например может быть метрика technical debt in days. И если она больше чем какое-то пороговое значение, мы понимаем что это является проблемой. Приоритезация беклога же обычно решается полиси вроде 80% юзер сторей, 20% enablers. ВП не должно касаться что в эти 20% идет. Ну а что бы в 20% не валился всякий муссор, то нужно что бы кто-то задал KPI и стартегию. Как ни крути нужен технический оунер, он же CTO

Хороните проект, У бизнеса нет желания уделять время для приоритизации заявок и разъяснения. У вас там заняться больше не чем, чем заниматься мертвым проектом? Я уверен что портфель заказов/заявок на 2 года минимум висит. Их висящий КПЭ не означает, что проект им нужен. Правила простые: 1. Если никто от бизнеса не берет на себя ответственность уделять 2 часа в неделю - хороним проект. 2. Если тот, кто взял на себя обязательство пропустил одну плановую встречу (без уважительной веской причины) - хороним проект. Это не зависит от количества промежуточных участников. На встрече может быть команда или аналитик, или архитектор. Но они все представляют сторону Исполнителя.

Спасибо. Это похоже на Product department, про который нам рассказывал тренер из ЮАР на курсе ICAgile. А у вас на один продукт из дирекции выделяется один РО или это всегда работа команды дирекции?

Хорошее решение в целом, понятное. Хотя сразу ассоциация с законом Паретто (и получается тогда смешно, что самую ценность какраз приносят enablers). Но в целом не соглашусь, не может быть части бэклога у РО, а другой части у кого-то еще. РО за весь Бэклог отвечает и должен разбираться, иначе грош ему цена. Что значит деприоретизировать? Может он и с ошибками тоже не хочет разбираться? Как это? Нет, изволь найти время и понимание. И при чем тут сиюминутная ценность? В Канбан есть отдельный класс сервиса: нематериальрый. Профукаете его и привет, у вас появится серьезная проблема, так что весь продукт встанет со всеми вашими супер фичами

Коллеги выше набросали вариантов и с ОЦТ, и из ИТ вырастить, и из Бизнеса научить, и аналитиком заменить. Стабильно работающий подход мне известен только один, вопрос РО решает человек ответственный за бюджет продукта, учитывая принятые в компании регламенты. Это его головная боль, его проблема и его необходимая квалификация. Если СД, ИК или ОЦТ выдали денег недостаточно квалифицированому человеку - корпоративно конструктивное действие - подождать пока он облажается и его уйдут.

Алексей, спасибо, меня прямо бодрить начинает от, как всегда, Вашего уверенного напора :-) Завидую. Может к нам в компанию устроитесь? А то у нас с таким напором выгорают на раз и привет... еще одного менеджера продукта не стало... Но идея мне нравиться. Лично сам проектному офису предлагал: "Таак, все!!! Если бизнес не выделяет в проект менеджера (читай РО) на 60 часов в неделю, кукиш с маслом, а не проект им!" Только всегда получается как в анекдоте про ковбоя и крашеную лошадь: "Извините, я только хотел спросить когда она высохнет". Не работали Вы похоже в жестких ентерпрайзах...

Дело в том, что нет никакого волшебного скила "разбираться в беклоге". Есть конкретные цели измеренные в каких-то числах для каждлого учатсника процесса. Да кстати и с багами, тожем можно подумать насчет полиси. Откуда ВП знает сколько багов нужно закрыть из имеющихся? Скорее всего где-то смежный есть товаришь - customer success. Можно придумать политику например классификации багов, какие-то фиксить на месте, какие-то в беклог и брать ~10% в спринт и так далее.

По ссылке, первым блоком идет выступление исполнительного директора ЕвроАвто, про проектные комитеты и принятие решений. https://www.youtube.com/watch?v=GtUMbRFNNZs Когда я работал в найме, я мало обращал внимание на существующие политики и правила. Если мне нужен был результат, то я его достигал любыми средствами. Самое важное в этом деле - помнить, что "завтра" может быть последний день в этой компании, но их на рынке еще много осталось. Ключевая история: Вы лично хотите УСПЕШНЫЙ проект или нет? Если да, то лучше действовать как я предлагаю, если вас всё устраивает, то зачем вообще дёргаться? Все изменения приводят к увольнению. Рано или поздно. Я могу только как Консультант вам помочь, в рамках консалтингового проекта. Только в этом варианте есть все необходимые полномочия.

Правила и полиси - это прекрасно, но нужно помнить закон Чизхолма, все что может быть понято неправильно, будет понято неправильно, поэтому мы все с вами привержены одной из ценности Agile - непосредственному общению. И если общаясь с тестировщиками РО делает круглые глаза на термины регресс, смоук, автотест, то вам и полиси не поможет. РО же должен это полиси, как член команды понять

На пальцах должен понимать, да. Но должен ли ПО заниматься созданием тестовой стратегии? Именно она диктует скоуп тестирования, кстати.

Воот, точно, на пальцах. Стратегией нет, но должен понимать, что она нужна и что вообще она есть такая (я например, к своему стыду первый раз слышу, у нас в компании похоже ее нет 😢 ) и возможно грамотный РО должен пушить блок ИТ, чтобы дизайн-системой занялся, безопасной разработкой, тестовой стратегией. А то ведь как рассуждает блок ИТ в корпорации: эти все вещи денег стоят, а кто за них платить будет? Опять за счет внутренней рентабельности выезжать? Например, у ИБ с этим проблем нет, напугать утечками и взломами можно легко, а как напугать тестовой стратегией, что она нужна?

Реальность такова, что если у какой-то функции нет C-level «представителя», то бюджета не дадут, а саму функцию будут рассматривать как кост-центр который нужно при первой возможности порезать/заутсорсить

Алексей, Вы мне все больше и больше импонируете. В моем возрасте прыгать по компаниям что-то уже нет желания. А в части увольнения вспомните Кена Швабера, никому не нужна мертвая пастушья собака

Я 6 лет в в энтерпрайзе отработал. И именно на таких условиях: хотите успешный успех, давайте в команду представителя от бизнеса. Нет РО со стороны бизнеса, нет успеха, сами виноваты. И да, это стоило много крови.

Денис, тут SAFe виден невооружённым глазом. Но мир шире, и такой подход противоречит тому, что РО - это максимизатор ценности. Нельзя просто так взять и отнять у него 20% капасити. Ну и в SAFe РО - и не РО вовсе :)

Ну почему же, мой мир значительно шире SAFe, к проблеме можно подходить и через канбан через сервис классы - получается примерно похоже. А вот мирок скрама наоборот мал и порождает «неразрешимые» проблемы вроде того, что невозможно приоритизировать ничего, что не является пользовательской историей.