Jakość w centrum. Czyli Total Quality Management.
Kto z nas nie zna powiedzenia „klient ma zawsze rację”? Za sprawą popkultury pewnie dla wielu z Was, podobnie jak i dla mnie, koncepcja ta niesie raczej skojarzenia z amerykańskim kapitalizmem, jego źródeł zaś intuicyjnie poszukiwalibyśmy co najwyżej półtora wieku temu, a z większym prawdopodobieństwem gdzieś u początków poprzedniego stulecia. Okazuje się jednak, że zamiłowanie człowieka do produktów i usług wysokiej jakości nie jest wcale wynalazkiem współczesności, a sama koncepcja jakości może być równie stara, jak nasza cywilizacja.
Kodeks Hammurabiego, zredagowany i spisany w XVIII w. p.n.e., przewidywał kary dla budowniczych popełniających błędy jakościowe w wykonywanej przez nich pracy. Kodeks Hammurabiego był prawem raczej surowym i, biorąc pod uwagę, jak bardzo brzemienna w skutkach bywa niska jakość, naprawdę powinniśmy się cieszyć, że dzisiejsze akty prawne nie są aż tak surowe. Ten babiloński zbiór praw w najgorszym wariancie zakładał karę śmierci dla wykonawcy… bądź jego syna. „Jeśli przy zawaleniu domu zniszczone zostanie dobro, to budowniczy ma wykonać to wszystko, co zostało zniszczone, ponieważ nie wybudował domu wystarczająco mocno, powinien więc odbudować go na własny koszt”.
Na przestrzeni tysiącleci koncepcja jakości ewoluowała tak samo, jak cywilizacja, która ją zrodziła. Najintensywniejszych zmian można dopatrywać się we wspomnianym już wcześniej początku XX stulecia, kiedy to w zakładach Forda w USA zapoczątkowano seryjną produkcję samochodów. Wprowadzone wówczas zasady zarządzania wspominały między innymi o ustaleniu najlepszej metody wykonania zadania czy szkoleniu i doskonaleniu robotników (celem przydzielenia prac, do których najbardziej się nadają). Z czasem firma zaczęła zatrudniać zespoły inspektorów, których zadaniem było sprawdzanie produktu, a samą procedurę stosowano we wszystkich fazach wytwarzania. Jej celem było oddzielenie produktów o niskiej jakości od wyrobów o jakości akceptowalnej. Gorsze produkty wycofywano, naprawiano i oferowano w niższej cenie.
Tak zrodziła się inspekcja jakości, pierwsza z czterech faz rozwoju koncepcji jakości. Z czasem ewoluowała do kontroli jakości oraz zapewniania jakości, by z czasem przyjąć formę dziś najwyższą: Total Quality Managementu.
Czym jest Total Quality Management?
Total Quality Management często spotyka się pod postacią akronimu TQM, a w literaturze polskiej możemy spotkać się również z zarządzaniem przez jakość, kompleksowym zarządzaniem przez jakość, kompleksowym zarządzaniem jakością oraz, co oczywiste, totalnym zarządzaniem jakością. Na tę koncepcję natknęłam się kilka lat temu, poznając różne metody i metodyki zarządzania i przyznam szczerze – urzekła mnie. Koncepcja ta jest bardzo prosta nie tylko do zrozumienia, ale również do przekazania: jest to podejście do zarządzania organizacją, charakteryzujące się tym, że każdy aspekt działalności przedsiębiorstwa realizuje się z uwzględnieniem spojrzenia projakościowego. Jakość jest traktowana jako integralny element polityki przedsiębiorstwa, dotyczący całej organizacji i we wszystkich aspektach. A mówiąc najprościej: jeśli coś da się zrobić lepiej, należy to zrobić lepiej.
Z kronikarskiego poczucia obowiązku w tym miejscu wspomnę, że różne źródła uznają różne wydarzenia w historii za moment narodzenia się koncepcji Total Quality Managementu. Części z nich wskazuje rok 1923, a Waltera Shewharta, pracującego wówczas w Bell Telephone Laboratories, jako ojca TQM. Opracował on wówczas statystyczny wykres, który nadal nosi jego imię. Warto też zapamiętać nazwisko Josepha Jurana: był on jedną z osób przeszkolonych w tej technice, a koncepcję rozwinął i zamieścił w swoim bardzo wpływowym „Podręczniku kontroli jakości”. Ostatnim wspomnianym ojcem (i chyba najpopularniejszym) jest W. Edwards Deming. W latach 50. Japończycy poprosili o cykl wykładów na temat metod statystycznej kontroli jakości Shewharta. Deming przekazał także własne pomysły, bazujące na obserwacjach z czasów wojennej produkcji, kiedy to kierownictwo i inżynierowie kontrolowali proces, a pracownicy liniowi odgrywają niewielką rolę w procesie kontroli jakości. Zaproponował więc między innymi znacznie większe zaangażowanie zwykłego pracownika w proces jakości i zastosowanie nowych narzędzi statystycznych. Dzięki sugestiom Deminga Japonia rozpoczęła proces wdrażania tego, co stało się znane jako TQM.
O zasadach…
Większość źródeł wspomina o 8 głównych zasadach (czy wręcz kluczowych pryncypiach) TQM, którymi są: orientacja na klienta, przywództwo, zaangażowanie pracowników, podejście procesowe, systemowe podejście do zarządzania, ciągłe doskonalenie, podjęcie decyzji na podstawie faktów oraz obustronnie korzystne relacje z dostawcami.
Wskazówek dotyczących wdrażania koncepcji TQM dostarcza również 14 zasad Deminga, obejmujących m.in.: stałą dbałość o doskonałość produktu (z uwzględnieniem potrzeb klientów), budowanie przekonania o konieczności wdrożenia zintegrowanego systemu zarządzania jakością czy stałe usprawnianie procesów wpływających na jakość. I choć TQM narodził się z potrzeby kontroli jakości seryjnej produkcji fizycznych towarów, to nic nie stoi na przeszkodzie, by wdrażać je także w firmach oferujących usługi, w innego rodzaju organizacjach (na przykład charytatywnych) czy w branży IT. Ponieważ nas interesuje najbardziej ta ostatnia, omówmy wspomniane zasady Deminga nieco szerzej i zastanówmy się, jak odnoszą się do wytwarzania oprogramowania w odniesieniu cyklu życia rozwoju oprogramowania.
Przestrzeganie długofalowych zamierzeń
Celem kierownictwa w TQM powinno być wyznaczanie długoterminowych celów, a wszyscy pracownicy powinni wspólnie do nich zmierzać. W projektach waterfallowych (archaicznych już raczej w IT) proces tworzenia oprogramowania tradycyjnie kończy się z chwilą wprowadzenia produktu na produkcję. Coraz więcej firm jednak wprowadza metodyki zwinne, a te zdają się w naturalny sposób sprzyjać tej zasadzie. Podobnie jak w Scrumie, w kulturze TQM nie ma linii mety dla zespołu. Zdarza się, że następuje przesunięcie priorytetów, jednak metody zwinne sprzyjają ciągłemu ulepszaniu. Jeśli więc Wasza firma korzysta ze zwinnych metod wytwarzania oprogramowania, jesteście już na bardzo dobrej drodze do pełnej jakości.
Zaakceptowanie nowej filozofii
W kulturze TQM jakość jest na pierwszym miejscu i wszyscy muszą ją zaakceptować i brać czynny udział w dążeniu do niej. Przykład musi płynąć z góry, a kierownictwo powinno jasno komunikować swoje poparcie dla tej koncepcji – żeby zapalać innych, samemu trzeba płonąć. Tutaj z odsieczą przychodzą metody zwinne: odpowiedzialność za jakość, spoczywająca na barkach zespołu wytwórczego (a nie, jak w przypadku projektów kaskadowych, zespołu utrzymaniowego), narzucana jest w większość znanych mi metod agile’owych. A to podejście jest bardzo w duchu Total Quality Management.
Eliminacja metod masowej kontroli
A mówiąc prościej: tak, jak lepiej jest zapobiegać niż leczyć, tak i lepiej przewidywać błędy niż je naprawiać. Lepiej i taniej jest zapobiegać błędom w kodzie niż przeglądać kod w celu usunięcia błędów. Inspekcja nie zapobiega występowaniu błędów, jedynie je wynajduje. Dobrze znane już i raczej szerzej przyjęte praktyki mówią o tym, że dobrze jest wdrażać pomiar jakości na jak najwcześniejszym etapie. Częściowo więc ten punkt jest wymuszany przez wiele metod wytwarzania oprogramowania. Ale warto pamiętać, że na zapobieganie błędów wpływają też wiedza i doświadczenie. Dlatego ważnym jest, by dbać o rozwój pracowników.
Niska cena nie jest najlepszym wyborem
Jak pewnie zauważyliście, do tej pory szło świetnie: realizacja wcześniej omówionych zasad Deminga wymuszona jest poprzez stosowanie znanych i dość powszechnie wdrażanych praktyk. Dochodzimy jednak do punktu, który – z mojej obserwacji – dość mocno kuleje. Cięcie kosztów jest chyba jednym z ulubionych zadań każdej korporacji. Stosuje się je na przykład przez zlecanie części lub całych projektów podwykonawcom, a najważniejszym kryterium jest cena. Powszechne jest też wykorzystywanie darmowych rozwiązań open-source. A to często wiąże się z pogorszeniem jakości, co z kolei zdecydowanie nie wpisuje się w zarządzanie przez jakość. Jeśli jednak koszty są dla nas bardzo istotne, to nie wolno zapominać, że niska jakość na dłuższą metę powoduje wysokie koszty całkowite.
Nieustanne doskonalenie, zdobywanie nowej wiedzy oraz ciągły rozwój
W tym punkcie zastanowimy się nad aż trzema zasadami, które różnią w zasadzie tylko niuanse lingwistyczne. W wypadku tych zasad niewiele odróżnia firmy branży IT od innych organizacji. Na barkach kierownictwa spoczywa dążenie do ciągłego doskonalenia i zadbanie o to, by procesy rozwoju systemu były stale monitorowane i ulepszane przez wprowadzanie nowej i działającej metodologii, standardów, technik, narzędzi i procedur. Wszystko to wymaga od organizacji ciągłego śledzenia praktyk uznawanych za najlepsze, a od wszystkich pracowników doskonalenia, aktualizacji oraz poszerzania swoich umiejętności.
Ważne jest też dopasowanie pracownika i jego umiejętności do zespołu i projektu. Dlatego kluczowe jest ocenienie wiedzy i predyzpozycji pracownika zanim zostanie on przydzielony do projektu – tak, aby mógł wykorzystywać swój potencjał z największą korzyścią dla jakości. Wszyscy pracownicy powinni być nieustannie zachęcani do ciągłego samodoskonalenia.
Przywództwo
Przywództwo zamiast zarządzania. Tutaj po raz kolejny z pomocą przychodzą nam metody zwinne. Większość z nich kładzie nacisk albo na przywództwo, albo na samoorganizację.
Eliminacja strachu i przełamywanie barier między pracownikami
Któż z nas nie obserwował problemów w komunikacji. A tworzenie oprogramowania wymaga współpracy pomiędzy wieloma ludźmi, o czym czasem zapominamy. Słaba komunikacja i niesprecyzowane jej standardy bardzo szybko mogą przełożyć się na niepożądane pogorszenie jakości. Często w swoim doświadczeniu spotykałam się z sytuacja nadmiaru narzędzi do komunikacji. Slack, e-mail, Jira, Conflunece… Ale komunikacja to nie tylko narzędzia, a też sposób, w jaki się komunikujemy. W firmach zajmujących się wytwarzaniem oprogramowania nie zawsze jest miejsce na przykład na szkolenia z komunikacji. Częściową odpowiedzią na ten problem może może być obecność Scrum Mastera w zespole. Natomiast szczególnym problemem w komunikacji jest strach, który jest wrogiem jakości. W TQM zależy nam na zaangażowaniu pracowników, jednak ciężko będzie im zgłaszać sugestie czy prosić o pomoc, gdy obawiają się współpracowników. Jeśli nie stworzymy stabilnego i przyjaznego środowiska, nigdy nie będziemy się zbliżać do całkowitej jakości.
Eliminacja sloganów
W moim odczuciu świat IT pełen jest „buzzwordów”, takich jak „all green policy”, „everything as a service” czy „hyperautomation”. Deming uprzejmie przypomina, że takie slogany nie zachęcają do pracy, a zamiast motywować – zniechęcają. Mogą one też wywoływać niepotrzebną i niepożądaną presję albo – co gorsze – śmieszność. Slogany nie budują systemów jakości. Zamiast tego lepiej stawiać realistyczne cele.
Eliminacja oceniania oraz limitów pracy
Ocenę pracowników, która może powodować strach, warto odstawić na bok, zostawiając miejsce dla dumy z wykonywania zadań. Ludzie naturalnie są zmotywowani do pracy i chcieliby wytwarzać produkty wysokiej jakości, jednak dobre wykonanie opiera się na dobrych materiałach, narzędziach czy metodach, zaś słabe narzędzia, nieefektywne metody lub wiecznie spóźniony harmonogram zmniejszają motywację i należy je wyeliminować. Podobnie demotywująco mogą działać wyśrubowane standardy i limity. Odnoszą się one do liczb, a nie do jakości. Warto pozostawić członkom zespołu pole do postawienia własnych celów. Menedżerowie powinni z kolei skoncentrować się na pomaganiu ludziom w jak najlepszym wykonywaniu pracy oraz w ustanawianiu tych celów (zamiast ich narzucania).
Ostatnią zasadą, która w zasadzie jest wynikiem wszystkich poprzednich, jest transformacja. Celem kierownictwa jest uzgodnienie znaczenia i kierunku, w jakim należy podążać, a następnie zaangażowanie wszystkich w proces, przy wykorzystaniu powyższych rad. Wymaga to często przyznania się do błędów i odwagi, by się zmienić. Koniecznie jest wyjaśnienie członkom organizacji, dlaczego zmiana jest konieczna i że zmiana obejmie wszystkich.
W powyższym artykule przybliżyłam Wam prostą, a jednocześnie bardzo skomplikowaną ideę postawienia jakości w centrum działań organizacji. Wymaga ona niejednokrotnie zwiększenia kosztów w krótkim terminie, by w dłuższej perspektywie móc cieszyć się większymi zyskami, ale przede wszystkim – zaufaniem klientów. Przybliżyłam Wam 14 zasad, które – według Deminga – powinny umożliwić pełnię realizacji Total Quality Management. Jak zauważyliście, sporo z nich zostało zaadaptowanych w zwinnych metodach wytwarzania oprogramowania. Oznacza to, że albo ich twórcy dostrzegli w nich wartość, albo też niezależnie doszli do takich samych konkluzji.
Być może i Was, podobnie jak mnie, urzeknie prostota tego podejścia i zechcecie korzystać z niego w pełni. A być może będzie ono dla was choć częściową inspiracją do ulepszenia już istniejących procesów.
