Defekty oprogramowań na rynku, czyli dlaczego orkiestra na Titanicu grała do końca?

Czas czytania artykułu: 5 minut
Michał
07.01.2021

Rynek zbytu jest głównym weryfikatorem stopnia powodzenia podejmowanego przedsięwzięcia. To on ocenia, czy produkt nań wniesiony okrzyknięty zostaje mianem przełomowego dzieła czy raczej okazuje się kiczem niedostosowanym do realiów i potrzeb użytkowników. W głównej mierze jednak przekaz ów nie jest zero-jedynkowy i stawia twórców przed trudną decyzją: zmienić repertuar, grać głośniej czy zamilknąć w ogóle?

Na początek aksjomat – nie ma oprogramowania bez defektów. Mimo rosnącej świadomości na temat istotności testowania produktu, nawet najdociekliwsze oko testera nie jest w stanie konkurować z pomysłowością i nieprzewidywalnością zachowań osób eksploatujących software. Rezultaty tych eksploracji nierzadko przyprawiają o ból głowy programistów próbujących załatać lukę w systemie czy aplikacji. O tym wszystkim wiedzą wytwórcy oprogramowania na każdym stopniu firmowej hierarchii. Na kim spoczywa więc największa odpowiedzialność za ewentualne luki znalezione w finalnej wersji aplikacji?

defekty_oprogramowan_na_rynku_w_tekscie1

Na pewnym etapie testowania oprogramowania testerzy częstokroć spotykają się z oporem osób odpowiedzialnych za projekt jako całość. Opór ów można najczęściej streścić słowami godnymi szefa grupy archeologów: „Długo jeszcze będziecie przy tym grzebać? Wszystko już chyba znaleźliście, prawda?”. Co bardziej empatyczny lider zapyta z nieukrywaną troską: „Jak myślicie, dużo jeszcze znajdziecie tych bugów?”. Niestety, ani archeologia, ani tym bardziej wróżenie z kuli nie leży w gestii testerów, toteż ci, wykonując pracę sumiennie, nie ustaną, póki nie zgłoszą wszystkiego, co wyda im się podejrzane, niepożądane lub po prostu bezsensowne. Oni przecież tylko wykonują polecenia przychodzące z góry.

Samo wytwarzanie oprogramowania różni się znacząco od rodzaju rynku oraz grupy docelowej użytkowników, tych pośrednich, jak i końcowych. Innym restrykcjom będzie podlegać produkt z branży medycznej, który będzie musiał być solidnie udokumentowany, sprawdzony i pobłogosławiony akredytacją ciał certyfikujących, inaczej wydana zostanie gra komputerowa przeznaczona na różne konsole i komputery, a zupełnie inną kwestią są proste strony dla wędkarzy niepodlegające niemal żadnym restrykcjom. Istnieje natomiast wspólny mianownik dla każdego rodzaju cyfrowego tworu – warsztat programistyczny. Ten warsztat opiera się o liczne godziny spędzone na poznawaniu wzorców projektowych, doskonaleniu umiejętności analitycznego podejścia do problemów czy nauce nowych i zgłębianiu już znanych języków i frameworków. Jeśli więc poczynione zostanie założenie, iż programista nie sabotuje projektu i rzeczywiście rozwija projekt zgodnie ze sztuką, czy uznać można, że ponosi odpowiedzialność za defekty znalezione dopiero na rynku?

defekty_oprogramowan_na_rynku_w_tekscie2

Powyższe dywagacje rozszerzyć można o role i pozycje architektów, analityków biznesowych, projektantów UI oraz UX, marketingowców oraz wszelkiej maści kierowników szczebla dowolnego. Konkluzja będzie zwykle ta sama: „Czy to moja wina, że nie zadziałało to czy to?”, co w linii prostej prowadzi do starej jak świat spychologii będącej dość naturalnym mechanizmem obronnym – wyparcia. Dużym błędem jest poprzestawanie tylko na szukaniu winowajcy, a jeszcze większym – znajdowanie kozła ofiarnego. Takie działanie jest zaprzeczeniem tego, na co defekt przychodzący z rynku powinien otwierać oczy, czyli na budowanie wspólnej, a nawet współdzielonej odpowiedzialności za dostarczany produkt, jako całość, od A do Z. Jest to tylko mały krok w tworzeniu zgranego zespołu, ale wskazuje osobom zawiadującym rytmem firmowej orkiestry na istotę zwalczania odpowiedzialności rozproszonej. Miarą dojrzałości współpracowników będzie więc stopień zaangażowania w nieprawidłowości, których bezpośrednimi autorami nie są oni sami. Czy w takim razie orkiestra, która pomyliła partytury, może naprawić swoje błędy i uratować koncert? Z pewnością, jednak trzeba pamiętać, że nawet najpiękniej sprzedany i zagrany koncert może nie wystarczyć, by uratować filharmonię przed upadkiem.


O autorze

Michał
Michał, software developer
Niezmiennie od 1994 związany ze Szczecinem. Student informatyki WI ZUT w Szczecinie. Najmłodszy software developer w Demant. Zawodowo odpowiedzialny za warstwę UI aplikacji desktopowych. Pasjonat .NET, eksperymentator IoT, specjalista od gadania oraz na wskroś szczecińskiego braku umiaru.