Jak efektywnie realizować zadania, kiedy jesteś tylko szeregowym programistą

Oryginalny post: Getting Things Done When You're Only a Grunt

Autor: Joel Spolsky

Ta strona poświęcona jest głównie zarządzaniu projektami programistycznymi. Jednak czasem nie masz na tyle władzy, aby w swojej firmie dokonywać przemian za pomocą dekretów. Oczywiście, jeśli jesteś tylko szeregowym programistą, na samym dole hierarchii, nie możesz tak po prostu nakazać ludziom, aby tworzyli harmonogramy czy korzystali z systemu zarządzania bugami. W rzeczywistości, nawet jeśli jesteś kierownikiem projektu, prawdopodobnie odkryłeś, że zarządzanie programistami jest bardzo podobne do hodowania kotów, tylko nie tak zabawne. Nie wystarczy, że powiesz "sprawcie, żeby tak było", żeby tak było.

Praca w firmie, która ma kiepski wynik w Teście Joela, może być frustrująca. Nieważne jak dobry kod piszesz, Twoi współpracownicy piszą kod tak mierny, że wstydzisz się w ogóle przyznać do swojego udziału w projekcie. Albo być może decyzje zarządu odnośnie tego, jaki kod pisać, są nietrafione i jesteś zmuszony marnować swój talent na debugowanie na systemie AS/400 gry w planowanie emerytury dla dzieci.

Zawsze możesz zrezygnować, tak sądzę. Ale załóżmy, że jest jakiś powód, dla którego tam utknąłeś. Nie możesz jeszcze sprzedać przyznanych Ci akcji firmy, nie ma lepszego miejsca pracy w Wygwizdowie a może Twój szef wziął za zakładnika kogoś, kogo kochasz. W każdym bądź razie, życie w takim kiepskim zespole jest w stanie doprowadzić do wściekłości. Istnieją jednak pewne strategie, dzięki którym możesz popracować nad swoim zespołem od podstaw, a ja chciałbym teraz kilkoma z nich się z Toba podzielić.

Strategia 1. Po prostu to zrób

Wiele da się zrobić w celu poprawienia sytuacji w projekcie, jeśli po prostu jedna osoba będzie to robić. Nie macie serwera do codziennych buildów? Stwórz taki. Zrób to na swoim komputerze — skonfiguruj go tak, żeby w nocy uruchumiał builda i rozsyłał maile z wynikami. Build wymaga za dużo kroków? Napisz plik makefile. Nikt nie robi testów interfejsu użytkownika pod kątem używalności? Sam przeprowadzaj takie testy korytarzowe z przypadkowymi ludźmi, używając w tym celu kartki papieru albo prototypu napisanego w VB.

Strategia 2. Wykorzystaj potęgę marketingu wirusowego

Wiele ze strategii z Testu Joela jest w stanie wdrożyć nawet jedna osoba w niezbyt zorganizowanych zespołach. Niektóre z nich, jeśli zrobi się to odpowiednio, rozprzestrzenią się w całym zespole.

Przykładowo, załóżmy, że nikt w Twoim zespole nie daje się przekonać do korzystania z systemu zarządzania bugami. Nie pozwól, żeby Cię to zniechęciło. Po prostu sam z takiego systemu korzystaj. Wprowadzaj do niego bugi, które znajdujesz w swoim kodzie. Jeśli znajdziesz buga, którego ktoś inny naprawdę powinien poprawić, przypisz tego buga do nich w systemie. Jeśli masz dobry system zarządzania bugami, zostanie wysłany do nich e-mail. Ale na początek wystarczy, że będziesz im stale przypominał drogą mailową, że jeszcze nie poprawili tego buga. W końcu zauważą wartość takiego systemu śledzenia bugów i sami zaczną z niego korzystać w prawidłowy sposób. Jeśli zespół QA nie che wprowadzać bugów poprzez system, po prostu odmawiaj przyjmowania zgłoszeń o błędach innymi kanałami. Gdzieś koło trzytysięcznego razu, gdy mówisz ludziom, "Słuchaj, chętnie bym to naprawił, ale na pewno o tym zapomnę. Czy możesz wprowadzić informację o błędzie do systemu?", zaczną tego systemu używać.

