TheTarPit

Kryzys wartości - odsłona pierwsza

Inżynieria oprogramowania (pomijając cokolwiek akademickie rozważania na temat zasadności samego słowa „inżynieria” w tym kontekście) jest jedną z najszybciej rozwijających się dziedzin działalności gospodarczej. Jeśli zagapisz się przez rok w innym kierunku, to właściwie nie masz szans wrócić w to samo środowisko — inne narzędzia, inne techniki, inne wymagania. Do spółki z wciąż szaleńczo galopującym rozwojem sprzętu tworzy to sytuację, w której tzw. „przeciętni ludzie” mimo, że mają coraz więcej powodów do korzystania z komputerów, rozumieją je coraz mniej. Nie potrafią powiedzieć jak to działa ani jak powstał program, który widzą „tam w środku”. A to są idealne wręcz warunki do rozwoju kilku zawodów i pojawiania się profesjonalistów — tam, gdzie szaleją demony, potrzebni są szamani, magicy i specjaliści wszelkiej maści.

wiedza nie weryfikowana

Wytwarzanie oprogramowania wymaga (i zawsze wymagało) konkretnej i często wcale nie banalnej wiedzy i doświadczenia. Nie tylko wiedzy technicznej, czysto inżynierskiej, ale niejednokrotnie również sporych umiejętności socjologicznych — aby stworzyć program dla ludzi trzeba rozumieć ich i ich potrzeby lepiej niż oni sami to zrozumieć potrafią. Wiedza ta jest dla wielu tak niedostępna, że łatwo osiąga dosyć wysoką cenę. Jest więc popyt i jest sens jego zaspokajania.

Jednak wiedzy, a tym bardziej zdolności twórców oprogramowania, nie potrafi zweryfikować nikt oprócz innych im podobnych. Ktokolwiek, kto styka się z oprogramowaniem na etapie innym niż jego produkcja, nie ma praktycznie żadnych możliwości zweryfikowania jakości procesu wytwórczego — może oceniać jedynie po efektach. Tymczasem oprogramowanie jest produktem tak złożonym i jego działanie zależy od tak wielu czynników zewnętrznych (począwszy od środowiska, przez wpływ innych programów, aż po specyficzny układ danych), że jego ocena oparta wyłącznie na efektach działania jakiejś wybranej instalacji jest co najmniej niepełna. To prowadzi do paradoksalnego wniosku, że ocena oprogramowania dokonywana przez jego użytkowników jest właściwie z założenia błędna.

jakość nie gwarantowana

Użytkownika oprogramowania raczej nie interesuje technologia jego produkcji, a tym bardziej teorie na temat możliwości lub niemożliwości stworzenia programu bez błędów. Jest on odbiorcą konkretnego produktu i ma pełne prawo oczekiwać, że produkt ten będzie pozbawiony wad fabrycznych. Producent natomiast nie jest w stanie zapewnić braku wad, czy choćby utrzymania ich na pewnym odpowiednio niskim poziomie istotności. Sprzeczne? Owszem, ale problem ten zwykło się rozwiązywać banalnie prosto — standardowa licencja EULA stanowi porozumienie stron, które zdejmuje z producenta produktu jakąkolwiek odpowiedzialność za jego wady, a odbiorcy skutecznie wybija z głowy pojęcia takie jak rękojmia lub podobne. Tak po prostu. Nie potrafię wskazać żadnego innego produktu przemysłowego czy komercyjnego, którego producent deklarowałby całkowity brak odpowiedzialności za działanie swojego dzieła i ewentualnie wyrządzone przez nie szkody. Jak również produktu, którego użytkownik tak łatwo i radośnie pozbywał by się wszelkich gwarancji jakości swego zakupu.

cena umowna

Wycena oprogramowania jest sama w sobie zagadnieniem makabrycznie trudnym. Przy pisaniu programów na zamówienie może ona zależeć np. od ilości osobogodzin koniecznych do wytworzenia wymaganego produktu. Ilość tych osobogodzin zależy natomiast od wiedzy, zdolności i zaangażowania twórców, a gotowość produktu od osiągniętego poziomu jakości. Jak wspomiałem wyżej, obie te cechy są z punktu widzenia odbiorcy danego produktu całkowicie niemierzalne i niemożliwe do zweryfikowania. Natomiast w przypadku programów „z półki” cena musi zapewnić producentowi opłacalność całego przedsięwzięcia przy założonej ilości sprzedanych egzemplarzy w zadanym czasie. W efekcie wychodzi na to samo — cena oprogramowania jest więcej niż umowna.

dylemat moralny

Załóżmy, że stworzyliśmy na zamówienie Piękny, Wielki System Informatyczny. Nie mamy najmniejszej wątpliwości, że tak jak dowolne inne oprogramowanie zawiera on błędy. Stanowi zatem produkt fabrycznie niepełnowartościowy — bubel z definicji. Ponieważ jednak napracowaliśmy się strasznie (głównie walcząc z własną niewiedzą i nieumiejętnością, ale jednak była to ciężka praca) to żądamy za ten bubel „stosownej” zapłaty. Ceny nie dało się niczym sensownym uzasadnić, więc jest wzięta „z sufitu”, ewentualnie wynika z porównania do cen innych producentów, co na jedno wychodzi. Swojemu produktowi nie ufamy za grosz (w końcu wiemy jakie indywidua to napisały) więc zmuszamy odbiorcę/użytkownika/kupującego do podpisania licencji, która zdejmie z nas jakąkolwiek odpowiedzialność za wady produktu i jego ewentualne niszczycielskie działanie. Kupujący jest do tego przyzwyczajony, więc podpisuje bez problemu. Nie jest jednak aż tak nierozgarnięty jak byśmy sobie życzyli, więc żąda od nas wsparcia i usuwania błędów (których się oczywiście spodziewa). Planujemy zatem odpowiednie procedury w zależności od kategorii błędu (przecież wiemy, że oprócz naszych drobnych błędów w kilku punktach nie zrozumieliśmy w ogóle o co klientowi chodziło) i zapewniamy mu serwis. Ponieważ QOS jest hasłem modnym i chwytliwym, to trzeba będzie o tym jakoś stosownie wspomnieć. Zatem nasz serwis będzie w pełni profesjonalny. Czyli płatny.

Jakby na to nie spojrzeć, trudno oprzeć się wrażeniu, że komercyjna produkcja oprogramowania to nie jest porządny, uczciwy fach...

Komentarze