Temat jakości nie jest popularny, często też jest kojarzony z dużymi, wręcz wybujałymi wymaganiami klienta, które w trakcie projektu schodzą na ziemię (lub są ściągane), ze względu na terminy, budżet i zakres. Wtedy jakość schodzi ‘pod ziemię.’ W niektórych firmach zarządzanie jakością jest traktowane jak kontrola, która się pojawia i znika, a jej celem jest przede wszystkim na początku dostarczanie wymagań, oraz kontrolowanie efektów końcowych. W tak zwanym między czasie ktoś popatrzy czy idzie zgodnie z planem. A w innych (szczególnie tych w których wprowadzone jest zarządzanie projektami) zarządzanie jakością jest to stały cykl Deminga:

• [Plan] Planowanie jakości
• [Do] Organizowanie prac tak, żeby uzyskać zaplanowaną jakość
• [Check] Monitoruj/kontroluj jakość w trakcie trwania prac
• [Act] Zapewniaj jakość nie tylko w jednym projekcie, ale we wszystkich, eliminuj błędy i twórz coraz doskonalszy produkt.

Jeden z ostatnich prowadzonych przeze mnie projektów był idealnie odwzorowanym cyklem Deminga, a pomimo tego, podczas podsumowania projektu zespół stwierdził, że w tym projekcie był kontroler, który patrzył im na ręce, kiedy oni przecież wiedzieli co mają robić. Przyznam, że mnie to zaskoczyło, owszem klient był wymagający, ale jednocześnie wyjątkowo konkretny. Podczas pierwszych warsztatów pokazał grafiki, częściowe teksty, sprecyzował funkcjonalności i po 2 dniach ustaliliśmy wymagania w formie MoSCoW. W trakcie prac weryfikował implementację z grafikami, patrzył na treści maili, mówił na przeglądzie jeżeli coś było niezgodne z jego wymaganiami. Oczywiście pilnowałam, żeby wymagania Should nie zmieniły się ot tak w Must, a Could nie był robiony ‘przy okazji’, ale dzięki temu, że rzeczywiście klient miał dla nas czas w trakcie trwania projektu, pracowaliśmy wspólnie, końcowy odbiór odbył się szybko.
Można by powiedzieć taki klient to skarb, a jednak zespół odbierał uwagi jako ciągłą kontrolę i zawracanie głowy szczegółami, kiedy jest jeszcze dużo ważniejszych i większych tematów do realizacji, niż poprawianie ‘pixeli’’. Po projekcie, pracowaliśmy dalej przy mniejszych change requestach, żeby dopracować produkt i wyeliminować luki, które nam pozostały.
Teraz z zespołem pracuję z klientem, dla którego wszystko jest ‘MUSTem’, na przeglądach pojawia się maksymalnie raz na miesiąc. Na jednej z ostatnich retrospektyw zespół zwrócił mi uwagę, że tak też jest niedobrze, bo martwią się o odbiór. Sami stwierdzili, że jednak tamten klient nie był taki zły. A gdy pokazałam im cykl Deminga i dopasowałam zachowanie klienta w trakcie projektu, czyli:

• [Plan] Był z nami na 2 dniowych warsztatach, ustalił z nami szczegóły aplikacji, dopracował priorytety
• [Do] Uczestniczył w projekcie czynnie, uszczegóławiał kolejne funkcjonalności i odpowiadał na nasze wątpliwości
• [Check] Poprawialiśmy wspólnie nawet małe braki/błędy na bieżąco, dzięki ciągłej interacji
• [Act] Pracował z nami po projekcie, eliminując braki/luki aplikacji.

Panowie stwierdzili, że to był idealny przykład zarządzania jakością i co więcej przyznali, że może jednak to ‘patrzenie na ręce’ nie jest tak do końca kontrolą czy czepianiem się, ale świadomym zarządzaniem jakością.
Jak to u Was wygląda? Napiszcie czy macie szansę w swoich projektach zarządzać jakością?