CIO: Proszę powiedzieć, jakie czynniki należy brać pod uwagę przy tworzeniu oprogramowania?

Patrząc na odsetek udanych projektów informatycznych, choćby na podstawie analizy raportów Chaos Group, widać, że mamy z tym problem i wydaje się, że inżynieria oprogramowania mimo wszystko wciąż jest na początku swojej drogi. Alfred Spector, amerykański informatyk, porównał kiedyś tworzenie oprogramowania do budowy mostów. Z punktu widzenia zarządzania nie ma zasadniczych różnic między tymi dwoma typami projektów. Dlaczego więc mosty raczej się nie zawalają, natomiast praktycznie każde oprogramowanie co jakiś czas ulega awarii? Być może dlatego, pisał Spector, że mosty budujemy od kilku tysięcy lat, więc mamy już doświadczenie.

Oprogramowanie też tworzy się nie od dzisiaj

Sądzę, że problem z tworzeniem oprogramowania polega na tym, że jest ono o wiele bardziej wrażliwe na poziom jakości. Nawet niewielki jej niedostatek może spowodować awarię lub zniechęcić użytkownika do korzystania z programu. Trzymając się analogii Spectora, można powiedzieć, że w przypadku mostu niska jakość, dajmy na to, elementów tworzących przęsła czy nawierzchnię, nie wpływa drastycznie na prawdopodobieństwo zawalenia się mostu ani na jego aspekt funkcjonalny. Ludzie przechodzący po moście nie zwrócą nawet uwagi na te kwestie. Natomiast jeden drobny błąd w kodzie może spowodować fatalne skutki. Inżynieria oprogramowania zna bardzo dobrze takie historie, chociażby przypadek rakiety Ariane 5 czy maszyn do radioterapii Therac-25, gdzie w wyniku błędu w oprogramowaniu w latach 1985–1987 śmierć poniosło sześcioro pacjentów. Wydaje mi się, że w porównaniu z mostami poziom jakości oprogramowania jest o wiele bardziej kluczowy dla powodzenia całego przedsięwzięcia.

Zobacz również:

• 9 cech wielkich liderów IT

Jakie są efektywne metody zapewnienia jakości?

Inżynieria oprogramowania zna bardzo wiele formalnych metod zarządzania, czy też zapewniania jakości w projektach informatycznych. Niestety, często są problemy z ich umiejętnym wykorzystaniem. Ludzie ulegają złudnemu wrażeniu, że skoro jakaś metoda jest opisana w tej czy innej książce lub normie, to wystarczy ją mechanicznie zastosować, zwalniając się z myślenia.

Radzi Pan, żeby przy realizacji projektów stosować myślenie systemowe. Na czym ono polega i dlaczego jest tak ważne?

Myślenie systemowe jest właśnie tym, czego brakuje przy stosowaniu wszelkiego rodzaju technik zarządzania czy zapewniania jakości. Ludzie pracujący w zespołach często ulegają pokusie zajmowania się swoją działką w oderwaniu od tego, co robią inni. Jest to widoczne zwłaszcza w dużych korporacjach, gdzie każdy ma poczucie, że jest tylko jednym z wielu trybików w maszynie. Dostaję jakieś zadanie do wykonania, więc je wykonuję, nie pytając nawet nikogo, czy to ma sens, czy moja praca będzie dla kogoś przydatna i czy stanowi jakąkolwiek wartość dodaną dla projektu.

Czym to grozi?

Postępując w ten sposób, tracimy z oczu obraz całego przedsięwzięcia, w którym uczestniczymy. Myślenie systemowe to sposób patrzenia na organizację obejmujący całościowo zachodzące w niej procesy, uwzględniający właśnie te wszystkie relacje pomiędzy poszczególnymi zadaniami wykonywanymi przez różne osoby.

Peter Senge wyróżnia pięć dyscyplin, które pomogą firmie stać się innowacyjną: mistrzostwo osobiste, modele myślowe, budowanie wspólnej wizji przyszłości, zespołowe uczenie się, myślenie systemowe.

Mistrzostwo osobiste oraz wspólna wizja przyszłości to dyscypliny związane z aspiracjami – indywidualnymi oraz organizacji. Mistrzostwo osobiste, w największym skrócie, to po prostu nieustanne pogłębianie własnej, świadomej wizji życia. Budowanie wspólnej wizji jest, można powiedzieć, zbiorowym odpowiednikiem mistrzostwa osobistego. To doskonalenie organizacji poprzez stworzenie wspólnego celu, do którego chcemy – jako organizacja i jako jej poszczególni członkowie – dążyć.

