Jeżeli jesteś szefem zespołu programistów to zobacz jakie błędy popełniają inni, żebyś Ty nie musiał.
Projekt nie jest najważniejszy - najważniejsi są ludzie
Jako programiści, co jest dla nas najważniejsze? Nasze projekty i terminy! Jedynym sposobem na udowodnienie szefowi naszej wartości i możliwości jest zapewnienie, że dostarczamy to, co do nas należy. Gorzej gdy tą mentalność przenosimy po awansie na szefa zespołu programistów chcąc zaimponować swoim szefom przez pokazanie im, że wszystkie projekty są realizowane na czas.
Pamiętaj, że projekty, które realizujesz, będą kiedyś przestarzałe. Będą nikomu niepotrzebną, zapomnianą historią. Ale ludzie, z którymi pracowaliśmy te X lat temu, wciąż będą żyli i może nawet dalej będą z nami pracować (jak nie w tej samej firmie to w innej). Jeśli nie znęcałeś się nad nimi wtedy to nadal będziecie dobrymi znajomymi a to tylko może się przysłużyć Twojej dalszej karierze.
Staraj się aby bezpośrednie spotkania z członkami zespołu nie ograniczyła się zawsze i w 100% na rozmowie o samym projekcie. Oczywiście, zadania postawione przed nami są bardzo ważne. Ale jeśli zbudujesz zespół to nie będziesz już tylko zarządzać zgrają nieznanych sobie bliżej ludzi i zwiększysz produktywność.
Procesy nie służą ulepszaniu statystyk ale rozwojowi
Ambitni menedżerowi wymyślają czasem aby programiści regularnie rejestrowali swój czas pracy i to tak dokładnie jak to możliwe. Na podstawie tych danych szefowie próbują potem wywnioskować coś o wydajności zespołu. Tymczasem takie dodatkowe zajęcie wymaga od programistów sporego wysiłku: muszą oni o tym pamiętać i wprowadzać te wszystkie wartości regularnie. Ktoś potem też te dane musi zebrać i wygenerować w postaci wykresów czy innych statystyk.
To wcale nie pomaga programistom w produktywności, ani w żaden sposób nie ułatwia ich pracy. Dodajesz w ten sposób tylko więcej procesów do ich pracy - bez żadnych korzyści. Głównym priorytetem programistów jest ukończenie projektu, a nie dostarczanie danych statystycznych. Każdy wprowadzony proces powinien pomóc im lepiej pracować nad projektem, zamiast obciążać ich większą ilością pobocznych zadań niż ich rzeczywista praca.
Nie zmuszaj programistów do rywalizacji
„Konkurencja poprawia wydajność”? Jeśli zastosujemy tę mentalność do rozwoju oprogramowania, zaczniemy wprowadzać procesy takie jak „zobacz kto stworzył najmniej błędów”. A może moglibyśmy również sprawdzić ilość wkładu w kod każdego członka zespołu, podzielić ją przez liczbę błędów w tych fragmentach kodu i w ten sposób zmierzyć osiągnięcia każdego dewelopera z osobna? Pozwólmy im konkurować o miano najbardziej produktywnego programisty.
Nie rób tak. Praca to nie olimpiada.
Ciągła konkurencja sprawi, że środowisko pracy będzie nieprzyjazne. Każdy będzie przychodził myśląc o tym, kto będzie jego następnym rywalem. Zbudujesz bardzo niechętny do współpracy i dysfunkcyjny zespół. Kraj, w którym toczy się wojna domowa, upadnie z powodu sił zewnętrznych. Podobnie organizacje z wewnętrznie konkurującymi, dysfunkcyjnymi zespołami przegrają z konkurencją zewnętrzną.
Nie szczędź pochwał
Jeżeli bliżej Ci do pokolenia 40+ niż 20+ to zapewne zostałeś wychowany w mentalności, że niejako domyślnie oczekuje się dobrze wykonanej pracy. To jest nasza odpowiedzialność i nie ma tu niczego, co wymagałoby pochwały, prawda? Ba, szefowie boją się inflacji pochwał i rezerwują je dla naprawdę dużych osiągnięć.
Błąd. Budujesz w ten sposób kulturę braku wdzięczności, w której po pewnym czasie ludzie zaczną wykonywać tylko podstawowe czynności. Ograniczą się do minimum ponieważ nikt nie będzie doceniał ich wkładu. Jeśli poprzeczka do usłyszenia „dziękuję” zostanie postawiona zbyt wysoko, nie będzie sensu zawracać sobie głowy jej osiąganiem. W efekcie tylko kilku najlepszych pracowników będzie otrzymywało uznanie czy podziękowania. Wkrótce większość ludzi zacznie się zastanawiać, po co w ogóle przychodzi do pracy (oprócz konieczności opłacenia rachunków).
