Postępowanie z zakałami projektu

Oryginalny post: Dealing With Bad Apples

Autor: Jeff Atwood

Robert Miesen przysłał mi następującą historię o patologii projektu:

Byłem częścią zespołu, który pisał internetowy system do aplikowania o pracę i klasyfikowania kandydatów (klient nazywał to kioskiem pracy). Razem z zespołem i klientem uzgodniliśmy, że do zaimplementowania tego kiosku użyjemy Windowsa, Apache'a, PHP5 oraz ZendFrameworka -- wszyscy się na to zgodzili oprócz jednego członka zespołu, którego będę nazywał "Joe". Przez całą fazę ustalania technologii Joe zalecał użycie JavaScriptu mimo, iż klient całkiem jasno określił oczekiwania, że większość kiosku, wraz z całą walidacją, ma być zaimplementowana z użyciem technologii po stronie serwera.

Fakt, iż klient to zatwierdził, jakkolwiek, nie powstrzymał Joe od dalszego zachęcania do JavaScriptu -- o zgrozo. Za każdym razem, gdy nasz projekt napotykał na przeszkody, Joe rozpoczynał tyradę o tym, o ile prostsze byłoby nasze życie, jeżeli tylko pisalibyśmy ten kiosk z użyciem JavaScriptu. Joe ciągle sprzeczał się o to, że wszystko co robimy jest źle, ponieważ nie robimy tego za pomocą JavaScriptu. Nie pofatygował się nawet nauczyć technologii, których używaliśmy, a kiedykolwiek jakiś kolega z zespołu próbował grzecznie przywrócić go do porządku (zazwyczaj używając poczty elektronicznej), Joe po prostu obrażał biedaka. W swoim najgorszym momencie pro-JavaScriptowego fanatyzmu Joe regularnie rzucałby komentarzami w stylu: "Cóż, jeśli tylko robilibyśmy to za pomocą JavaScriptu,", do tego stopnia, że zespół lepiej by na tym wyszedł, gdyby Joe odszedł (albo został przeniesiony bądź zwolniony).

Po przeczytaniu tej historii, musiałem powstrzymać się od chęci pochylenia się do przodu, podparcia brody w zamyśleniu, zmarszczenia czoła i zapytania -- czy próbowaliście JavaScriptu?

Robert myślał, że to była ostrzegawcza historia na temat uzależnienia od technologii, ale ja dostrzegam co innego: problematyczny członek zespołu, typowa zakała.

Jestem pewien, że "Joe" miał najlepsze intencje, ale w momencie, gdy aktywnie agitujesz przeciwko projektowi i postępujesz wbrew woli kolegów z zespołu -- jesteś obciążeniem dla projektu.

Koszt problematycznego personelu w projekcie jest poważny, jak jest to opisane w rozdziale 12 książki McConnella Rapid Development: Taming Wild Software Schedules.

Jeśli tolerujesz choć jednego programistę, którego reszta uważa za problem, ranisz morale dobrych programistów. Dajesz do zrozumienia, że nie tylko oczekujesz tego, aby pracownicy dawali z siebie wszystko; oczekujesz od nich, aby to robili, kiedy inni współpracownicy pracują przeciwko nim.

W przeglądzie 32 zespołów zarządzających, Larson i LaFasto zauważyli, iż najczęstsze skargi od członków zespołu dotyczyły tego, że ich kierownicy byli niechętni do konfrontacji i rozwiązywania problemów związanych z kiepską wydajnością, spowodowaną indywidualnymi członkami zespołu. (Larson i LaFasto 1989). Donoszą, iż "bardziej niż przez jakikolwiek inny aspekt przywództwa, wydajność pracowników jest zaburzona przez kierowników, którzy są niechętni do bezpośredniego i efektywnego radzenia sobie z egoistycznymi oraz nieprzykładającymi się współpracownikami." Dalej dochodzą do tego, iż jest to kluczowy problem, którego nie dostrzega kadra zarządzająca, ponieważ menedżerowie zawsze uważają, że ich zespoły lepiej sobie radzą, niż członkowie tych zespołów.

Jak identyfikujemy problem z personelem? To nie takie trudne jakby mogło się wydawać. Kiedyś jeden z moich przyjaciół określił kogoś w swoim zespole -- i to jest dosłowny cytat -- mianem "raka". W momencie kiedy Ty bądź ktokolwiek inny z zespołu używacie słów typu rak do opisania kolegi, macie doczynienia z poważną patologią projektu. Nie musicie się przyjaźnić z każdym członkiem projektu, niemniej jednak to pomaga, ale pewien podstawowy poziom osobistego i profesjonalnego szacunku jest konieczny w każdym zespole, by normalnie funkcjonować.