Modele myślowe to z kolei nasze głęboko zakorzenione założenia, uogólnienia czy wyobrażenia o otaczającym nas świecie. Umiejętność ich identyfikowania i analizy pomaga w zrekonstruowaniu mechanizmów naszych działań. Często pozwala na odkrycie, że coś, co wydawało nam się do tej pory nie do wykonania, da się jednak zrobić. Modele myślowe są ściśle związane z zespołowym uczeniem się. Obie dyscypliny wymagają prowadzenia rozmów z innymi członkami zespołu, a rozmowy sprzyjają uczeniu się. Senge trafnie zauważa, że umiejętność prowadzenia dialogu, czyli swobodnego przepływu myśli w grupie, niemal zanikła we współczesnym świecie. Dialog wyparty został przez dyskusję, będącą swego rodzaju pojedynkiem na poglądy prowadzonym aż do całkowitego zwycięstwa jednej ze stron. Tak w skrócie wyglądają cztery pierwsze dyscypliny.

Jaki wpływ ma piąta dyscyplina na pozostałe?

Piąta dyscyplina, czyli myślenie systemowe, służy integracji pozostałych. Senge pisze, że „dzięki niej pozostałe dyscypliny nie staną się tylko modnymi nowinkami czy przemijającymi fanaberiami organizacji. Bez orientacji systemowej nie ma motywacji, by poznawać wzajemne powiązania między dyscyplinami. Podkreślając rolę pozostałych dyscyplin, myślenie systemowe wskazuje, że całość jest czymś więcej niż sumą poszczególnych części”.

Jak można zastosować myślenie systemowe w tworzeniu oprogramowania?

Nie ma tu jednej, uniwersalnej odpowiedzi. Wszystko zależy od kontekstu, od tego, przed jakimi wyzwaniami stoi dana organizacja itd. Myślę jednak, że jest jedna rzecz wspólna dla wszystkich projektów deweloperskich, która może stanowić dobry punkt wyjścia dla zastosowania piątej dyscypliny. Tym wspólnym mianownikiem jest obserwacja, że celem procesu wytwarzania oprogramowania nie jest – jak myśli, świadomie bądź podświadomie, wielu członków zespołów wytwórczych – stworzenie tego oprogramowania. Dla wielu osób może to zakrawać na herezję. Jeśli jednak zastanowimy się przez chwilę nad pytaniem, po co tworzymy to oprogramowanie, od razu powinno stać się dla nas jasne, że tworzymy je po to, by nasz klient mógł rozwiązać swój problem biznesowy. To właśnie ten problem, nie oprogramowanie, powinien być w centrum zainteresowania wszystkich członków zespołu, od dyrektora IT po szeregowego programistę. Samo oprogramowanie jest tylko narzędziem, pośrednim etapem w realizacji głównego celu.

Jeśli tak postawimy problem, otwiera się przed nami zupełnie inna perspektywa.

Jest to dobry punkt wyjścia do zastosowania pięciu dyscyplin. Członkowie zespołu mogą zacząć dostrzegać, że mają wspólny cel, więc nie są jedynie wyizolowanym fragmentem większej układanki, ale tę układankę współtworzą. Zaczną ze sobą rozmawiać i uczyć się od siebie nawzajem, dostrzegając, że projekt jest systemem naczyń połączonych i że wykonanie jakiejś akcji w jednym miejscu spowoduje reakcję w wielu innych miejscach. Zdając sobie sprawę, jak ich praca przekłada się na realną wartość dla klienta, będą mogli łatwiej zrozumieć, jak efekty ich pracy wpłyną na działania innych członków zespołu. To z kolei pozwoli im optymalizować swoje działania, na przykład pod kątem dostarczenia odpowiedniej jakości końcowego produktu. To bardzo ogólny, ale typowy dla większości organizacji przykład możliwości wykorzystania pięciu dyscyplin.

Peter Senge nie stosuje pojęcia „technologie”, ale „dyscypliny”, dlaczego?

Technologia jest pojęciem typowo inżynierskim, oznacza metodę przeprowadzenia jakiegoś procesu. To pojęcie ma techniczny, formalny posmak. Nazywając swoje pięć działań „dyscyplinami”, Senge wyraźnie wskazuje, że aby odnieść sukces, sama technologia nie wystarczy, potrzeba czegoś więcej.

Zauważmy, że żadna z dyscyplin nie skupia się na technicznych aspektach działania organizacji, ale na ludziach: ich dążeniach, oczekiwaniach, aspiracjach, relacjach z innymi, sposobach funkcjonowania, myślenia i działania. Doskonalenie organizacji odbywa się przede wszystkim przez doskonalenie pracujących w niej ludzi. Stosowane technologie to jedynie narzędzia będące pochodną zbiorowej mądrości organizacji, wynikającej z mądrości poszczególnych jej członków. Warto dodać, że organizacje często przywiązują nadmierną wagę do narzędzi. Wielu menedżerów naiwnie sądzi, że zakup tego czy innego oprogramowania, sprzętu bądź innej infrastruktury automatycznie rozwiąże większość problemów, z jakimi boryka się firma. Zapominają tylko, że te narzędzia nie działają same, lecz są używane przez myślące istoty. Warto zatem najpierw zainwestować w ludzi, a dopiero potem w martwy sprzęt.

