Co mierzy dobry Product Owner, odcinek #3/5 Jak zmierzyć JAKOŚĆ?

Spis Treści

Co mierzy dobry Product Owner, odcinek #3/5 Jak zmierzyć JAKOŚĆ?

Kilka lat temu, gdy zacząłem uczyć się języka polskiego, poznałem stwierdzenie „temat rzeka”, czyli jak tłumaczy Wielki Słownik Języka Polskiego, to temat na który można rozmawiać niemal bez końca, bardzo obszerny i mający wiele wątków. Wspominam o tym, bo dla mnie „jakość produktu” to temat rzeka. Postaram się nie odpłynąć.

 

Przeczytaj drugą część: Jak zmierzyć DOSTOSOWANIE? Kliknij TUTAJ

 

Czym jest jakość produktu?

Wiele źródeł, między innymi Wikipedia, definiuje jakość produktu jako pewien poziom doskonałości produktu. Uważa się, że jakościowy produkt ma zdolność do zaspokojenia potrzeb określonego nabywcy.

Jakość produktu rozpatrujemy w dwóch aspektach:
– jakość wewnętrzna (technologiczna): wszystkie cechy wbudowane w produkt (funkcjonalność, praktyczność, niezawodność, trwałość, bezpieczeństwo użytkowania);
– jakość zewnętrzna (rynkowa): cechy istotne z punktu widzenia konsumenta (ekskluzywność, estetyczność, prezentacja, koszt nabycia, usatysfakcjonowanie).

Product Owner i jakość

Zgodnie z zasadami Scrum, odpowiedzialność za jakość produktu ponosi zespół scrumowy, czyli Product Owner, Scrum Master i zespół deweloperski. Niestety, nie znajdziesz w Scrum Guidzie informacji kto konkretnie za który z aspektów jakości odpowiada i w jaki sposób. Odpowiedzi musisz więc szukać w innych źródłach, a niektóre hipotezy „potwierdzić” samodzielnie, biorąc pod uwagę warunki Twojej organizacji.

Wiedząc czym jest jakość produktu, jakie ma aspekty oraz rozumiejąc ogólne zasady Scruma, możemy wnioskować że, istotny wpływ na jakość wewnętrzną ma zespół scrumowy. Natomiast, jeżeli chodzi o jakość zewnętrzną, to tu zdecydowanie więcej pracy ma Product Owner. Dobry Product Owner, powinien mieć otwarte oczy na oba aspekty jakości, ponieważ są one ściśle powiązane ze sobą. Mówiłem że to temat rzeka? Zaparkujmy tu.

 

Product Owner i jakość wewnętrzna

Jakość wewnętrzną oceniać można na wiele sposobów, a wybór odpowiedniej metryki zależy tylko od postawionego celu. Na przykład, można przeprowadzić diagnozę jakości wewnętrznej produktu na podstawie danych o liczbie wykrytych błędów i poziomie ich istotności. Zaznaczam, że zbieranie tego rodzaju danych nie jest bezpośrednim obowiązkiem Product Ownera. Chodzi tu raczej o uzyskanie informacji zarządczej [management information], czyli informacji używanej do podjęcia decyzji.

The Defect Count

Używając tego narzędzia, zespół scrumowy pozna bieżącą liczbę wykrytych błędów w oprogramowaniu. Jest to tak proste narzędzie, że nie ma co o nim bardzo mówić. Rysunek pokazuje jak może wyglądać wykres.

The Fault Severity metric

To narzędzie jest wykorzystywane do oceny poziomu istotności błędów w oprogramowaniu. Wyróżniamy trzy rodzaje błędów: drobne [Minor faults], główne [Major faults] i krytyczne [Critical faults]. Zespół scrumowy może sklasyfikować błędy samodzielnie lub skorzystać z istniejących standardów. Na przykład, organizacja dla której obecnie pracuję, używa standardu TL9000. 

Widziałem dwa sposoby używania tej metryki:

  • dla kategoryzacji i obliczenia wykrytych błędów;
  • dla kategoryzacji i obliczenia naprawionych błędów.

Z pierwszego sposobu częściej korzystały zespoły scrumowe (rozwój produktu), z drugiego – zespoły zarządzania operacyjnego (utrzymanie produktu).

To raczej jest oczywiste, ba nawet trywialne, ale muszę o tym powiedzieć. Nawet wysokiej jakości produkt informatyczny zawiera małą ilość błędów. To akurat jest normalne. Natomiast fakt, że w oprogramowaniu nie znaleziono żadnych błędów, nie gwarantuje, że ich tam nie ma. 

Podczas oceny jakości wewnętrznej, zwracaj uwagę nie tylko na ilość błędów, ale i na ich istotność, ponieważ dla przeprowadzenia wartościowej analizy tylko danych o liczbie błędów będzie za mało. Na przykład, naprawa trzech drobnych, czy dwóch głównych błędów, nie zajmie tyle czasu, ile naprawa jednego krytycznego błędu. A wykrycie trzech lub więcej krytycznych błędów w krótkim czasie może doprowadzić do sytuacji, gdy konieczną będzie zmiana zakresu prac i ponowne uszeregowanie celów według priorytetu. Im gorsza jakość oprogramowania, tym więcej czasu zespół będzie naprawiać błędy, a nie dostarczać nową wartość biznesową.

Dane o poziomie jakości technologicznej produktu zawsze przydają się Product Ownerowi. Product Owner świadomy jakości wewnętrznej produktu potrafi:

– sensowniej ustalić krótkoterminowe i średnioterminowe plany na rozwój produktu z interesariuszami;

– lepiej przygotować się do Refinementu i planowania Sprintu;

– precyzyjniej opisać elementy backlogu produktu, np. doprecyzować definicję ukończenia [definition of done] czy kryteria akceptacji [acceptance criteria];

– obliczyć koszt wytwarzania i koszt naprawy produktu;

– anulować Sprint…

… mogę jeszcze długo wymieniać, to temat rzeka, ale chyba na ten moment wystarczy.

 

Product Owner i jakość zewnętrzna

Dla badania i oceny jakości rynkowej użyjemy innych, ale już znanych z poprzednich odcinków narzędzi. Na przykład, sprawdzimy satysfakcję konsumenta i jego opinie na temat estetyki czy ekskluzywności produktu za pomocą narzędzia Net Promoter Score (NPS). 

Prawie we wszystkich kwestiach związanych z kosztem nabycia oraz możliwości jego obniżenia czy podwyższenia pomogą narzędzia Return on Investment (ROI) i Relative Return on Investment (RROI).

W średnich i dużych organizacjach, Product Owner może współpracować nie tylko z interesariuszami, ale i z innymi działami organizacji: finansowym, marketingu i sprzedaży. W ramach tej współpracy, PO może zlecić wykonania badań i oceny jakości zewnętrznej produktu, a później być odbiorcą wyników i raportów pochodzących z tych badań.

Na tym zakończmy odcinek o jakości. Niech nasze produkty będą jakościowe i zapewnią radość z korzystania.

 

Shopping cart

0

No products in the cart.