Management 3.0 w metaforze turystycznej

For every complex problem there is an answer that is clear, simple, and wrong.

H.L. Mencken, journalist, writer (1880–1956)

Gdyby dwa lata temu ktoś powiedział mi, że napiszę dzisiejszy tekst, to najprawdopodobniej odpowiedziałbym mu gromkim śmiechem (albo rozjebał butelkę na głowie bo wtedy dosyć dużo piłem). Otóż dwa lata temu, po kilkuletnim obcowaniu z upośledzonymi firmami jadącymi mieszanką wodospado-biurokracji, wszystko co kojarzyło mi się z Metodykami Zwinnymi było niczym głos mędrca w ciemności, śpiew skowronka po koncercie ich troje czy zapach oazy wśród pustynnych piasków. Dwa lata później okazało się, że korporacja jest w stanie zjebać nawet i to :(. Ale od początku...

Na początku był debilizm

Z czytanek, które w ostatnich latach przeleciały mi przez ręce wnioskuję, że wszystko zaczęło się w XIX wieku, kiedy to masa analfabetów pozbawionych zdolności analitycznych przyjechała za chlebem do wielkich miejskich fabryk. Poprzednie zdanie nie ma na celu deprecjacji czy ośmieszania grup społecznych ale proste stwierdzenie faktu. Czego by nie mówić o dzisiejszym szkolnictwie to 150 lat temu sytuacja była o wiele tragiczniejsza. Właściciele fabryk (czy też ktoś z ich otoczenia)zauważyli, iż owi szeregowi pracownicy nie kwapią się zbytnio do optymalizowania procesu wytwórczego (wtedy jeszcze nauka nie odkryła, że napierdalanie przy taśmie po 15 godzin 7 dni w tygodniu nie sprzyja auto-motywacji). Dlatego też cały proces był nadzorowany przez inżynierów (TAK TAK! Inżynierów a nie managerów!) . Później pojawia się Tayloryzm z całym gównem w tle, procesy stają się coraz bardziej skomplikowane i pojawia się potrzeba kogoś kto jest w stanie nadzorować nie tylko pracę przy maszynach ale abstrakcyjne procesy tworzone na papierze - tak rodzi się "management". W międzyczasie wszyscy na około zaczynają się napie*dalać co przyśpiesza rozwój maszyn liczących...

Później był trochę inny debilizm

Wielu pseudo-geniuszy na forach internetowych powie wam, że programista jest jak murarz. Powinien siedzieć cicho i skromnie napie*dalać co mu architekt przyśle (Tym panom oczywiście dedykujemy nowo niepowstały odcinek autostrady A2). Generalnie tak samo pomyśleli sobie pewni ludzie w połowie poprzedniego wieku. Jeśli jeden zasób typu programista tworzy dziennie 5000 linii to dwóch chyba stworzy 10000 no nie?! To teraz tylko oszacujmy ile linii ma dana funkcjonalności, ile mamy (kurwa) zasobów ludzkich, podzielmy i wio. Czas na metaforę! Zerknijmy dlaczego poniższy obrazek jest bez sensu.

Powiem wam dlaczego jest bez sensu (w kontekście naszej metafory) . Byłem w tamtym miejscu niecałe dwa tygodnie temu i ani po 3 godzinach ani do tej pory do Chęcin nie doszedłem... W ogóle co to jest to 2h 50? Szybkość z jaką przejdzie dziecko, dorosły czy emeryt? Poszukałem na necie i jest jakiś sztywny algorytm liczenia tych czasów, ale przy okazji znalazłem takie oto opinie :

" Fakt, ze czasy na drogowskazach po polskiej stronie Tatr sa chyba podawane dla emerytow niosacych 30kg plecaki i robiacych co 100m przerwy na podziwianie widoków :D "

" Inna sprawa, że już od dawna nie sugeruję siê czasami z przewodników czy drogowskazów, bo z nabytego doświadczenia dość łatwo przychodzi mi oszacowanie czy dana trasa jest możliwa (w normalnym tempie) do przejścia w ciągu dnia czy nie. "

Teraz jak to wszystko ma się do IT? Otóż niestety do tej pory istnieją firmy gdzie panuje tzw. Filozofia "Command and control". W tychże firmach tzw. Architekci i Managerowie szacują ile co ma trwać a później zrzucają na daną funkcjonalność ze spadochronem developerów. No niestety. Drogowskaz (architekt) mówił 2,5 godziny a tu się niestety okazało, że po pierwsze to ów developer za cholerę nie pokonuje odcinków drogi w obliczonym czasie to jeszcze zerwała się burza, trzeba było zmienić szlak i wracać do schroniska. Eh gdyby ci turyści byli jak murarze to wszystko by działało zajebiście...

Debilizm 2.0

Teraz zerknijmy na inny obrazek

Powyższe drogowskazy i wtedy i w tej chwili są w zasadzie poprawne. Bez względu na to jak szybko idę, jaka jest pogoda, co jadłem na śniadanie, jaki mam humor i co było wczoraj w telewizji to odległość z miejsca na obrazku do rezerwatu białogon wynosi około 4,4 km. Koncepcja z pozoru jest super zajebista. Mamy jakąś miarę odległości i teraz od indywidualnego przypadku zależy jak szybko zostanie ta odległość pokonana. Dla nieuważnych jest to nawiązanie do koncepcji prędkości ("velocity") w metodykach zwinnych.

Widzimy tutaj zdecydowany postęp - nie strzelamy już z dupy, że coś będzie skończone według jakichś dziwnych uśrednień i wróżb ale staramy się na podstawie obserwacji stwierdzić jaka jest prędkość developera i wtedy już faktycznie oszacować kiedy przejdzie on daną ilość kilometrów. A ponieważ w projektach IT nie ma kilometrów to używamy punktów funkcyjnych zaś "odległości" są mierzone przez jedynych ludzi, którzy wiedzą po czym stąpają czyli przez zespół. I właśnie 2 lata temu ta teoria wydawała się logiczna, zupełna i całkowita. Dzisiaj zaś...

Wyobraźmy sobie, że liczymy ile jako turysta jestem w stanie pokonać kilometrów w przeciągu dwóch tygodni (jeden sprint). Pierwszego dnia wyszedłem na świeżo, była ładna pogoda to pyknąłem około 20 km, następnego dnia pojawiły się odciski to już tylko 15 , trzeciego dnia musiałem ograniczyć się do wycieczki po mieście. Teraz teoria mówi, że pomimo tych różnic jeśli weźmie się kilka takich odcinków dwutygodniowych to jakoś auto-magicznie wszystko się ustabilizuje. Teraz jednak zamieńmy naszego turystę w turysto-komandosa (co bardziej przypomina realizm projektów IT), który jest co chwila rzucany po całym świecie. W trakcie pierwszego sprintu udało się przejść 150 kilometrów , i teraz nasz komandos jest przerzucony w tatry. Tutaj wspomniane 4,4 km niestety pokonuje się w 3 razy dłuższym czasie bo po skałach. Po dwóch tygodniach wracamy w góry świętokrzyskie.Ale tutaj widzimy, że zerwała się burza i w głębokim błocie wcześniej znany odcinek pokonaliśmy w 2 razy dłuższym czasie.

Oczywiście można dalej mnożyć przykłady jak nasz turystyczny komandos został wysłany Himalaje i nawet z samolotu (planning) odcinek wydawał się być krótki ale po wylądowaniu (napierdalanie) okazało się, że nie ma tlenu (wymagań) i ogólnie trzeba czekać. Dalej dla zabawy możemy pomnożyć listę turystów przez 10 , zróżnicować ich kulturowo i dorzucić wycieczki morskie. W tym momencie zostaje nam już tylko myślenie magiczne, że wszystko nam się "jakoś uśredni".

Teraz metafora staje się coraz trudniejsza bo dochodzimy do...

Korpodebilizm

Na początek pytanie retoryczne (nie wymagające ku*wa odpowiedzi) co dzieje się gdy zespół jest oceniany na podstawie ilość procentowej pokrycia kodu? ("o ten ma 100% to są profesjonaliści", " ten tylko 50% to tacy pół spece"). Zespół oczywiście znajdzie sposób aby zmaksymalizować ową metrykę ale cały proces niewiele będzie już miał wspólnego z pierwotnym założeniem. Dla przypomnienia - jeśli tworzymy poprawne testy jednostkowe to pokrycie kodu daje nam jako taką informacje o tym czy czegoś nie przeoczyliśmy. Jeśli mamy zaś mieć 100% pokrycia to jest kilka sztuczek aby to osiągnąć - na przykład testy bez asercji.
Podobnie jeśli jesteśmy oceniani według przewidywalnej ilości linii kodu to jeśli wyjdzie nam za mało danego dnia to robimy if(false) i tutaj jest miejsce na brakujące linie. Jeśli zaś wypełnimy normę do czternastej w sposób normalny to cóż sprawdzimy co tam słychać na onecie.

Dlaczego z velocity ma być inaczej? (znowu pytanie retoryczne). Jeśli profesjonalizm naszego turysty jest oceniany według tego czy może on tak zaplanować sobie wędrówkę aby w okresie dwutygodniowym pokonywać te same odcinki to jasne, że znajdzie sposób aby coś takiego zasymulować! Najlepiej wtedy obiecać , że przejdziemy drogę od domu do monopolowego i z powrotem. Oczywiście większym "profesjonalizmem" wykaże, się zespół donoszący cyklicznie tą samą drogą węgiel ze wsi A do wsi B niż zespół który zrzucono nad dziką dżunglą w Ameryce Południowej. Niestety obserwacje to potwierdzają gdyż na własne oczy widziałem jak priorytetem staje się takie wpisanie wartości do JIRY aby wykresy przecięły się w odpowiednim miejscu...

Jeśli nie velocity to co?

Na początku duże nadzieję wiązałem ze słabo jeszcze przeze mnie poznanym kanbanem ale w ostatnich dniach w ręce wpadła mi książka, która być może będzie przełomem

"Management 3.0 = Complexity The last few decades saw the birth and rise of complexity theory, first ap- plied to mathematics and biology and later to economics and sociology. It was a major breakthrough. Stephen Hawking thought it was so important that he called the 21st century the “century of complexity.“"

"Many of us already knew that “leadership” is just a trendy name for managers doing the right thing and doing things right. But complex- ity thinking adds a new dimension to our existing vocabulary. It makes us realize that we should see our organizations as living systems, not as machines."

Książkę zacząłem dopiero czytać ale już poruszyła tematy ,które mnie zdobyły. Zobaczymy co przyniesie dalsza lektura, być może pojawią się rzeczy , które przeczą dzisiejszemu tekstowi ;) W każdym razie to co mi się podoba to to, że propaguje ona podejście kompletne, zobaczmy :

