W "Przewodniku po rynku szkoleń IT" (Computerworld, wrzesień 2012) możemy przeczytać, jakie wymagania pojawiają się najczęściej w ofertach pracy. Widzimy tam nazwy: systemy klasy ERP firmy SAP, systemy klasy ERP firmy Oracle, systemy wspierające zarządzanie relacjami z klientami CRM, projektowanie aplikacji internetowych, wirtualizacja, oprogramowanie klasy ERP Comarch, Java, .Net, HTML, C++, PHP, Delphi, Oracle, MySQL, Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell… Brakuje określeń: inżynieria oprogramowania, inżynieria wymagań, zapewnienie jakości, zarządzanie projektami informatycznymi, testowanie, projektowanie systemów, udoskonalanie procesów.

Jak usprawniać procesy, a nawet tworzyć choćby pojedyncze, ale dobre rozwiązania IT, skoro nie zwraca się uwagi, jaki jest cel i sens biznesowy danego rozwiązania, ani jaka jest skuteczność i opłacalność metod IT, lecz koncentruje się na detalicznej, przemijającej znajomości technologii?

Struktura rynku szkoleń IT jest odwzorowaniem tego stanu rzeczy. Teraz podobno dobrze sprzedają się kursy dla użytkowników modnego narzędzia Cucumber (jedno z setek, akurat dzisiaj cool, narzędzi do wykonywania tzw. testowania za pomocą słów-kluczy), kursy języka programowania Ruby (jeden z dziesiątków obiektowych języków programowania, sympatyczny, ale ani gorszy, ani lepszy od innych) oraz kursy Selenium - jednego z wielu narzędzi do testowania aplikacji webowych. Spróbujcie jednak sprzedać wiedzę pozwalającą naprawdę zrozumieć te zagadnienia ponad technologicznymi szczegółami. Nie uda się - zbyt mały jest popyt. Mało kto chce rozumieć, wszyscy chcą tylko umieć, szukają gotowych przepisów na jedną sytuację.

Podsumowując: zafascynowani selenem, ogórkiem oraz rubinem, nie znając inżynierii oprogramowania, realizujemy projekty IT ad hoc, kierując się zawodnym instynktem lub opierając się na ratujących sumienie menedżerów gotowcach (następny akapit). Dopóki to się nie zmieni, dopóki analiza biznesowa oraz inżynieria wymagań nie znajdą się na szczycie listy w przewodniku po rynku szkoleń, dopóty udoskonalanie procesów będzie w dużym stopniu grą pozorów i fikcją.

Moda na gotowce: BEPL, UML, ITIL, PRINCE 2

Nie mam nic przeciwko tym znakomitym językom (BEPL i UML) ani tym niezłym standardom (ITIL, PRINCE 2). To dobre narzędzia pracy. Niestety, nie zastąpią myślenia - a takie próby niekiedy są podejmowane. Tak samo jak niestosowne jest sięganie po młotek, zanim się wie, co do czego trzeba przybić i czy w ogóle przybijać, tak mija się z celem modelowanie w języku UML wymagań, które są niepoprawnie pozyskiwane, czy wręcz można się ich tylko domyślać.

Moda na gotowce utrudnia udoskonalanie procesów. Skoro już zainwestowało się spore sumy we wdrożenie UML, to niełatwo znaleźć czas na zastanowienie się, czy ten sposób modelowania jest zawsze stosowny. Jeśli firma weszła w świat PRINCE 2, trudno jej z niego zrezygnować w projektach, w których nie przynosi on korzyści.

Słowem, aby móc naprawdę oceniać jakość procesów i usprawniać je, punktem wyjścia muszą być rzeczywiste cele biznesowe i realne wymagania, a nie narzędzia, które mogą (choć nie muszą) usprawnić realizację tych wymagań. Dotyczy to zarówno narzędzi wysokich, np. BEPL, jak i niskich, typu ogórek, selen czy rubin.

Od samuraja do Deminga i Jurana

