Każdy kij ma dwa końce ? czyli firmy informatyczne "na dorobku"

Problem, który opisany jest w tym artykule, jest jak sami przyznajecie dość powszechny bez wzgledu na rozmiar firmy informatycznej. Problem jak zawsze leży w ludziach.

Po pierwsze przywiazanie do jakości jest cechą niewielu narodowości. Nawet jeżeli nie jest wrodzona a narzucona przez kogoś/coś to i tak wyrobienie właściwych nawyków trwa długo i jest męczące i mozolne czytaj: wiekszości się nie chce.

W wiekszości przypadków oddawanie czegoś dobrej jakości jest związane z ludzką przyzwoitością opierającą się na prostej zasadzie "Nie będę firmował swoim nazwiskiem bubla." I co ciekawe również większość chciałaby tę zasadę właśnie stosować nie tylko przy tworzeniu programów ale przy każdej innej pracy. Po prostu być oazą doskonałości w tym co się robi bez względu na okoliczności.

A tymczasem zanalizowaliście juz dość dokładnie te okoliczności:
1. Złe nawyki wyniesione ze studiów lub innych kursów związanych z informatyką. Sami zastanówcie się jak w studenckich warunkach można oddać na zaliczenie laborek dobry jakościowo filtr dolnoprzepustowy napisany w C++ jeżeli za stworzenie go zabieramy się na 24 godziny przed terminem oddania bo przez 3 miesiące semestru balowalismy i spotykalismy się ze znajomymi. Kto w tych warunkach będzie się przejmowął stylem pisania kodu czy poprawną koncepcją klas i obiektów. Asystent który prowadzi laborki też się nie zna bo konczył studia w tych samych warunkach. Daj Boże żeby był jednym ztych którym się chce, wtedy moze bubla nie puści. Ale jeżeli ma na głowie artykuł do napisania dla profesora bo go poprosił to pozalicza wszystkim na 3 i będzie "z głowy".
Jest to problem braku systematyczności w tym co się robi i braku powtarzalności pewnych działań na przestrzeni jakiegoś czasu (studencka zasada 3Z). Jeżeli wykonuje sie kilka razy tę samą pracę to średnio zdolny nawet student sam się zorientuje, że warto część rzeczy usprawnić, ulepszyć może skorzystać z gotowych sprawdzonych rozwiązań aby uniknąć wywarzania otwartych juz drzwi.

2. Spójrzmy na problem od strony pracodawcy. Slusznie moim zdaniem artykuł nazywa pewien odsetek firm firmami "na dorobku". Otóż jest to stwierdzenie bardzo trafne choć należy je rozumieć nie tak jak sie rozumie powiedzmy małżeństwo na dorobku. Wyobraźcie sobie ze macie 25 lat. Właśnie ukonczyliscie studia informatyczne macie głowę pełną pomysłów i macie ambicję przenosić góry i walczyć z wiatrakami. W czasie studiów na niejednej imprezie piliście wódkę z ludźmi którzy po studiach jakimś dziwnym trafem stają się szeregowymi pracownikami firm mniejszych lub większych ale również dziwnym trafem dostają na tyle mocy decyzyjnej że mają prawo decydować o wyborze dostawcy powidzmy serwisu www. No więc wybór jest prosty "Włodziu nie machnałbyś nam strony www?". Oczywiscie zgadzamy się bo co to dla nas zrobić stronę www. I tym samym sposobem którym oddalismy filtr dolnoprzepustowy na zaliczenie oddajemy stronę www. Najgorszy przypadek jest wtedy gdy Odbiorca ma znikome pojęcie o tym jak to powinno wyglądać od strony właśnie jakości czy samego ryzyka takiego projektu. Niestety w większości przypadków firmy nie mają takiego pojęcia, a więc przyjmują dowolny kit jaki im się wciśnie zgodnie z zasada "byle działało". Koło "braku jakości" zamyka się. Zostajemy polecani innym firmom jako solidny partner w biznesie i siła inercji wszystko samo się toczy.

