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!
Brak komentarzy:
Prześlij komentarz