Os Product Owners podem definir requisitos de arquitetura?

Basicamente, é tarefa do Product Owner definir o que deve ser construído e não como deve ser construído. No entanto, também existem situações em que é apropriado que o Product Owner tome algumas decisões sobre a arquitetura.

Quando faz sentido o Product Owner definir diretrizes?

Quando a empresa Sun, por exemplo, quis divulgar a linguagem de programação Java há alguns anos, ofereceu dinheiro às empresas para desenvolverem aplicações com Java. Alguns Product Owners com quem eu trabalhava na época determinaram que suas equipes deveriam trabalhar com Java.

Em alguns casos, as aplicações eram business cases menores que não se justificariam sem o financiamento da Sun. Nesses casos, as diretrizes faziam total sentido. Os desenvolvedores não se opuseram, pois queriam experimentar essa tecnologia novíssima.

Não deveria acontecer com frequência de um Product Owner fazer uma exigência técnica, e quando isso ocorrer, ele deveria fazê-lo com extrema consciência, para ter certeza de que está certo em fazer essa exigência técnica.

Na maioria dos casos, no entanto, exigir Java não foi uma boa decisão, pois em seus primeiros dias, Java ainda não conseguia realmente lidar com os desafios dessas aplicações.

Vamos usar um dispositivo embarcado (embedded device) como outro exemplo. O Product Owner decidiu que o produto é economicamente viável com um determinado hardware, mas não com um hardware um pouco mais caro.

O Product Owner então diz ao Dev Team que devem usar apenas esse hardware. Naturalmente, a equipe talvez preferisse trabalhar com o hardware mais caro, mas o produto não seria mais economicamente sustentável.

Product Owners podem, portanto, em alguns casos, definir a arquitetura. Mas devem fazer isso raramente, de forma bem pensada e preferencialmente em acordo com a equipe.

Este texto é do Blog de Mike Cohn e foi disponibilizado para tradução para o alemão.