Temat: Skokowy wzrost wydajności

Skokowy wzrost wydajności. Co kierownictwo firmy naprawdę musi wiedzieć na temat IT?

Automatyczne zapobieganie błędom

Blisko trzy lata temu, na łamach „Computerworld” opublikowany został artykuł pt. „Między biurokracją a chaosem” . Traktował on o metodyce automatycznego zapobiegania błędom (ADP – Automated Defect Prevention), stworzonej i opisanej w książce Adama Kolawy , założyciela i właściciela firmy „Parasoft” , oraz Doroty Huizinga , wice-przewodniczącej California State University – Fullerton.

Adam, mający doktorat z fizyki teoretycznej na California Institute of Technology , potrzebował kiedyś stworzyć oprogramowanie na użytek swoich badań. Zrobił to i odkrył, że informatyka pociąga go bardziej niż fizyka. Wtedy (1987) założył firmę „Parasoft”, specjalizującą się w produkcji narzędzi, wspomagających produkcję oprogramowania. Narzędzia „Parasoftu” służą przede wszystkim programistom, umożliwiając wczesne testowanie oprogramowania (analiza statyczna, automatyczne testy jednostkowe), testerom (automatyczne testy funkcjonalne) oraz kierownikom projektów (Parasoft Concerto ).

Przy okazji, Adam odkrył, że oprogramowanie można tworzyć zupełnie inaczej – dramatycznie sprawniej i skuteczniej – niż pozwalają na to sposoby, dominujące dziś w przemyśle informatycznym. Ta nowa, rewolucyjna metoda, została opisana w książce Automated Defect Prevention (wydana w USA w 2007 roku, nie tłumaczona na język polski).

Ile samochodów Toyoty jeździ w Polsce?

Około 80 lat temu, dwóch amerykańskich specjalistów, Joseph Juran i Wiliam Deming opracowało metodyki zarządzania jakością, których podstawą jest teza, że zapobieganie błędom (a więc i defektom) jest o wiele tańsze i skuteczniejsze niż wykrywanie defektów i ich mozolne usuwanie. Tezy tej nie bardzo chciał słuchać – w latach 40-ych, po zakończeniu II wojny światowej, amerykański przemysł motoryzacyjny; zarządzanie jakością polegało tam przede wszystkim na kontroli jakości: na wykrywaniu braków i ich mozolnym usuwaniu.

Natomiast idee Jurana i Deminga wzięli sobie do serce japońscy producenci samochodów i dlatego – jeszcze dziś – na polskich (i nie tylko!) drogach widzi się o wiele więcej aut produkcji japońskiej niż amerykańskiej.
Obecnie podejście Jurana/Deminga jest czymś naturalnym w większości branż produkcyjnych. Zamiast tylko naprawiać lub odrzucać wadliwe produkty, zarządzanie jakością koncentruje się na identyfikacji i usuwaniu wad procesu produkcyjnego. Proces zarządzania jakością jest ciągły, i każdy z pracowników jest w niego zaangażowany. Jako TQM (Total Quality Management , kompleksowe zarządzanie jakością), lub pokrewna metoda SixSigma , koncepcja ta znana i stosowana jest od dawna.

Ale nie w przemyśle informatycznym!, Tutaj, niestety, wciąż dominuje podejście typu „jakość to będzie”: głownym sposobem zarządzania jakością jest kontrola jakości; zamiast usprawniać procesy i procedury, koncentrujemy się na testowaniu i „debugowaniu”, czyli szukaniu i usuwaniu defektów gotowych produktów. Takie podejście ma wysoce niekorzystne skutki biznesowe.

IT a biznes

OK, powie Czytelnik, IT – produkcję oprogramowania – można usprawnić. Równie dobrze można usprawnić dostawy elektryczności, wywóz śmieci albo znaleźć tańsze lokale dla firmy – czy jednak ma to większe, nie mówiąc już o „dramatycznym”, znaczenie dla skuteczności firmy, dla jej rezultatów biznesowych?

Temu właśnie tematowi poświęcona jest najnowsza książka Adama Kolawy „Skokowy wzrost wydajności” (The Next Leap in Productivity), która niedawno wyszła w polskim tłumaczeniu (autora tej wiadomości).

Otóż współczesny biznes nie tylko – jak 20 lub 30 lat temu – wykorzystuje IT, jako funkcję o marginalnej wartości w porównaniu np. z marketingiem i sprzedażą, lecz – niezależnie od tego, czy chodzi o handel butami, produkcję oprogramowania lub sprzedaż usług, np. wycieczek zagranicznych – współczesny biznes to jest IT!

Jednorazowe oprogramowanie

Jaki jest typowy problem z oprogramowaniem? Kierownicy działów IT śmiertelnie boją się wszelkich zmian i modyfikacji: „co nie jest popsute, tego nie należy naprawiać”. Zmiany budzą obawy i zajmują wiele czasu, a oprogramowanie jest notorycznie zawodne.

