Polecam jeśli ktoś interesuje się zarządzaniem zespołami programistycznymi. Dużo matematyki, fizyki, filozofii. Duży nacisk na samoorganizacje zespołów.
Reguły Jurgena, opracowane na podstawie zasad holenderskiego ruchu drogowego i zarządzania zespołem Agile:
- Kultura: bez względu na to, jakie metody zastosujesz w celu wypracowania kompetencji w systemie społecznym, ostatecznie i tak wszystko sprowadza się do tego, czy ludziom na tym zależy.
- Instruktorzy: ucz ludzi, jak mają wykonywać dobrze swoją pracę. I jeszcze raz, i jeszcze raz, i jeszcze raz.
- Prawo jazdy: żądaj, aby ludzie zostali odpowiednio sprawdzeni, zanim pozwolisz im brać udział w (wymagających) projektach.
- Znaki drogowe: zmniejsz szanse wystąpienia problemów w twoich zespołach, korzystając z inteligentnych i aktywnych narzędzi, list kontrolnych, alertów, powiadomień oraz innych środków sterujących.
- Policja drogowa: zaangażuj menedżera procesu, którego zadaniem będzie sprawdzanie próbek wyników twoich projektów pod względem jakości. A jeśli się okaże, że jakość jest niska… cóż, ty decydujesz.
- Klakson: upewnij się, że członkowie twojego zespołu mają odwagę, aby mówić sobie nawzajem, jak lepiej pracować. Pozwól im, aby używali klaksonów lub pokazywali sobie środkowe palce. Oczywiście nie w dosłownym tego słowa znaczenia.
- Rząd: gdy wszystko inne zawiedzie, wkroczy rząd. Jego członkowie zbadają, co poszło źle, ustanowią nowe reguły lub ograniczenia i zdecydują, kto miał rację, a kto nie. Kierownictwo będzie musiał posprzątać bałagan.
Zaciekawiło mnie również proste równanie kompetencji a szczególnie z czego ono wynika:
dyscyplina (procedury) + umijętności (edukacja) = kompetencja
Typowa metoda liniowa którą nasz drogi Jurgen rozbił na czynniki, podważył podgrzał i doszedł do wniosku, który zresztą jest przesłaniem całej książki że wszystko jest błędne, również jego przemyślenia. Mimo wszystko zacytuję typowy model ulepszania wszystkiego, pomijając drogocenne przemyślenia naszego Jurgena który opracował swoją własną nie liniową metodę ulepszeń wychodząc słusznie z założenia że problemów nie liniowych w środowisku nie liniowym nie da się rozwiązać w sposób liniowy (przedstawiony poniżej):
- Analizujemy naszą bieżącą sytuację i wyznaczamy nasz najważniejszy problem (na przykład okazuje się, że tyjemy)
- Definiujemy nasz cel, który pomoże nam się wydostać z problematycznej sytuacji (chcemy ważyć o 10 kg mniej)
- Definiujemy narzędzie pomiarowe, które pozwoli nam stwierdzić, czy nasz plan się powiódł (przynosimy naszą starą wagę ze strychu)
- Identyfikujemy ulepszenie, które może nas skierować ku pożądanemu celowi (decydujemy, że będziemy biegać i jeść zdrowe posiłki)
- Realizujemy implementację – w postaci jak najmniejszego kontrolowanego eksperymentu (kupujemy buty do biegania i książkę kucharską)
- Następnie przystępujemy do wykonania naszych codziennych działań, które pozwolą nam osiągnąć mierzalne rezultaty (codziennie biegamy i jemy zdrowe posiłki)
- Później rozpoczynamy analizę pomiarów w celu weryfikacji ulepszenia ( o nie, tylko jeden kilogram w ciągu trzech tygodni?)
- Wreszcie analiza umożliwia zdobywanie wiedzy o problemie, rozwiązaniu i pomiarach (nigdy nie ufaj starej wadze)
Po ukończeniu kroku ósmego wracamy do kroku pierwszego, aby określić, czy ten sam problem nadal istnieje (wciąż jestem gruby), lub aby stwierdzić, że inny problem jest teraz bardziej palący (potrzebna jest nowa waga)
Jeśli Jurgen napisze kiedyś zarządzanie 4.0 czy ją przeczytam ? Zdecydowanie nie, myślę że można ideę zarządzania przekazać w prostszej formie a Juren w zarządzaniu 3.0 zaliczył za dużo odlotów. W końcu mieszka w Holandii 🙂