sobota, 7 czerwca 2014

Ekonomika zapewnienia jakości

Ekonomika zapewnienia jakości

Dyskusje na temat jakości zwykle skupiają się wokół tematyki, jak „dobry” powinien być produkt. Piszę „dobry” w cudzysłowie, bo to pojęcie względne. Zamiast niego mówimy też często „jakość” i wokół niej toczą się często jałowe spory, na przykład czy w „kryzysie” (też cudzysłów – na czym niby ten kryzys, poza dziennikarskim mówieniem o nim, polega?) stać nas na jakość? Domyślna odpowiedź, że jakoby nas nie stać, odnosi się do specyficznego w polskiej kulturze znaczenia słowa „jakość” w znaczeniu „duży, drogi, wypasiony”. Prawidłowa odpowiedź powinna, być może, brzmieć, że właśnie w kryzysie jakość – rozumiana jako wystarczająca funkcjonalność za niezbyt wielkie pieniądze – jest potrzebna szczególnie.

Jakość to pojęcie wielowymiarowe: ma wiele składników, wiele atrybutów. I znów, można toczyć niekończące się spory, czy ważniejsza jest funkcjonalność, czy niezawodność, czy osiągi, a może wydajność, może łatwość obsługi, może odporność na ostre warunki? 

Do załadowania: prezentacja w PDF
 


-----------------------------------------------------------------------------
 Oczywiście, takie dyskusje, toczone w kontekście IT, są i zawsze będą najzupełniej jałowe, bo nie ma jednej, dobrej odpowiedzi, bo to, co dla którego klienta albo użytkownika jest ważne, i w jakim stopniu, jest ogromnie zróżnicowane.

Zdobywaniem wiedz na ten temat: CO jest komu potrzebne, jakie atrybuty jakości mają najwyższy priorytet, to zadanie nie dla specjalistów od jakości, tylko dla fachowców badań rynku, marketingu, a dla produktów IT robionych na zamówienie  - dla inżynierów wymagań, chronicznie a mylnie zwanych „analitykami biznesowymi”.

Działy marketingu i reklamy od lat dzieli od działu IT tradycyjna bariera, nie mająca żadnego merytorycznego uzasadnienia, poza hackerską tradycją IT. Być może pojawiają się pierwsze sygnały, że to się zmienia: mówię o inżynierii wymagań napędzanej rynkiem” (MDRE, Market Driven Requirements Engineering), inżynierii wymagań dla produktów IT robionych nie na zamówienie, a na otwarty rynek. O tym opowiem przy innej okazji.

Teraz chciałbym przejść do właściwego tematu tej prezentacji: do jakości (wydajności, sprawności) PROCESU IT:



-----------------------------------------------------------------------------
Niezależnie od tego, czy celem przedsięwzięcia (projektu) IT jest produkt wypasiony, czy skromny, niezawodny czy tani i awaryjny, wydajny czy też mający ograniczone możliwości, interesujące jest, aby tę potrzebę trafnie zidentyfikować i szybko, sprawnie zrealizować. Dać klientom to, czego potrzebują, w miarę możliwości szybciej, trafniej i taniej niż konkurencja – to definicja JAKOŚCI PROCESU IT; zresztą, każdego procesu, także w innych gałęziach niż IT.

Szukamy odpowiedzi na pytanie: jak stworzyć taki proces? Najpierw jednak zorientujmy się, jak takiego procesu NIE TWORZYĆ.

Tradycyjne podejście do jakości procesów – reprezentowane między innymi przez standardy CMMI, SPICE, częściowo także – z uszanowaniem ich specyfiki – przez ITIL i COBIT – głosi, że proces im cięższy, tym lepszy. Tak, jestem niesprawiedliwy i trochę upraszczam, ale taka jest istota rzeczy, wie o tym każdy, kto ma na przykład praktyczne doświadczenie z działaniami, mającymi na celu osiągnięcie przez organizację wyższego „poziomu dojrzałości” SPICE Automotive.

To oczywista nieprawda:

 

-----------------------------------------------------------------------------
Szkoła przeciwna, powstała często w opozycji do skrytykowanych na poprzednim slajdzie metodyk ciężkich, głosi – znów pozwalam sobie na uproszczenie – że im proces jest lżejszy, tym lepszy, że każdy niemal dokument to strata czasu. Przykładem takiego podejścia jest częsta niemądra interpretacja zasad agile, jakoby – bo to nieprawda – głoszących, że wszelkie procedury są zbędne i szkodliwe. Efekt może być taki, jakbyśmy łyżką chcieli wykopać kilka ton węgla: nie da się.



-----------------------------------------------------------------------------
Od czasu wyjścia testowania z podziemia około ćwierć wieku temu, spotyka się czasem przekonanie, że im więcej się testuje, im wnikliwiej i dokładniej, tym lepiej. Oczywiście, nadal, spotka się także podejście tradycyjne, przeciwne: że wszelkie testowanie to strata czasu.

I jedna, i druga opinia jest nieprawdziwa: nie ma sensu do kontroli jakości przy konstruowaniu krzesła używać mikroskopu, ale z drugiej strony…



-----------------------------------------------------------------------------
… z drugiej strony brak testów czy pobieżne, powierzchowne testy tam, gdzie potrzebna jest szczegółowa weryfikacja, to jak z młotkiem porywać się na testowanie układu scalonego: nie będzie to dobra metoda.
            