Z tego powodu zmiany systemów IT chronicznie nie nadążają za zmianami rynkowymi: nowymi potrzebami lub upodobaniami klientów. Jakakolwiek modyfikacja istniejących aplikacji połączona jest ze znacznym ryzykiem, czego wyraźnym objawem są m.in. rozbudowane systemy zarządzanie błędami („defektami” wg terminologi ISTQB ), ponieważ błędy znajduje się zwykle pod koniec projektu, a ich naprawa – podobnie jak każda modyfikacja istniejącej funkcjonalności - zawsze budzi obawy, że zepsuje się to, co dotąd działało poprawnie.

Taki stan rzeczy powoduje, że firmy nie nadążają szybko i elastycznie reagować na zmienne potrzeby rynku, na potrzeby tworzenia nowych wersji oprogramowania, na zróżnicowanie rynków w epoce globalizacji. Dlatego potrzebna jest metoda, która pozwoliłaby tworzyć – wg określania Adama – „oprogramowanie jedorazowe”, tak jak istnieją obecnie jednorazowe maszynki do golenia, pieluchy, talerze i sztućce. Takie oprogramowanie można by tworzyć i modyfikować szybko i niezawodnie, bez długotrwałego procesu produkcji, testowania, debugowania i wdrażania. Jak osiągnąć ten cudowny – zdawałoby się - wynik?

Według Kolawy, rozwiązanie jest proste: poprzez zastosowanie ADB do wytwarzania aplikacji. Czy to możliwe? Tak. Zastosowanie ADB, czyli: w pełni zautomatyzowanych testów statycznych, jednostkowych i funkcjonalnych, w połączniu z narzędziami do zarządzania projektem, śledzenia związków wymagań z komponentami oprogramowania i testami, pozwala kilkakrotnie, nawet kilkunastokrotnie zwiększyć wydajność w tworzeniu oprogramowania, co odpowiednio i umiejętnie wykorzystane, może doprowadzić do wielokrotnego wzrostu wydajności przedsiębiorsta – dramatycznego, skokowego wzrostu wydajności firmy.

Jak to osiągnąć w praktyce?

Szczegóły na temat ADP znadują się albo we wspomnianym już artykule „Między biurokracją a chaosem”, albo w samej książce. ADP pozwala osiągnąć „dramatyczny wzrost wydajności” działu IT. Pozwolę sobie tylko przypomnieć podstawowych sześć zasad ADP:

• Stworzenie infrastruktury jednoczącej ludzi i technologię;

• Określenie i zastosowanie dobrych praktyk;

• Dostosowanie dobrych praktyk do specyfiki firmy, technologii,
produktu i projektu;

• Pomiary i monitorowanie statusu projektu;

• Automatyzacja;

• Przyrostowe wdrożenie praktyk ADP.

Oczywiście, same nazwy niewiele mówią. Dlaczego ADP, a nie - szerzej przecież znane - ISO 9000 – ISO 9001, Six Sigma, CMMI, COBIT, ITIL, TickIT, ISO/IEC 12207, Bootstrap, SPICE, ISO/IEC 15504, TMM, MMAST, TAP, TCMM, TIM, TOM, TSM, TPI? Dlatego, że są to metody normatywne: wymagają spełnienia szeregu zasad, a jakość ocenia się na podstawie zgodności ze standardem, nie z produktywnością. No i wprowadzają masę biurokracji… mało mają wspólnego z regułami TQM!

Co jest kluczem do powodzenia w biznesie?

Dotąd mówiło się głównie, że kluczowe jest, aby dyrektor IT rozumiał dobrze biznes. Teraz już wiemy, że równie ważne jest, aby dyrektor zarządzający rozumiał dobrze możliwości, które stwarza IT.

Adam Kolawa pisze:
"Bez IT nie bylibyśmy w stanie wykorzystywać okazji i unikać szybko pojawiających się zagrożeń. Aby móc szybko i sprawnie reagować na zmiany na rynkach, potrzebne są duże pieniądze i elastyczne zasoby IT.

Mówiąc szczerze, IT musi umieć zmieniać się równie szybko jak rynki. Statyczne IT nie pomoże organizacji konkurującej w globalnym biznesie.
Aby szybko dostosowywać się do zmian, IT potrzebuje dającego się dostosować oprogramowania, co jest wprawdzie kłopotliwe, ale stwarza też nowe okazje.
Organizacje umiejące szybko i sprawnie przekształcić wiedzę oraz informację w kod oprogramowania, uzyskają przewagę konkurencyjną nad rywalami, mającymi wolniejsze, mniej sprawne procesy wytwarzania oprogramowania.

W kolejnej rundzie światowej konkurencji nie wystarczy mieć najlepszych ludzi. Co będzie potrzebne? Najszybsi i najbardziej kreatywni programiści, umiejący przetwarzać pomysły biznesowe w kod oprogramowania?

Wcale nie. To przestarzały i niebezpieczny sposób myślenia. Zakłada się, że IT jest tylko kosztem ponoszonym, aby móc utrzymać przedsiębiorstwo. W rzeczywistości, IT jest olbrzymią wartością – bezcennym motorem wzrostu i ekspansji. To jest właśnie tematem tej książki."

