I Product Owner possono imporre requisiti architetturali?
Fondamentalmente, il compito del Product Owner è stabilire cosa deve essere costruito e non come deve essere costruito. Tuttavia, ci sono situazioni in cui è appropriato che il Product Owner prenda alcune decisioni sull'architettura.
Quando ha senso che il Product Owner dia indicazioni?
Ad esempio, quando anni fa l'azienda Sun voleva diffondere il linguaggio di programmazione Java, offriva denaro alle aziende per sviluppare applicazioni in Java. Alcuni Product Owner con cui lavoravo all'epoca ordinarono quindi ai loro team di lavorare con Java.
In alcuni casi, le applicazioni erano business case marginali che non sarebbero stati giustificati senza il finanziamento di Sun. In quei casi, le indicazioni avevano perfettamente senso. Gli sviluppatori non si opposero, perché volevano provare questa nuovissima tecnologia.
Non dovrebbe accadere frequentemente che un Product Owner dia un'indicazione tecnica, e quando lo fa, dovrebbe farlo con estrema coscienziosità, per avere ragione nell'imporre tale indicazione tecnica.
Nella maggior parte dei casi, tuttavia, imporre Java non fu una buona decisione, poiché nei suoi primi giorni Java non era ancora in grado di affrontare le sfide di quelle applicazioni.
Prendiamo come ulteriore esempio un dispositivo embedded. Il Product Owner ha deciso che il prodotto è economicamente sostenibile con un determinato hardware, ma non con un hardware leggermente più costoso.
Il Product Owner dice quindi al Dev Team di utilizzare solo quell'hardware. Naturalmente il team preferirebbe forse lavorare con l'hardware più costoso, ma il prodotto non sarebbe più economicamente sostenibile.
I Product Owner possono quindi, in alcuni casi, imporre l'architettura. Tuttavia, dovrebbero farlo raramente, in modo ben ponderato e preferibilmente in accordo con il team.
Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.
