Czy Product Owner może narzucać wymagania architektoniczne?
Zasadniczo zadaniem Product Ownera jest określenie, co ma zostać zbudowane, a nie jak ma zostać zbudowane. Istnieją jednak sytuacje, w których Product Owner powinien podjąć pewne decyzje dotyczące architektury.
Kiedy narzucanie wymagań przez Product Ownera ma sens?
Kiedy firma Sun chciała kiedyś wypromować język programowania Java, oferowała firmom pieniądze za tworzenie aplikacji w Javie. Niektórzy Product Ownerzy, z którymi wtedy pracowałem, nakazywali więc swoim zespołom korzystanie z Javy.
W niektórych przypadkach były to niewielkie projekty biznesowe, które bez finansowania przez Sun w ogóle nie byłyby uzasadnione. W takich sytuacjach takie wymagania miały sens. Deweloperzy nie sprzeciwiali się, bo chcieli wypróbować tę zupełnie nową technologię.
Product Owner nie powinien zbyt często narzucać wymagań technicznych, a jeśli już to robi, powinien podejść do tego bardzo rozważnie – i mieć pewność, że jego decyzja jest słuszna.
W większości przypadków narzucanie Javy nie było jednak dobrą decyzją, ponieważ we wczesnych dniach język ten nie radził sobie dobrze z wyzwaniami, jakie stawiały te aplikacje.
Weźmy jako kolejny przykład urządzenie wbudowane (embedded device). Product Owner zdecydował, że produkt jest opłacalny ekonomicznie przy użyciu określonego sprzętu, ale nie przy nieco droższym.
Product Owner informuje więc zespół deweloperski, że powinni korzystać wyłącznie z tego sprzętu. Oczywiście zespół mógłby woleć pracować z droższym sprzętem, ale wtedy produkt nie byłby już ekonomicznie opłacalny.
Product Ownerzy mogą więc w niektórych przypadkach narzucać architekturę. Powinni jednak robić to rzadko, po przemyśleniu i najlepiej w porozumieniu z zespołem.
Tekst pochodzi z bloga Mike'a Cohna i został udostępniony nam do tłumaczenia.
