Kopanie studni w sto osób, czyli rzecz o zespole
-
- Jakub Chabik,
- 16.07.1999
Typ 8. Katalizator
Katalizator właściwie nie robi nic szczególnego. Gdyby nadal rozliczano na podstawie zaprogramowanych linii kodu lub liczby zaprojektowanych klas, to Katalizator byłby najgorzej opłacanym członkiem zespołu. Jednak praktycznie żadna dyskusja nie może się odbyć bez niego. Katalizator każe sobie wyjaśniać szczegóły każdego rozwiązania i nie spocznie, dopóki nie zrozumie go. Często takie dyskusje obnażają ewidentne słabości projektowe, które kiedy indziej przeszłyby nie zauważone. Charakterystyczne wyrażenia: "Mam wrażenie, że Jacek boryka się z podobnym problemem...", "Nadal nie rozumiem, po co ładujemy te dane do pamięci, skoro odwołujemy się do nich tylko dwa razy...", "Ładnie opowiadasz, ale gdyby to można było przeczytać w twojej dokumentacji, byłoby jeszcze lepiej..."
Katalizator znakomicie łączy zespół. Najlepszy sposób zarządzania nim to zapoznawanie go z każdym elementem systemu, dawanie mu czasu na zrozumienie problemu i wysłuchanie jego uwag. W przypadku konfliktu w zespole Katalizator na ogół potrafi rozwiązać go skutecznie i bez hałasu.
Nowi członkowie zespołu
W podręcznikach matematyki dla szkoły podstawowej można znaleźć następujące zadanie: "Sześciu robotników kopie fundamenty domu w dwa dni robocze po osiem godzin każdy. W jakim czasie wykopie fundamenty domu osiemnastu robotników?". Na końcu książki można znaleźć prawidłową odpowiedź: pięć godzin i dwadzieścia minut.
Jak widać, od najmłodszych lat jesteśmy przyzwyczajani do traktowania czasu pracy jako takiego samego zasobu, jak cement, woda czy pieniądze. Przyzwyczaja się nas do korzystania z trywialnej proporcji traktującej czas pracy i liczbę osób jako zamienne wielkości. Stąd wziął się słynny "osobo-miesiąc", poddany druzgocącej krytyce przez Fredericka Brooksa w książce The Mythical Man-Month. 20th Anniversary Edition with Four New Chapters. Ciekawe, jak autor zacytowanego zadania (matematyk, zapewne) odpowiedziałby na pytanie: "A ile czasu zajmie wykopanie fundamentów domu stu robotnikom?".
W przypadku informatyków "kopiących" fundamenty systemu informatycznego sprawa komplikuje się jeszcze bardziej. Po pierwsze, członkowie zespołu nie są zamienni. Po drugie, ich wydajność może się różnić nawet o rząd wielkości. Po trzecie, nie wystarczy po prostu kopać, trzeba jeszcze kopać we właściwym miejscu i starannie.
Przyjęcie nowych członków do zespołu to coś więcej niż tylko podpisanie umowy o pracę, przydzielenie biurka z komputerem i założenie konta sieciowego. To także, czy raczej, przede wszystkim:
Często popełnianym błędem jest przyjmowanie pracowników hurtem. Skutek jest taki, że zamiast wdrożyć się w zadania zespołu, przejąć jego kulturę i standardy, dezorganizują jego pracę, dominują i wprowadzają chaos. Oczywiście, po pewnym czasie wykształci się nowa kultura pracy, ale sporo wody może w Wiśle upłynąć, a stara atmosfera pracy już nie wróci. Jest to dobre tylko wtedy, gdy jej zmiana jest właśnie celem takiej operacji .
Innym częstym błędem jest wiara, że nowy pracownik może stać się pełnoprawnym członkiem zespołu natychmiast albo po tygodniu. Może tak się dzieje w produkcji młotków, ale nie w tworzeniu oprogramowania. Naiwnym jest sądzić, że nowicjusz osiągnie pełną produktywność bez wykonania przynajmniej dwóch prostych, quasi-prototypowych zadań - jednego w pełni samodzielnego, drugiego we współpracy z innymi członkami grupy.
Jeszcze innym błędem jest niepytanie nowego człowieka, czym chciałby się zajmować. Czy bardziej interesują go zagadnienia związane z bazą danych, czy raczej projektowanie interfejsu użytkownika? Czy wolałby dostarczać klasy biblioteczne, czy woli pracować na "froncie" robót? Z kim, jego zdaniem, pracowałoby mu się dobrze, a z kim nie najlepiej? I nie chodzi o to, żeby stosować politykę "każdy robi, co mu się podoba" - nie, firma to nie uczelnia. Chodzi o to, żeby pracownik miał poczucie, że jego szefom zależy na jego rozwoju zawodowym, a on sam realizuje swoje ambicje.
Głęboko wierzę, że każdy nowy pracownik powinien mieć swojego mistrza, mentora. Nie chodzi o jakieś sformalizowane relacje, ale wskazanie mu palcem: "Słuchaj, ten facet jest naprawdę niezły i sporo możesz się od niego nauczyć". Systemy informatyczne to trudna, interdyscyplinarna dziedzina; nie sposób nauczyć się ich tworzenia inaczej niż pod kierunkiem kogoś bardziej doświadczonego.
Konstruktywna, wzajemna weryfikacja
Zadania członków zespołu powinny być starannie weryfikowane na forum zespołu i wszyscy powinni podzielić się z delikwentem swoimi uwagami. To pozwoli mu usprawnić swoją pracę i jednocześnie poczuć bardzo ważną prawdę:
Członek zespołu nie powinien wahać się, czy pójść do kolegi i powiedzieć mu: "Słuchaj, stary, musisz poprawić tę metodę, bo sypie się w nieoczekiwanych momentach. Nigdy nie zrobimy sensownego produktu, jeżeli tego nie poprawisz".
Z doświadczenia wiem, że niektórym ciężko jest to zaakceptować. Informatycy, choć werbalnie zgadzają się z tą opinią, często "kryją" błędy koleżanek i kolegów, uważając taką krytykę za przejaw braku lojalności. Czasami takie próby wzajemnej weryfikacji prowadzą do konfliktu. Ale zastanówmy się - jeżeli ktoś nie przyjmuje krytyki, to czy nie lepiej, żeby wyszło to na początku zanim zostanie wdrożony w główny tok prac? Czy lepiej "kryć" kolegę i brać baty od szefa zespołu albo klienta? Czy może lepiej rozsądnie, konstruktywnie i starannie przedstawić autorowi swoje uwagi na temat jego dokonań? Warto spróbować - to boli mniej, niż można by przypuszczać, a korzyści są ogromne!
<hr size=1 noshade>Tekst jest fragmentem rozdziału Proces i produkt książki Jakuba Chabika - Praktyka skutecznego programowania, która ukaże się we wrześniu br. nakładem poznańskiego wydawnictwa Nakom.
<sup>1</sup> Określenie zaczerpnięte z książki Świat według Garpa Johna Irvinga.
