niedziela, 30 września 2012

Mobilizacja 2012 jako przykład samoorganizacji

Miłe słowa i podziękowania

Na początek trochę miodu. Jeszcze raz chciałbym podziękować wszystkim, którzy przybyli na konferencję za to, że stali się częścią tego fantastycznego wydarzenia. Wydarzenia, który przynajmniej od strony informatycznej ożywia to trochę senne miasto jakim jest Łódź.

Gdy rok temu Marek Defeciński i Mariusz Saramak rzucili pomysł aby zrobić w naszym mieście konferencję pokroju dawnej Javarsovii wszyscy na około raczej przejawiali nastawienie w stylu - "chyba was pojebało". W trakcie pierwszej edycji zawitało na mobilizację około 150 osób ale to wystarczyło aby ludzie zaczęli wierzyć w powodzenie tego z pozoru szalonego przedsięwzięcia :). Tym razem gościliśmy prawie 500 słuchaczy i możemy śmiało mówić, że mobilizacja jest jednym z największych wydarzeń kulturalnych w Łodzi i jednym z ciekawszych wydarzeń IT w Polsce.

Samoorganizacja

W opisach konferencji w tym miejscu zazwyczaj następuje lista notek z poszczególnych prezentacji. Jednak dziś skupię się na innym fascynującym temacie - samoorganizacji organizatorów w trakcie organizacji konferencji :) Nie było żadnych gantów, żadnych menadżerów, czy rozliczania tasków. Były za to cotygodniowe siedzące stand-upy w makdonaldzie, ciągła i równoprawna dyskusja na grupie oraz grupowe współtworzenie rozproszonych dokumentów na google docs.

O samoorganizacji można pisać i pisać - powstają pewnie także całe książki na ten temat. Dlatego dzisiaj zerknijmy tylko na dwie ciekawe koncepcje.

Variety (Różnorodność)

http://en.wikipedia.org/wiki/Variety_(cybernetics)

Link powyżej koncentruje się co prawda bardziej na stabilności danego systemu aniżeli stanach wyjściowych ale idea generalnie jest taka - traktujemy zespół jako system i im więcej ten system ma stanów tym więcej możliwych wyników generuje. Wynikami w tym przypadku są decyzje i pomysły. Jeśli więc w zespole będziemy mieli tylko absolwentów informatyki około 25 lat, gdzie każdy gra po godzinach w sapera i doczytuje książki o Javie to możemy liczyć na limitowany zestaw stanów.

Z drugiej strony zmieszajmy w tyglu ekstrawertyzm z domieszka introwertyzmu, trochę nieobliczalności z rezerwą oraz doświadczenie ze świeżym spojrzeniem. Dostaniemy całe spektrum pomysłów, z których oczywiście część będzie zjebana ale inne takie jak wojskowa grochówka na obiad, mundury dla załogi czy "kontakt z bazą" spotka się z miłym przyjęciem (przynajmniej tak ludzie mówili :))

Darkness principle

Each element in the system is ignorant of the behavior of the system as a whole [...] If each element ‘knew’ what was happening to the system as a whole, all of the complexity would have to be present in that element

Uwzględniając to prawo zgadzamy się z tym, że gdyby jedna osoba chciała wszystkim zarządzać to musiałaby ogarnąć cały system, ogarnąć cały problem bez żadnych uproszczeń (każde uproszczenie generuje ryzyko pomyłki). Z drugiej strony dzieląc problem na wszystkich uczestników zespołu sprawiamy, że każdy koncentruje się na części modelu co znacznie redukuje złożoność samego problemu.

Logika podpowiada, że potrzebna jest jakaś synchronizacja wysiłków, informacji i sub-domen problemu. Ktoś mógłby napisać, że tutaj pojawia się rola dla kogoś w stylu project managera. Niekoniecznie. Okazało się, że "ciałem zarządzającym złożonością całego problemu" był sam zespół. Spotkania w Maku i wymiana informacji na grupach wystarczyły

Czekając na mobilization 2013

Mobilizacja jest wciąż młodą konferencją i każda pomoc się przyda. Jeśli drogi czytelniku byłeś na konferencji, podobała ci się ona i prowadzisz jakąś formę bloga - podziel się swoją opinią. Do zobaczenia (oby ;)) w 2013

czwartek, 6 września 2012

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.