Nikt z Twojego zespołu nie chce korzystać z systemu kontroli wersji? Załóż swoje własne repozytorium, nawet na swoim własnym dysku, jeśli nie ma innej możliwości. Nawet bez współpracy ze strony innych członków zespołu możesz wrzucać swój kod do repozytorium, niezależnie od innych. I gdy napotkają na jakiś problem, który system kontroli wersji mógłby rozwiązać (ktoś przez przypadek wpisze rm * ~ zamiast rm *~), przyjdą po pomoc do Ciebie. W końcu ludzie uświadomią sobie, że równie dobrze sami mogliby korzystać z takiego systemu.

Strategia 3. Zgromadź wokół siebie kapitał doskonałości

Zespół nie chce robić harmonogramów? Albo specyfikacji? Zrób swoje. Nikt nie będzie marudził, jeśli poświęcisz dzień lub dwa na napisanie minimalnej specyfikacji bądź harmonogramu dla prac, które zamierzasz wykonać.

Sprowadź lepszych ludzi do swojego zespołu. Zaangażuj się w rekrutację i bierz udział w rozmowach z kandydatami, żeby tych dobrych ściągnąć do swojego zespołu.

Poszukaj ludzi, którzy są zainteresowani rozwijaniem się i są do tego zdolni oraz przeciągnij ich na swoją stronę. Nawet w słabych zespołach prawdopodobnie znajdziesz ludzi, którzy po prostu jeszcze nie mają na tyle doświadczenia, żeby tworzyć znakomity kod. Pomóż im. Zachęć ich do nauki. Rób przeglądy ich kodu. Jeśli zrobią coś głupiego, nie pisz do nich pogardliwych maili, w których wytykasz głupotę w ich kodzie. To ich jedynie rozzłości i przyjmą postawę defensywną. Zamiast tego, delikatnie daj im znać o bugu spowodowanym przez ich kod. Pozwól im samym dojść do tego, co jest przyczyną błędu. Kiedy sami poradzą sobie z bugiem, zapamiętają tę lekcję o wiele lepiej.

Strategia 4. Zneutralizuj przygłupów

Nawet w najlepszych zespołach zdarza się jedna bądź dwie osoby, które, delikatnie mówiąc, nie są zbyt rozgarnięte. W sytuacjach, gdy masz do czynienia z kiepskimi programistami, są dwie główne przyczyny frustracji — kiedy ich kiepski kod psuje Twój dobry kod albo gdy dobrzy programiści muszą marnować czas na sprzątanie po tych słabszych.

Jako szeregowy programista powinieneś dążyć do minimalizacji i powstrzymywania zniszczeń. Prędzej czy później jeden z tych geniuszy spędzi całe dwa tygodnie na wyprodukowaniu kodu tak niewiarygodnie złego, że nigdy nie będzie działać poprawnie. Może Cię kusić, żeby poświęcić piętnaście minut na poprawne napisanie tego od nowa. Powstrzymaj się. Stajesz właśnie przed doskonałą okazją na neutralizację tego kretyna na dobrych kilka miesięcy. Po prostu nie przestawaj zgłaszać bugów w jego kodzie. Nie będzie dla niego innego wyjścia, jak miesiącami siedzieć przy tym kodzie i go poprawiać aż Ty nie będziesz już w stanie znaleźć nowych błędów. W ciągu tego czasu nie będą mogli narobić szkód w innym miejscu.

Strategia 5. Unikaj rozpraszaczy uwagi

Wszystkie przyjazne środowiska pracy są do siebie podobne (prywatne biura, cisza, doskonałe narzędzia, niewiele rozpraszaczy uwagi i jeszcze mniej długich spotkań). Wszystkie nieprzyjazne środowiska są nieprzyjazne na swój sposób.

Złe wiadomości są takie, że zmiana środowiska pracy jest prawie niemożliwa w praktycznie każdej firmie. Długotrwałe umowy najmu moga oznaczać, że nawet CEO nie jest w stanie nic z tym zrobić. To właśnie dlatego tak niewielu programistów ma prywatne biura. Dla firm jest to szkodliwe z co najmniej dwóch powodów. Po pierwsze, trudniej jest takiej firmie pozyskać programistów z najwyższej półki, którzy wybiorą pracodawcę oferującego wygodniejsze warunki pracy (przy założeniu, że inne aspekty są na podobnym poziomie). Po drugie, duża liczba rozpraszaczy może dramatycznie obniżyć produktywność programistów, którzy w takich warunkach nie są w stanie "wejść w strefę" i pozostać w niej tak długo, jak tego potrzebują.

