Wiedza odpływa z organizacji

Nie wiem, czy kryzys rzeczywiście był, czy go nie było, ale widzę skutki plotek o kryzysie. Departamenty IT dostały bana na zwiększanie kosztów stałych, czyli na zatrudnianie programistów. Backlog rzadko kiedy się skurczył, więc aby sprostać wymaganiom biznesu zastosowano najbardziej narzucające się rozwiązanie outsourcing.

Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.

Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:

• Konsultanci wykonują większość prac programistycznych
• Etatowi programiści nadzorują pracę konsultantów
• Jeśli dla konsultanta przez pewien czas (np. tydzień) nie można znaleźć zajęcia to trzeba go zwrócić do puli
• Konsultanci działają na zasadzie stateless, więc jeśli znów potrzebujemy konsultanta, to dostajemy nie poprzednio zwróconego, lecz pierwszego wolnego

W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:

• przyuczaniu konsultantów i nadzorowaniu ich pracy
• routowaniu maili między biznesem a konsultantami i ew. zewnętrznymi podwykonawcami
• przygotowywaniu dokumentacji wynikającej z procedur organizacyjnych, których początki są tak stare, że chyba już skamieniały
• analizowaniu logów systemowych, gdy coś się wywali

Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.

Utrzymujący się taki stan rzeczy ma następujące skutki:

• Konkretna wiedza systemie, jego architekturze, problemach w kodzie migruje od programistów etatowych do konsultantów
• Rotacja konsultantów sprawia, że wiedza techniczna w ogóle odpływa z organizacji
• Nikt nie jest odpowiedzialny za rozwój architektury, która zaczyna dryfować
• Dla podkreślenia: nie, etatowi programiści nie zajmują się architekturą (choćby nawet takie były początkowe ustalenia) bo niby co to oznacza? rysowanie umli? etatowi programiści zajmują się organizowaniem zajęcia dla konsultantów
• Jakość kodu zaczyna się dramatycznie obniżać
• Dryfowanie architektury sprawia, że z każdą funkcjonalnością coraz trudniej dodawać nowe i modyfikować istniejące
• W pewnym momencie pojawia się osobliwość, czyli taki moment, w których za pomocą metod inżynierskich, architektury nie da się już naprawić; o czym pisałem trochę tutaj

Nie oddawaj core własnego biznesu

Z perspektywy organizacji, która nie jest softwarehousem takie postępowanie ma sens. Tworzenie oprogramowania nie jest core biznesu, więc spokojnie można je oddać komuś do podwykonania. Mam jednak wrażanie, że próbuje się z jednej strony mieć marchewkę i zjeść marchewkę. Z jednej strony chcemy sami tworzyć soft, aby móc go dostosowywać i być elastycznym (kolejne po "architektura") słowo-wytrych. Z drugiej strony chcemy outsourcować, aby zapłacić za to jak najmniej. Ostatecznie wydatkujemy więcej za kiepski produkt.

Przeciwdziałanie

Można przeciwdziałać odpływowi wiedzy z organizacji przestrzegając pewnych zasad. Oczywiście nie jest to tak banalne jak poniższe sformułowania. Najtrudniejsze jest przecież wdrożenie i konsekwentne trzymanie się n/w wytycznych. O następujących rzeczach warto jednak pamiętać:

• zatrudniaj konsultantów na długo i nie zwracaj ich do puli, gdy przez kilka dni nie mają nic do roboty
• dbaj, aby konsultantów było nie więcej niż etatowych programistów
• etatowi programiści pełnią tymczasowe role teamliderów w miniprojektach powoływanych na wdrożenie konkretnych funkcjonalności
• teamliderzy implementują jakąś część ticketów (tak, wiem, że kiedyś twierdziłem inaczej, ale złagodziłem nieco to zdanie
• dbaj, aby działał nazwany proces rozwoju architektury, czyli podczas dostarczania, można realizować itemy techniczne

Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)

Nowy rok, nowy Michał:)

Po głębokich przemyśleniach doszedłem do wniosku, że myśl Hanibala Albo odnajdziemy drogę albą ją zbudujemy, która dotąd była moim mottem i firmowała też poniekąd ten blog, już do mnie nie przemawia:) Teraz zaczynam kolejny etap sponsorowany przez hasło: Bądź obecny, weź to, co jest i rób to, co mówisz

Po 33rd Degree '13

