Victo logo
Victo
Szkolenia
Certyfikaty Wiedza (E)doradztwo
(E)coaching
(E)wdrożenia

Recepta na wzrost zysków w IT
Na jakości nieźle się zarabia
Istnieje bardzo prosta i skuteczna metoda zwiększenia zysków IT, zarówno przez ograniczenie jego kosztów, jak i przez dramatyczne zwiększenie wydajności. Jak dotąd, bardzo mało kto ją wykorzystuje, lub tylko w nieznacznym stopniu.
Ta metoda - kaczka, dosłownie znosząca złote jajka - to inwestowanie w jakość.
Kaczka, znosząca złote jajka, to ograniczenie kosztów i zwiększenie wydajności dzięki inwestowania w jakość.
Mówiąc wprost: na jakości można znakomicie zarobić. Ten prosty i oczywisty fakt z ogromnym trudem jednak toruje sobie drogę do świadomości sektora IT.
Oczywista oczywistość?
Już słyszę zarzuty: na jakości nie da się zarobić, przecież jakość oznacza poważne dodatkowe koszty! Ileż to trzeba się nagłowić, napracować i cyzelować, żeby coś działało naprawdę dobrze – mówią, niestety niezmiernie liczni, przeciwnicy tej prostej i łatwej do poparcia liczbami, prawdy, że jednak jakość jest znakomitym generatorem zysku.
Niestety, samo słowo „jakość” brzmi jakby mało fachowo, kojarzy się z nierealistycznym, pro-jakościowym zacietrzewieniem i teoretycznym nudziarstwem, choć naprawdę ma konkretne znaczenie biznesowe, przeliczalne na pieniądze. Po prostu: kiepski proces produkcji jest znacznie, dramatycznie wręcz droższy i mniej wydajny, niż proces uporządkowany.