Rozglądnij się za sposobami na ucieczkę z takiego środowiska. Zabierz ze sobą laptopa do firmowej kawiarni, gdzie przez większą część dnia jest pusto (i nikt nie może Cię znaleźć). Zarezerwuj pokój konferencyjny na cały dzień i tam pisz kod. Jednocześnie pokaż za pomocą liczby checkinów, o ile więcej jesteś w stanie zrobić, gdy masz cały pokój tylko dla siebie. Następnym razem, gdy atmosfera zrobi się gorąca ze względu na zbliżający się deadline i Twój kierownik zapyta, czego potrzebujesz, żeby To Zrobić Na Jutro, wiesz co odpowiedzieć. Z pewnością znajdą Ci jakieś biuro na cały dzień. I niedługo zaczną się zastanawiać, co mogliby zrobić, żeby utrzymać tak wysoki poziom produktywności przez cały rok.

Zjawiaj się w pracy poźno i wychodź późno. Te godziny po tym, gdy reszta firmy wybrała się już do domów, mogą być tymi najbardziej produktywnymi. A jeśli większość Twojego zespołu przychodzi do pracy późno, Ty przychodź o 9. W ciągu tych dwóch godzin, które masz do dyspozycji, zanim pozostali zaczną się schodzić i przeszkadzać, zrobisz więcej niż przez resztę dnia.

Nie zostawiaj swojego klienta poczty ani komunikatora włączonych przez cały czas. Jeśli chcesz, sprawdzaj pocztę nawet co godzinę, ale nie zostawiaj klienta włączonego.

Strategia 6. Stań się nieoceniony

Żadna z tych strategii nie zadziała, jeśli sam nie wnosisz dużej wartości. Jeśli nie piszesz dobrego kodu, i to sporo dobrego kodu, ludzie będą mieć do Ciebie pretensje, że dłubiesz sobie przy systemie zarządzania błędami, podczas gdy "powinieneś" pisać kod. Nie ma nic bardziej zabójczego dla Twojej kariery zawodowej niż posiadanie reputacji kogoś, kto bardziej przejmuje się procesem niż tym, żeby cokolwiek ukończyć.

Kiedyś, gdy zaczynałem pracę w pewnej firmie jako szeregowy programista, odkryłem, że ta firma osiągała około 2 punktów w Teście Joela i byłem zdeterminowany, żeby to zmienić. Wiedziałem jednak również, że pierwsze wrażenie jest bardzo ważne. Postanowiłem więc przeznaczyć pierwsze siedem godzin każdego dnia na pisanie kodu, tak jak się tego ode mnie oczekiwało. Nic lepiej nie poprawi Twojego wizerunku w zespole, jak zalew checkinami. Natomiast ostatnią godzinę przed pójściem do domu zarezerowałem sobie na ulepszanie procesu. Wykorzystywałem ten czas na naprawianie rzeczy, które utrudniały debugowanie naszego projektu. Skonfigurowałem dzienne buildy i system zarządzania bugami. Naprawiłem wszystko to, co od długiego czasu stanowiło dla zespołu udrękę i spowalniało cały proces. Pisałem specyfikacje dla pracy, którą miałem danego dnia wykonać. Przygotowałem dokument, w którym opisałem, jak od podstaw przygotować maszynę dla developera w naszej firmie. Gruntownie udokumentowałem ważny, wewnętrzny język, którego nikt wcześniej nie opisał. Powoli proces stawał się coraz lepszy. Nikt poza mną (i moim zespołem, któremu później przewodziłem) nie tworzył harmonogramów ani specyfikacji, ale poza tym osiągnęliśmy 10 punktów w Teście Joela.

Jesteś w stanie wiele poprawić, nawet jeśli to nie Ty rządzisz, ale musisz być jak żona Cezara: poza wszelkimi podejrzeniami. W przeciwnym razie będziesz tylko zdobywał nowych wrogów.