Nastrój konferencji był mocno filozoficzny. Niewiele tematów technicznych za to dużo ontologicznych rozważań kim jesteśmy? dokąd zmierzamy? i po co?. Tematy konferencyjne są zazwyczaj odzwierciedleniem nastrojów w branży. Zatem skoro krążą nam po głowach takie pytania, to dobrze że temat został podjęty. Poniżej moje osobiste wrażenia z prelekcji, w których uczestniczyłem.

Decisions Decisions, Dan North

Dla mnie osobiście, to była kwintesencja tej konferencji. Po ponad 10 latach Agile przeszedł z fazy buntu przeciw istniejącemu porządkowi i odrzucania autorytetów w fazę stabilizacji i wydoroślał. Zamiast kategorycznego "nie" przeciw owym "starociom", często mówi się "nie zawsze (...)", "nie, ale (...)", "czasem (...)".

W moim odbiorze ta prelekcja była ostrzeżeniem, abyśmy nie skupiali się fanatycznie na tym czy innym podejściu lecz przede wszystkim na sprawach klientów, które należy rozwiązać. W jednym zdaniu odebrałem to tak: "nie powiem Ci czy masz używać tdd czy nie, czy us czy uc, czy pisać testy czy nie(...) wszystko zależy od tego, co chcesz zrobić, dla kogo i po co".

Busy Developer's Guide to Iconoclasm, Ted Neward

Transformational Leadership nazwany inaczej z elementami retoryki w stylu Anthonego Robbinsa. Miał być wykop na początek i był. Jednak najbardziej zapamiętałem nazwanie jednego z uczestników idiotą. Zgrzytnęło mi w głowie po raz pierwszy.

Leading Technical Change, Nathaniel Schutta

Słowo "technical" jest tu opcjonalne. Jeśli planujesz wprowadzić zmianę w organizacji, to po pierwsze musisz zbudować koalicję rzecz zmiany. Po drugie musisz nieustannie informować ludzi, co robisz, bo inaczej będą wykonywać nerwowe ruchy. Bez umiejętności interpersonalnych i small talks się nie obejdzie. Dobrze by nam zrobiło, gdybyśmy zajrzeli do całych tomów dorobku konsultingu, chociażby tutaj. Naprawdę, te rzeczy już zostały wymyślone i sprawdzone. Nie ma potrzeby wymyślać ich na nowo.

Software quality – you know it when you see it, Erik Dörnenburg

Absolutna rewalacja! Prezentacja referencyjna, sam konkret, przykłady, jasne i klarowne. Sam Erik stwierdził, że żaden z tego "rocket science". Dla mnie był. Do tej pory brakowało mi czegoś co pozwoli rzucić okiem na tony kodu, porównać ze sobą jakość kodu w modułach, projektach między zespołami. Nie żeby dawało od razu odpowiedzi, ale żeby mieć ogólne rozeznanie w jakości kodu i szybko namierzać podejrzane miejsca. Tabelki ze wskaźnikami metryk nie są dla mnie specjalnie czytelne, a przedstawione wizualizacje bardzo. Dzięki!

Pragmatic Architecture, Ted Neward

Przestawienie myśli Scotta Amblera , a przede wszystkim postulatu There is nothing special about architecture. Ciekawa była definicja architektury: architektura to zbiór odpowiedzi, na które musi odpowiedzieć sobie programista, gdy tworzy software.

W trakcie prelekcji skupiałem się przede wszystkim na formie przekazu, którą stosuje Ted, nie na treści prezentacji. Zgrzytnęło mi w głowie po raz drugi. Ted Neward buduje kontakt ze słuchaczami za pomocą metafor, historyjek i żartów opartych przede wszystkim na różnicowaniu nas (IT, programistów) od nich(ludzi biznesu), na podkreślaniu jak bardzo się różnimy od siebie i jakie absurdalne może wydawać się innym to, co robimy ("programowanie to fikcja", "normalni ludzie tak nie robią"). Różnicując się z "nimi", Ted automatycznie buduje poczucie wspólnego "my" z uczestnikami na zasadzie "też jestem taki dziwny jak wy". I to działa, ludzie to kupują i rechotają z jego żartów.

