"Don't try to race sheeps. don't try to herd racehorces. The message beyond this one is really powerful. You cannot treat people uniformely. Do not ask expert to fill timesheets!"
Choć ustanowienie formalnych procedur dla osób na niższych poziomach jest korzystne, nawet wówczas reguły nie mogą zastąpić zdrowego rozsądku. W miarę jak umiejętność oceny sytuacji i podejmowania decyzji wzrasta, należy rozluźnić nacisk, jaki kładziemy na sztywne, z góry ustalone zasady.
Podsumowując, mamy następujące poziomy:
1. Nowicjusz - Nic nie wie, niczego nie próbował.
2. Początkujący - Coś już potrafi, od czasu do czasu ma problemy. Wciąż woli, by ktoś inny mówił mu, co ma zrobić.
3. Kompetentny - Jak typowy dwulatek, wie wszystko, czego mu trzeba i jest szcześliwy.
4. Biegły - Dostrzega większy obraz, zadaje pytania.
5. Ekspert - "God calls him from time to time".
Zdecydowana większość osób pozostaje na poziomie drugim.
Dlaczego?
Istnieje kluczowa różnica między poziomami 2 i 3. Na poziomie drugim tylko wykonujemy polecenia. Na poziomie trzecim sami podejmujemy decyzje. Bierzemy na siebie odpowiedzialność. Ryzykujemy.
Smutna prawda jest taka, że większość osób po prostu ma wszystko gdzieś. Nie chce ryzyka i odpowiedzialności. Bo po co? Praca jest dla nich źródłem utrzymania, nie pasją. Przychodzą, by odsiedzieć swoje 8 godzin. Czemu mają przy okazji się narażać? Niech ktoś inny powie im, co mają robić!
Inną kwestią jest to, że większość kierowników również jest na poziomie drugim. I znacznie wygodnie zarządza się grupą ludzi, którzy pytają "Co mam zrobić teraz?" niż takich, którzy powiedzą "Nie sądzę, byś naprawdę chciał to zrobić ;)"
Czasami zwracamy się do kogoś bardziej doświadczonego z prośbą o pomoc. Wysłuchujemy szczegółowych wyjaśnień, kiwając głową i potakując. Po czym siadamy do komputera, odpalamy Google i próbujemy dowiedzieć się, o czym ten człowiek mówił.
Błąd.
Zamiast przytakiwać, powiedzmy: "Chwila! Podaj mi to w małych porcjach. Pozwól mi poeksperymentować z nową wiedzą. Nabiorę trochę doświadczenia. Przyjdę po więcej". Domagając się, by ludzie traktowali nas zgodnie z poziomem, na którym jesteśmy, będziemy uczyć się szybciej. I znacznie szybciej osiągniemy poziom 3 lub 4.
Eksperci nie powinni być automatycznie awansowani na kierowników. Należy promować doświadczenie. Utrzymywać ekspertów na stanowiskach, na których mogą wykorzystać i rozwijać swoje umiejętności. I odpowiednio ich wynagradzać.
Nie możnemy wrzucać programistów do jednego worka. Różnice w wydajności (w zależności od tego, którym badaniom wierzymy), to 10:1, 20:1 a nawet 40:1. (Pragmatic Thinking And Learning, Dreyfus at Work: Herding racehorces and racing sheep). Kiedy musimy dokonać kluczowego wyboru, jedną krótką odpowiedzią: "użyjmy tego" ekspert może zaoszczędzić firmie miliony złotych.
poniedziałek, 15 sierpnia 2011
Model kompetencji braci Dreyfus [2]
Załóżmy, że masz problem, nad którym pracujesz cały dzień. Bezskutecznie. Zostajesz po godzinach. Nic.
W końcu wracasz do domu, bierzesz prysznic, idziesz na spacer... i nagle - eureka! - znasz już rozwiązanie.
Brzmi znajomo?
To cudowne uczucie, gdy w pewnej chwili po prostu wiesz, co należy zrobić - Eksperci tak mają przez cały czas.
Bracia Dreyfus, pracując nad zagadnieniem sztucznej inteligencji, skoncentrowali się na sposobie, w jaki ludzie zdobywają doświadczenie. Określili i opisali pięć poziomów osiąganych podczas tego procesu:
1. Nowicjusz
Nowicjusz nie ma pojęcia, co robi. Nie obchodzi go szerszy kontekst. Chce wykonać zadanie. Potrzebuje prostych, szczegółowych instrukcji i krótkich zadań przynoszących natychmiastowe efekty. Nie wie, co zrobić, gdy napotka problemy.
2. Początkujący
Początkujący zaczyna dostrzegać wzorce. Może samodzielnie wykonywać zadania. Radzi sobie w przypadku problemów, choć z pewnymi trudnościami. Wciąż potrzebuje poleceń i nadzoru.
Dave Thomas w swojej prezentacji wspomina własną naukę latania szybowcem:
W pewnym momencie nadchodzi czas na samodzielny lot za samolotem holującym. Kluczowe jest zapamiętanie jednej zasady: szybowiec unosi się znacznie szybciej niż samolot, dlatego należy utrzymywać się na wysokości ok. 3 stóp nad ziemią, zanim samolot nie wzbije się w powietrze. W przeciwnym wypadku samolot będzie miał dwie możliwości: zostać najdroższą na świecie kosiarką do trawy lub odpiąć szybowiec. Pilot wybierze to drugie.
Po solidnym treningu, instruktor zabrał Dave'a na krótką rozmowę:
- Oto, co za chwilę się stanie: wsiądziesz do szybowca i uniesiesz się nad ziemię. Będziesz pamiętał, by utrzymywać się na wysokości 3 stóp, jednak w którymś momencie twoja koncentracja trochę osłabnie - zorientujesz się, że nagle jesteś 8 stóp nad ziemią i musisz obniżyć lot. Popchniesz drążek w dół. W tym momencie do głosu dojdzie twój gadzi umysł - "Hej, jestem na wysokości 8 stóp i lecę z prędkością 50 mil na godzinę prosto w ziemię!" - i zanim zdążysz cokolwiek zrobić, pociągnie za drążek. Twój świadomy umysł powie "Przestań!", tamten odpowie "Nie ma mowy!", itp. Szybowiec będzie leciał w górę, w dół, w górę, w dół, a samolot cię odepnie.
- Nie bądź głupi - odpowiedział Dave - ćwiczyliśmy to setki razy, nic takiego się nie stanie.
Minutę później siedział na ziemi, w szybowcu odpiętym od samolotu. Podszedł do instruktora.
- Skąd wiedziałeś, że to zrobię?
Instruktor wzruszył ramionami.
- Wszyscy tak robią.
Ile razy, dając początkującemu zadanie do wykonania, mamy do czynienia z następującą sytuacją:
"You say to them: 'But whatever you do, don't to that.' And half an hour later, what have they done? That. They're not stupid. They're not malicious. They're advanced beginners."
3. Kompetentny
Znaczący krok naprzód. Kompetentny nie potrzebuje już poleceń - sam podejmuje decyzje i bierze za nie odpowiedzialność. Nie otrzymuje zadań do wykonania, tylko cele do osiągnięcia. Jest jak szczęśliwy dwulatek - potrafi chodzić, mówić, włączyć odtwarzacz dvd kiedy tylko zechce. Ma kontrolę nad wszystkim dookoła i jest mu z tym dobrze.
4. Biegły
Po pewnym czasie nadchodzi moment, w którym wszystko zaczyna się sypać. Nic już nie jest tak proste, jak do tej pory. Kompetentny przeszedł na kolejny poziom - stał się Biegłym. Dwulatek, Pan Wszechświata, który może biegać po całym domu i robić co tylko zechce, któregoś dnia podchodzi do drzwi, otwiera je i mówi: "Wow! To jest większe, niż myślałem!"
Biegłego można porównać do trzylatka. Jakie jest ulubione pytanie dziecka w tym wieku? "Dlaczego". W korporacjach łatwo zauważyć osoby na tym poziomie - są pierwsi w kolejce do zwolnienia, gdy nadchodzą ciężkie czasy.
- Dlaczego używamy JEE?
- Wszystkie nasze projekty używają JEE.
- Ale dlaczego wszystkie nasze projekty używają JEE?
- To nasz korporacyjny standard.
- Ale dlaczego jest to nasz korporacyjny standard?
...
Na tym poziomie człowiek zaczyna syntetyzować informacje zebrane z różnych obszarów. Zaczyna zauważać podobieństwa, dostrzegać większy obraz.
5. Ekspert
Eksperci zazwyczaj używają metafor i opowieści, ponieważ czyste fakty już nie wystarczają. Paradoksalnie, wieloznaczność pozwala im wypowiadać się precyzyjniej. Jeżeli spotkasz dwóch dyskutujących ekspertów, prawdopodobnie w którymś momencie zaczną się kłócić. Jeżeli są to naprawdę dobrzy eksperci, jest duża szansa, że zaobserwujesz coś ciekawszego: ekspert 1 broni pozycji A, ekspert 2 broni pozycji B. W pewnym momencie zamienią się miejscami i nadal, z pełnym zaangażowaniem, będą bronić swoich racji.
Organizacje nieustannie wymagają od ekspertów, by dowodzili tego, co wiedzą. Muszą nauczyć się kłamać, by uzasadnić swoje decyzje. To tak, jakby kazać komuś wytłumaczyć, skąd wiedział które mięśnie poruszyć, by unieść rękę. Eksperci uwielbiają się kłócić - oni ćwiczą.
Eksperci nieustannie czytają. Najprawdopodobniej nie będą to książki o JEE. Będą dotyczyły najróżniejszych tematów. Ekspert następnie zsyntetyzuje zdobyte informacje, rozszerzając swoje rozumienie JEE.
I jeszcze jedno:
"Never ever ask an expert to choose the architecture of your next project. He will say: we should use this framework, this persistence layer, this orm layer and this web server. Why? Because they're curious to see if it will work."
W końcu wracasz do domu, bierzesz prysznic, idziesz na spacer... i nagle - eureka! - znasz już rozwiązanie.
Brzmi znajomo?
To cudowne uczucie, gdy w pewnej chwili po prostu wiesz, co należy zrobić - Eksperci tak mają przez cały czas.
Bracia Dreyfus, pracując nad zagadnieniem sztucznej inteligencji, skoncentrowali się na sposobie, w jaki ludzie zdobywają doświadczenie. Określili i opisali pięć poziomów osiąganych podczas tego procesu:
1. Nowicjusz
Nowicjusz nie ma pojęcia, co robi. Nie obchodzi go szerszy kontekst. Chce wykonać zadanie. Potrzebuje prostych, szczegółowych instrukcji i krótkich zadań przynoszących natychmiastowe efekty. Nie wie, co zrobić, gdy napotka problemy.
2. Początkujący
Początkujący zaczyna dostrzegać wzorce. Może samodzielnie wykonywać zadania. Radzi sobie w przypadku problemów, choć z pewnymi trudnościami. Wciąż potrzebuje poleceń i nadzoru.
Dave Thomas w swojej prezentacji wspomina własną naukę latania szybowcem:
W pewnym momencie nadchodzi czas na samodzielny lot za samolotem holującym. Kluczowe jest zapamiętanie jednej zasady: szybowiec unosi się znacznie szybciej niż samolot, dlatego należy utrzymywać się na wysokości ok. 3 stóp nad ziemią, zanim samolot nie wzbije się w powietrze. W przeciwnym wypadku samolot będzie miał dwie możliwości: zostać najdroższą na świecie kosiarką do trawy lub odpiąć szybowiec. Pilot wybierze to drugie.
Po solidnym treningu, instruktor zabrał Dave'a na krótką rozmowę:
- Oto, co za chwilę się stanie: wsiądziesz do szybowca i uniesiesz się nad ziemię. Będziesz pamiętał, by utrzymywać się na wysokości 3 stóp, jednak w którymś momencie twoja koncentracja trochę osłabnie - zorientujesz się, że nagle jesteś 8 stóp nad ziemią i musisz obniżyć lot. Popchniesz drążek w dół. W tym momencie do głosu dojdzie twój gadzi umysł - "Hej, jestem na wysokości 8 stóp i lecę z prędkością 50 mil na godzinę prosto w ziemię!" - i zanim zdążysz cokolwiek zrobić, pociągnie za drążek. Twój świadomy umysł powie "Przestań!", tamten odpowie "Nie ma mowy!", itp. Szybowiec będzie leciał w górę, w dół, w górę, w dół, a samolot cię odepnie.
- Nie bądź głupi - odpowiedział Dave - ćwiczyliśmy to setki razy, nic takiego się nie stanie.
Minutę później siedział na ziemi, w szybowcu odpiętym od samolotu. Podszedł do instruktora.
- Skąd wiedziałeś, że to zrobię?
Instruktor wzruszył ramionami.
- Wszyscy tak robią.
Ile razy, dając początkującemu zadanie do wykonania, mamy do czynienia z następującą sytuacją:
"You say to them: 'But whatever you do, don't to that.' And half an hour later, what have they done? That. They're not stupid. They're not malicious. They're advanced beginners."
3. Kompetentny
Znaczący krok naprzód. Kompetentny nie potrzebuje już poleceń - sam podejmuje decyzje i bierze za nie odpowiedzialność. Nie otrzymuje zadań do wykonania, tylko cele do osiągnięcia. Jest jak szczęśliwy dwulatek - potrafi chodzić, mówić, włączyć odtwarzacz dvd kiedy tylko zechce. Ma kontrolę nad wszystkim dookoła i jest mu z tym dobrze.
4. Biegły
Po pewnym czasie nadchodzi moment, w którym wszystko zaczyna się sypać. Nic już nie jest tak proste, jak do tej pory. Kompetentny przeszedł na kolejny poziom - stał się Biegłym. Dwulatek, Pan Wszechświata, który może biegać po całym domu i robić co tylko zechce, któregoś dnia podchodzi do drzwi, otwiera je i mówi: "Wow! To jest większe, niż myślałem!"
Biegłego można porównać do trzylatka. Jakie jest ulubione pytanie dziecka w tym wieku? "Dlaczego". W korporacjach łatwo zauważyć osoby na tym poziomie - są pierwsi w kolejce do zwolnienia, gdy nadchodzą ciężkie czasy.
- Dlaczego używamy JEE?
- Wszystkie nasze projekty używają JEE.
- Ale dlaczego wszystkie nasze projekty używają JEE?
- To nasz korporacyjny standard.
- Ale dlaczego jest to nasz korporacyjny standard?
...
Na tym poziomie człowiek zaczyna syntetyzować informacje zebrane z różnych obszarów. Zaczyna zauważać podobieństwa, dostrzegać większy obraz.
5. Ekspert
Eksperci zazwyczaj używają metafor i opowieści, ponieważ czyste fakty już nie wystarczają. Paradoksalnie, wieloznaczność pozwala im wypowiadać się precyzyjniej. Jeżeli spotkasz dwóch dyskutujących ekspertów, prawdopodobnie w którymś momencie zaczną się kłócić. Jeżeli są to naprawdę dobrzy eksperci, jest duża szansa, że zaobserwujesz coś ciekawszego: ekspert 1 broni pozycji A, ekspert 2 broni pozycji B. W pewnym momencie zamienią się miejscami i nadal, z pełnym zaangażowaniem, będą bronić swoich racji.
Organizacje nieustannie wymagają od ekspertów, by dowodzili tego, co wiedzą. Muszą nauczyć się kłamać, by uzasadnić swoje decyzje. To tak, jakby kazać komuś wytłumaczyć, skąd wiedział które mięśnie poruszyć, by unieść rękę. Eksperci uwielbiają się kłócić - oni ćwiczą.
Eksperci nieustannie czytają. Najprawdopodobniej nie będą to książki o JEE. Będą dotyczyły najróżniejszych tematów. Ekspert następnie zsyntetyzuje zdobyte informacje, rozszerzając swoje rozumienie JEE.
I jeszcze jedno:
"Never ever ask an expert to choose the architecture of your next project. He will say: we should use this framework, this persistence layer, this orm layer and this web server. Why? Because they're curious to see if it will work."
niedziela, 14 sierpnia 2011
Model kompetencji braci Dreyfus [1]
Temat ten został omówiony w drugim rozdziale książki "Practical Thinking & Learning" Andy'ego Hunta oraz niezrównanej prezentacji Dave'a Thomasa "Developing Expertise: Herding Racehorses, Racing Sheep" dostępnej tutaj.
Przede wszystkim musimy uświadomić sobie, że oprogramowanie nie jest pisane przez narzędzia, metodologie, języki ani frameworki. Jest pisane przez ludzi.
W ciągu otatnich lat drastycznie zmieniły się używane języki; spontaniczne hackowanie zastąpiliśmy metodologiami; miejsce edytorów tekstowych zajęły IDE. Współczynnik błędów na 1000 linii kodu w połowie lat 70-tych wynosił 5.5. W połowie lat 90-tych - 5.6. Jest stały. Ponieważ jedno się nie zmieniło. My.
W większości zespołów można spotkać kilka typowych postaci. Przyjrzyjmy się im.
Ekspert.
To człowiek, dla którego wszystko po prostu działa. Ekspert może sięgnąć po zupełnie nową technologię i w ciągu dwóch godzin będzie się nią posługiwać z niewiarygodną efektywnością. Ekspert może spojrzeć na dowolny fragment kodu i w trzy sekundy wskaże, co jest z nim nie tak. Ekspert zna wszystkie nowe frameworki, wszystkie nowe technologie.
Tacy ludzie istnieją. Widziałam ich. Na własne oczy.
Eksperci znają odpowiedzi na większość pytań. Często nie są w stanie ich uzasadnić, po prostu intuicyjnie wiedzą, co należy zrobić. I zazwyczaj mają rację.
Istnieje prosty test, gdy podejrzewamy kogoś o bycie ekspertem. Wystarczy wziąć nowego programistę i gdy będzie miał pytania, wysłać go do takiego człowieka. Jeżeli wróci ze łzami w oczach - mamy Eksperta w zespole.
(Tu małą uwaga - na jednej z prezentacji spotkałam się z wyróżnieniem dodatkowego, szóstego poziomu w modelu kompetencji braci Dreyfus - Guru. Guru jest Ekspertem który wie, jak przekazać swoją wiedzę.)
Po drugiej stronie spektrum mamy Nowicjuszy.
Nowicjusz potrzebuje jasnych, szczegółowych instrukcji i krótkich zadań, które pozwolą mu szybko osiągnąć pierwsze sukcesy.
Nie zarzucajmy nowicjuszy na wstępie stertą książek i dokumentów do przeczytania. Taki człowiek przyszedł, by coś robić - i należy mu na to pozwolić. Dopiero gdy zapozna się ze środowiskiem i wykona pierwse, proste zadania - przyjdzie czas na przekazywanie wiedzy.
Dobrym przykładem jest instruktor wspinaczki, który na pierwszej lekcji upewnił się, że uczniowie mają dobrze zamocowane liny i kazał im się wspinać. Sam w tym czasie poszedł na kawę. Po kwadransie wrócił i zaczął wykładać teorię - w jaki sposób stawiać stopy i jak utrzymać równowagę. Dzięki temu uczniowie mogli odnieść te informacje do własnych doświadczeń - miały znacznie więcej sensu niż gdyby otrzymali je na samym początku.
Nowicjusz potrzebuje konkretnych, szczegółowych instrukcji. Umieścić w piekarniku nagrzanym do 200 stopni. Piec przez godzinę. Polecenie "dosolić do smaku" nie ma dla niego żadnej wartości. Nie posiada kontekstu, w którym taka wskazówka nabrałaby znaczenia.
"Cook them for about 20 minutes. How am I supposed to do this? Should I cook them for 19 minutes? or 21? Or maybe until they catch fire? I don't know, I've never done this before!"
Ludzie w większości zespołów mocno różnią się poziomem doświadczenia. Problem polega na tym, że próbujemy wszystkich traktować w ten sam sposób! Narzucamy im te same procedury, te same metodologie, nie biorąc pod uwagę faktu, że mają zupełnie różne potrzeby!
Przede wszystkim musimy uświadomić sobie, że oprogramowanie nie jest pisane przez narzędzia, metodologie, języki ani frameworki. Jest pisane przez ludzi.
W ciągu otatnich lat drastycznie zmieniły się używane języki; spontaniczne hackowanie zastąpiliśmy metodologiami; miejsce edytorów tekstowych zajęły IDE. Współczynnik błędów na 1000 linii kodu w połowie lat 70-tych wynosił 5.5. W połowie lat 90-tych - 5.6. Jest stały. Ponieważ jedno się nie zmieniło. My.
W większości zespołów można spotkać kilka typowych postaci. Przyjrzyjmy się im.
Ekspert.
To człowiek, dla którego wszystko po prostu działa. Ekspert może sięgnąć po zupełnie nową technologię i w ciągu dwóch godzin będzie się nią posługiwać z niewiarygodną efektywnością. Ekspert może spojrzeć na dowolny fragment kodu i w trzy sekundy wskaże, co jest z nim nie tak. Ekspert zna wszystkie nowe frameworki, wszystkie nowe technologie.
Tacy ludzie istnieją. Widziałam ich. Na własne oczy.
Eksperci znają odpowiedzi na większość pytań. Często nie są w stanie ich uzasadnić, po prostu intuicyjnie wiedzą, co należy zrobić. I zazwyczaj mają rację.
Istnieje prosty test, gdy podejrzewamy kogoś o bycie ekspertem. Wystarczy wziąć nowego programistę i gdy będzie miał pytania, wysłać go do takiego człowieka. Jeżeli wróci ze łzami w oczach - mamy Eksperta w zespole.
(Tu małą uwaga - na jednej z prezentacji spotkałam się z wyróżnieniem dodatkowego, szóstego poziomu w modelu kompetencji braci Dreyfus - Guru. Guru jest Ekspertem który wie, jak przekazać swoją wiedzę.)
Po drugiej stronie spektrum mamy Nowicjuszy.
Nowicjusz potrzebuje jasnych, szczegółowych instrukcji i krótkich zadań, które pozwolą mu szybko osiągnąć pierwsze sukcesy.
Nie zarzucajmy nowicjuszy na wstępie stertą książek i dokumentów do przeczytania. Taki człowiek przyszedł, by coś robić - i należy mu na to pozwolić. Dopiero gdy zapozna się ze środowiskiem i wykona pierwse, proste zadania - przyjdzie czas na przekazywanie wiedzy.
Dobrym przykładem jest instruktor wspinaczki, który na pierwszej lekcji upewnił się, że uczniowie mają dobrze zamocowane liny i kazał im się wspinać. Sam w tym czasie poszedł na kawę. Po kwadransie wrócił i zaczął wykładać teorię - w jaki sposób stawiać stopy i jak utrzymać równowagę. Dzięki temu uczniowie mogli odnieść te informacje do własnych doświadczeń - miały znacznie więcej sensu niż gdyby otrzymali je na samym początku.
Nowicjusz potrzebuje konkretnych, szczegółowych instrukcji. Umieścić w piekarniku nagrzanym do 200 stopni. Piec przez godzinę. Polecenie "dosolić do smaku" nie ma dla niego żadnej wartości. Nie posiada kontekstu, w którym taka wskazówka nabrałaby znaczenia.
"Cook them for about 20 minutes. How am I supposed to do this? Should I cook them for 19 minutes? or 21? Or maybe until they catch fire? I don't know, I've never done this before!"
Ludzie w większości zespołów mocno różnią się poziomem doświadczenia. Problem polega na tym, że próbujemy wszystkich traktować w ten sam sposób! Narzucamy im te same procedury, te same metodologie, nie biorąc pod uwagę faktu, że mają zupełnie różne potrzeby!
sobota, 13 sierpnia 2011
Practical Thinking And Learning: Refactor Your Wetware, Andy Hunt
Kto by pomyślał, że tyle dobrego można znaleźć w jednej książce.
niedziela, 7 sierpnia 2011
Marsz ku klęsce, Edward Yourdon
"Co więcej, taki codziennie budowany system trzeba zautomatyzować i zostawić, aby pracował nienadzorowany w środku nocy, kiedy już wszyscy programiści poszli do domu (albo wskoczyli do śpiworów i śpią pod biurkami)".
Książka, mimo niewielkich rozmiarów i swobodnego, nasyconego humorem tonu, jest dość ciężkostrawna. Autor obiecywał zwięzłość, a większość spostrzeżeń powtarzana jest wielokrotnie. Przechodząc przez kolejne zagadnienia, miałam wrażenie, że właściwie niczego się nie dowiaduję. Opisane sytuacje i problemy rzeczywiście występują w przyrodzie. Przeczytałam jak sklasyfikować projekty; graczy politycznych związanych z projektami; członków zespołu pod względem ról psychologicznych. W tym miejscu, podążając za radą samego autora, pozostaje spytać: "Co z tego?". Jak mogę wykorzystać tę wiedzę? Na te pytania jednak nie dostaję już odpowiedzi.
Z drugiej strony książka przedstawia zagadnienia, którym warto poświęcić kilka chwil podczas czytania. Porównać z własnymi doświadczeniami i wnioskami. Uśmiechnąć się od czasu do czasu.
1. Dlaczego projekty wkraczają na drogę ku klęsce?
- Aby zdobyć kontrakt przyjmowany jest nierealny budżet i nierealny harmonogram. Obiecuje się nierealną ilość funkcjonalności.
- Kierownictwo wierzy, że projekt można wykonać o 10% szybciej/taniej, jeżeli tylko dość mocno się tego chce.
- Niedoszacowanie pracochłonności, z uwagi na naiwny optymizm młodości ("Zrobimy to w weekend!") i mentalność komandosów ("Prawdziwi programiści nie muszą spać!")
- Próby wykorzystania najnowszej, niesprawdzonej i nieobeznanej technologii jako "magicznej różdżki", która pozwoli zrealizować projekt znacznie szybciej i taniej.
- Wiara w liniową zależność zasobów od czasu. (Problem jest szerzej opisany w książce "Mityczny osobomiesiąc" i streszczony przez prawo Brooksa: "Dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej".)
- Nadmierna formalizacja procesu. Programista, który pisze wielostronicowy raport, nie programuje.
- Polityka.
Lub też, cytując jedną z pierwszych stron: "Projekty bywają marszami ku klęsce, ponieważ kierownictwo to obłudne sukinsyny, a użytkownicy są naiwni i nie myślą realnie". ;)
2. Należy zidentyfikować głównych graczy politycznych. Najlepiej, by cały zespół wiedział, kim są. Właściciel, mistrzowie, użytkownicy, pośrednicy, interesariusze. Kto ma być szczęśliwy podczas trwania projektu. Kto będzie próbował go sabotować. Do kogo się zwrócić w razie problemów.
3. Projekty dzielimy na cztery rodzaje:
- "Mission impossible" - wysokie szanse na sukces, wysokie zadowolenie zespołu. "Kierownik projektu to przystojny hollywoodzki bohater, hakerzy są genialni i Bóg jest po stronie zespołu. Członkowie zespołu są fanatycznie lojalni wobec siebie."
- "Brzydkie projekty" - wysokie szanse, niskie zadowolenie. "To projekty, w których członkowie zespołu są barankami ofiarnymi, które kierownik projektu zarżnie z zimną krwią, żeby doprowadzić projekt do udanego zakończenia."
- "Projekty samobójcze" - niskie szanse, niskie zadowolenie. "Wszyscy są skazani na zgubę i wszystko jest żałosne".
- "Kamikadze" - niskie szanse, wysokie zadowolenie.
4. Należy określić stopień zaangażowania członków zespołu. Może się zdarzyć, że niektórzy będą mieli rodziny, albo nawet hobby.
"Zaangażowanie zależy także w znacznej mierze od tego, czy kierownik projektu potrafi wzbudzić w pracownikach uczucie lojalności i zaangażowania. Jest to w pewnym stopniu sprawą jego charyzmy. Bywają kierownicy, którzy umieją stworzyć taką atmosferę, że reszta zespołu, nie bacząc na związane z projektem ryzyko, pójdzie za nimi na koniec świata. Inni kierownicy nie skłonią zespołu do żadnego dodatkowego wysiłku, nawet gdyby chodziło o uratowanie ludzkości przed inwazją kosmitów".
"Niezależnie jednak od typu osobowości, nikomu nie zaszkodzi praca po 10 godzin dziennie. Kiedy już projekt wystartuje, można spodziewać się po wszystkich 60 godzin pracy tygodniowo. Jeżeli tego nie robią, sprawdź, czy coś w organizacji projektu nie powoduje frustracji."
"Kierownik projektu powinien poświęcić projektowi maksimum swego czasu. Po pierwsze, musi służyć przykładem. Nie może oczekiwać, by członkowie zespołu pracowali w dodatkowych godzinach, jeśli sam tego nie robi. Po drugie, musi być na miejscu, żeby odpowiadać na pytania, stawić czoła biurokracji, pokonywać trudności, które pojawią się w tych oddatkowych godzinach."
Wszystko jednak z umiarem. Kogoś, kto pracuje więcej niż 80-90 godzin tygodniowo, kierownik powinien stanowczo odesłać do domu na odpoczynek.
5. Motywacja. "Pieniądze, korzyści, wygoda i tak dalej, to czynniki 'higieny'. Ich brak wywołuje niezadowolenie. Nie są one jednak źródłem zadowolenia z pracy ani też źródłem potrzebnego ludziom wewnętrznego napędu. O napędzie decydują takie sprawy, jak poczucie osiągnięcia czegoś, duma z wykonania dobrej roboty, zwiększona odpowiedzialność, awans i rozwój osobisty. Tajemnica polega na wzbogacaniu pracy".
Ładna premia na zakończenie projektu ("Za 10 000 dolarów nagrody można kupić nowy samochód lub spędzić urlop na Bali".) jest zawsze mile widziana. Choć trzeba pamiętać, że perspektywa dużych sum różnie wpływa na ludzi ("George miał czelność zwolnić się w Wigilię po to tylko, żeby być z tąswoją beznadziejną rodzinką. A to przecież najgorętszy okres prób. Przez niego premia przejdzie nam koło nosa").
Nie ma liniowej zależności między wielkością premii a wydajnością. Dyrekcje niektórych firm oferowały pracownikom podwójną premię wierząc, że skłoni to ich do podwojenia liczy godzin pracy. Jeśli jednak ktoś pracuje po 18 godzin na dobę, to już z arytmetyki wynika, że nawet przy największym poświęceniu nie będzie mógł pracować dwa razy dłużej.
Premia musi być wiarygodna. Zespół musi w nią wierzyć. Ludzie muszą być przekonani, że dyrekcja nie wymiga się od jej wypłacenia w jakiś pokrętny sposób.
6. "Wpierw rób, a potem przepraszaj". Prośby o zwolnienie z różnych biurokratycznych przepisów, które utrudniają pracę przy projekcie, mogą być stratą czasu. Warto spróbować, jak nie wyjdzie - nie trać więcej czasu, po prostu to zrób. Gdy doczekasz się telefonu z awanturą, przygotuj sobie odpowiedź w rodzaju: "Tak, Wielki Szefie, postanowiliśmy zrezygnować z oficjalnej metody firmy, gdyż gwarantowała klęskę. Jeśli ma pan do nas pretensje, to mogę wraz z zespołem odejść już dzisiaj. Jeśli nie, proszę dać nam spokój i powiedzieć zespołowi kontrolnemu, żeby też dał nam spokój. Mamy robotę".
7. "Członkowie zespołu natomiast są jak rodzina. Kierownik powinien nie tylko traktować ich w sposób uczciwy i profesjonalny, lecz także czuć się za nich odpowiedzialny."
"W każdym razie walka z firmową biurokracją należu do kierownika. Nie chcielibyśmy, by fachowcy tracili czas i energię na utarczki z księgowością. By wdawali się w dyskusje, czy dopuszczalne było zamówienie pizzy z dodatkami dla ludzi pracujących do późnego wieczora, czy też wystarczyłaby zwykła pizza".
8. Kierownik powinien mieć wolną rękę przy doborze zespołu.
"Można izolować członka zespołu, którego narzucono wbrew woli kierownika. Daje się temu człowiekowi jakiś nieszkodliwy podprojekt do wykonania lub wysyła, by, do czasu zakończenia projektu, badał obyczaje godowe afrykańskich muszek tse-tse".
"Często przy końcu projektów będących na drodze do klęski sytuacja staje się rozpaczliwa. Dyrekcja szafuje forsą. 'Chcesz jeszcze 20 osób?'. Zawsze chcę. Posyłam ich do obsługi ekspresu do kawy, wymiany bezpieczników i różnych innych tegotypu rzeczy. W tym czasie zajmuję się ważniejszymi sprawawmi".
9. Tworzenie zespołu. Grupa ludzi to jeszcze nie zespół. A już na pewno nie zgrany, dobrze współpracujący zespół. Nie wystarczy "wziąć sześciopaku programistów i wrzucić ich do projektu".
Oprócz ról technicznych, należy uwzględnić role psychologiczne: przewodniczący, kształtujący, agent, kontroler, wyrobnik, pracujący w zespole, badacz zasobów, kompletujący.
10. Warunki pracy. "Wyłączcie telefony. Jeżeli możecie, opanujcie całe piętro lub nawet budynek. Wywieście piracką flagę na szczycie budynku. Ustawcie strażnika, który będzie strzelał do niepożądanych gości".
11. Triage. Czyli priorytety. Podziel zadania na "zrobić koniecznie", "powinno się zrobić" i "ewentualnie zrobić". Podziel porządnie, realizuj w tej kolejności. Kluczowe dla sukcesu.
12. Projekt na drodze do śmierci to nie poligon doświadczalnych dla nowych, narzuconych z góry procesów i narzędzi.
"Okazało się, że praca przy projekcie idzie znacznie wolniej. Wszyscy czytali instrukcje, uczyli się programów narzędziowych oraz zastanawiali, co zrobić dalej (i robili ponownie to, co już wcześniej zrobili w "złej" kolejności)".
13. Zarządzaj ryzykiem. Wywołaj wszystkie wilki, ustaw je w rządku i codziennie się im przyglądaj. Ryzyko może być też pozytywne. Wykorzystaj szanse, które się pojawiają.
14. Zbieraj i dokumentuj doświadczenia i najlepsze praktyki na bieżąco. Przyda się na przyszłość.
"Co gorsza, w projektach zmierzających do klęski panuje duża śmiertelność. Ludzie, którzy mogliby najwięcej doradzić przy następnym projekcie, odeszli, zostali wyrzuceni, popełnili samobójstwo, mieli załamanie nerwowe lub otoczyli się skorupą cynizmu".
15. "Wiedz, że coś się dzieje", czyli sygnały, na które warto zwrócić uwagę:
- "Im więcej rysunków z Dilbertem pojawia się na drzwiach i tablicach ogłoszeń, tym gorzej z projektem".
- "Nadmiar wisielczego humoru. Jeśli członkowie zespołu zaczynają przychodzić do pracy w czarnych koszulach lub nadawać muzykę pogrzebową przez głośniki, to mamy kłopoty".
Książka, mimo niewielkich rozmiarów i swobodnego, nasyconego humorem tonu, jest dość ciężkostrawna. Autor obiecywał zwięzłość, a większość spostrzeżeń powtarzana jest wielokrotnie. Przechodząc przez kolejne zagadnienia, miałam wrażenie, że właściwie niczego się nie dowiaduję. Opisane sytuacje i problemy rzeczywiście występują w przyrodzie. Przeczytałam jak sklasyfikować projekty; graczy politycznych związanych z projektami; członków zespołu pod względem ról psychologicznych. W tym miejscu, podążając za radą samego autora, pozostaje spytać: "Co z tego?". Jak mogę wykorzystać tę wiedzę? Na te pytania jednak nie dostaję już odpowiedzi.
Z drugiej strony książka przedstawia zagadnienia, którym warto poświęcić kilka chwil podczas czytania. Porównać z własnymi doświadczeniami i wnioskami. Uśmiechnąć się od czasu do czasu.
1. Dlaczego projekty wkraczają na drogę ku klęsce?
- Aby zdobyć kontrakt przyjmowany jest nierealny budżet i nierealny harmonogram. Obiecuje się nierealną ilość funkcjonalności.
- Kierownictwo wierzy, że projekt można wykonać o 10% szybciej/taniej, jeżeli tylko dość mocno się tego chce.
- Niedoszacowanie pracochłonności, z uwagi na naiwny optymizm młodości ("Zrobimy to w weekend!") i mentalność komandosów ("Prawdziwi programiści nie muszą spać!")
- Próby wykorzystania najnowszej, niesprawdzonej i nieobeznanej technologii jako "magicznej różdżki", która pozwoli zrealizować projekt znacznie szybciej i taniej.
- Wiara w liniową zależność zasobów od czasu. (Problem jest szerzej opisany w książce "Mityczny osobomiesiąc" i streszczony przez prawo Brooksa: "Dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej".)
- Nadmierna formalizacja procesu. Programista, który pisze wielostronicowy raport, nie programuje.
- Polityka.
Lub też, cytując jedną z pierwszych stron: "Projekty bywają marszami ku klęsce, ponieważ kierownictwo to obłudne sukinsyny, a użytkownicy są naiwni i nie myślą realnie". ;)
2. Należy zidentyfikować głównych graczy politycznych. Najlepiej, by cały zespół wiedział, kim są. Właściciel, mistrzowie, użytkownicy, pośrednicy, interesariusze. Kto ma być szczęśliwy podczas trwania projektu. Kto będzie próbował go sabotować. Do kogo się zwrócić w razie problemów.
3. Projekty dzielimy na cztery rodzaje:
- "Mission impossible" - wysokie szanse na sukces, wysokie zadowolenie zespołu. "Kierownik projektu to przystojny hollywoodzki bohater, hakerzy są genialni i Bóg jest po stronie zespołu. Członkowie zespołu są fanatycznie lojalni wobec siebie."
- "Brzydkie projekty" - wysokie szanse, niskie zadowolenie. "To projekty, w których członkowie zespołu są barankami ofiarnymi, które kierownik projektu zarżnie z zimną krwią, żeby doprowadzić projekt do udanego zakończenia."
- "Projekty samobójcze" - niskie szanse, niskie zadowolenie. "Wszyscy są skazani na zgubę i wszystko jest żałosne".
- "Kamikadze" - niskie szanse, wysokie zadowolenie.
4. Należy określić stopień zaangażowania członków zespołu. Może się zdarzyć, że niektórzy będą mieli rodziny, albo nawet hobby.
"Zaangażowanie zależy także w znacznej mierze od tego, czy kierownik projektu potrafi wzbudzić w pracownikach uczucie lojalności i zaangażowania. Jest to w pewnym stopniu sprawą jego charyzmy. Bywają kierownicy, którzy umieją stworzyć taką atmosferę, że reszta zespołu, nie bacząc na związane z projektem ryzyko, pójdzie za nimi na koniec świata. Inni kierownicy nie skłonią zespołu do żadnego dodatkowego wysiłku, nawet gdyby chodziło o uratowanie ludzkości przed inwazją kosmitów".
"Niezależnie jednak od typu osobowości, nikomu nie zaszkodzi praca po 10 godzin dziennie. Kiedy już projekt wystartuje, można spodziewać się po wszystkich 60 godzin pracy tygodniowo. Jeżeli tego nie robią, sprawdź, czy coś w organizacji projektu nie powoduje frustracji."
"Kierownik projektu powinien poświęcić projektowi maksimum swego czasu. Po pierwsze, musi służyć przykładem. Nie może oczekiwać, by członkowie zespołu pracowali w dodatkowych godzinach, jeśli sam tego nie robi. Po drugie, musi być na miejscu, żeby odpowiadać na pytania, stawić czoła biurokracji, pokonywać trudności, które pojawią się w tych oddatkowych godzinach."
Wszystko jednak z umiarem. Kogoś, kto pracuje więcej niż 80-90 godzin tygodniowo, kierownik powinien stanowczo odesłać do domu na odpoczynek.
5. Motywacja. "Pieniądze, korzyści, wygoda i tak dalej, to czynniki 'higieny'. Ich brak wywołuje niezadowolenie. Nie są one jednak źródłem zadowolenia z pracy ani też źródłem potrzebnego ludziom wewnętrznego napędu. O napędzie decydują takie sprawy, jak poczucie osiągnięcia czegoś, duma z wykonania dobrej roboty, zwiększona odpowiedzialność, awans i rozwój osobisty. Tajemnica polega na wzbogacaniu pracy".
Ładna premia na zakończenie projektu ("Za 10 000 dolarów nagrody można kupić nowy samochód lub spędzić urlop na Bali".) jest zawsze mile widziana. Choć trzeba pamiętać, że perspektywa dużych sum różnie wpływa na ludzi ("George miał czelność zwolnić się w Wigilię po to tylko, żeby być z tąswoją beznadziejną rodzinką. A to przecież najgorętszy okres prób. Przez niego premia przejdzie nam koło nosa").
Nie ma liniowej zależności między wielkością premii a wydajnością. Dyrekcje niektórych firm oferowały pracownikom podwójną premię wierząc, że skłoni to ich do podwojenia liczy godzin pracy. Jeśli jednak ktoś pracuje po 18 godzin na dobę, to już z arytmetyki wynika, że nawet przy największym poświęceniu nie będzie mógł pracować dwa razy dłużej.
Premia musi być wiarygodna. Zespół musi w nią wierzyć. Ludzie muszą być przekonani, że dyrekcja nie wymiga się od jej wypłacenia w jakiś pokrętny sposób.
6. "Wpierw rób, a potem przepraszaj". Prośby o zwolnienie z różnych biurokratycznych przepisów, które utrudniają pracę przy projekcie, mogą być stratą czasu. Warto spróbować, jak nie wyjdzie - nie trać więcej czasu, po prostu to zrób. Gdy doczekasz się telefonu z awanturą, przygotuj sobie odpowiedź w rodzaju: "Tak, Wielki Szefie, postanowiliśmy zrezygnować z oficjalnej metody firmy, gdyż gwarantowała klęskę. Jeśli ma pan do nas pretensje, to mogę wraz z zespołem odejść już dzisiaj. Jeśli nie, proszę dać nam spokój i powiedzieć zespołowi kontrolnemu, żeby też dał nam spokój. Mamy robotę".
7. "Członkowie zespołu natomiast są jak rodzina. Kierownik powinien nie tylko traktować ich w sposób uczciwy i profesjonalny, lecz także czuć się za nich odpowiedzialny."
"W każdym razie walka z firmową biurokracją należu do kierownika. Nie chcielibyśmy, by fachowcy tracili czas i energię na utarczki z księgowością. By wdawali się w dyskusje, czy dopuszczalne było zamówienie pizzy z dodatkami dla ludzi pracujących do późnego wieczora, czy też wystarczyłaby zwykła pizza".
8. Kierownik powinien mieć wolną rękę przy doborze zespołu.
"Można izolować członka zespołu, którego narzucono wbrew woli kierownika. Daje się temu człowiekowi jakiś nieszkodliwy podprojekt do wykonania lub wysyła, by, do czasu zakończenia projektu, badał obyczaje godowe afrykańskich muszek tse-tse".
"Często przy końcu projektów będących na drodze do klęski sytuacja staje się rozpaczliwa. Dyrekcja szafuje forsą. 'Chcesz jeszcze 20 osób?'. Zawsze chcę. Posyłam ich do obsługi ekspresu do kawy, wymiany bezpieczników i różnych innych tegotypu rzeczy. W tym czasie zajmuję się ważniejszymi sprawawmi".
9. Tworzenie zespołu. Grupa ludzi to jeszcze nie zespół. A już na pewno nie zgrany, dobrze współpracujący zespół. Nie wystarczy "wziąć sześciopaku programistów i wrzucić ich do projektu".
Oprócz ról technicznych, należy uwzględnić role psychologiczne: przewodniczący, kształtujący, agent, kontroler, wyrobnik, pracujący w zespole, badacz zasobów, kompletujący.
10. Warunki pracy. "Wyłączcie telefony. Jeżeli możecie, opanujcie całe piętro lub nawet budynek. Wywieście piracką flagę na szczycie budynku. Ustawcie strażnika, który będzie strzelał do niepożądanych gości".
11. Triage. Czyli priorytety. Podziel zadania na "zrobić koniecznie", "powinno się zrobić" i "ewentualnie zrobić". Podziel porządnie, realizuj w tej kolejności. Kluczowe dla sukcesu.
12. Projekt na drodze do śmierci to nie poligon doświadczalnych dla nowych, narzuconych z góry procesów i narzędzi.
"Okazało się, że praca przy projekcie idzie znacznie wolniej. Wszyscy czytali instrukcje, uczyli się programów narzędziowych oraz zastanawiali, co zrobić dalej (i robili ponownie to, co już wcześniej zrobili w "złej" kolejności)".
13. Zarządzaj ryzykiem. Wywołaj wszystkie wilki, ustaw je w rządku i codziennie się im przyglądaj. Ryzyko może być też pozytywne. Wykorzystaj szanse, które się pojawiają.
14. Zbieraj i dokumentuj doświadczenia i najlepsze praktyki na bieżąco. Przyda się na przyszłość.
"Co gorsza, w projektach zmierzających do klęski panuje duża śmiertelność. Ludzie, którzy mogliby najwięcej doradzić przy następnym projekcie, odeszli, zostali wyrzuceni, popełnili samobójstwo, mieli załamanie nerwowe lub otoczyli się skorupą cynizmu".
15. "Wiedz, że coś się dzieje", czyli sygnały, na które warto zwrócić uwagę:
- "Im więcej rysunków z Dilbertem pojawia się na drzwiach i tablicach ogłoszeń, tym gorzej z projektem".
- "Nadmiar wisielczego humoru. Jeśli członkowie zespołu zaczynają przychodzić do pracy w czarnych koszulach lub nadawać muzykę pogrzebową przez głośniki, to mamy kłopoty".
Ćma
Rzuciwszy okiem na moje życie nie mogę się oprzeć wrażeniu, że przypominam ćmę, z bezgranicznym zapałem i determinacją lecącą w stronę ognia. W dodatku taką, której ogień wcale by nie interesował, gdyby nie parzył.
W tej chwili jestem ćmą w olbrzymim, zupełnie ciemnym pomieszczeniu. I choć nareszcie mogę swobodnie oddychać i pozwolić trochę odpocząć zmęczonym, obolałym skrzydełkom; tak naprawdę jedyne, czego chcę, to na nowo zachłysnąć się zbyt dużą porcją zbyt intensywnych emocji.
W tej chwili jestem ćmą w olbrzymim, zupełnie ciemnym pomieszczeniu. I choć nareszcie mogę swobodnie oddychać i pozwolić trochę odpocząć zmęczonym, obolałym skrzydełkom; tak naprawdę jedyne, czego chcę, to na nowo zachłysnąć się zbyt dużą porcją zbyt intensywnych emocji.
Subskrybuj:
Posty (Atom)