Data publikacji oryginału: grudzień 25, 2001

19 komentarze:

Anonimowy pisze...

Super artykuł, taki bezpośredni :)

Masz jedną literówkę w strategii 5., akapicie pierwszym "wszystkie przyjane", poza tym jest jak najbardziej poprawnie.

Pozdrawiam.

Krzysztof Łojniewski pisze...

Dzięki za artykuł!
Bardzo ciekawe podsumowanie.

Marek Stój pisze...

@Anonimowy
Dzięki, poprawione :]

Tomasz Kowalczyk pisze...

W firmie w której mam przyjemność pracować na szczęście nie ma takiego problemu - pokazałem możliwości jakie oferują różne systemy i kilka z nich zostało wdrożonych od razu. ;]

noisy pisze...

bardzo dobry artykuł. Bardzo motywujący! :)

Anonimowy pisze...

kupa bzdetów i tyle.

Anonimowy pisze...

Zakładam, że kolega autor nie pracował jeszcze w korporacji, bo po przeczytaniu tego artykułu tak mi się zdaje. Ja pracuje już prawie 10 lat w tym zawodzie i na początku miałem podobne ambicje... wręcz niemal identyczne, dlatego opiszę moje negatywne spostrzeżenia.

ad 1.
Prawdopodobnie wszyscy pracownicy oleją mejle wysyłane z automatycznego builda stworzonego przez Ciebie. Będą się burzyć, że spamujesz poczte, itp. Najbardziej aktywne w krytyce będą oczywiście te osoby po których "buildy" nie przechodzą. Jakkolwiek byś się nie starał to ci starsi stażem zawsze powiedzą Ci, że masz źle środowisko postawione, bo "u nich się builduje". A jak się będziesz dopytywał W ten sposób prawdopodobnie zetrzesz się z prawie każdym członkiem zespołu. Jednakże, jeśli "przeżyjesz" pierwszą okres krytyki być może uda się to wdrożyć. Ale pamiętaj: starsi stażem pracownicy, czyli ci z największym autorytetem, a więc ci którzy mogą coś faktycznie zmienić... nie lubią zmian. Autobuildy to przykład mechanizmu zarządzania odpowiedzialnością: Ty jesteś odpowiedzialny za checkin-a w taki sposób, żeby cały projekt działał. Jeśli to nie jest odgórnie wprowdzone to odpowiedzialności nie ma, a więc na twoje, autorskie autobuildy nikt nie zwróci uwagi.

ad 2.
Na dzień dobry dostaniesz reprymendę, że to nie Ty ustalasz kto ma się tym bagaiem zająć (naprawić lub przydzielić dalej). Tym zajmuje się kierownik projektu. Wszelkie tłumaczenia "że to tylko takie info" na nic się nie zda bo (znowu) robisz niepotrzbny spam (jeśli twoje zmagania zostaną potraktowane pobłażliwie) lub (co gorsza, jesli twoje zmagania zostaną potraktowane serio) sprawiasz, że kiero projektu będzie baaardzo nie zadowolony, dlatego że wchodzisz w jego kompetencje. I znowu ostro zadzierasz z ludźmi - tym razem z (prawdopodobnie) twoim przełożonym. Konsekwencję: wylot lub dozgonna niełaska u kiera gwarantowane. Tak czy siak zmiana pracy potrzebna.

ad 3.
Hmmmm.... "A co robiłeś wczoraj? ... Napisałeś se harmonogram dla swoich prac? Przecież to ja Ci ustalam plan prac, po co ci to? Zmarnowałeś dzień pracy." - Kiero projektu.
Nie wyobrażam sobie, żeby szeregowemu programiście pozwolono pójśc na spotkanie HRowców i kandydata na pracownika. Nie masz żadnego wpływu na to czy Ten gośc będzie pracował u Ciebie... twu! (rozpatrujemy wersje z punktu szeregowego programisty...) ...w twoim zespole, te decyzje zapadają bez twojej wiedzy i udziału. A ewentualne próby ingerencji mogą się zakończyć konsenkwencjami... patrz ptk 2.

Anonimowy pisze...

