Teoria a praktyka

Autor: Konrad, Opublikowano: 21/12/2009

Ostatnio sporo czau poświęcam na poszerzanie swojego horyzontu postrzegania zagadnień związanych z programowaniem. Oprócz poznawania kolejnych języków (Java, Python i inne) przyglądam się wytwarzaniu różnego typu oprogramowania w różnych warunkach. Z racji, że sięgam zarówno po źródła naukowe i stworzone przez praktyków, widzę rosnący kontrast pomiędzy tymi rzeczywistościami. Przyznam, że co jakiś czas pojawiają się osoby łączące te dwie drogi, ale przeważają rozmyślania rozwijające dziedziny nie zweryfikowane – czy to w formie badań naukowych, czy komercyjnych projektów. Dużo osób teoretyzuje zamiast szukać kompromisu. Wieżą, że skoro model, który stosują (w większości przypadków) sprawdza się, to model będący rozwinięciem ich wiedzy i przeczuć, też będzie się sprawdzał. Narzucają swoją wizję, zamiast znaleźć partnera z drugiej strony i wspólnie przetestować pomysły. Każda ze stron ma coś cennego do zaproponowania, ale również zbyt wielkie zadufanie związane ze swoimi osiągnięciami. Gdy dorzucę trzecią grupę, o której większość nie myśli, a od której wszystko zależy, powinno stać się jasne dlaczego obecny stan jest nieciekawy. Tą grupą są inwestorzy – zarówno inwestujący swój czas, jak i pieniądze. Inwestorami jesteśmy również my – programiści. Rozwijamy się aby realizować coraz bardziej złożone zadania i decydujemy się na korzystanie z określonych technologii. Technologia, za którą stoją zwolennicy ma większa siłę głosu i zwracania uwagi inwestorów z kapitałem. Przekłada się to na pracę, lepsze narzędzia, ciekawe projekty, itd. Gdy technologia nas zawiedzie, bo jej kolejny krok oparty o wiedzę i przeczucie, okaże się (choćby zaledwie) nie tyle skuteczny co rozwiązania już wykorzystywane, następuje zniechęcenie i różnica między oczekiwaniami a rzeczywistością. Różnica ta przekłada się na kapitał stojący za technologią. Spróbuje to lepiej zobrazować. Obecnie sytuacja wygląda tak (pozwolę sobie pominąć szeroko rozumianych monopolistów i użyć porównania do dwóch kostek): technologie powinny mieć za sobą mocny stały kapitał i tym samym niewielkie wahania w kapitale dodatkowym. Czyli kostkę kapitału stałego oraz kostkę wahań. Powinniśmy doprowadzić do sytuacji, gdy rzucamy pierwszą kostką tylko wtedy, gdy wiemy, że przyniesie to wzrost wartości wylosowanej - zwłaszcza w sytuacji, kiedy nie możemy przewidywać kolejnych okazji do rzutu. Drugą kostką wykonywane są rzuty niezależnie od naszej woli i zazwyczaj przynoszą efekt przeciwny do naszych oczekiwań – można ją nazwać kostką hazardzisty. Większość osób widzi tylko sumę oczek z dwóch kostek – nie widzi podziału. Inwestorzy (z kapitałem) widzą natomiast dwie. Dla branży IT często na pierwszej kostce jest niska wartość, a na drugiej częsta zmiana. Tym trudniej jest zdecydować się na inwestycję, gdyż rzuty są nieprzewidywalne. Wprowadzenie dialogu pozwoli doprowadzić do sytuacji, gdzie będziemy mogli pierwszą kostkę zastąpić kilkoma. Jedną rzucać i samemu ustawiać wynik na pozostałych. Ile sprawnych kompromisów tyle dodatkowych kostek. Oczywiście kostki mają taką samą ilość ścian. Tym samym zmniejsza się znaczenie kostki hazardu.

Obrazując:

kostki kapitału stałego: maksimum (pełne porozumienie), 3/4 maksimum, 5/6 maksimum, losowa wartość;

kostka wahań: wartość losowa;

Jak to się ma w skali mikro – czyli nas programistów. Im lepszy dialog, tym mniejsze rozczarowanie, że rozwiązanie, które poznawaliśmy przez n-lat zablokuje nasz rozwój na kolejne lata. Najgorszy scenariusz, że po prostu umrze zastąpione przez inne. Mniejszy codzienny, że obiecując wykonanie zadania, nie będziemy siedzieć po godzinach zwalczając niespodziewane ficzery. Mając gwarancję dialogu, mamy pewność, że jakiekolwiek powstaną zagrożenia, nasz język i my sami im sprostamy – będzie się rozwijał z naukowym pomysłem i miał uzasadnienie powody biznesowe do użycia.  Wybór (np.) języka nie będzie niósł za sobą ryzyka, a możliwość dostosowania narzędzi pod własne preferencje. Na koniec, tak do przemyślenia, chciałbym trochę uciec od języka do szerszego ujęcia. Chciałbym, aby każdy porównał otaczającą go rzeczywistość z tą teoretyczną (przykład poniżej). Czy w Twoim środowisku tłumaczone są różnice. Wiesz z czego wynikają? Co jest ich konsekwencją? Zachęcam do przemyślenia i dzielenia się własnymi przemyśleniami z innymi – to jedyna droga abyśmy pracowali w warunkach o jakich marzymy.

