Filozoficzny model projektu

Metafory i modele

Metafory są zjebane - zwłaszcza wtedy kiedy nie są pomocne. Wystarczy znaleźć jedno malutkie podobieństwo pomiędzy diametralnie różnymi sytuacjami by zacząć dowodzić dowolnej głupoty. Można sobie zrobić z programistów murarzy bo i tu i tam pojawia się słówko "architekt". Albo coś lepszego : projekt to ciąg pewnych decyzji i szachy to ciąg pewnych decyzji - więc w projekcie czasem warto poświęcić "pionki" by chronić króla. Kiedyś chyba zorganizuję nawet konkurs na najbardziej debilną metaforę IT

Co innego modele! Model z założenia nie jest prawdą. Specjalnie wszedłem na wikipedię aby upewnić się, że używam odpowiedniego słowa i odebrać oręż potencjalnym trolom. Mamy taki oto cytat : "system założeń, pojęć i zależności między nimi pozwalający opisać (zamodelować) w przybliżony sposób jakiś aspekt rzeczywistości" . (co prawda inne znaczenie to "wieś w województwie mazowieckim") . Tworząc model wcale nie twierdzę, że coś jest takie a nie inne, nie rzucam dogmatów wyrażających złote prawa prowadzenia projektów ( z cyklu : "jest powszechnie wiadome, że ...") czy też nie udaję, że moje zdolność telepatyczne rozwinęły się na tyle, że mogę ogarnąć psychikę całej populacji ( "wszyscy wiedzą, że ..."). Model jest uproszczeniem. Model nie jest prawdą. Ale może pomóc dostrzec pewne reguły kiedy odfiltrujemy szum.

Dawno dawno temu - podstawy modelu

Filozofia do stworzenia podstaw naszego modelu pochodzi od pana z obrazku obok - owy dziadu to Arystoteles. Zanim jeszcze Grecy przestawili się na biznes turystyczny i każde cięcia budżetowe witali falangą najebanych restauratorów, Arystoteles miał ciekawą myśl :

• Wszystko jest złożone z tzw. Substancji
• Substancja jest w ciągłym Ruchu
• Substancja osiąga kombinacje form posiadających Stan Aktualny i Potencjał

I na przykład weźmy takie drewno jako substancję. Drewno ma pewne potencjalne stany - może być np. stołem albo laską. Ale kiedy już osiągnie stan laski to już wśród jego potencjału nie ma stanu stołu. Jednak dla odmiany Szkło może być lampą lub butelką - i gdy osiągnie jeden ze stanów to teoretycznie drugi z nich jest cały czas dostępny ale będzie to wymagało większego ruchu.

I teraz czas na IT.

• Wszystko jest złożone z substancji zwanej Kodem
• Kod jest w ciągłym ruchu powodowanym przez Motywację programistów
• Kod osiąga kombinację form przynoszących Aktualną Mamonę i Potencjalną Mamonę

Energetyczny graf przejścia stanów

Wspomniana MAMONA będzie formą energii jakiej użyjemy do umotywowania ruchu po grafie stanów projektu. Jednostka mamony to $

Zaczynamy nasz projekt w węźle 1 i założenie jest takie, że im większy węzeł tym większa wartość aktualnej Mamony . Jeśli skupimy się tylko na tym czynniku to idziemy do dwójki i mamy więcej aktualnej mamony niż w trójce. Ale teraz pojawia się problem bo z dwójki możemy już iść tylko do szóstki czyli potencjalna Mamony już tak atrakcyjnie nie wygląda. Najlepiej byłoby trafić do 6 i "nabrać" sporo aktualnej mamony.

Owe tajemnicze strzałki na grafie symbolizują sumę decyzji o architekturze, funkcjonalności, morale teamu i jakości papieru toaletowego czyli wszelakie moce sprawcze, które sprawiają, że projekt jest w takim a nie innym stanie. No i czasem zdarza się tak, że nasza substancja czyli KOD tak sprawnie porusza się po grafie i zmienia stan tak umiejętnie, że projekt osiąga najwartościowszy węzeł.

Pomyślmy co takiego dokładnie powoduje Ruch? No niby napisałem, że motywacja developerów ale i ta wielkość jest wynikiem działania różnych czynników : pieniądze, pizza, uznanie,szacunek, karabin maszynowy MG 42. Czas ubrać to w odpowiednie abstrakcje.

Dwie mityczne siły

Wyobraźmy sobie, że na naszą substancję działają dwie niesamowite siły.


SIŁA AKTUALNOŚCI

Ta siła ciągnie do jak najszybszej przemiany mamony w wartość aktualną.

Niebezpieczeństwo : zamykamy przed sobą bardzo zyskowne stany aplikacji.

Przykład : "Teraz zakodujmy jak najwięcej, będzie sukces to testy dopiszemy później"

SIŁA POTENCJAŁU

Ta siła ciągnie do osiągnięcia jak największej liczby możliwych przemian stanu

Niebezpieczeństwo : Nie osiągamy wartości aktualnej.