Bałagan i chaos kosztują bardzo dużo, podczas gdy koszty zapewnienia jakości – często demonizowane i wyolbrzymiane – są zwykle niewielkie. Złoty interes!
Przyczyny nieporozumienia
Podstawową przyczyną tego błędu jest powszechne mylenie jakości procedur (procesów, projektów) z jakością produktów (oprogramowania, urządzeń, usług). To nieporozumienie wyraża się w wielu różnych formach.
Jakość produktu
Często spotykanym pseudo-argumentem przeciwko wysokiej jakości produktów, w tym produktów IT, jest teza, że nie stać nas na produkty o najwyższej jakości, bo kryzys, bo potrzeby klientów, i tak dalej. W tym podejściu kryją się aż dwa błędy.
Po pierwsze, pojęcie produktu wysokiej jakości zastosowane jest w powyższym twierdzeniu zgodnie z jego specyficznym, kulturowo określonym znaczeniem. W przybliżeniu, w codziennym języku polskim produkt o wysokiej jakości to, produkt kosztowny, „wypasiony”, na przykład Mercedes z górnej półki albo Maybach. W innych kulturach, odcień znaczeniowy pojęcia „jakość” jest inny: dla Szweda, produkt wysokiej jakości jest przede wszystkim solidny, dla Niemca – niezawodny i mający wyśrubowane parametry techniczne, dla Francuza – wykwintny i ekskluzywny, dla Szwajcara – dokładny i precyzyjny.
Po drugie, poprawny sens ekonomiczny słowa „jakość” nie jest ani polski, ani szwedzki, ani francuski, lecz następujący: produkt wysokiej jakości to rzecz, lub usługa, spełniająca jak najlepiej wszystkie potrzeby klienta, w tym cenę [1].
Produkt wysokiej jakości to rzecz, lub usługa, spełniająca jak najlepiej wszystkie potrzeby klienta, w tym cenę.
Tak więc, przykładowo, można poprawnie twierdzić, że Daewoo Tico jest samochodem równie wysokiej jakości jak Mercedes E63, ponieważ jego niska cena równoważy niższe parametry techniczne i niższą niezawodność; chyba, że ktoś usiłuje Tico sprzedawać za cenę Mercedesa.
Czasy kryzysu nie tylko nie powodują więc spadku zapotrzebowania na wysoką jakość produktów, lecz wręcz przeciwnie: klient, cierpiący na niedostatek środków, tym bardziej poszukuje najwyższej jakości, czyli jak najlepszej relacji ceny i kosztów użytkowania do pozostałych parametrów produktów i usług.
Jakość procesu
Temat jakości procesów jest zupełnie niemodny: brzmi jak nudne moralizowanie, wydaje się nie mieć nic wspólnego ani z podejściem biznesowym, ani z technologiczną, hakerską kreatywnością, ani z inżynierską doskonałością.
Jest jednak dokładnie odwrotnie. Biznesmen, haker oraz inżynier postrzegają proces produkcji i jego cele odmiennie, ale pod jednym względem mylą się identycznie: nie doceniają udziału w tym procesie czynności organizacyjnych, porządkowych. Dla biznesmena, projekt IT to w 80% jego cele biznesowe, a w 20% - technika, która je realizuje. Dla hakera i dla inżyniera, projekt IT to w 80% technologia, a w 20% - cele biznesowe, które tę zabawę umożliwiają i usprawiedliwiają. Rzeczywistość jest zupełnie, zupełnie inna: projekt IT to w 20% biznes, w 20% technologia, a w 60% proces.
Projekt IT
Rysunek 1: Co naprawdę jest jest kluczowe w projektach IT
Niezrozumienie tej prawdy bierze się stąd, że procesu nie widać, gdyż kryje się, rozproszony w dziesiątkach spotkań, rozmów na korytarzach, telefonów, maili, sms-ów i posiedzeń, w dokumentacji formalnej i nieformalnej, w procesie dostawy, w kompilacjach i poprawkach kodu źródłowego, w zmianach, w poprawianiu błędów, w wersjonowaniu i konfigurowaniu, w codziennym chaosie, z którym tak dzielnie sobie radzimy, marnując czas, pieniądze, siły i nerwy. Nie zauważamy go, niczym tlenu w powietrzy, ale bez niego nie dzieje się nic.
Jakość jest za darmo?
Przypominam jeszcze istnienie „kontrowersyjnej” tezy [2], że jakość jest za darmo. To tytuł książki Philipa Crosby z 1979 roku, na język polski nigdy nie tłumaczonej. To, oczywiście, uproszczenie: niektóre atrybuty jakości produktów, na przykład wysoka niezawodność lub wysokie osiągi, za darmo nie są, lecz kosztują; Mercedes kosztuje więcej, niż Tico. To jakość procesów (procedur) jest – do pewnego poziomu – nie tylko za darmo, a nawet przynosi znaczne zyski w tym sensie, że koszty zapewnienia jakości często są niższe, niż uzyskane dzięki nim obniżenie kosztów braku jakości.
Przykładowo: koszt odkładania młotka zawsze na to samo miejsce w warsztacie kowalskim to 5 dodatkowych sekund przy każdym korzystaniu z młotka, a szybsze jego znalezienie, to oszczędność, dajmy na to, 30 sekund, za każdym razem oprócz pierwszego. Używając młotek 51 razy dziennie, kowal i jego pomocnik tracą 255 sekund odkładając go na miejsce, a zyskują 1500 sekund, unikając jego szukania.
Można zbudować produkt wysokiej jakości przy używając procesu niskiej jakości, ale będzie to niepotrzebnie kosztowne.
Istnieją jeszcze dwie zależności, powodujące, że określenie „jakość jest za darmo” jest prawdziwa nawet w odniesieniu do jakości produktowej.
  • Nawet, jeśli celem działań jest podniesienie jakości produktu, to często obejmują one – z konieczności - modyfikacje procedur, powodujące spadek kosztów; ta prawidłowość nie pojawia się przy tak zwanym policyjnym podejściu do jakości, czyli stosowaniu kosztownej kontroli jakości na końcu procesu wytwarzania, zamiast zapewnienia jakości przez cały czas procesu.
  • Aby podnoszenie jakości procesów zakończyło się sukcesem, dobrze jest jako cel postawić nie jakość, bo to budzi opory, i pokusy stosowania policyjnego paradygmatu kontroli jakości, tylko podniesienie wydajności. Kowal, besztający porzucającego narzędzia byle gdzie czeladnika, żeby odkładał je na miejsce, ma mniejsze szanse powodzenia, kiedy argumentuje, że „porządny pracownik odkłada narzędzia na swoje miejsce!”, niż wtedy, gdy za cel stawia czeladnikowi możliwość wcześniejszego wyjścia do domu, albo większej wypłaty. Moralizatorstwo nie popłaca.