Co można uzyskać, stosując myślenie systemowe? Czy pomoże uniknąć błędów w realizacji projektów?

Przede wszystkim stosowanie myślenia systemowego pozwala na udoskonalenie naszej organizacji. Dostrzeganie związków pomiędzy różnymi działaniami poszczególnych członków zespołu pomoże zrozumieć, jak ten skomplikowany system funkcjonuje, pozwoli zidentyfikować dodatnie i ujemne pętle sprzężenia zwrotnego pomiędzy różnymi procesami. To umożliwi eliminację złych nawyków, a w efekcie spowoduje zmianę stylu pracy. Jeśli dla kogoś brzmi to zbyt abstrakcyjnie, zachęcam do lektury książki Petera Senge'a „Piąta dyscyplina”. W jednym z rozdziałów opisuje on niezwykle ciekawy eksperyment, tzw. „grę piwną”, który doskonale pokazuje, jak brak umiejętności uczenia się może destrukcyjnie wpłynąć na rzeczywistość.

Może wróćmy jeszcze na chwilę do tworzenia oprogramowania. Uważa Pan, że rola programisty nie powinna ograniczać się tylko do tworzenia kodu. Na czym powinna polegać jego współpraca z innymi członkami zespołu?

Podam prosty przykład ilustrujący zastosowanie myślenia systemowego w tym kontekście. Programista tworzy kod, który podlega testom. Od jakości tego kodu zależeć będzie efektywność przypadków testowych stworzonych przez testera. Kod źle napisany, zwłaszcza trudno testowalny, ogranicza możliwość jego weryfikacji. Kod po takich testach wraca więc do dewelopera z informacją, że znaleziono niewiele poważnych błędów. To stwarza złudne wrażenie, że w programie rzeczywiście nie ma błędów i wzmacnia przekonanie programisty, że jego sposób pisania kodu jest słuszny. W efekcie daje to kod jeszcze trudniej testowalny, w którym wykrytych będzie jeszcze mniej błędów. Mamy tu klasyczne dodatnie sprzężenie zwrotne. Negatywny efekt będzie rósł w czasie, oprogramowanie będzie coraz gorszej jakości, choć zespół będzie miał zupełnie odmienne wrażenie. Po wydaniu oprogramowania do klienta wszystkie błędy oczywiście się ujawnią, a ich naprawa będzie nas słono kosztować.

Jak tego uniknąć?

Jeśli deweloper przeanalizuje zależność między stylem pisania kodu a jego końcową jakością, zrozumie, że warto poświęcić więcej czasu na zapewnienie testowalności kodu. Musi tylko spojrzeć nieco dalej niż na ekran swojego monitora i dostrzec chociażby testerów oraz ich rolę w procesie zapewniania jakości. Programista może też porozmawiać z testerem (dialog!) o tym, jak styl kodowania wpływa na testowalność kodu i możliwość wykrywania błędów. W rezultacie, rozumiejąc rolę pozostałych członków zespołu, programista jest w stanie zmienić swoje nawyki tak, by skutkowało to podniesieniem końcowej jakości produktu. Czasami drobne zmiany mogą dać, na zasadzie efektu motyla, bardzo duże korzyści.

W metodykach zwinnych stosuje się TDD (Test Driven Development). Na czym polega ta metoda i jak ją wprowadzić w życie?

TDD to wytwarzanie oprogramowania sterowane testami. Polega na tym, by zanim napiszemy kod,opracować do niego testy. To wartościowa technika, ale chyba ze względu na swą koncepcyjną prostotę często niewłaściwie rozumiana. TDD nie jest techniką testowania, lecz kodowania. Test ma tu służyć jako dokumentacja funkcjonalności realizowanej przez kod, pisany pod dany test. Zdanie testu oznacza zrealizowanie funkcjonalności i stanowi pewnego rodzaju dowód jej poprawnego zaimplementowania.

Uważa Pan, że programista powinien być także testerem. Jak pogodzić obie role?

Może nie tyle być testerem, ile posiadać pewne kompetencje w zakresie projektowania testów. Przecież testy jednostkowe to domena programistów. Korzyść z projektowania efektywnych testów bardzo dobrze się uwidacznia właśnie we wspomnianej wcześniej technice TDD: samo zaprojektowanie dobrego testu, np. uwzględniającego jakieś szczególne warunki brzegowe dla danych wejściowych, często pozwala na uniknięcie błędów w późniejszej implementacji danej funkcjonalności.

Przy jakich jeszcze projektach realizowanych przez IT można stosować myślenie systemowe? Jaką ma Pan uniwersalną radę dla szefa IT?

Piąta dyscyplina jest techniką uniwersalną, dlatego można ją stosować w zasadzie w każdym projekcie. A dla szefów IT mam taką samą uniwersalną radę jak dla każdego innego członka każdego zespołu w każdej organizacji: zanim cokolwiek zrobisz, pomyśl. Mam bowiem wrażenie, że zdroworozsądkowe myślenie jest w dzisiejszych czasach towarem mocno deficytowym.