Przykład : "Zróbmy piętnaście warstw abstrakcji tak na wypadek gdyby w przyszłości ktoś miał podłączyć się pegasusem do naszej aplikacji"

Lepszy Przykład : "ej przepiszmy wszystko na Grailsy"

Przemyślenia jakie powstają po analizie tych dwóch przykładów, mogą doprowadzić do wniosku, że owe dwie siły muszą jakoś sobie przeciwdziałać, tak aby docelowo doprowadzić projekt do najlepszego stanu.

To dlaczego się ku*wa nie udaje?

Asymetria sił - czyli dlaczego projekty się nie udają

To był upalny czerwcowy dzień. Roman podjechał swoim najnowszym Audi A6 na zarezerwowane miejsce parkingowe. W głębi duszy cieszył się, że zajmuje pozycje jaką zajmuje. Inaczej musiałby krążyć po okolicznych trawnikach i kamienicach w poszukiwania pustego skrawka dla swojego samochodu. Rozejrzał się dookoła przyciskając guzik automatycznego pilota. Jego wzrok raz za razem przeskakiwał z opuszczających najnowsze modele sportowych samochodów sylwetek ludzi. Każdy z nich był w pewien sposób podobny do Romana. To oni stanowili o sile tej firmy, to oni każdego dnia zamieniali dzięki swym niezwykłym umiejętnościom idee w zyski, to oni cieszyli się niesamowitym szacunkiem za swoje dokonania. Podobnie jak Roman - wszyscy byli Inżynierami.

Roman nie mógł się doczekać aż zasiądzie do klawiatury i zakończy kolejny fascynujący moduł systemu. Jeszcze pozostała mu tylko jedna sprawa do załatwienia. Musi przygotować dzisiejsze zadania dla project managerów. W głębi serca Roman czuł wielką sympatię do tych ludzi, gdyby nie oni musiałby spędzać cenne godziny swojego czasu na dopracowywaniu detali projektowych. Współczucie pogłębiła jeszcze myśl, że ludzie ci nie cieszyli się takim statusem jak Roman - jak ich nazywał HR? - chyba "zasobami" czy coś takiego. Cóż każdy musi jakoś zacząć, jeśli będą się starać i wykażą umiejętność analitycznego myślenia - być może wtedy będą mogli pokusić się o awans na stanowisko inżyniera i kto wie - może kiedyś będą mieli swoje miejsce na parkingu...

Asymetria sił - czyli dlaczego projekty się nie udają - powrót do rzeczywistości

Powyższe akapity wydają się fantastyką? Być może gdyby ewolucja poszła innymi drogami tak by wyglądał nasz świat ale jednak (podobno) kiedyś biegaliśmy po drzewach i jedliśmy banany. Przez eony ewoluowaliśmy w otoczce struktury hierarchicznej aż parenaście tysięcy lat temu modne stało się "okazywanie" braku potrzeby pracy (Teoria klasy próżniaczej). Nic dziwnego, że wydaje nam się że "tak po prostu jest".

A co gdyby jednak obydwie siły z naszego modelu współpracowały? Co gdyby wzorzec "Command-and-control" zastąpić wzorcem "wzajemne zaufanie i szacunek"? Czy tak trudno wyobrazić sobie, że synergia (bardzo ładne słowo) warstwy technicznej i biznesowej może nas doprowadzić do osiągnięcia wymarzonego stanu ogromnej mamony? Wiele osób bez mrugnięcia okiem podkreśla jak to programiści nie radzą sobie "biznesowo" ale ze względu na istniejącą asymetrię niewiele osób ma odwagę krzyknąć, że tzw "biznes" nie ma pojęcia (takiego prawdziwego pojęcia) o tworzeniu systemów informatycznych! Jeśli czyta to programista to wiedz, że twoją rolą jest obrona jakości technicznej projektu. Ludzie, którzy zostali sztucznie postawieni ponad tobą w hierarchii firmowej najczęściej (bo nie zawsze) nie mieli okazji nabyć odpowiedniej wiedzy aby się tym zająć. Umiesz liczyć - licz na siebie i zespół. No i żeby nie było niejasności. Wszystkie te zdania i słowa wyobraź sobie w kontekście jak najbardziej szczerej współpracy.

Współpraca - bardzo ładne słowo - ale czy istnieją jakieś prawa i zasady tej współpracy? Za rogiem czai się bardzo ciekawy temat, coś czego jeszcze chyba nie było. Ostatnie lata minęły (przynajmniej dla mnie) pod znakiem pojedynku Agile vs. Wodospad. Wodospad jest dobry dla procesów w fabryce drobiu zaś Agile sprawdza się najlepiej dla grupy doświadczonych developerów z 30 letnim stażem. Czy jest trzecia droga? Niech to będzie przedsmakiem : http://en.wikipedia.org/wiki/Complex_adaptive_system

A ponieważ nie znalazłem fajnego obrazka przedstawiającego wizualizację koncepcji teorii systemów dlatego na koniec wklejam zdjęcie kota popierdalającego przez galaktykę na keybordzie.