Po co w ogóle bawić się w ulepszanie procesów? W porównaniu z ogórkiem, rubinem i selenem brzmi to mało konkretnie. Budzi podejrzenia, że chodzi o zaspokojenie niepotrzebnych ambicji i potrzeb leśnych dziadków, czy o sprostanie wymogom modnej poprawności politycznej, a nie o budowanie aplikacji ani nie o biznesowy sukces i zysk.

Jest odwrotnie. To fiksacje technologiczno-narzędziowe z jednej strony, a z drugiej strony nawiedzony, niejasny język biznesu i marketingu służą głównie zaspokajaniu potrzeb rozmaitych młodych wilczków (pojęcia "młode wilki" i "leśni dziadkowie" niekoniecznie odnoszą się do daty urodzenia - raczej do sposobu pracy i systemu wartości), a mało biznesowym, finansowym korzyściom. Zapoznajmy się z klasycznym przykładem.

Lata 60. XX wieku. Raczkujący, japoński przemysł motoryzacyjny rodzi śmiech i politowanie, podczas gdy amerykańskie krążowniki szos zachwycają i budzą podziw. W tym czasie dwaj leśni dziadkowie, Deming i Juran (Juran żył 104 lata, jak na leśnego dziadka przystało: 1904-2008) głoszą swoje teorie jakości. Pewne siebie amerykańskie firmy motoryzacyjne nie chcą ich słuchać. Bo po co, skoro dysponują najnowszymi motoryzacyjnymi odpowiednikami ogórka, selenu i rubinu? Procedury - to dobre dla mięczaków!

Deming i Juran pojechali więc do Japonii, gdzie gospodarze uważnie ich słuchali… i posłuchali. W japońskich fabrykach zaczęto odchodzić od starego paradygmatu produkcji taśmowej, gdzie kontrola jakości skupiała się na końcu taśmy, a wykrywane braki albo odrzucano, albo naprawiano… wielokrotnie, gdyż wciąż powracały. Nowa kontrola jakości pojawiła się na każdym etapie produkcji, zaś wykrywane braki wykorzystywano, by wykryć ich przyczynę i trwale ją usunąć. Mówiąc językiem IT, zamiast obszernych i kosztownych testów systemowych i wdrożeniowych, zaczęto stosować znacznie skuteczniejsze testy wymagań, testy statyczne kodu źródłowego oraz testy jednostkowe, a wykryte defekty wykorzystywano do tego, aby usuwać ich technologiczne lub procesowe przyczyny. Kiedy IT dojrzeje do tego?

Co zrobili Japończycy z amerykańskim przemysłem motoryzacyjnym, dobrze wiemy: "1980 - Japan surpassed the United States and became first in auto manufacturing" (http://en.wikipedia.org/wiki/Automotive_industry_in_Japan). To samo zrobią z innymi za najwyżej 10 lat firmy, których działy IT skoncentrują się na ulepszaniu procesów, zamiast na rubinach, ogórkach, selenie, oraz na "wirtualizacji, oprogramowaniu klasy ERP Comarch, Java, .Net, HTML, C++, PHP, Delphi, Oracle, MySQL, Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell".

Żeby ulepszać, trzeba mierzyć

Dobrze, więc ulepszajmy, skoro tyle na tym wygrali Japończycy. Agile! - krzyczą jedni. Programowanie ekstremalne! - krzyczą drudzy. TDD! SPICE! COBIT! CMMI! PMBOK!

Jeśli wygrało Agile, nagle wszystko staje na głowie i zamiast robić oprogramowanie, wszyscy chodzą na treningi współpracy w grupie, kierownicy stają się nagle mistrzami młyna, wymagania - zaległościami (backlog), a kolejne etapy projektu - przebiegami. Tylko co to zmienia? Nawet przyjąwszy, że agile jest cudowną bronią (Wunderwaffe, silver bullet), to co z procedurami czynności innych niż samo pisanie oprogramowania - tymi, z których powodu CMM stało się CMMI?

Więc może CMMI, może COBIT? Świat się biurokratyzuje, jest smutniej, a efekt biznesowy mizerny. Nawet po osiągnięciu kosztem znacznych nakładów magicznego poziomu CMMI-5. Nie wystarczy wdrożyć procedury, których domaga się zewnętrzny standard. Trzeba mierzyć, ile ich wdrożenie i przestrzeganie kosztuje, jakie przynosi efekty, jeśli chodzi o jakość i o wydajność, i jaki jest ich ostateczny skutek biznesowy, mierzony obrotami, zyskiem, udziałem w rynku. Bez tego cała robota na nic. Najwięcej na świecie firm IT mających poziom dojrzałości procesów CMMI-5 jest w Indiach, ale jakoś indyjski przemysł informatyczny dotąd świata nie podbił.

Trzeba mierzyć prawdziwe koszty, zarówno zbudowania systemu IT, jak i jego poprawek, modyfikacji, utrzymania. Próbować oszacować efekty biznesowe wdrożenia systemu i porównać je z oszacowaniem biznesowych skutków zaniechania wdrożenia. Dział finansowy każdej, w miarę dobrze prowadzonej firmy ma dane i narzędzia, aby takie porównania zrobić. Musi tylko otrzymać wytyczne od kierownictwa firmy, a dane - z działu IT.

Pomiary wydajności oraz kosztów w IT nie cieszą się dobrą sławą. Począwszy od doświadczenia z "bystrymi inaczej" firmami doradczymi, usiłującymi mierzyć wydajność IT liczbą przyciśnięć przez pracowników klawiszy klawiatury na godzinę, a skończywszy na obawach przed rozbudowaną papierologią: pół dnia się pracuje, a drugie pół wpisuje w formularze, co w tym czasie się robiło.

Nie! Tak rozumiane "pomiary wydajności" nie działają. Trzeba to robić inaczej - automatycznie. Wtedy dopiero, bez żmudnych, nudnych, dodatkowych nakładów, będzie można bez trudu dowiedzieć się, co ile czasu zajmuje w projektach IT i ocenić efekty ulepszeń.

Jak można to robić? Polecam artykuły:

- "Między biurokracją a chaosem" (https://www.computerworld.pl/artykuly/321693_2/Miedzy.biurokracja.a.chaosem.html)

- "Dramatyczny wzrost wydajności dzięki IT" (https://www.computerworld.pl/artykuly/361381/Dramatyczny.wzrost.wydajnosci.dzieki.IT.html)

- "Jakość warunkiem wydajności" (http://victo.eu/PL/Wiedza/jakosc_warunkiem.pdf).

Sukces w biznesie a udoskonalanie procesów

Po co udoskonalać procesy IT? Po to, żeby docelowo zwiększyć lub co najmniej utrzymać zysk firmy. Docelowo, czyli:

- albo zwiększywszy stopę zysku przy tych samych co wcześniej obrotach;

- albo zwiększywszy obroty, np. wprowadziwszy nowe produkty / usługi;

- albo utrzymawszy / zwiększywszy udział w już istniejącym segmencie rynku.

Zarówno dla firm IT, które tworzą oprogramowanie na zamówienie, jak i działów IT w firmach zajmujących się innym biznesem, kluczem do sukcesu są wymagania: żeby miały biznesowy sens, żeby były dobrze zdefiniowane i opisane, i wreszcie sprawnie - możliwie szybko i niedrogo - zrealizowane.

Usprawnianie procesu pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań, czyli całego procesu IT jest dla firmy równie ważne jak - lepiej znane, rozumiane i doceniane - ulepszanie procesów zarządzania finansami, marketingiem, sprzedażą, procesem dostaw.

Proces produkcji oprogramowania nie jest - w przeciwieństwie do procesów produkcyjnych w tradycyjnym przemyśle - wytwarzaniem wielu kopii tego samego produktu. Każdy projekt IT jest inny, realizuje odmienne wymagania. Dlatego, aby móc stwierdzić, na ile skuteczne są próby udoskonalenia procesu IT, trzeba znaleźć miary pozwalające porównywać ze sobą projekty i produkty IT. Taką miarą są wymagania, ich trudność i złożoność.

W tym miejscu łączą się trzy obszary, tradycyjnie taktowane jako odrębne:

- inżynieria wymagań i wykonywane na podstawie wymagań oszacowania pracochłonności;

- zarządzanie projektami IT;

- metody udoskonalania i oceny jakości procesu IT.