ad 4.
W 100% tak. Jednażke, z czasem możesz stać się nie lubiany w śród załogi. Ktoś w końcu powie "On robił coś podobnego i zrobił to w dwa dni. Ja robię to trzeci tydzień, prosiłem go, ale nawet słowem mi nie poradzi... ch*j i szczurek!" - Ostre, ale prawdziwe (na bazie moich doświadczeń).

ad 5.
Po pierwsze jesteś szeregowym programistą (zgodnie z tym co zakłądamy), więc będzie spory opór, żeby Ci dać konferencyjny do "posiedzenia". Konferencyjny jest dla CEO, projektanów, analityków, na ważne wydarzenia, dla klientów itp. Szeregowy nie dostanie konferencyjnego dlatego, że ten pokój w każdej chwili może być potrzebny komuś ważniejszemu (głupia argumentacja, ale nie do przejścia).
"I niedługo zaczną się zastanawiać, co mogliby zrobić, żeby utrzymać tak wysoki poziom produktywności przez cały rok" - haha. Dyrektor upomni "rozpraszaczy" i jednocześnie zapowie, że wszelkie objawy rozpraszania ludzi mają być kierowane na jego skrzynke (dochowa anonimowości). Będzie wyciągał konsekwencję i zaprowadzi ciszę. Następnie uzna problem za rozwiązany i od Ciebie będzie wymagał równie wysokiej produktywności tak jakbyś siedział sam w pokoju. A jeśli będizesz miał obiekcje to powie Ci, że przecież jesteś dorosły i naucz się asertywności. No i w końcu problem rozwiązany, co nie?! Oczywiście pozostanie tak jak było, bo nikt oprócz Ciebie nie będzie kapował szefowi, ale wysoka produktywność będzie od Ciebie wymagana. W ten sposób nic się w środowisku pracy nie zmiani poza wymaganiami wobec Ciebie - samobój.

"Zjawiaj się w pracy poźno..." - zwolnienie dyscyplinarne? Masz być w pracy o wyznaczonej porze, dlatego, żeby mieć bezpośredni konktakt z ludźmi, z którymi współpracujesz. A nóż Cię ktoś może potrzebować od rana. Po za tym "... i wychodź późno" - nie masz rodziny i przyjaciół z którymi chciałbyś się widzieć po pracy?


Realnie: Im mniejsza firma tym twoje pomysły mają szanse na większe powodzenie. Im większa lub korporacja, będziesz na to pracował latami, a najgorsze co możesz zrobić to zaczynać rewolucję. Na początku zdobądź kolegów i zaufanie, a później dużo podchodów i gadania, czyli takiej firmowej polityki, to chyba jedyne wyjście, żeby cokolwiek ośiągnąć, a na końcu to i tak Ci się odechce. Przeżyłem takie i takie podejście. Zmieniałem firmy kilkukrotnie. Wylądowałem w dużej firmie. Bałagan i godziny gadania o każdą pierdółę (czy to projektową, czy to organizacyją błachostkę i wykłucanie się), ale pewność zatrudnienia i dobra pensja. Teraz mam już w dupie swoją ambiję. Przychodzę, pracuję, wychodzę.

Anonimowy pisze...

Poradnik jak zostac szczurem.

"Zjawiaj się w pracy poźno..." - dokladnie jak to podkreslil przedmowca. Sa wazniejsze sprawy.

Raczej zjawiaj sie najwszesniej jak sie da i wychodz najwczesniej jak sie da. Nie pracujesz dla siebie. Wolny czas poswiec dla wlasnego rozwoju, zeby ktoregos dnia powiedziec "zegnam" i pracowac na swoim.

Po co efektywnie realizowac zadania? Oczekujesz premii? I tak jej nie dostaniesz.

A co jesli stajesz sie kims "waznym" w swojej firmie? - Najlepiej uciekac!, bo twoja nowa ranga pozbawi cie bezposredniego kontaktu z programowaniem, bedziesz sie tylko "spotykal", "rozmawial" i wysylal e-maile. W konsekwencji za pare lat przestaniesz byc programista i zostaniesz super-szczurem.

Krystian pisze...

Świetny artykuł i dobre tłumacznie. Anonimowemu z całą listą pt. "u nas to nie zadziała i tak się nie da" proponuję zmianę pracodawcy. Po co się stresować? :)