Jakość procesów – kaczka, znosząca złote jajka
Jeśli powyższą kowalską analogię uznajesz, Czytelniku, za naciąganą, bo odnosi się do kowalstwa, a świat IT jakoby jest inny, szczególny i z niczym nieporównywalny, może przekona Cię poniższe porównanie.
Koszty zapewnienia jakości, to:
  • Wdrożenie procedur (w tym: irracjonalny opór przed zmianami)
  • Przestrzeganie procedur (w tym: poczucie braku luzu, na szczęście szybko przemijające, chyba że ten proces wdraża i nadzoruje ktoś niekompetentny i technicznie, i społecznie)
  • Wdrożenie i używanie narzędzi.
Niewiele. Co więcej? Nic więcej nie przychodzi do głowy. Podkreślić należy, że koszty zapewnienia jakości są notorycznie wyolbrzymiane z powodu takich psychologicznych czynników jak ludzka niechęć wobec zmian, testosteron (moda na szpanerskie techniczne nowinki zamiast banalnych usprawnień procedur) oraz obawę przed uznaniem swoich błędów. Jeśli ktoś dziesięć lat poświęcił na doskonalenie swojej umiejętności życia w chronicznym bałaganie, niechętnie przyzna – to zjawisko psychologowie nazywają dysonansem poznawczym – że te lata zmarnował na głupoty.
Podsumowując: zwolennicy jakości procesów głoszą znaczenia jakości nie dlatego, jak się często sądzi, że mają taką nerwicę, że są nadzwyczaj etyczni, że są nudziarzami, że chcą na siłę uszczęśliwiać innych, lub że popisują się, jacy są bardzo mądrzy, a tylko i wyłącznie z egoistycznych pobudek: aby uniknąć kosztów braku jakości. Modna ostatnio na łamach popularnych czasopism iluzja, jak to rzekomo jesteśmy zagonieni, „zarobieni”, zestresowani, jak cierpi na tym jakość życia i tak dalej, zawiera może – poza lekko histeryczną modą na takie narzekanie - ziarnko prawdy, ale przyczyną takiego zabiegania nie jest ani kapitalizm, ani mityczny zły szef, ani nie leniwi podwładni, ani nawet nie zły, leniwy małżonek, lecz zła organizacja i powszechna kultura bałaganu.

Heroiczne radzenie sobie z bałaganem jest z jakiegoś powodu popularne, podczas gdy proste ulepszenia procedur postrzegane są jako słabość, nudziarstwo czy swoiste… frajerstwo.
Koszty braku jakości, to:
Koszty braku jakości procedur, oraz spowodowany tym brak jakości produktów, są wielorakie.
Składa się na nie zmniejszenie przychodów: opóźnienie, niezadowolenie klienta, wyższa cena w ofercie, mniejsza elastyczność w realizacji wymagań, mniejsza możliwość zmian, niższa terminowość, antyreklama, oraz wzrost kosztów: kary, odszkodowania, frustracja pracowników, przeróbki, późne naprawy, obsługa awarii, czasochłonna metoda prób i błędów, wreszcie utrudnienie ponownego wykorzystania.
W przeciwieństwie do wyolbrzymianych kosztów zapewnienia jakości, koszty jej braku są pomniejszane:
  • Ile tak naprawdę kosztuje chroniczny chaosik (z którym przecież jakoś sobie radzimy, jesteśmy z siebie dumni)?
  • Jak trafnie oszacować utracone wpływy, np. z powodu dłuższego terminu dostawy, unikania IT przez biznes, fochów Klienta?
  • Koszty trudno-mierzalne: nuda, cynizm, zmiany pracy przez pracowników.
