Do tego, ów kapitalizm, to jak pokazuje autor Korporacji (gorąco polecam tę książkę i film). Rozpoczynając czytanie tej książki traktowałem ją z początku jak kolejny efekt "spiskowej teorii dziejów", jednak z każda stroną zmieniałem zdanie gdyż z dużymi firmami mam do czynienia regularnie a tak zwane afery opisywane w prasie stanowią niejako naturalną ilustracje tej książki.Jedną z kluczowych tez autora tej książki jest to, że kluczem do zysków korporacji są wyzysk pracowników i przerzucanie swoich kosztów na klientów (nabywców ich towarów i usług). Nie będę tu się rozpisywał na ten temat, wystarczy poczytać w prasie i na forach dyskusyjnych jak wygląda realizacja niejednego projektu IT. Najpierw jest przetarg na podstawie wątpliwej jakości opisu potrzeb, potem dostawca - zatrudniając najtańszych pracowników na rynku - próbuje zrealizować swoje zobowiązanie rutynowo (czyli niskim kosztem) przerzucając koszty każdego ryzyka na zamawiającego. W efekcie otrzymujemy niskiej jakości i bardzo kosztowny produkt.Autor, w swoim artykule, wymienia także Państwo jako wyzyskiwacza. I tak to wygląda na prawdę: wszystkie koszty złego (kosztownego) funkcjonowania Państwa są przerzucane na podatnika, ten zaś jako usługobiorca (Państwo świadczy usługi dla obywateli) jest dokładnie w takiej samej sytuacji jak w przypadku brania kredytu w banku czy kupowania pasty do zębów w supermarkecie.Na koniec coś optymistycznego: osobiście widzę światełko w tunelu: przybywa ludzi oczekujących jakości od tego co dostaje. Pojawiły się nieco zdrowsze sałatki w sieciach fast-food, nabiera wartości na rynku dobre rękodzieło, nawet piwo z regionalnych browarów (droższe nie raz dwukrotnie od produkowanego masowo) dało się we znaki gigantom browarnictwa (każdy ma ambicję na piwo niepasteryzowane itp.) odbierając im część rynku. Oby tylko to światełko nie pozostałą niszą...
Nie jestem wrogiem Agile, jestem zwolennikiem innego autorytetu: Yourdona, który napisał w swojej książce o modelowaniu UML: bez planów można z marszu zbudować z desek np. budę dla psa bo jest mało skomplikowana i ogarnia ją wyobraźnia przeciętnego człowieka, ale dlaczego tak wielu ludzi próbuje tą metodą budować wielkie biurowce...Ciesze się, gdy pojawiają się polemiki z moimi artykułami, to znaczy, ze ktoś to czyta i budzą one emocje. Czytamy na pewnym blogu (który gorąco polecam jako całość):Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: ?[...] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora [...]?. A dzisiaj czytam, jak autor krytykuje praktyki Agile ? czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. (źr. Zwinna analiza ? TouK).Cóż, problem w tym, że Agile jest głównie na społecznych stronach definiowane więc nie miałem wielkiego wyboru: społeczna metodyka to i społeczna wiedza o niej.... (wiem czym jest i wiki i wikipedia, nie sądzę by tu tkwił problem).
Nie raz pojawia się wątek "filozoficzny" w procesie analizy (a konkretnie w rozmowach o niej...;)). Jednym z kluczowych elementów, celem, każdej analizy jest jej efekt czyli poznanie czegoś i przekazanie tej wiedzy komuś (najczęściej zleceniodawcy tej analizy). Rzecz w tym, że liczy się to czy zleceniodawca nie tylko otrzymał wyniki analizy a także czy je sobie przyswoił...Przyjmując, że dany system pojęciowy jest kompletny (pozwala na zapisanie każdej informacji z danej dziedziny), analiza polega tu na rozłożeniu tekstu (danych) pozyskanych np. z wywiadów czy dokumentów, na skończoną liczbę pojęć i związków pomiędzy nimi. W efekcie uzyskujemy np. diagram procesu BPMN (jeżeli celem był model procesu biznesowego) lub diagram klas UML (jeżeli celem była np. analiza pojęciowa i zbudowanie taksonomii).Tu dotykamy procesu komunikacji, czyli przekazania pozyskanej wiedzy i wyników analizy innej osobie.
Koszt analizy i opracowania to ok. 20% wartości implementacji i mieści się nie raz nawet w kwocie nie wymagające przetargu (co istotnie skraca czas całości). Po drugie mając projekt, wycena implementacji nie jest już wróżeniem z fusów z narzutem 200-500% na wszelkie niewiadome (powszechna praktyka wielu firm developerskich, z bożej łaski integratorów). Zlecenie całości (analiza, projektowanie, wykonanie) jednej firmie nie raz kończy się tak:Wykonawca został wybrany w trybie zamówienia z wolnej ręki, ze względu na ochronę praw wyłącznych firmy Sygnity SA. Wykonawca został wybrany zgodnie z prawem polskim, natomiast zastrzeżenia Komisji wynikają z faktu, że w owym czasie polskie prawo nie było dostosowane do unijnego
Twierdzenia, że nie da się inaczej, klienci nie wiedzą czego chcą, dokumenty tekstowe to jedyne możliwe opisy wymagań itp. są prostu nie prawdą, to usprawiedliwienia braku kompetencji albo zawyżania kosztów projektów (a raczej pokrywania braku kompetencji pieniędzmi z kieszeni klientów). Pewien znajomy, współwłaściciel pewnej firmy programistycznej, napisał mi niedawno: "korzyści z takiego dokumentowania wymagań są ogromne. Wykonawca, który potrafi pracować na modelach ma 2-3 krotnie niższe koszty i 1,5-4 krotnie krótszy czas wykonania. AMEN TO THIS:)" A co on miał na myśli?
Tak więc analiza wymagań to jest praca wykonana by opisać czego oczekujemy i dokonać wyboru. Analiza przedwdrożeniowa to praca wykonywana przez dostawcę, którego wybrano, w celu opracowania specyfikacji prac jakie należy wykonać by wdrożyć dany produkt. Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a także nie raz stanowią zbędne ograniczenia. Użycie takiego modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne: wystarczy go rozesłać do dostawców i zapytać po pierwsze czy ich system pasuje do niego, jeżeli tak to ile kosztuje ten produkt rok po roku. Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens (co nie raz zdają się podważać dostawcy) a dostawca musi zdeklarować, że jego produkt pasuje do modelu.
Wiele firm programistycznych ma etatowych, tak zwanych analityków wymagań, jednak oni z reguły nadal nie są projektantami. Raczej zapisują, w z góry ustalony sposób, to co mówi Zamawiający (z reguły zresztą bez pełnego zrozumienia co powiedziano). Bywa, że projektanta lub programistę wysyła się w roli analityka. To też nie działa z tych samych powodów komunikacyjnych, co potwierdza praktyka.Czy wykonawca może mieć dobrego analityka projektanta? Może mieć, niejeden nawet ma ale... z jakiegoś powodu uznano, w znacznie starszej niż inżynieria oprogramowania, branży budowlanej, że Wykonawca nie powinien być autorem tego co należy wykonać dla Zamawiającego. Zamawiający także nie powinien być projektantem. Dlaczego? Każda firma (jej Prezes) dąży do maksymalizacji swojego zysku (tu rentowności naszego projektu), interesy Zamawiającego i Wykonawcy są więc sprzeczne dlatego wymagana jest trzecia rola: niezależny projektant. I tak własnie to wygląda w projektach budowlanych, w których architekt to osobny podmiot. Zachowuje on także prawo nadzoru autorskiego nad realizacją swojego projektu by także na etapie realizacji panować nad nim. W trakcie realizacji nadal interesy Zamawiającego i Wykonawcy sprzeczne - Zamawiający maksymalizuje funkcjonalność czyli forsuje wzrost kosztów to zaś niszczy zysk Wykonawcy, który stara się tę funkcjonalność minimalizować.
Moda na procesy, zarządzanie zorientowane procesowo, outsourcing procesów biznesowych itp. to nie moda. Moim zdaniem to kolejny etap zrozumienia tego co się wokoło nas dzieje bo w sadzie nie ma procesu procesowego. W sądzie ma miejsce proces dochodzenia do poznania prawdy i wydania sprawiedliwego sądu.
Wychodzenie z kryzysu, które stało się faktem także w naszej gospodarce, stwarza nowe szanse rozwoju. Także dla firm informatycznych. Jednak recesja wyedukowała menedżerów. Oni już nie chcą kupować komputerów, Oni oczekują biznesowego wsparcia. Jeszcze niedawno kupowane były komputery i programy. Można było nie raz przeczytać o dużych kontraktach wdrożeniowych, niestety nie wiele mniej razy można było przeczytać o porażkach tych wdrożeń. Wiele z nich to były i nie raz nadal są wdrożenia o przekroczonym budżecie a nawet wdrożenia nieukończone. Nikt nie wie ile z tych systemów w ogóle się zwróciło.