Steve przedstawia kilka znaków ostrzegawczych mówiących o tym, że macie do czynienia z zakałą w zespole:

  1. Ukrywają swoją niewiedzę zamiast uczyć się od współpracowników. "Nie wiem jak wyjaśnić mój projekt; Po prostu wiem, że działa." albo "Mój kod jest zbyt skomplikowany, by go testować." (Oba stwierdzenia są prawdziwymi cytatami.)
  2. Posiadają nadmierną potrzebę prywatności. "Nie potrzebuję, aby ktokolwiek przeglądał mój kod."
  3. Są terytorialni. "Nikt poza mną nie może poprawiać błędów w moim kodzie. Teraz jestem zbyt zajęty, by je poprawić, ale zrobię to w następnym tygodniu."
  4. Narzekają na decyzje zespołu i powracają do starych dyskusji długo po tym, jak zespół ruszył dalej. "Wciąż uważam, iż powinniśmy się cofnąć i przeprojektować to, o czym rozmawialiśmy w zeszłym miesiącu. To, na co się zdecydowaliśmy nie będzie działało."
  5. Zespół dowcipkuje bądź narzeka regularnie na tę samą osobę. Programiści często nie narzekają bezpośrednio, więc musisz popytać, czy jest jakiś problem, gdy słyszysz wiele żartobliwych komentarzy.
  6. Nie udzielają się w aktywnościach zespołu. W jednym z projektów, w których pracowałem, na dwa dni przed ostatecznym terminem, programista poprosił o dzień urlopu. Powód? Chciał spędzić dzień na wyprzedaży odzieży męskiej w pobliskim mieście -- wyraźny znak, że nie zintegrował się z zespołem.

Pozwól, że wyrażę się jasno na ten temat: jeśli Twój team leader bądź menedżer nie radzi sobie z zakałami w Twoim projekcie, to nie wykonuje on swojej pracy.

Nigdy nie powinieneś obawiać się usunięcia -- albo nawet zwolnienia -- ludzi, w których interesie nie leży dobro zespołu. Możesz rozwinąć umiejętność, ale nie możesz rozwinąć pozytywnego nastawienia. Im dłużej te zakłócające spokój osobistości są uwikłane w projekt, tym gorszy tego efekt. Będą powoli rozsiewać truciznę w Twoim projekcie, w formie kodu, stosunków oraz kontaktów.

Usuwanie kogoś z zespołu jest bolesne; dla nikogo nie jest zabawne. Ale zdanie sobie sprawy z tego, że powinno się usunąć kogoś sześć miesięcy temu, jest o wiele bardziej bolesne.

Data publikacji oryginału: kwiecień 17, 2008

9 komentarze:

paffnucy pisze...

Świetny blog. Czytam go od początku, w sumie już nawet nie śledzę bloga Jeffa, bo skupiam się na waszym. Tłumaczenia może nie zawsze są idealne, ale macie fajny sposób pisania i czyta się z przyjemnością :) Trzymajcie tak dalej, pozdrawiam!

zbiju pisze...

"JavaScripta"? moim zdaniem powinno byc "JavaScriptu"

poza tym, fajny blog, ale takie bledy rażą okropnie ;)

mg pisze...

Poprawione.

sprae pisze...

Nieposłusznym członkom zespołu zwykle polecamy ten film http://www.youtube.com/watch?v=hspNaoxzNbs

Anonimowy pisze...

Interesuje mnie przeznaczenie jabłka. Jaki ono ma związek przekazem? Rzecz wygląda coraz to gorzej, ale przecież nikt na ten stan nie wpływa. To naturalny proces. Natomiast treść ujęta przez głównego autora ukazuje kretynizm dwóch jednostek. Wnioskując, kretynizm jest naturalny?

mg pisze...

Według mnie jabłko zostało wybrane dlatego, że kojarzy się z czymś zdrowym.
Kolejne fazy rozkładu lub psucia mają symbolizować stan zespołu, który posiada "zakałę" na pokładzie. I chyba nic więcej.
Co więcej proces przedstawiony na obrazku, niekoniecznie musi być spowodowany postępem czasu. Może to być choroba, wirus itp.

Tak ja to odbieram.

rafek pisze...

@Anonimowy: Wydaje mi się, że to trochę gra słówek i obrazków. Oryginalny tytuł to "Dealing with Bad Apples", czyli dosłownie "Postępowanie ze zgniłymi jabłkami". "Bad apple" tłumaczy się na polski jako "zakała", "czarna owca", więc obrazek nie spełnia do końca swojej roli. Ale generalnie pokazany jest proces "rozkładu" zespołu, w którym zakała "rozsiewa truciznę". Takie jest moje zdanie. :)

batman pisze...

Czasami taka zakała jest potrzebna w zespole jako przestroga przed tym, kim można się stać. Zamiast usuwać taką osobę, lepiej ją wyedukować. W końcu każdy jest człowiekiem i każdy ma prawo popełniać błędy.

Anonimowy pisze...

Do pkt1. dodałbym "Nie mogę tego poprawić/zrobić/dodać, bo wymaga to dużych zmian w logice programu". Również autentyk, wykorzystywany dość często przez autora.

Prześlij komentarz

Related Posts with Thumbnails