Jakość jest za darmo?
Rysunek 2: Jakość obniża koszty
Sporo miejsca poświęciłem powyżej dowodzeniu, że – wbrew rozpowszechnionej opinii i wielu modnym bzdurom – dwa razy dwa jest jednak cztery, że inwestowanie w jakość jest ogromnie opłacalne, zwrot z inwestycji jest duży, i, co najważniejsze, bardzo szybki, czasem niemal natychmiastowy. Ale tak dzieje się tylko do pewnego momentu, i prawdziwą sztuką jest jego znalezienie.
W poszukiwaniu złotego punktu
Rozumowanie przedstawione w rozdziale wyżej jest jednak prawdziwe tylko do pewnego momentu. Kiedy pójdzie się za daleko, jakość przestaje się opłacać, staje się kosztowną przesadą i dziwactwem. To jak mycie rąk: choć wyraźnie korzystne dla zdrowia i wyglądu jest mycie rąk kilka razy dziennie, to mycie rąk kilkadziesiąt razy dziennie jest już tylko kosztowną kompulsją, natręctwem.
Złoty
                        punkt
Rysunek 3: Jakość najpierw obniża koszty, potem je powyższa

Zasada złotego punktu – kiedy już się go znajdzie – usuwa odwieczne pozorne dylematy, i towarzyszące im jałowe dyskusje: ile należy testować? czy porządnie napisana specyfikacja wymagań to kosztowna fanaberia, czy opłacalna oczywistość?
Gdzie więc leży ten magiczny punkt? To zależy od branży, od kontekstu systemu, od grożących kosztów braku jakości produktu, którym zapobiegają ponoszone koszty zapewnienia jakości:
Złoty
                        punkt
Rysunek 4: Uciekający złoty punkt jakości

Jedenaście czynników
W rzeczywistości, sprawa jest – oczywiście – jeszcze o wiele bardziej zawiła. Dotąd w tym tekście przyjąłem postawę propagandzisty: usiłowałem jak najbardziej przekonywająco i atrakcyjnie przedstawić istotę sprawy, nie komplikując wywodu zamazującymi sedno szczegółami. Pora wrócić do rzeczywistości. Dogłębna analiza tematu nie jest jednak w zasięgu artykułu, wymaga książki, a jej powstanie wymaga dostępu do wielkiej ilości danych – dlatego nad tematem będziemy pracować grupowo: zapraszamy na portal ryzyko.wymagania.org.pl, i do naszej grupy dyskusyjnej na LinkedIn o tej samej nazwie (ryzyko.wymagania.org.pl).
1. Oszacowanie pracochłonności uwzględniające jakość

Znane formuły na oszacowanie pracochłonności projektów IT to metoda punktów funkcyjnych, różne odmiany metody CoCoMo oraz wzór Putnama. Dla testowania, jest algorytm analiza punktów testowych (TPA). Żaden z tych wzorów nie uwzględnia czynników kosztów jakości i kosztów braku jakości – jakby nie istniały. Spróbujmy stworzyć lepszą formułę.

2. Wzorce dla różnych rodzajów systemów

Intuicyjnie, zgadzamy się, że złoty punkt – optymalny poziom kosztów zapewnienia jakości, pozwalający uniknąć kosztów braku jakości – jest zupełnie inny dla gry na urządzenie mobilne i dla oprogramowania sterującego rozrusznikiem serca. Jakie są doświadczenia różnych branż w tej dziedzinie? Czy i jakie istnieją normy?