Elastyczne i szybkie tworzenie niezawodnego oprogramowania pozwala przedsiębiorstwu szybko, sprawnie i elastycznie dostosować się do zmian na rynkach, wyprzedzać konkurencję, dostarczać klienton to, co chcą. Dyrektor IT każdej firmy – zarówno wytwarzającej oprogramowanie na własne potrzeby, jak i na sprzedarz - powinien z grubsza znać metodykę ADP, umozliwiającą taki tryb pracy. Analitycy systemów , projektanci oraz programiści powinni stopniowo uczyć się pracować zgodnie z tą metodyką, aby móc ją stosować w praktyce i wytwarzać aplikacje – lub modyfikować istniejące – tak, aby szybko i niezawodnie przekładać pomysły biznesowe na poprawnie działające oprogramowanie!

Nie można ulepszyć tego, czego się nie rozumie

Po co dyrektor zarządzający, właściciel lub presez firmy ma rozumieć podstatowowe zasady IT, tak jak opisuje je Adam Kolawa? Oczywiście nikt nie wymaga – byłoby to absurdem – by prezes uczył się programowania. Nie w tym rzecz. Natomiast zadaniem jego jest zatrudnienie własciwego dyrektora IT i narzucenie mu właściwego kierunku; aby umieć to zrobić, musi rozumieć z grubsza tezy Adama.

Uwaga: choć narzędzia firmy „Parasoft” oferują funkcjonalność, która potrzebna jest do realizacji „dramatycznego wzrostu wydajności”, ani książka Kolawy, anie ten artykuł nie służy ich promocji. Te same wyniki można osiągnąć przy pomocy narzędzi innych firm, lub narzędzi wolnodostępnych (freeware). Naromiast metodyka Kolawy – darmowa – jest niezastąpiona. Wystarczy zakupić książkę, liczącą dużo mniej niż 200 stron, można ją przeczytać w jeden wieczór.

Wiele praktycznych doświadczeń potwierdza (przykłady znajdziemy w książce), że wzrost wydajności IT i firmy naprawdę może nastapić – skokowo, zaskakująco, dramatycznie. Nic nie stoi na przeszkodzie – oprócz kurczowego trzymania się przyjętych, tradycyjnych metod – aby dać swojej firmie dramatyczną, rynkową przewagę nad konkurencją. Aby, stosując zasady ADP, osiągnąć umiejętność szybkiego, niezawodnego tworzenia nowego oprogramowania lub modyfikacji już istniejących aplikacji. Dzięki temu, produkcja oprogramowania przestanie być hamulcem zmian, a stanie się – ich nośnikiem.

Architektura zorientowana na usługi

Architektura zorientowana na usługi, czyli SOA – Service Oriented Architecture. To modne dziś określenie – o co w nim chodzi? O dwie właściwości oprogramowania:

• Po pierwsze, aplikacje znajdują się na serwerze dostawcy (co określa
skrót ASP – Application Service Provider), nie wymagają więc
kłopotliwych instalacji, ładowania nowych wersji i „łat” – nie
musimy, mówiąc słowami autora książki „Hakerzy i malarze” , Paula
Grahama, być administratorami systemów własnych laptopów;

• Po drugie, dostarczne przez Internet usługi to nie są kompletne
aplikacje, lecz ich fragmenty, które, łącząc z komponentami od innych
dostawców, można przekształcić w przydatne nam aplikacje.

SOA jest przyszłością. W latach 50-ych i 60-ych programy komputerowe były całościami, mającymi dokładnie określoną funkcjonalność, wykonywanymi na tej samej maszynie „mainframe”, gdzie były przechowywane na dysku. W latach 70-ych pojawiła się architektura „klient-serwer”. Kiedy powstał Internet, możliwe stało się korzystanie z aplikacji, których nie trzeba nawet instalować na własnym komputerze. A wreszcie, zamiast sprzedawać – i kupować – gotowe aplikacje – możliwe stało się, dzieki wykorzystaniu usług SOA z różnych źródeł - łatwe tworzenie własnych aplikacji.

Utrzymanie jakości usług SOA wymaga jeszcze większej sprawności w zarządzaniu jakością niż dotąd. Czyli wartość książki i tez Adama wzrośnie jeszcze bardziej. Zapraszamy do fascynającej lektury – i fascynujących, nowych możliwości!

Psychologia wydajności

Zarówno programistów i technokratów, jak i zwolenników formalnych metod zarządzania zaksakuje, jak dużą wagę przywiązuje Kolawa do psychologicznych aspektów zarządzania jakością: określenia takie jak „porozumienie”, „jakość nie może być nudna”, „pracownicy powinni być zadowoleni”, „kluczowa jest niekonfrontacyjna forma komunikacji” mogą wydawać się nie na miejscu w „twardej”, biznesowej książce. Tak, ale bez spełnienia tych „miękkich” warunków skokowy wzrtost wydajności nie powiedzie się! Ale to już temat do następnego artykułu.