Odczuwam pierwsze objawy choroby, z którą zawsze walczyłem. Przez lata widziałem jak ludzie sprowadzani do roli pionka w projekcie zamieniają się w zombie pozbawione pasji. Wszędobylski palec wskazujący wsparty lśniącym gantem stanowił narzędzie wyroczni określającej byt pokornej jednostki ( w sensie - "ty Zdzichu tera robisz to i masz na to dwie godziny").
Odczuwam pierwsze objawy choroby, z którą zawsze walczyłem. Kiedy jesteś odpowiedzialny tylko za swoją pracę to dostaniesz wpi***** tylko za swoją pracę. Kiedy jesteś odpowiedzialny za pracę wielu to cios może przyjść z każdej strony. Umysł sam zaczyna się bronić szukając wszędzie potwierdzenia, że jesteśmy kryci - "czy to już jest gotowe" lub " na kiedy to będzie skończone" . Kiedy sam sobie piszesz kod doskonale wiesz na jakim etapie jesteś - kiedy masz dostać wpi**** za czyjś kod nagle zaczyna cię bardzo ciekawić na jakim etapie on jest - chyba dlatego ci ludzie zawsze tak bardzo wielbili raporty...
Odczuwam pierwsze objawy choroby, z którą zawsze walczyłem... i będę walczył dalej. Najpierw trzeba zrozumieć objawy, później opracować lekarstwo...
Objawy
Objawy są naturalne i występują u wszystkich znajdujących się w określonej sytuacji - no może prawie wszystkich. Aby to sobie przećwiczyć zerknijmy na obrazek powyżej, który pochodzi z gry kolonizacja. Jeśli ktoś o niej nie słyszał to idea w uproszczeniu wygląda tak - dopływamy do brzegu w 1492 roku, tworzymy miasto a w nim zbieramy surowce i produkujemy towary. Jeśli akurat z Europy wyemigruje specjalista to będziemy zbierać tych zasobów i produkować towarów więcej. Ale z drugiej strony jak już na przykład nazbieramy odpowiednio dużo rudy żelaza to przerzucamy górnika do pasania świń bo tak maksymalizujemy zyski miasta. Brzmi znajomo?
Widziałem to wiele razy w projektach bazujących na ganto-excelu - Dobra tego taska mamy zrobionego to przesuńmy risorsa do łatania layoutów, a później zbierzemy resztę risorsów do aktualizacji dokumentacji
Ba byłem nawet na studiach dla managerów i widziałem na własne oczy Ćwiczenia z MS Projecta polegające na "zrobieniu tak aby paski były zielone" . I ch** kogo obchodziło, że programista nazwany przez instrukcję ćwiczenia "Janem" będzie pracował przez 3 godziny and jednym taskiem, później przez godzinę nad innym i na koniec na godzinę wróci do pierwszego. Grunt, ze gantt będzie zielony.
No i pamiętam jak w jednej takiej firmie zawsze na koniec dnia manager robił obchód po sali i podbijał do każdego "raportuj, raportuj gdzie jesteś na gancie" - not kool , not f*** kool
Umysł dąży do uproszczenia modelu. A jeśli do tego psychika danego człowieka jest na etapie "jak najlepiej zaspokoić moje potrzeby" to mamy gotowy przepis na ganta-style-managera.
Co można z tym zrobić jeśli już sobie uświadomimy problem? Natura, mechanika czy elektronika już znalazły rozwiązanie. Co ma wspólnego układ hormonalny, lodówka i tranzystor z napięciem zasilania Baza-Kolektor?
Ujemne sprzężenie zwrotne!
Zaciśnij dłoń i uderz nią w ścianę - powinno zaboleć co powstrzyma cię przed kontynuowaniem tej czynności (no chyba, że bardzo to lubisz) - właśnie zostałeś poddany działaniu ujemnego sprzężenia zwrotnego. Jak tę koncepcję zastosować w IT? - proste - Jak już coś wymyśliłeś to musi cię to też zaboleć. Można to łatwo osiągnąć będąc cały czas blisko kodu. Ta koncepcja została ładnie opisana w tej książce ---> http://37signals.com/rework - wszystkie ręce na front! - jak już coś obiecałeś to też się przy tym namęczysz. A przy okazji będziesz wiedział co się dzieję w projekcie i nie będziesz ludzi męczył pytaniami (no dobra w praktyce na razie mi to tak w 90% przypadków wychodzi)
Dlatego cały czas intuicyjnie byłem przeciwny koncepcji team lidera, który biega sobie tylko na spotkania, naobiecuje i deleguje. Powiedziałem moim mocodawcom, że chcę być jak Mel Gibson w Patriocie (przełożeni z USA) z bagnetem na pierwszej linii frontu aniżeli jak jakiś generał siedzieć wygodnie w namiocie spokojnie przesuwający figury na mapie
No i akurat w tym tygodniu ktoś wrzucił taki fajny symboliczny rysunek na fejsa :
Bardzo fajny post. To się dobrze wpisuje w aktualny trend o eliminowaniu nadzorców czystej wody i pozwalaniu zespołom na samoorganizowanie się przy oczywistym ponoszeniu odpowiedzialności :)
OdpowiedzUsuńU nas od jakiegoś czasu w projektach nie ma team leaderów, na rozmowach z klientem jest zawsze więcej niż jedna osoba, na demach również. Dzięki temu wszyscy czują się odpowiedzialni, nie ma spychologi "zostawię to team leaderowi, pewnie się tym zajmie".
Tomek w sumie byłoby to bardzo pomocne gdyby twoja firma zrobiła dużo kasy przy pomocy tego podejścia, o którym mówisz - przez co byłby dostępny taki "Proof of concept" ;)
UsuńGeneralnie rozmawiając o kwestiach samoorganizacji i o pewnych praktykach metodyk zwinnych napotykam często problem klasy " to nie ja robię coś źle tylko po prostu tak się nie da".
Np. Kilku znajomych w małych firmach już spaliło się próbując robić projekty dla klientów metodykami zwinnymi. No i reakcja rzadko kiedy przypomina "no cóż może po prostu nie mam odpowiednich umiejętności i muszę ku*wa się w czymś doszkolić" a raczej częściej można usłyszeć "próbowałem, nie udało się tak się nie da". To tak jakbym wsiadł na motocykl po raz pierwszy w życiu - bo przecież znam się na prowadzeniu pojazdów gdyż jeżdżę samochodem od 7 lat - i bym się wyjebał zaraz po zapuszczeniu sprzęgła - "właśnie udowodniłem, że nie da się jeździć na motocyklu, próbowałem, wyjebałem się, nie da się"
Dlatego taki przykład "ala Valve" z polskiego runku byłby bardzo pomocny w dyskusji.
A używasz pair programing? Dla mnie to jest rewelacyjna metoda budowania zespołu.
OdpowiedzUsuńPozdrawiam
Piotrek Kotynia
Kopę lat Piotrek.
UsuńGeneralnie pair programming jest dobre ale to już raczej pomoc w dalszym etapie po przeskoczeniu pierwszej bariery kulturowej, którą można nazwać "Team lider nie programuje".
W pierwszej firmie w której pracowałem często można było usłyszeć słowa w stylu "ten to pewnie jeszcze maks 2 lata będzie tylko klepał" ( a później zamieni się w doskonałą formę menadżerską - dop. autora).
W obecnej firmie słyszę też kwestię w stylu "nie, nie ja już nie programuje" albo "kiedy jeszcze programowałem to ...".
I teraz jeśli taka osoba "delegująca" siada do czegoś co ma przypominać pair programming to z tego co widziałem zamienia się to w dziwną i patologiczną formę mikro managementu poprzez patrzenie przez ramię.
Ale jeśli już się to ogarnie to pair programming czasami jak najbardziej tak. (Chociaż mi osobiście programowanie najlepiej idzie jak zarzucę techno na słuchawki i wtedy mogę napierdalać nawet bite 8 godzin z przerwą jedynie na wc i białko-koksy)
pzdr
Masz rację, Kopę lat :)
OdpowiedzUsuńOdnośnie programowania to się z Tobą zgadzam, kodzenie to raczej osobista czynność. Mi najlepiej się klepie po paru lampkach taniego whiskey. Oczywiście w pracy zarobkowej uprawiam takiego procederu :)
Mimo to uważam że pair programing może dobrze działać. Dla mnie to jest taki święty gral programowania. Wszyscy zgadzają się, że to jest fajna sprawa ale zawszę są jakieś ale :)
Daj znać co o tym myślisz.
Pozdrawiam
Piotrek
Myślę, że w naszej branży i tak jesteśmy uprzywilejowani pod względem "normalności" relacji team leader - reszta zespołu. Znam osoby pracujące w korporacjach zajmujących się outsourcingiem księgowo-procesowym. Tam właściwie normą jest opisywana przez Ciebie patologia: "Team leaderzy" zajmujący się tylko raportami w Excelu i chodzeniem na spotkania nie mają pojęcia o pracy wykonywanej przez swój zespół.
OdpowiedzUsuńGdzieś czytałem dobre podsumowanie, coś w stylu: prawdziwy leader nie woła "Do boju!" tylko "Za mną!" - w sumie podobne w wymowie do rysunku boss vs leader :-)