3. Inwestycja w jakość a strategia ryzyka

Na dłuższą metę, inwestycja w jakość procesu zawsze jest opłacalna, aż do optymalnego poziomu. Jednak jest to zależność statystyczna, nie bezwzględna. Czasem można mieć szczęście, i w pojedynczym projekcie uniknąć wszelkich zagrożeń mimo braku czynności zapobiegawczych. Można mieć też pecha i jednorazowo paść ofiarą wielu niekorzystnych zbiegów okoliczności mimo przyjęcia rozsądnych środków ostrożności.

Wynika z tego, że – zależnie od przyjęcia różnych strategii ryzyka biznesowego – można w pojedynczych projektach stosować różne strategie inwestowania w jakość.

4. Ile tego zapobiegania?

Istnieje dobrze potwierdzona zasada, że z reguły taniej jest zapobiegać, niż leczyć; że koszty usunięcia defektu są tym mniejsze, im we wcześniejszej fazie projektu defekt zostanie znaleziony. Co to oznacza konkretnie, jaka jest na przykład optymalna relacja kosztów testów jednostkowych do kosztów testów systemowych i akceptacyjnych?

5. Jakimi metodami najlepiej zapewniać jakość?

Jeśli organizacja znajduje się daleko na lewo od złotego punktu, można z dużą pewnością przewidywać, że niemal każda, dobrze zrealizowana, inwestycja w jakość przyniesie zyski większe, niż koszty. Co jednak należy wybrać? Powiedzmy, że mamy do dyspozycji ulepszenie procesu pozyskiwania wymagań, wdrożenie częściowej automatyzacji testów lub  usprawnienie procesu zarządzania zmianami i błędami. Co wybrać, w jakiej kolejności, a może każde z tych ulepszeń jednocześnie, po jednej trzeciej dostępnego budżetu?

6. Zakres i metody testowania

Testowanie na podstawie ryzyka głosi, że najstaranniej należy testować obszary najbardziej ryzykowne. Jak przetworzyć tę dobrą, ale przeraźliwie ogólnikową zasadę we wzór, pozwalający wyliczyć wagę testowania ze względu na takie czynniki, jak konsekwencje awarii, prawdopodobieństwo defektu, prawdopodobieństwo użycia funkcji, widoczność ewentualnej awarii, wreszcie – jak w FMEA – łatwość wykrycia ewentualnego defektu w danym obszarze (skuteczność testów)?

Drugi temat, to – po przyjęci wynikającej z analizy ryzyka wagi testowania – przy pomocy jakich kryteriów wybrać technikę projektowania testów (przykładowo, testy eksploracyjne, czy może na testowanie przejść stanów, albo przypadków użycia?), i jaki poziom pokrycia?

7. Czynniki miękkie: wielka ściema oraz model Kano

Wykonano szereg dobrych badań ([3], [4]) wskazujących, że subiektywna ocena jakości oprogramowania zależy nie tylko od jego atrybutów jakości, lecz także od szeregu czynników psychologicznych i społecznych: nacisku grupowego, czarnej legendy, różnych zbiorowych histerii, które w epoce mediów społecznościowych rozprzestrzeniają się szybko, niczym pożar suchego stepu. Można się z tego powodu zżymać, ale warto te czynniki uwzględniać. Może to ułatwić mało w IT znany, z znakomity model Noriaki Kano.
Kano             Model
                      Kano

Rysunek 5 - Model Kano


8. Inżynieria oprogramowania – nauka czy kult cargo?

Kulty cargo [5] to irracjonalne, zwykle najzupełniej fałszywe, lub w najlepszym razie nie dające się udowodnić – opinie i przekonania o istnieniu korelacji lub nawet zależności tam, gdzie ich nie ma. To pseudonauka, głosząca – niekiedy hałaśliwie, zwykle bardziej elokwentnie, niż prawdziwa nauka – rozmaite gołosłowne zasady.