Dlaczego na to zwracam uwagę? Dlatego, że nie w ten sposób ja rozumiem Agile. Różnicowanie się od "nich" i wprowadzanie Linii Maginota "My IT-oni biznes" to nie jest to, o co moim zdaniem w Agile chodzi. To zupełnie, ale to zupełnie odwrotnie. Mamy z biznesem współpracować, wychodzić do niego, a nie się z nim różnicować i podkreślać swoją odrębność. Jeśli Ted robi to celowo, aby mieć drive na widowni, to ok, ale ja tego stylu nie kupuję. Jeśli nie robi tego celowo, to gdzieś tu...no właśnie...zgrzyta.

Managing gang of chaotic software developers is complex, Piotr Burdyło

No, jeśli to rzeczywiście tak działa, jak zostało przedstawione to szacun. Zarządzanie przez wartości, wizję i Autonomy-Mastery-Purpose w całej firmie. Super, że takie rzeczy możliwe są też nad Wisłą. Chętnie usłyszałbym o innych firmach, które tworzą u siebie organizację tego pokroju. Na następnej konferencji chętnie posłucham o problemach podczas wdrażania.

The deconstruction of architecture in times of crisis, Jarosław Pałka

Również rozwinięcie myśli Scotta Amblera wzbogacone o ideę myślenia systemowego. Wbrew deklaracjom Autora, żarty wcale nie były niskiej jakości:) Prezentację można by streścić w słowach pewnego prezesa kierowanych do dyrektorów: "Myśleć, k**a, myśleć!".

Po słowie

Dziękuję tym, którzy podarowali mi godzinę swojego czasu i przyszli na moją prezentację. W przerwie, Piotrek zwrócił mi uwagę, że w przedstawiłem DDD w zbyt wykrzywionym kontekście (dzięki!), a potem powiedział ważną rzecz: musisz dobrze opanować, te wszystkie techniczne sprawy, żeby potem móc je zostawić i pójść dalej.

Przypomniało mi to film Hero i wypowiedź jednego z bohaterów na temat czym jest mistrzostwo miecza?.

Pierwszym celem tego kunsztu jest osiągnięcie jedności człowieka z mieczem.
Gdy zjednoczenie ma miejsce, nawet źdźbło trawy może być śmiertelną bronią.
Drugi etap następuje, gdy miecz jest niesiony w sercu,gdy nie ma go w dłoni.
Wtedy można atakować przeciwnika ze 100 kroków, nawet z gołymi rękoma.
Ostatecznym celem szermierskiej sztuki...jest całkowita nieobecność miecza, zarówno w sercu, jak i w dłoni. Taki szermierz pozostaje w harmonii z resztą świata. On nie chce zabijać. On sprowadza ludziom pokój

To jest właśnie to! Core mojej prezentacji! Jakiś czas temu miałem wystąpienie dla łodzkiej JUG pt. Od kodera przez developera do lidera


Przedstawiałem między innymi nasze perspektywy patrzenia na rozwój programisty, na których opieramy swoje usługi. Między innymi o tym, że na strukturę rozwoju programisty można patrzeć jak na warstwy: technologiczna, inżynieryjna, miękka. Podobnie jak w cytacie z filmu pierwszym krokiem mistrzostwa jest mistrzostwo w języku programowania, bibliotekach, frameowkrach, technologii. Wymiatamy. Lecz jeśli zatrzymamy się na tym etapie, to w pewnym momencie będzie to tylko (jak to zgrabnie pewien prelegent mawia:)) technologiczny...zabawa...

Potem tracimy zainteresowanie gadżetami, skupiamy się na bardziej abstrakcyjnych ideach. Drugim stopniem mistrzostwa jest mistrzostwo we wzorcach, czystym kodzie, omawianych podczas prezentacji frameworkach mentalnych w stylu *-Driven *. To naprawdę fantastyczne narzędzia. Lecz zatrzymanie się na nich prowadzi do uprawiania sztuki dla sztuki.

To jednak nie koniec. W pewnym momencie, opanowawszy te wszystkie rzeczy, możemy się od nich oderwać. Zapakować do zasobnika jako użyteczne narzędzia i pójść w kierunku biznesu i ludzi.

To właśnie z tego powodu napisałem tę książkę. Książkę o brakującym klocku w TDD, BDD, DDD, itd, o sztuce zadawania pytań. Sądzę, że tylko wychodząc w stronę biznesu i spotykając klientów i użytkowników tam, gdzie oni są, możemy zrobić prawdziwie dobry użytek ze całego nagromadzonego warsztatu. Wtedy przestajemy już programować, a zaczynamy pomagać ludziom. To ogromna różnica!