Role i skład zespołu projektowego:

Kierownik projektu
Kierownik projektu jest osobą, która czuwa nad całością projektu, a jej najważniejszym zdaniem jest organizowanie i kontrolowanie pracy zespołu, kontaktowanie się z klientem oraz sprawdzanie czy „wszystko idzie dobrze”.

Analityk
Głównym zadaniem analityka jest zbudowanie modelu analitycznego (konceptualnego) systemu. W tym celu musi on stale kontaktować się z klientem, dla którego budowane jest oprogramowanie oraz dobrze zrozumieć jego potrzeby i orientować się w dziedzinie problemowej, której dotyczy system. Z całą pewnością nie jest to zadanie łatwe i oprócz rozległej wiedzy wymaga odpowiedniego doświadczenia i umiejętności pracy z ludźmi. Dobrze wykonany model analityczny ma kluczowe znaczenie dla powodzenia całego projektu. Błędy popełnione na tym etapie są później trudne do usunięcia i zazwyczaj bardzo kosztowne.

Projektant
Zadaniem projektanta jest zbudowanie projektu systemu. Projekt systemu jest kolejnym modelem systemu, ale na innym poziomie szczegółowości niż projekt wykonany przez analityka. Zawiera on bowiem informacje o szczegółach implementacyjnych systemu. Projektant musi wobec tego mieć odpowiednią wiedzę na temat systemu na którym będzie implementowana aplikacja i narzędzi, które zostaną wykorzystane do jej budowy.

Programista
Zadaniem programisty jest zakodowanie projektu opracowanego przez projektanta.

Tester
Zadaniem testera jest przeprowadzenie różnorodnych testów aplikacji zanim trafi ona do klienta.

Wdrożeniowiec
Wdrożeniowiec jest osobą, która przeprowadza uruchomienie (wdrożenie) aplikacji u klienta. Powinien on również umieć przeszkolić użytkownika w użytkowaniu produktu, a często jest też twórcą dokumentacji dla użytkownika.

Akademickie Podręczniki Multimedialne – Bazy Danych, Włodzimierz Dąbrowski, Paweł Potasiński, Wydanie B, Warszawa 2004.

Bolesna prawda o interim management (i nie tylko)

Autor: Konrad, Opublikowano: 18/10/2009

Odnalazłem taki ciekawy fragment dyskusji na jednym z forów, którego jestem członkiem. Pozwolę sobie nie podawać nazwisk, gdyż wolę nie naruszać prywatności przytoczonych osób:

[...]

Zbigniew B:
I to jest sedno sprawy. Interim ma bardzo konkretne cele do zrealizowania. Faktycznie za to mu płacą i tylko pozornie więcej.

Andrzej P:
Ciekawe jest to „pozornie wiecej”. Istnieje prosta regula wyliczania mozliwych kosztow interima. Zaklada sie ogolnie ze, top manager „generuje” dla firmy 3 razy wiecej niz zarabia. Zakladajac, ze top manager zarabia 120.000, to generuje 360.000.
Jak „brakuje” top managera przez 3 miesiace, to „straty” dla firmy wynosza 90.000. Czyli zatrudnienie interima na 3 miesiace, za kazda sume ponizej 90.000 powoduje, ze firma nie ponosi strat, a czesto zyskuje.

[...]

Niestety mało firm ma świadomość takich zależności. Nie tylko w kategorii Interim management. Ten sam problem tyczy się wielu zawodów (również programistów – zarówno freelancerów jak i pracujących na etat). Z jednej strony zbyt mocne przywiązanie do ciasnej wizji stanowiska. Blokuje ono z góry możliwość zatrudnienia osób, które  nie mieszczą się w budżecie, a przyniosłyby nieporównywalnie większe zyski. Nie pomaga nawet udokumentowanie wyników czy poparcie prostą matematyką. Z drugiej strony realizując projekty z użyciem freelancerów zapomina się, że nie są oni częścią firmy. Ich sposób pracy wiąże się z ryzykiem po dwóch stronach. Ryzyko to przekłada się na cenę. Firmy niestety nie patrzą przez pryzmat prowizji od dostępu do specjalisty, lecz oczekują zysku porównywalnego do tego generowanego przez pracownika na etacie. Tym samym generują zwyrodnienie na rynku – gdzie zatrudniają najtańszych, realizujących jak najprościej projekty. Wykraczając kompetencjami poza przestrzeń banału trafia się na pustynię. Perspektywy są dwie: stworzyć coś na tej pustyni przy olbrzymim ryzyku, albo wpisać się w masę niedocenianych specjalistów pracujących za niewspółmierne wynagrodzenie.

Bolesne jest również przymykanie oczu na łamanie praw autorskich. Te same firmy potrafią krzyczeć gdy dzieje się im krzywda, a gdy sięgają, z pełną swiadmością, po produkty wykonane z naruszeniem praw autorskich, nie odezwą się ani słowem. Coraz bardziej doceniam zagadnienia, które stawiają próg do pokonania, by zacząć z nich kozystać (np. środowiska płatne, antypirackie). Mam nadzieję, że im większa świadomość wspomnianych zagadnień w społeczeństwie, tym większa będzie chęć do zmiany wspiomnianego stanu przez masy – by w końcu rzeczywiście zmienił się w firmach, w których pracujemy, i które zakładamy.