Trzy poziomy jakości

Trzy poziomy jakości. Dlaczego? Co to właściwie znaczy? Jakość powinna być jedna, niezmienna. Teoria teorią, ale życie zwykle pokazuje coś innego. Istnieją co najmniej trzy poziomy jakości. A ja jestem ciekaw, czy po przeczytaniu tego tekstu przyjdą Wam do głowy kolejne.

 

Jakość, nie jakoś!

Jakość jest podstawą. Nie ma co wytwarzać produktów, jeśli nie jesteśmy w stanie zagwarantować ich jakości. To ona powoduje, że klient wraca do nas po więcej. Sprawia również, że raz wytworzony produkt nie wymaga późniejszych modyfikacji. Bo po prostu nie ma po co.

Nie dziwi więc fakt, że każdy przykłada do jakości tak dużą wagę. Mam tu na myśli wszystkie osoby zaangażowane w proces wytwórczy naszego projektu – od twórców po odbiorców. Nie ma tutaj znaczenia, czy tworzymy oprogramowanie czy dobra materialne. Wszystkie produkty muszą cechować się jakością.

Na potrzeby mojego wywodu przyjmę, że produkujemy oprogramowanie. Ze statystyk wynika, że większość z Was to właśnie programiści lub osoby zajmujące się wytwarzaniem oprogramowania. Świetnie się składa, bo my też dokładnie na tej działce straciliśmy włosy.

Trzeba podkreślić, że jakość przez rozumiana będzie w inny sposób przez różne grupy osób. Dla jednych odpowiednią jakością będzie “brak błędów”, a dla innych…

 

Trzy poziomy jakości

Liczba “trzy” pojawia się najczęściej, gdy zaczynamy rozmawiać o różnych spojrzeniach na jakość. Uwzględnia ona różnych uczestników procesu wytwarzania oprogramowania. Możemy więc wyszczególnić:

  • jakość definiowaną przez zespół wytwórczy,
  • jakość definiowaną przez klienta,
  • jakość definiowaną przez zespół architektoniczny (lub dowolny inny zespół bez “skin in the game”).

Jakość definiowana przez zespół, to nic innego jak testy rozwiązania przeprowadzone w zespole odpowiedzialnym za wytworzenie produktu. Jasne jest, że zespół powinien dołożyć wszelkich starań oraz skorzystać ze wszystkich dostępnych narzędzi, aby dostarczane oprogramowanie było bez wad. To jednak może nie wystarczyć. Częstym błędem zespołu testującego jest rutyna, a więc postępowanie według utartych schematów. Pomaga w tym (i jednocześnie przeszkadza) dobre Definition of Done.

Jakość klienta jest odzwierciedlana poprzez akceptację rozwiązania. Jeśli oprogramowanie działa zgodnie z życzeniem klienta, jest on zadowolony i przeważnie uznaje, że jest ono wysokiej jakości. Takie podejście ma też swoje wady. Klient najczęściej zweryfikuje jedynie te części aplikacji, z których będzie korzystał na co dzień. Sprawdzi też tylko pozytywną ścieżkę (ang. happy path). Może to spowodować, że aplikacja teoretycznie pozbawiona wad okazuje się niskiej jakości po natrafieniu na przypadek szczególny.

Jakość zespołu architektonicznego (lub zespołu wydajności, bezpieczeństwa, itd.) to nic innego jak spełnienie wymagań narzuconych przez wyspecjalizowany zespół. Czystość kodu, wydajność rozwiązania czy zadbanie o jego bezpieczeństwo to część jakości, o której na pewno nie pomyśli 90% klientów i 50% zespołów wytwórczych. Jest to kolejny poziom jakości, który musi znaleźć odzwierciedlenie także w procesie wytwórczym.

 

Jedna jakość

Skoro posiadamy co najmniej trzy poziomy jakości, warto byłoby je uspójnić. Są tacy, którzy powiedzą, że jest to niemożliwe. Ja jednak stoję po stronie tych, którzy będą próbować.

Nie można oczekiwać, że każdy z uczestników procesu będzie pamiętał o wszystkim. Na pewno zaś nie można tego oczekiwać od klienta. Możemy go jedynie uświadomić, poprzez odpowiednie zdefiniowanie wymagań w Backlogu Produktu, że czystość kodu i wydajność rozwiązania są tak samo ważne, jak brak błędów funkcjonalnych.

Co więcej, metodyki zwinne dają nam narzędzia wspierające wysoką jakość produktu. Pętla zwrotna (feedback od klienta), HLAC czy DoD-a to tylko przykłady niektórych z nich. Odpowiednie ich zaimplementowanie w naszym procesie spowoduje, że jakość będzie istotna dla każdego uczestnika procesu i dla każdego będzie ważna.

A przede wszystkim będzie jedna!

 

Cena wysokiej jakości

Jakość, niezawodność, ilość defektów – to są elementy jednego z marnotrawstw wyszczególnianych przez Lean i opisanych przez Taiichi Ohno w słynnym Toyota Production System. Już dziesiątki lat temu zdiagnozowano, że niskiej jakości produkt powoduje straty dla całego przedsiębiorstwa. Nie idźmy więc tą drogą.

Nie uda się nam całkowicie wyeliminować różnego postrzegania jakości. Każdy z nas podchodzi do niej ze swojego punktu widzenia tak samo, jak każdy z nas dba o nią na swoim poziomie. Powinniśmy jednak zrobić wszystko, aby trzy wyszczególnione przeze mnie powyżej poziomy jakości tworzyły jedną całość.

Im mniej osi podziału, im mniej rozumowania “my/oni” tym większa szansa na sukces w postaci wysokiej jakości produktu.

A na tym powinno zależeć absolutnie wszystkim.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: