Jest pięć prostych zasad, niezbędnych, aby projekty IT kończyły się biznesowym sukcesem. Te zasady wielokrotnie omówiono i opisano, weszły w skład podstawy programowej nauczania dla zawodowców IT, ale okazuje się, że zbyt łatwo o nich zapominamy. Warto nie tylko je powtórzyć, ale także zastanowić się nad ich znaczeniem.

1. Jakość jest za darmo

Książka Crosby'ego "Quality is Free" ("Jakość nic nie kosztuje") została wydana w roku 1979. Jedna z dyskusji na ten temat odbyła się blisko dekadę temu, podczas konferencji Computerworld w 2004 r. Niestety, zwyciężył wniosek, że jakość jednak nie jest za darmo.

Od tego czasu niewiele się zmieniło. W działach IT nieliczni jajogłowi nadal muszą walczyć o uznanie zasady, że warto najpierw stworzyć specyfikację wymagań, zamiast zaczynać kodowanie bez kierunku, bez celu i bez planu. Jakość nadal wielu widzi jako zbędny luksus, z którego można zrezygnować, podczas gdy jeśli naprawdę mamy kryzys, to jesteśmy zbyt biedni, by pozwolić sobie na rozrzutne niechlujstwo: potrzeba nam zdyscyplinowanego oszczędzania, czyli jakości.

2. Monopole szkodzą przedsiębiorczości

Monopole są aroganckie, pewne siebie i ograniczają konkurencję albo dbają, by nie rozkwitła. Wydaje się, że w IT, gdzie istnieje mit samotnego programisty w garażu, co w ciągu roku staje się miliarderem, zagrożenie monopolizacją jest mniejsze. Niestety, nie jest. Dobrowolnie tolerujemy monopole.

Rewolucja testowa, która do Polski przyszła w latach 2002-2003, spowodowała wprawdzie, że niedostrzegane wcześniej testowanie i kontrola jakości stały się nominalnie uznaną częścią krajobrazu IT, ale kosztem rezygnacji ze swego podstawowego przesłania, jakim jest oszczędność i zysk przez mądrze dozowaną jakość. Zamiast tego, testowanie - podobnie jak wcześniej programowanie i zarządzanie - stało się lunaparkiem narzędzi o pokracznych nazwach, dziwacznych pseudometod i zamkniętych, nie podlegających żadnej kontroli systemów certyfikacji, które więcej kosztują, niż dają.

Fora dyskusyjne testerów intelektualnie zamarły, dominują tam dzisiaj reklamy obowiązkowych, wciąż tych samych szkoleń certyfikacyjnych tych samych firm, trochę detalicznych pytań o narzędzia i na tym koniec.

3. Jakość warunkiem wydajności

Panuje przekonanie, że jakość to kosztowny luksus, na który stać najbogatszych. To taki sam nonsens jak wiara, że tylko bogatych stać na zdrowy tryb życia.

Jeśli celem działań jest abstrakcyjne "podniesienie jakości", możliwa jest tylko przegrana. Albo projakościowe działania szybko ulegną typowej w IT kulturze sztukowania i łatania dziur, zamiast mierzenia, projektowania i planowania, albo jakość - zbiurokratyzowana i nieskuteczna - wprawdzie zostanie, ale jako dokuczliwa otoczka, dodatkowa robota, która nie przyczynia się do wzrostu wydajności, a wręcz przeciwnie.

Należy więc zacząć od przeciwnego końca: nie dbać o jakość, starać się tylko zwiększyć wydajność. Niech za pół roku pięciu programistów w dwa miesiące umie zrealizować pracę, która dzisiaj dziesięciu programistom zajmuje pół roku. Jak to osiągnąć?

Popatrzmy, co naprawdę robią w pracy programiści. Trochę programują, a poza tym? Po pierwsze, dużo czasu poświęcają na przerabianie tego, co już raz i drugi zrobili, bo biznes nie potrudził się, aby swoje potrzeby precyzyjnie określić, a wymagania opisać. Byłem niedawno w firmie produkującej programy na smartfony i tablety, która chciała usprawnić czasochłonne testy, automatyzując je. Automatyzacja jest skomplikowana i wymaga sporo pracy, więc zaproponowałem im usprawnienia tańsze i szybsze: pisanie prostych specyfikacji wymagań w formie tabeli w Excelu zamiast historyjek obrazkowych i opowieści tworzonych w PowerPoint, a także półautomatyczne tworzenie z nich uporządkowanych scenariuszy testowych, mogących zastąpić kreatywną eksplorację. Moje podejście nie wzbudziło entuzjazmu, automatyczne testy wydają się ciekawsze.

Drugie marnotrawstwo czasu to tzw. debugowanie - szukanie w kodzie defektu, który od czasu do czasu powoduje awarię. Można znacznie, o 50% i więcej, obniżyć potrzebę debugowania, wdrażając proste, automatyczne lub półautomatyczne środki zapobiegawcze, np. tzw. analizę statyczną i automatycznie generowane testy jednostkowe.

Trzecie marnotrawstwo to zbędne gadanie. Nie gadanie dla rozrywki i przyjemności - to warto popierać, bo zadowolony człowiek pracuje lepiej i wydajniej. Chodzi o konieczność gadania - bezpośredniego, e-mailem, SMS-em, telefonem czy społecznym medium - w celu uzgadniania, zdobycia informacji, potwierdzenia, zarezerwowania dostępu, skonfigurowania, przyniesienia lub odzyskania czegokolwiek. Tam gdzie synchronizacja oraz administrowanie odbywają się przez gadanie, zamiast procesu i narzędzia, tam marnujemy nieskończenie wiele czasu. Duże pieniądze można zarobić, usuwając chaos za pomocą prostego narzędzia do tzw. śledzenia powiązań wymagań.

4. Taniej zapobiegać, niż leczyć

Kiedyś sądzono, że projekt IT mogą zrealizować niemal sami programiści kierowani przez jedną osobę czy dwie osoby z żyłką do interesów. Stopniowo przekonano się, że taki numer, owszem, od czasu do czasu się udaje, ale jego koszty wielokrotnie przekraczają pozorne korzyści. Te koszty to rozgniewani klienci, przemęczeni programiści, ogromne wydatki na na usuwanie skutków nieoczekiwanych awarii i nerwowe naprawy pod presją terminów i odszkodowań, czego łatwo uniknąć, jeśli przed wdrożeniem oprogramowanie przyzwoicie sprawdzić (przetestować). Tak zaczęła się kariera testerów, których rację bytu przemysł zaakceptował, tak jak akceptuje się i nawet ceni istnienie policji, straży pożarnej czy pogotowia ratunkowego.

Nauczywszy się gasić pożary, można z czasem wpaść na dalej idący pomysł, że jeszcze lepiej byłoby nauczyć się pożarów unikać. Dlatego przed kilku laty pojawiła się idea ADP - Automated Defect Prevention - prosta, logiczna, elegancka i niesamowicie skuteczna. Tymczasem IT nadal bardziej podziwia odpornych na stres, dzielnych strażaków, zamiast tych, którzy mówią, że jest czas najwyższy - jak w każdym innym przemyśle cywilizowanego świata - porzucić XVIII-wieczną manufakturę - debugowanie i dokręcanie śrubek w trakcie jazdy - na rzecz XX-wiecznej taśmy produkcyjnej, gdzie błędów i defektów przede wszystkim się unika, a nie gorączkowo je poprawia w gotowych produktach.

5. Pamiętaj o inżynierii wymagań

Oczywiście, że każda złotówka wydana na inżynierię wymagań przynosi dziesięć razy większy zysk niż złotówka wydana jakikolwiek akurat modny trend. Inżynierii poświęciliśmy ostatnio kilka artykułów w "Computerworld", można znaleźć je w naszym serwisie internetowym.

Autor jest prelegentem konferencji FORUM JAKOŚCI SYSTEMÓW INFORMATYCZNYCH, organizowanej przez Computerworld w dniach 21-22 maja 2013 w Warszawie.

Jak projektować, testować i tworzyć niezawodne systemy informatyczne?

Dowiedz się na konferencji!