3. Dlaczego tak więc się dzieje że Odbiorca nie stanowi naturalnej bariery przed złą jakościa. Przecież jak idziemy kupować ziemniaki na rynek to przyglądamy się uważnie czy nie łądują nam do siatki zgniłych. prawda? A może nie zawsze? A co jeśli robimy imprezę i w jej trakcie zabrakło nam czipsów. Wysyła sie kogoś po czipsy. Ten idzie do nocnego a tam tylko czipsy marki czipsy. Ponieważ potrzeba jest silniejsza od rozsądku a polecenie było jasne "Kup więcej czipsów" to nasz dostawca kupuje te byle jakie czipsy i wszyscy sa zadowoloeni. Nie ważne, że na drugi dzień wszyscy maja zgagę i biegunkę ważne, że sama impreza nie ucierpiała kosztem braku jakis tam czipsów. I tak jest właśnie u naszych polskich Odbiorców oprogramowania. Jeżeli u Odbiorcy nikt nie ma pojęcia o tym co nazwałbym "dobrymi praktykami zarzadzania projektami IT" to Dostawca "na dorobku" nie ma motywacji aby nauczyć sie czegoś dobrego/słuszniejszego po prostu lepszego. I znów koło się zamyka. Programuje sie byle jak, byle co, na byle czym, przez ekhm... byle kogo, byleby zdążyc w terminie bo kara za niewykonanie projektu jest sroga a nasza mała firemka z 5 kredytami jest do zaoraania w jedną chwilę. Najgorsze jest jak nasze refernecje spodobają się gigantom. W polskiej rzeczywistości jest tak że firmy "krzak" robią gignatyczne projekty dla gignatów bo Ci chcąc ciąć koszty sugerują się glównie ceną za wykonanie proejktu a nie faktyczną jego jakością. W razie czego po prostu nie zapłacą Dostawcy i go zaorają. Byleby nie zaksiegowano straty i prezes nie dowiedział sie że firma straciła pieniądze. Idea, że nie wdrożenie czegoś kosztuje firmę wiecej jest tylko ideą z książek o zarządzaniu. Najczęściej menadżer może zkillować projekt pod warunkiem, że za niego nie zapłaci i prezes to kupi. A tak naprawde liczy się tylko wynik sprzedaży i to na ogół pod ten wynik robi się cokolwiek.

4. Absurd idzie z góry. Niestety absurd, o którym piszecie w artykułach 387 i 388 idzie z samej góry. Bez względu na to, czy to jest Dostawca czy Odbiorca wszystko sprowadza się do tego na ile osoby odpowiedzialne za zarządzanie pozwolą na szerzenie się absurdu. Jednym i drugim zależy na zysku i terminie. Na sposobie choćby poprawnego nazywania zmiennych, metod, klas nikomu w tym momencie nie zależy. Programista niedoświadczony uczy sie już na samym poczatku swojej ścieżki złych nawyków. Z czasem widzi, że nie ma sensu sie przykładać bo to i tak nie ma zadnego znaczenia. Liczy się termin oddania i byleby jakos tam działało. Nawet doświadczeni programiści przymykają oko na rażące błedy bo termin jest ważniejszy a optymalizację kodu zrobi się już na żywym organizmie. Architektura kuleje bo nie ma czasu na jej gruntowne przeanalizowanie. Wiekszość spraw wychodzi w praniu i "na żywca" klepie sie poprawki, hotfixy i inne. Po 2 miesiącach system lub nawet zwykła strona www nie przypomina w niczym pierwszego projektu. Jest stekiem bzdurnych pomysłów i kolekcją łat na łacie. Najlepszym spsoobem ocenienia tego jest spojrzenie w plik .css takiej strony. Wielokrotnie moza tam dojrzeć zakomentowane całe linie właściwości. Klasy typu banner1 banner2....banner-dupa itd. Chaos niesamowity a to tylko dlatego, że trzeba było cos na szybko poprawić bo prezes Obiorcy poprosił o to naszego Prezesa i tak juz zostało: "przysługa za przysługę - zróbcie to nam tanio i szybko a my bedziemy zlecać Wam wszystkie nasze projekty"....

Z zainteresowaniem przeczytałem artykuł Każdy kij ma dwa końce ? czyli firmy informatyczne "na dorobku" i od razu nasunęło mi się porównanie do wymienionego w tytule prawa. Choć prawo Kopernika (Greshama) dotyczy teorii pieniądza łatwo je sprowadzić na grunt informatyki.

Obserwując historię i mając wciąż w pamięci spostrzeżenia zawarte w artykule chciałbym sprowokować rozmowę na temat:
Czy i kiedy oraz w jakich dziedzinach oprogramowanie "kiepskiej jakości" wyprze z rynku oprogramowanie o "wyższej jakości"?

A podchodząc bardziej praktycznie, w jakich dziedzinach życia patologiczne akceptowanie przez rynek kiepskich systemów oraz wysokiego ryzyka fiaska inwestycji staje się normą?