Inżynieria oprogramowania pełna jest kultów cargo. Dyskusje o wyższości, na przykład metod agile nad tradycyjnymi (lub odwrotnie) używają różnych sposobów argumentacji, z wyjątkiem jednego w tej sytuacji właściwego: eksperymentu kontrolowanego, lub szeregu kontrolowanych obserwacji, wspartych wieloczynnikową analizą statyczną.

Niektórzy zwolennicy / przeciwnicy tych metod (lub wielu innych: wyższości względnie niższości języków obiektowych nad strukturalnymi, przypadków użycia nad diagramami aktywności, Mac’a nad Windows) głoszą wręcz, że takie badanie nie ma sensu, że należy po prostu wybrać to, co nam odpowiada, co wydaje się najlepsze. Takie podejście jest ryzykowne, czasem katastrofalne, zawsze – kosztowne. Niechętnie godzimy się, aby tak rozumowali na przykład lekarze, prawda? Bo tam skutki złych wyborów są dla pacjenta bolesne. Choć i to nie jest prawdą – moda na szalbiercze pseudo-terapie szerzy się, napędzana zdolnością Internetu do szerzenia bzdur, zastraszająco.

9. Statystyczne ulepszanie

Zależność między rozmaitymi działaniami pro-jakościowymi, a kosztami i zyskiem, nie jest nigdy bezwzględna, zawsze statystyczna. Jak duża jest siła takich zależności, oszacowana na podstawie szeregu pomiarów, jak wysoka ich statystyczna istotność? To można i warto liczyć, korzystając z technik takich jak metoda Monte Carlo, sieci bayesowskie [6] itp.

10. Wybór właściwych atrybutów jakości

Jeśli chodzi o jakość produktów, kluczowe jest właściwe – odzwierciedlające prawdziwe potrzeby klientów – ważenie różnych atrybutów jakości. Inżynierski instynkt faworyzuje funkcjonalność, podczas gdy dla użytkowników często o wiele ważniejsza jest łatwość użytkowania, wydajność, dostępność serwisu. Nie opłaca się cyzelować jakości produktu pod kątem cech, których klienci nie chcą i nie cenią.

11. Korzyści krótkoterminowe i długofalowe

W odniesieniu do jakości produktu, przykładem atrybutu jakości, który nie ma znaczenia w krótkiej perspektywie, a znaczenie kluczowe – w perspektywie wieloletniej, jest łatwość utrzymania i modyfikowania, skalowalność.

Analogicznie, jeśli chodzi o jakość procesów, dominująca w IT metoda projektowa faworyzuje zyski krótkoterminowe (rozmaite szybki, cudowne metody) przed długoterminowymi (dość kosztowne w początkowej fazie ulepszenia procesów).

Z powrotem do działu Wiedza


[1] Potrzeby klienta (użytkownika, interesariusza), czyli tak zwane atrybuty jakości, to między innymi funkcjonalność, niezawodność, łatwość utrzymania, wydajność, łatwość obsługi, cena.

[2] Słowo „kontrowersyjny” piszę w cudzysłowie, gdyż ostatnio modne jest określanie tym przymiotnikiem każdej opinii, która, choć prawdziwa, jest niewygodna lub sprzeczna z obiegowymi, fałszywymi mądrościami. W istocie, jakość – tak jak rozumie ją Philip Crosby – po prostu jest za darmo, i nie jest to przedmiotem żadnej kontrowersji, a jedynie – fałszywych mniemań.

[3] http://www.computerworld.pl/artykuly/366523/Oprogramowanie.a.emocje.html

[4] http://niezaleznykonsultant.blogspot.com/2013/05/czy-oprogramowanie-wzbudza-w-nas-emocje.html

[5] http://pl.wikipedia.org/wiki/Kult_cargo, http://pl.wikipedia.org/wiki/Pseudonauka oraz http://testerzy.org.pl/bzdury.html

[6] http://www.computerworld.pl/artykuly/388752/Bez.eksperymentowania.html

© Victo