Wszyscy od dłuższego czasu obserwujemy efekty działania niektórych amerykańskich banków. Znamy też powód tej finansowej czkawki, którym jest zaklinanie rzeczywistości, ale od początku...
Jesteśmy bankiem, który radzi sobie jako tako, ale jako zarządzający chcemy mieć się czym pochwalić, więc zaczynami szukać nowych możliwości. Ludzi o dobrej zdolności kredytowej szybko nie przybędzie, więc może by tak pójść na skróty i udzielać kredytów coraz mniej pewnym. Generujemy genialne wyniki sprzedaży, ale na tym nie kończymy, bo z racji dobrych wyników, nakręcamy spiralę i udziałowcy chcą jeszcze więcej. Chcemy zgarnąć premię, więc robimy jeszcze więcej. Kogo to obchodzi, że wszystko jest ładne tylko na papierze. Premia na koncie jest już teraz. Potem pojawia się jeden niespłacający, potem następny, załamanie na rynku i panika... a wystarczyło pielęgnować swoje instrumenty finansowe i pamiętać, że chęć ogromnych zysków to i ogromne ryzyko. Niby w świecie finansjery znane nawet początkującym, ale jak to bywa w rzeczywistości mogliśmy się przekonać.
Teraz przejdźmy do naszego podwórka, czyli programowania i kodu, bo kto powiedział, że musimy uczyć się tylko na błędach we własnej branży ;)
Mamy niewielki, stabilny i dobrze napisany kod, ale pojawia się okazja do ogromnego zarobku po dodaniu kilku ficzerów w krótkim czasie. Dodajmy je i zbieramy forsę, ale czasu na posprzątanie w kodzie już nie było. Spokojnie -- myślimy sobie -- zrobimy to później. Ale nie ma później, przychodzi inny klient, kładzie forsę, a my chcemy ją dostać i... dorabiamy nowe ficzery. Idzie nieco trudniej, ale dajemy jakoś radę. Sytuacja potarza się ze 2 lub 3 razy. Udziałowcy zachwyceni, ale na kod się już patrzeć nie da, bo błaga o przepisanie. Przychodzi kolejny klient, kładzie forsę, podaje termin, zgadzamy się i... nie dajemy rady. Lecimy z karą, błędami, nowi klienci zaczynają nas omijać, bo jesteśmy niepewni i dopiero co startująca konkurencja bez bagażu zrobi to za pół ceny w 1/3 czasu. Czas zwijać interes lub sporo wydać na przebudowę własnego systemu. Na zastrzyk ze strony rządu raczej nie mamy co liczyć, oprogramowanie to nie bank.
A wystarczyło być szczerym z klientem i samym sobą, czyli zapewnić wysoką jakość kodu po projekcie, nie rzucać się na każdą okazję, a jeśli nawet to dobrze wyliczyć zyski i straty. Brak refaktoryzacji zmniejsza naszą szybkość reakcji w przyszłości, czyli nasze przyszłe zyski. Oczywiście nie mówię tu o przesadnej refaktoryzacji, bo określone pieniądze z projektów już teraz są również bardzo ważne, ale o równowadze. Drobne opóźnienia taktyczne w zapewnieniu wysokiej jakości są poprawne, jeśli jesteśmy tego świadomi, znamy konsekwencje i chcemy to później szybko spłacić. Nie wierzmy tak jak niektórzy prezesi banków, że magia istnieje i konsekwencji nie będzie.
0 komentarze:
Post a Comment