Как решить, что владелец продукта и руководитель группы предъявляют противоречащие друг другу требования?

Скажем, Владелец Продукта, который утверждает всю работу до того, как она пойдет в производство, записывает требования как X.

Руководитель группы (старший разработчик), который одобряет все изменения кода, говорит, что нужно делать Y, что противоречит X.

Как вы разрешаете противоречивые направления между двумя людьми, каждый из которых имеет власть над проектом?

Указывали ли вы кому-либо из них на противоречие в требованиях?
Это технические требования или функциональные требования? Владелец продукта отвечает за то, что продукт делает, тимлид отвечает за то, как он это делает.

Ответы (2)

Это тот случай, когда вы сначала соберете их двоих в комнату и позволите им все обсудить.

В рабочем процессе Agile владелец продукта определяет требования. У руководителя группы есть право голоса, пока готовится история ( как и у всех членов команды ), но как только история находится в спринте, требования не должны меняться .

Если двое из них не могут прийти к соглашению/пониманию, обсудите это со своим менеджером , так как это может быть проблема, которую вы не можете решить самостоятельно.

Однако на данный момент кажется , что вашему руководителю группы необходимо напомнить, что владелец продукта определяет требования, и команда в целом должна их реализовать (внедрить).

Примечание . Если есть техническая причина, по которой может потребоваться изменение требования, это следует обсудить с владельцем продукта перед кодированием .

В Scrum требования могут меняться во время спринта в результате того, чему они научились во время спринта, и это тоже не обязательно плохо.
@Erik согласился как исключение, а не как норма.
@Erik по определению вы хотите, чтобы требования к элементам, которые будут созданы во время спринта, были зафиксированы в камне, в противном случае эти требования еще недостаточно хорошо поняты, чтобы этот элемент можно было использовать в спринте. Одним из основных моментов схватки является то, что все происходит плавно вплоть до спринта, так что вы можете быть достаточно уверены, что действительно сможете обеспечить приращение, соответствующее требованиям. Если требования меняются, вам необходимо переоценить, сможете ли вы их выполнить, что отнимает время на создание приращения.
@Cronax Нет, нет. Если происходит что-то странное и вам приходится выбирать между изменением требований и созданием неправильного продукта, вы хотите изменить требования. Как говорит Нео, это должно быть исключением, но это все же лучше, чем альтернатива, когда это происходит.
@ Эрик Я говорю, что вы не хотите, чтобы это была стандартная рабочая процедура, потому что в этот момент вы никогда не будете уверены, действительно ли вы можете выполнить спринт. На самом деле я бы сказал, что вместо того, чтобы просто принимать меняющиеся требования с ходу, желательной процедурой было бы полностью остановить спринт и, если функция по-прежнему является наиболее важным и подходящим способом добавления ценности, доработать ее в достаточной степени, а затем начать новый спринт. Команда фиксирует невыполненную работу спринта, когда вы меняете требования, вы больше не делаете то, что обещали.
Если нам нужно обсудить это дальше, я бы предложил перенести это в чат.
Команды @Cronax не брали на себя обязательства по спринту с 2011 года :)
@ Эрик, слово «обязательство» было выбрано неудачно, концепция все еще актуальна: без согласованного объема вы никогда не сможете провести успешный спринт.

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

Обратите внимание, что отметка в комментариях — отличное и неизменное место, чтобы указать, как это изменение противоречит требованиям владельца продукта, но требуется руководителем группы.