-----------------------------------------------------------------------------
Z takich nieprozumień biorą się dość powszechnie uprawiane, ale bezużyteczne, bo nie mające żadnego sensu ani szansy jednoznacznego rozwiązania, dyskusje: jaki wybór jest najlepszy? 
  


-----------------------------------------------------------------------------
Czyli, nie ma jednej recepty na najlepszy proces. Proces trzeba umieć dobierać zależnie od kontekstu, od potrzeb sytuacji: tylko wtedy będzie się naprawdę skutecznym.



----------------------------------------------------------------------------- 
Na przykład: jak bardzo starannie pilnować porządku, zbierać, dokumentować, analizować i sprawdzać?

Jeśli mamy za wielki bałagan, wprawdzie nie tracimy czasu na asekurację – na czynności zabezpieczania się – ale niszczą nas koszty bałaganu, chaosu.

Poprawiając staranność, wdrażając kontrole, czyli inwestując  jakość, można wtedy zmniejszyć łączne koszty, bo czas i zasoby poświęcone na utrzymanie porządku będą mniejsze, niż korzyści płynące z tego, że nie marnuje się więcej tyle czasu na radzenie sobie w bałaganie!

I można przesadzić, sprawdzać i kontrolować zbyt wiele, aż to przestaje się opłacać. Lepiej jest myć ręce kilka razy dziennie, niż nie myć rąk wcale – unika się w ten sposób wielu przykrości i zatruć pokarmowych, ale nie wynika z tego, że jeszcze lepiej jest myć ręce na przykład sto razy dziennie!



-----------------------------------------------------------------------------
 Tak, ten sposób widzenia (ilustracja poniżej) nadal jest powszechny: trochę ładu i dyscypliny, a zaraz padają oskarżenia o duszącą biurokrację, o bezsensowne ograniczenia, niemal zamach na ludzką wolność.

Z drugiej strony, koszty bałaganu, zwłaszcza te odległe w czasie, jak konieczność zwiększenia obsady biur obsługi klienta, czy koszty skalowania i modyfikacji źle napisanego programu – łatwo umykają, nie widzi się ich związku z wcześniejszymi o kilka miesięcy albo rok, pozornymi oszczędnościami podczas projektu:



-----------------------------------------------------------------------------
Lepiej testować, czy zapobiegać? Lepiej dbać o wersje i konfigurację, analizować wymagania, czy prościej raz a dobrze wszystko przetestować na samym końcu?

Zbyt duży nacisk na samo testowanie („tester jako odkurzacz”, albo „testowanie jako choroba współuzależnienia), to jak próba zmniejszenia przestępczości samym mnożeniem policyjnych patroli: i dużo kosztuje, i nie działa. Ale nie sprawdza się też przeciwne podejście, wynikające z przekonania, że mamy tak świetny proces i wymagania, że testowanie jest niemal zbędne: efekt taki, jak wycofać policjantów z ulic w kraju, gdzie bardzo dobre są przedszkola: groźny pomysł!



-----------------------------------------------------------------------------

Odwieczna dyskusja: testować wcześnie, czy na samym końcu? Stara, zła norma, że testuje się za późno, w ostatniej chwili, zamiast na początku procesu, nadal niestety jest powszechna, wbrew oczywistemu twierdzeniu krzywej Boehma, że lepiej jest zapobiegać, niż diagnozować i potem leczyć. 

Z drugiej strony, z krzywej Boehma (naprawy znajdowanych błędów są tym tańsze, im wcześniej w procesie wytwarzania te błędy się zidentyfikuje) nie ma wynikać, że co tylko się da, testujemy jeszcze w wymaganiach, bo wtedy zapomina się o krzywej Rybera: testowanie późniejsze jest o wiele tańsze, jeśli chodzi o koszt jego realizacji:


-----------------------------------------------------------------------------
Modna stała się od pewnego czasu, chwilami zażarta dyskusja na temat rzekomej wyższości tak zwanego testowania eksploracyjnego, nad innymi podejściami. Nie chodząc w szczegóły, które opisuję gdzie indziej (qualitology.blogspot.com/2014/06/extremely-agile-exploratory-risk-based.html), trzeba przyznać, że spór -  w takiej formie - nie ma najmniejszego sensu.

Prawda jest taka, że testowanie eksploracyjne ma szereg zalet, które znakomicie uzupełniają testowanie planowe, projektowane zawczasu, ale go w żadnym razie nie zastępują:


-----------------------------------------------------------------------------
Trzeba się więc nauczyć dobierać proces najlepiej pasujący to projektu, a nie marnować czas na poszukiwaniu nieistniejącego procesu, który byłby najlepszy  w każdej sytuacji. Jak tego szukamy? Większość ma nadzieję znaleźć cudowne rozwiązanie, słuchając wystąpień praktyków w stylu „jak to zrobiliśmy w naszej firmie i jak to działa”. Teoria rzekomo jest „sucha” i nie przekłada się na użyteczne rozwiązania.

Jest dokładnie odwrotnie. Słuchanie opowieści przy ognisku czy na konferencji bywa cudowną inspiracją, ale takie wyrwane z kontekstu opowieści użytkownika nie są żadnym rozwiązaniem, jeśli nie uzupełnić ich głęboką analizą i porównaniem z możliwymi alternatywami. A nawet, jak na ilustracji obok, może być śmiertelnie niebezpieczne!



-----------------------------------------------------------------------------
  

Brak komentarzy:

Prześlij komentarz