• Na początku mamy kompletnie upośledzony sposób szacowania w ogóle pomijający jakikolwiek ludzki pierwiastek w projekcie
• Później wkracza agile i zespół developerski zostaje obdarowany należną mu rangą. Szacowanie nie bierze się już z dupy ale jego zbytnie uproszczenie (zwłaszcza w środowisku korporacyjnym) może prowadzić do wypaczeń
• Rozwiązanie kompleksowe ogarniające wpływ wielu czynników z należytym naciskiem na "człowieczeństwo" ludzi wykonujących pracę

Co może wpływać na pracę?

Masa czynników! Koncepcja Velocity zakłada, że developer ( w odróżnieniu od takiego Kmicica) jest bohaterem raczej statycznym - ewentualnie wszystko jakoś samo magicznie się uśredni. Ze swojego przykładu mogę powiedzieć, że jakiś czas temu miałem okres relatywnej hiperproduktywności kiedy to udało mi się zaimplementować ładny kawałek pojebanej logiki biznesowej. Oczywiście owa hiperproduktywność nie wytworzyła się sama. Była to mieszanka wiedzy psychologicznej, którą zdobywam od 15 lat ( kotwice , praca z submodalnościami czy techniki oddechowo-medytacyjne) ale także dużą rolę odegrała suplementacja! Otóż na przełomie lutego i marca jadłem t100 od olimpu (wśród skłądników resveratrol, różaniec górski, DAA) do tego ZMA (cynk,magnez B6) co podbiło testosteron chyba do granic naturalnych możliwości. Zaowocowało to niesamowitą energią i minimalnymi skokami agresji co skutecznie pozwoliło mi realizować odmianę techniki "pomodoro" - obrony przed przeszkadzaniem ( mówimy wtedy "pomidor" albo po prostu "wypierdalaj"). Do tego od początku stycznia do końca marca nie wypiłem nawet kropli alkoholu i dorzuciłem dodatkowe antyosydanty. Mogłem generalnie rozjebać dowolną funkcjonalność.

Oczywiście to tylko mój mały wycinek rzeczywistości. Nie jest tajemnicą stwierdzenie, że każdy chce czuć siłę swojego wpływu na rzeczywistość. Co by się stało gdyby w okresie gdy napierdalałem wyżej wspomniane suple manager postawił w kuchni miskę z jabłkami? Otóż pewnie bym się poczęstował bo jabłka generalnie lubię i owy manager mógłby z całej sytuacji wyciągnąć wniosek, że zajebiście motywują mnie właśnie jabłka. W teorii złożoności (przynajmniej w moim rozumieniu) nie ma miejsca na takie deklaracje. Nie możemy powiedzieć "coś zadziałało", poprawnym stwierdzeniem jest "po dodaniu jednego elementu cały skomplikowany kompleks oddziaływań zachował się tak a tak"

Jak skończę czytać książkę napiszę coś więcej