Anonimowy pisze...

Tia... wszystko zależy od podejścia i ambicji moi drodzy. "Po co efektywnie realizować zadania?" Bo życie staje się wtedy dużo prostsze i przyjemniejsze, ludzie się mniej kłucą, a efekty ich pracy satysfakcjonują ich samych oraz ich szefów. Po prostu jest tak jak powinno być, ale zrozumie to tylko ten kto miał okazję popracować w zgranym rozsądnym i pracowitym zespole (nie tylko w informatyce). Dziękuję za ten artykuł, nawet jeśli znajdzie się tylko 5 mądrych osób, które właściwie wykorzystają te porady, to i tak świat stanie się o te znikomą cząstkę lepszy... Z drugiej strony, mój kumpel ostatnio zatrudniony w firmie miał inna strategię. Wpadł, znalazł 3 osoby, które się nie bały zagadał, przegadał, zrobił plan, poszedł do szefa, zagadał, przegadał, dostał wolną rękę, zagadał, przegadał, uświadomił wszystkich że ma taki a taki pomysł, żeby ułatwić nam wszystkim życie, pokazaliśmy nasze poparcie, pomogliśmy i dzięki przebojowości i odrobinie rozsądku "nowego, młodego" po miesiącu mamy życie o połowę łatwiejsze. Wszystkich problemów nie usuniesz, zwłaszcza ludzi, ale jak się CHCE to można!

Anonimowy pisze...

Belka z lewej zaslania tekst. Gdyby nie to, moze przeczytalbym potencjalnie ciekawy artykul.

rafek pisze...

@Anonimowy: Jaka rozdziałka? Jaka przeglądarka?

Marek Stój pisze...

@Anonimowy: belka poprawiona :]

Anonimowy pisze...

Mnie też zasłania ale ja mam 1024 na swoim 12".
W ogóle po cholerę komu takie bajery przecież nikt w to nawet nie klika, a wszystkie próby forsowania tego rozwiazania od kilku lat spełzają na niczym

Krystian pisze...

Strategia 4. Zneutralizuj przygłupów nie działa w Agile. Dostarczona funkcjonalność nie spełni definicji DONE i zostanie odrzucona przez Product Ownera. Cały Team ucierpi.

Anonimowy pisze...

Moim zdaniem , jest to nie życiowe, nie praktyczne , szkoda czasu, energii. Jak już jesteś w takiej firmie, to lepiej robić co Ci każą, i tak się nie wybijesz, lepiej na boku robić zdalny projekt ,lub swoją realizację. Nie wierzę, że istnieją takie firmy programistyczne, że ludzie nie chcą nowości , nie chcą się rozwijać , pracuje pare lat i klika firm zwiedziłem , nie spotkałem się z taki nastawieniem jak tu piszesz. Faktycznie musi to być jakieś miejsce za górami , lasami w Chinach. I pewnie ludzie którzy z Tobą pracują mają wykształcenie podstawowe.

Anonimowy pisze...

Dobre - aczkolwiek zgadzam się częściowo z krytyką z komentarzy. U mnie w dużej firmie jako zwykły żuczek nic nie zdziałam. Ba, nawet mój przełożony ma problem żeby coś załatwić. Na szczęście wyżej wprowadzają zmiany ale z różnym powodzeniem. Czasami kupiony system do zarządzania projektem tylko spowalnia całą pracę. Ale rzeczywiście nie wyobrażam sobie pracy bez repozytorium. Budowanie całej aplikacji co jakiś czas i rozsyłanie maili z błędami do osób które wprowadziły zmiany również się przydaje.

nintyfan pisze...

Ze mnie raczej cienias, a nie programista, więc serwer SVN na pewno się przyda. Realizuję własne i duże projekty w C, a nie raz natknąłem się, że chciałem sprawdzić bezpieczeństwo danego wywołania/funkcji, więc zrobiłem to najbardziej prymitywnym sposobem - podmianą paru linijek. Potem na miesiąc nie kontynuowałem projektu, a później przez tydzień nie potrafiłem znaleźć błędu, który sam wprowadziłem.

Prześlij komentarz

Related Posts with Thumbnails