Qaswdd cd

?

IDDQD

Так уже выше отметили. Нет никакого противоречия. Разные жизненные циклы. Соотвественно продуктовый может включать несколько проектов.
1. Разработка концепта
2. Вывод на рынок.
3. Проекты по обновлению, фиксинг и т.п.
4. Проект по закрытию.

А как и в какой методологии не важно...

Собянинские коды?

👍

Это только IDCLIP

IDKFA )

IDSPISPOPD

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

Юлия, часто встречающаяся практика при работе "здесь и сейчас")
Есть вменяемая версия - когда для заказчика просто меньшая детализация - чтобы не грузить, но при этом все прозрачно (точно так же, как и с планом - у тебя 4-6 уровней, с заказчиком обсуждаются 2-4).
Влияет на отношения позитивно, если просят детально показать - показываешь.
Есть неправильная - когда они реально отличаются, при том иногда всем, кроме начальной и конечной точки)))
Как правило убивает отношения при долгих работах/ сотрудничестве.
Либо там просто все очень плохо, либо много распила 😂
Уровень примерно такой же, как "ну мы же обозначили проблему месяц назад, не будем напоминать про нее - остальное же ок (кроме того, что за месяц не сдвинулись в решении проблемы и она осталась блокером))

Если контракт по фикспрайс, то какой смысл подрядчику посвящать заказчика в детали и хитросплетения своего производственного процесса? Какой смысл заказчику знать все эти хитросплетения, захочет ли он этого? Для заказчика достаточно хорошо продуманного плана контрольных точек, то есть вех. И регулярных отчетов, которые показывают прохождение по вехам.
Но если подрядчик работает по T&M, тогда придется показывать подробности, но это уже такие условия контракта. А учить обманывать нехорошо :) это я про одобривших.

Александр, ответ иногда до смешного прост - страховка и проверка себя.
На контрольных точках заказчик видит очень условную картинку.
Да, в самую глубь его посвящать смысла особо нет, а для топов и контрольных точек хватит.
Но тот же план с хорошей декомпозицией (как писал выше - чуть ниже, чем у себя), обсуждаемый с начальником отдела/экспертом - помогает учесть особенности их оргструктуры и организации работ.
При условии, что человек не формально смотрит)

Когда работаешь с разными заказчиками - часто можно недооценить нюансы

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

Если мы говорим про "правильного" заказчика, то там и ситуация с бэклогом, описанная Юлией абсолютно не возможна.
Но будем честными - часто это делается крайне формально.

У меня было достаточно заказчиков, которые согласовали любой ИСР - вы ж эксперты, вам виднее

Часто заказчик не является специалистом в технологиях.

Часто. Отсюда и польза детального обсуждения плана с представителем заказчика

Если захочет этим заниматься. И часто сотрудникам заказчика не до этого. Поэтому остаются вехи.