Jestem liderem zespołu z ponad 5 programistami. Mam programistę (nazwijmy go A ), który jest dobrym programistą, który pisze dobry, czysty i łatwy do zrozumienia kod. Jest jednak nieco trudny w zarządzaniu i czasami zastanawiam się, czy naprawdę osiąga słabe wyniki, czy nie.

1. Nasza firma wymaga od programistów wskazywania postępów pracy w używanym przez nas narzędziu do śledzenia błędów, nie tylko w celu monitorowania programistów, ale w celu informowania zainteresowanych stron o postępach. Chodzi o to, że A aktualizuje postęp zadania tylko wtedy, gdy jest on wykonywany (może 3 tygodnie po pierwszej pracy), a to sprawia, że ​​wszyscy zastanawiają się, co się dzieje w środku tygodnia programowania. Nie zmieniłby swojego nawyku pomimo wielokrotnych badań. (W porządku, programiści nienawidzą papierkowej roboty, ja też)
2. W ciągu ostatnich 2-3 miesięcy często wyjeżdżał na urlop z powodu różnych wydarzeń - albo jest chory, albo musi uczestniczyć w wielu osobistych wydarzeniach itp. (W porządku, złe rzeczy zdarzają się w szeregu. To tylko zbieg okoliczności)
3. Definiujemy sprinty lub mapy drogowe na każdy miesiąc. Na początku sprintu omówimy ilość pracy, jaką każdy z programistów musi wykonać w sprincie, a programiści mogą ustawić czas potrzebny na każde zadanie . Zwykle nie będzie w stanie ukończyć wszystkich z nich. (Jest OK, programiści regularnie nie dotrzymują terminów nie z powodu swojej winy).
4. Mam siedzibę w Singapurze. Nie jestem pewien, czy to ma znaczenie. Tak, wiadomo, że Azjaci są powściągliwi, ale czy to ma znaczenie?

Jeśli zdarzy się tylko jedno lub dwa z powyższych zdarzeń, nie będę czuł, że A osiąga słabe wyniki, ale wszystkie one występują razem. Mam więc wrażenie, że A osiąga słabe wyniki, a może ... Boże, niech się nie rozluźni.

To tylko uczucie oparte na moim wieloletnim doświadczeniu jako programisty. Ale mogę się mylić.

Niezwykle trudno jest zmierzyć pracę programisty, biorąc pod uwagę, że nie wszystkie dwa zadania są takie same, i nie ma standardowego celu pomiaru zaangażowania programisty w Twoją firmę. Zupełnie niemożliwe jest ustalenie, czy programista wykonuje swoją pracę, czy zwalnia. Wszystko, co możesz zrobić, to zaufać im - tak, ufanie im i zapewnianie im autonomii jest najlepszym sposobem dla programistów do pracy, wiem to, więc nie zaczynaj wykładu, dlaczego musisz ufać swoim programistom, dziękuję wszystkim dużo - ale jeśli nadużywają twojego zaufania, możesz to wiedzieć?

Wynik:

Właśnie z nim rozmawiam na temat mojego postrzegania jego występu. Był oburzony, gdy zasugerowałem, że mam wrażenie, że nie gra na najlepszym poziomie. Czuł, że było to całkowicie niesprawiedliwe uczucie. Odpowiedziałem wtedy, że to moje uczucie i nie wiedziałem, czy moje uczucie było słuszne, czy nie. Nie miałby nic z tego i natychmiast zakończył dyskusję.

Przed odejściem powiedział, że „postarałby się dać firmie więcej” bardzo zimnym tonem. Byłem zaskoczony jego reakcją. Jestem pewien, że obraziłem go w pewien sposób. Nie jestem jednak pewien, czy to była właściwa rzecz dla mnie, aby być z nim tak szczerym.

Moje pytanie brzmi: w jaki sposób możesz stwierdzić, czy twoi programiści osiągają słabe wyniki? Na pewno są doświadczeni liderzy zespołów, którzy wiedzą o tym lepiej ode mnie? 

Dodatkowe uwagi:

1. Nienawidzę mikrozarządzania. Tak więc wszystko, co mamy dla naszego procesu oprogramowania, to Sprint (gdzie zadania są traktowane priorytetowo i przypisywane, a pod koniec miesiąca przegląd ilości wykonanej pracy). Programiści będą musieli aktualizować zadania w miarę ich codziennego wykonywania.
2. Nie ma spotkania standup ani niczego w tym rodzaju. Głównie dlatego, że mamy swobodę pracy w domu i wszyscy tę wolność cenią.
3. Chociaż to ja ustalam ostateczny termin, ale programiści dostarczą oszacowanie dla każdego zadania, a ja zdecyduję - na podstawie oszacowania - zadania, które przejdą do określonego sprintu. Jeśli nie będą mogli ukończyć zadań pod koniec sprintu, popchnę je do następnego. Tak więc teoretycznie można wykonać tylko 1 lub 2 zadania podczas całego sprintu, a następnie przesunąć pozostałe 99 zadań do następnego sprintu i nadal będzie dobrze, dopóki to uzasadnia - w postaci codziennych aktualizacji postępu pracy

To powinien być zaskakująco łatwy problem do rozwiązania.

Umów się z nim na drugie spotkanie. Powiedz mu, że akceptujesz fakt, że prawdopodobnie przyczyną jest twoje postrzeganie rzeczywistości. Następnie zakwalifikuj to za pomocą „jednak jeśli tak jest, to musimy współpracować, aby poprawić moją percepcję”. Wreszcie rzuć mu wyzwanie, aby rozwiązał ten problem, aby nie czuł się mikro zarządzany.

Ta dokładna rzecz zdarzyła mi się dawno temu. Dla mnie problemem było to, że nie podoba mi się możliwość, że ktokolwiek mógłby pomyśleć, że szukam dodatkowego kredytu po prostu wykonując swoją pracę. I to było dość uczciwe, ale musi być regularna pętla zwrotna między każdym członkiem personelu a jego przełożonym.

Jeśli nie ma, masz problemy.

Regularne, planowane 1: 1 to świetny pomysł. I, jak zauważyli ludzie, pojedynki nie muszą być ortogonalne do pracy w domu. Ale muszą obejmować trzy pytania: co robiłeś wczoraj? Co planujesz dziś zrobić? I ta, o której większość ludzi zapomina ... Co cię powstrzymuje?

To powiedziawszy, powinieneś starać się odradzać sytuacje, w których członkowie zespołu nigdy nie pracują razem. Pracowałem już wcześniej w tej sytuacji, co spowodowało brak zaufania w zespole i poza nim. Miej regularny dzień, kiedy wszyscy przychodzicie do biura. Odbywaj regularne spotkania, na których ludzie mogą wyrazić pomysły na usprawnienie procesów lub coś w tym rodzaju.

Nie rób z tego zdarzenia raportowania liniowego. Zrób to po prostu porozmawiać. Będziesz zaskoczony tym, czego się nauczysz. Jeśli to możliwe, zmień to w wydarzenie towarzyskie, idź na drinka w czasie pracy jako ćwiczenie integracyjne.

Jest tu wiele świetnych porad i nie chcę z nich rezygnować, więc zamieszczam to jako osobną odpowiedź.

Po pierwsze, dla mnie (i najwyraźniej innych) jest oczywiste, że nie odkryłeś źródła problemu . Patrzysz na objaw i próbujesz go wyleczyć. Musisz dowiedzieć się, co powoduje tak duże tarcie między tobą a tym deweloperem. Być może jesteś zbyt autorytatywny (moja Właścicielka produktu niedawno opisała siebie jako posiadającą „Nieskończoną Moc” nad projektem i było to dla mnie obraźliwe, mimo że się śmiała, kiedy to powiedziała). Być może ma poważne problemy rodzinne (tłumaczyłby cały czas bez pracy). Występuje tutaj główny problem i dopóki go nie znajdziesz, nie zostanie to naprawione.

Good Catch!

Jeśli jego wydajność mogłaby być lepsza, to świetnie, że to ustaliłeś. Pamiętaj jednak, że jeśli jego słaba wydajność jest nadal dobra w porównaniu, musisz ostrożnie stąpać, aby nie stracić dobrego programisty. Trudno znaleźć dobrych programistów, a dobrzy programiści wymagają bardzo specyficznego zestawu rzeczy. Być może spójrz na test Joela, aby sprawdzić, czy jego potrzeby są zaspokojone.

Znajdź źródło problemu

Jeśli jest niezadowolony z czegoś związanego z pracą, którą wykonuje, możesz to naprawić tylko poprzez określenie źródła problemu. Pozwólcie, że wyjaśnię, że programista napisał dobry kod. Oznacza to, że uwielbia programować. Jest bardziej niż oczywiste, że jest sfrustrowany w pracy (z twojego opisu spotkania) i prawdopodobnie masz rację, że jego wydajność jest poniżej tego, gdzie powinna być, ale nie zakładaj . Pamiętaj, że wielu programistów po prostu nie ma umiejętności społecznych.

Albo nie jesteś idealny

Pamiętaj, że czasami będziesz mieć konflikty osobowości, szczególnie z introwertykami . Jeśli okaże się, że jest to konflikt osobowości, zastanów się, jak daleko jesteś gotów się posunąć, aby uzyskać wzrost wydajności (patrz 1)

Wszystko to powiedziane

Napisałem wpis na blogu o zarządzaniu programistami. Myślę, że powinieneś to przeczytać.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Nie mogę wystarczająco podkreślić ostatniej części tego postu.

Jeśli twoi programiści są w ogóle dobrzy, chcą kodować.

Twój programista, nawet jeśli zwalnia, nie chce się zwalniać. Musisz znaleźć źródło tego problemu, a może się okazać, że jest to coś, czego po prostu nie da się naprawić i trzeba go puścić, ale cokolwiek to jest, nie możesz podjąć świadomej decyzji, nie określając go.

Kiedy wydaje Ci się, że ktoś jest „nieco trudny w zarządzaniu”, tak jak to opisujesz, aby lepiej zrozumieć, jak się wykonuje i czy występują problemy (obiektywne lub subiektywne) wpływające na wydajność członków zespołu programistów, zastanów się nad ustanowieniem praktyki regularnych 1: 1 z twoimi członkowie zespołu, jak pokazano w doskonałym artykule Aktualizacja, The Vent i The Disaster :

... Nie sugeruję, że każdy 1: 1 jest krętą sprawą, by odkryć głęboko ukryte katastrofy, ale chcesz stworzyć cotygodniowe miejsce, w którym może pojawić się niezadowolenie. 1: 1 to szansa na wykonanie cotygodniowych przeglądów profilaktycznych przy jednoczesnym zrozumieniu stanu zdrowia zespołu.

... Dźwięk otaczający udany reżim 1: 1 to cisza. Całe słuchanie, zadawanie pytań i dyskusja, które mają miejsce w czasie 1: 1, to kierownicze utrzymanie prewencyjne. Zobaczysz, kiedy zainteresowanie projektem zacznie słabnąć i podejmij działania, zanim stanie się ono niezadowoleniem z pracy. Usłyszysz o napięciu między dwoma pracownikami i moderujesz dyskusję, zanim stanie się ona krzykiem na spotkaniu. Nagrodą za kulturę zdrowych 1: 1 jest wyraźny brak dramatu .

_{Bardzo mocną stroną wspomnianego artykułu jest to, że jest samowystarczalny , w tym sensie, że oprócz wyjaśnienia korzyści, zapewnia również zestaw praktycznych zaleceń, w zasadzie pozwalając zacząć ćwiczyć regularne 1: 1 bez zagłębiania się w inne źródła (chociaż szuka się dodatkowe informacje nie zaszkodzą, wiesz).}

Oczywiście istnieje tutaj poważny problem z komunikacją. Być może wykonuje fantastyczną pracę, ale jeśli masz wrażenie, że nie wiesz, co on robi, to samo w sobie stanowi problem. A jeśli nie wiesz, co on robi, prawdopodobnie jego współpracownicy też tego nie wiedzą. Może to powodować problemy, gdy sprawdza swój dwutygodniowy kod. Zwłaszcza, jeśli ktoś pracował w podobnym obszarze.

Zawsze możesz zasugerować, aby sprawdzał / zapewniał aktualizacje częściej, aby zminimalizować tego rodzaju konflikty. Może to pozwolić ci rozpatrzyć twoją prośbę pod względem pomocy zespołowi zamiast „nie wiem, co robisz”.

Wiem, że pojedynki budzą nienawiść, ale tak naprawdę nie muszą się odbywać w tym samym pokoju. Szybka rozmowa lub grupowa aktualizacja Skype raz dziennie jest bardzo szybka i utrzymuje wszystkich na tej samej stronie.

Obecnie pracuję z Indii z zespołem w Irlandii i nie wyobrażam sobie, aby nie komunikować się z każdym z nich na co dzień i albo wiem z grubsza, na czym one są, albo mogę bardzo szybko się dowiedzieć.

Bezcelowy

Codzienne aktualizacje statusu są bezcelowe. To, że ludzie zgłaszają, że „dzisiaj mam ukończone 2,5%”, „dziś mam ukończone 3,74%” jest śmieszne.

Nie zapewnia żadnej wartości interesariuszom i denerwuje osoby wykonujące pracę.

Pozostaw je w spokoju.

Bezpodstawny

Jak przypuszczasz, na jakiej podstawie programista A „osiąga gorsze wyniki”? Jeśli jego praca jest wykonywana na czas, powinno to wystarczyć.

Mówisz, że nie znosisz zarządzania mikromaniami, ale dokładnie to opisałeś.

Nasza firma wymaga od programistów wskazywania postępów pracy w używanym przez nas narzędziu do śledzenia błędów, nie tylko w celu monitorowania programistów, ale w celu informowania zainteresowanych stron o postępach. ... Programiści będą musieli aktualizować zadania w miarę ich codziennego wykonywania.

To bez sensu (patrz wyżej) nonsens. Twój zespół nie rzuca burgerami, oni opracowują rozwiązania techniczne. Postęp nie jest liniowy, nie można go łatwo zmierzyć ani nawet oszacować. Nawet gdyby tak było, takie codzienne pomiary lub szacunki nie mają żadnej wartości.

Niebezpieczny

Przeanalizuj ponownie podstawy swojego „odczucia”, że programista A „osiąga gorsze wyniki”. Myślisz, że on / ona mogłaby zrobić lepiej, ale na podstawie jakich dowodów?

Nieszczęśliwy! = Słabe wyniki

Kontynuuj zgodnie z opisem, a w pewnym momencie programista A prawdopodobnie zdecyduje, że jest niedoceniany, dał wystarczająco dużo firmie i znajdzie inną firmę. Wyciśnięcie ostatnich 0,01% wysiłku pracowników jest o wiele mniej ważne niż utrzymanie ich na dłuższą metę.

Deweloperzy mogą nienawidzić wysiłku dokumentowania tego, co robią i aktualizowania statusów - ale to część bycia profesjonalnym programistą. Sugerowałbym, abyś mógł wskazać mu, że jego późne aktualizacje dziennika problemów powodują niepotrzebne negatywne postrzeganie jego pracy. Jeśli nie widzi, że jego brak komunikacji stanowi problem z wydajnością - jesteś liderem jego zespołu; powiedz mu, że tak.

Jeśli chodzi o szacowanie - to klasyczny problem. Polecam przeczytanie „Oszacowania oprogramowania - odsłanianie czarnej sztuki” Steve'a McConnella. W tym przypadku sprawiasz wrażenie, że większość programistów nie docenia. Jest to, co ciekawe, normalne i rzadko podejmowane. Sugerowałbym, że masz problem z samym procesem szacowania, a nie z tą jedną osobą.

Spróbuj „zamknąć pętlę” oceny i oceny szacunków i poprawić. Następnie, jeśli twoi programiści przychodzą na czas częściej, a ta jedna osoba nie jest, możesz zastanowić się, co z nim zrobić.

Na koniec zorganizuj spotkanie stand-up. Nawet jeśli jest to wiadomość błyskawiczna. Wszystko, czego chcesz, to żeby wszyscy wiedzieli „co zrobiłem, co robię dzisiaj, wszelkie problemy”. A jeśli pojawią się problemy, wyłącz je do późniejszej dyskusji. Tak robiłem wcześniej i było to skuteczne dla tego zespołu.

Po pierwsze, dlaczego twoje sprinty są tak długie? Sprinty nigdy nie powinny przekraczać dwóch tygodni. Myślę, że większość twojego problemu leży właśnie tam. Poleciłbym skrócić czas sprintu na zasadzie próbnej, a następnie ponownie przeanalizować pytanie.

Co z odprawą kodu? Czy cały czas sprawdza swój kod? Osobiście uważam, że programiści nie są tak naprawdę menedżerami, a im więcej próbujesz zarządzać, tym bardziej będą sfrustrowani. W rzeczywistości nienawidzę wykonywać tych zadań aktualizacji i prawdopodobnie dlatego są po to PM i Leads. Ale jednocześnie zapewniam status podczas spotkań scrumowych lub za każdym razem, gdy się spotykamy. Teraz, kiedy przypisujesz zadanie, czy przypisują się do osi czasu, czy to ty przypisujesz im oś czasu?

Dlatego jedynym sposobem, w jaki mogę stwierdzić, czy ktoś nie wykonuje, jest mapowanie zatwierdzonej osi czasu na% wykonanej pracy. Oczywiście, jeśli ktoś powie, że napisanie metody sumującej dwie liczby zajmie mu dwa dni, wiesz, że jest problem, więc harmonogram powinien być realistyczny i uzgodniony przez obie strony.

Weź to w ten sposób - jeśli możesz napisać fragment kodu w ciągu godziny, daj mu godzinę + bufor. Jeśli dostarczy ci to w tak krótkim czasie, myślę, że dobrze sobie radzisz. Jeśli nie, zapytaj go, a potem to Ty decydujesz, czy dostarczy rozsądne wyjaśnienie, czy nie.

Jedną rzeczą, którą możesz zrobić, to zintegrować coś takiego jak XPlanner z narzędziem do kontroli wersji.

Nie sądzę, aby zawód programisty z natury różnił się od innych zawodów, jeśli chodzi o identyfikację kogoś, kto zwalnia. Być może będziesz musiał iść z jelitami.

Osobiście uważam, że to dziwne, że A odmawia aktualizacji przez kilka tygodni. Jestem programistą pracującym w domu i istnieje domniemana umowa między mną a moim pracodawcą, że muszę codziennie aktualizować swoje postępy. To nie są „oficjalne” aktualizacje, to tylko krótki e-mail lub wiadomość błyskawiczna informująca go o tym, co się dzieje z oprogramowaniem, za które mam płacić. Aktualizacja trwa mniej niż minutę lub dwie i oferuje zamknięcie dla nas obu. W przypadku poprawek błędów oznaczam bilet jako rozwiązany w naszym narzędziu do śledzenia błędów do końca dnia. Nie są to dla mnie trudne procedury, chociaż lubię zrelaksowane środowisko pracy z bardzo małą ilością formalności.

Jestem pewien, że nawet codzienne aktualizacje będą mile widziane. Brzmisz bardzo, bardzo łagodnie w swoim poście. Jeśli podejrzewasz, że zwleka od dłuższego czasu, nie potrzebujesz innej wymówki, aby się z nim skontaktować.

Codzienne awarie, nawet jeśli przez Skype lub w pokoju czatu, są na drodze do tego, ale nie, jeśli traktujesz to jako aktualizację dla interesariuszy. Kiedy raz dziennie cały zespół zamelduje się, aby powiedzieć, nad czym pracują, jakie wyzwania napotykają i co planują robić dalej, otrzymasz kilka zwycięstw:

• Niezależnie od tego, czy marnujesz czas z dobrych czy złych powodów, to, że coś trwa zbyt długo, będzie bardziej przejrzyste, zachęcając twoich twórców do proszenia o pomoc, kiedy będą jej potrzebować, i nie przesadzaj z badaniami, które prawdopodobnie nie musiały się wydarzyć lub rozwiązanie problemu związanego z wyzwaniem, gdy wkład reszty zespołu pomógłby im znacznie szybciej go wyeliminować.

• Ty, jako menedżer, widzisz, gdzie ludzie najczęściej napotykają przeszkody, co pomaga lepiej oszacować i ewentualnie rozwiązać podstawowe problemy, które marnują czas / pieniądze.

• IMO naprawdę pomaga zespołowi lepiej nauczyć się nie doceniać szacunków, gdy widzą, ile czasu zwykle zajmuje każdemu, aby czasami zrobili nawet stosunkowo proste rzeczy.

• Często przypomnisz sobie o rzeczach, które należy przekazać w ramach zmiany priorytetów, gdy członkowie Twojego zespołu powiedzą ci, co planują robić dalej.

Więc zapomnij o „% ukończenia”. Po prostu wykonaj proces o tym, aby wszyscy byli wobec siebie tak samo szczerzy, jak wobec wszystkich innych, robiąc lepsze / bardziej wiarygodne szacunki, gdy zdobywają w tym więcej doświadczenia i dając ludziom więcej motywacji do zgłaszania postępów bez zmieniania ich w umysł -numeralne ćwiczenie polegające na umieszczaniu numeru na czymś, czego tak naprawdę nie można.

Wygląda na to, że wyższe kierownictwo rozumie, że terminy nie zawsze są przestrzegane. Robienie codziennych pojedynków da ci więcej amunicji na tym froncie, ponieważ będziesz miał znacznie bardziej szczegółowe pomysły na to, dlaczego nie zostaną trafieni.

I nie rób ich z góry. Zawsze pomyłka IMO. Ludzie potrzebują czasu, aby zatopić zęby z powrotem w problemie, zanim będą mogli bardziej niezawodnie informować o wszystkich problemach, IMO.

Szybkie standupy, które bardziej dotyczą komunikacji niż rozliczalności i po prostu wyznaczają cele, bardziej niż cokolwiek innego, sprawiają, że zwinna praca moim zdaniem. Resztę mogłem wziąć lub odejść, szczególnie Scrum, który uznałem za olej węża wykonawczego / interesariusza.

Niewystarczające?

Intensywność odpływa i przepływa podczas kariery danej osoby. Jeśli jest wart więcej niż kosztuje, porozmawiaj z nim i spróbuj ułatwić mu pracę. Albo zacznij szukać zamiennika.

Porozumiewanie się

Nie polegaj na cotygodniowych spotkaniach. Większość ludzi nie zrobi kompletnego braindumpa. Zaplanuj więcej 1: 1. Zapytaj ich, jak się sprawy mają, co możesz zrobić lepiej i co według ciebie mogą zrobić lepiej. Czasami nie będzie o czym rozmawiać, ale to jest w porządku. Mając więcej 1: 1, zwiększasz prawdopodobieństwo, że będą pamiętać o czymś.

Mają bardziej trwałe środki komunikacji

Możesz uzyskać więcej informacji od ludzi, jeśli nie sprawi, że poczujesz się jak dodatkowy obowiązek. Jeśli wszystkie są zdalne, niech używają programu do czatowania z funkcjami rejestrowania, takimi jak Hipchat lub IRC. Posiadanie bardziej wytrwałych środków komunikacji zachęca ludzi do większej rozmowy. Dawaj przykład i często mów, aby zachęcić innych do zrobienia tego samego. Przynajmniej raz dziennie, niech ludzie mówią, gdzie są przy swoich projektach. Czasami, po prostu patrząc na czat, możesz poczuć, jak postępują.

Kontrola źródła

Niech każdy codziennie sprawdza swój kod. Jeśli używasz git, poproś, aby wypchnęli do swojego oddziału w repozytorium firmy. Patrząc na zatwierdzenia, możesz stwierdzić, jak sobie radzą.

Oddziel środki od końców

Interesariusze chcą być na bieżąco? Sami zajmuj się interesariuszami. Częścią twojej pracy jako menedżera jest bzdura, aby Twoi koderzy mogli skupić się na swojej pracy. Przejrzyj dzienniki czatu i zatwierdzenia, a następnie napisz podsumowanie, jak się sprawy mają.

Oto moje sugestie:

1. Innowacja: wyobraźnia i kreatywność wykorzystywane do obniżania kosztów i poprawy obecnej sytuacji.

2. Korporacja: Chęć pomocy innym w osiągnięciu ich celów

3. Inicjatywa: próba nietypowych zadań i zadań.

4. Frekwencja: nieobecności lub spóźnienia, poniżej standardów.

5. Czujność: umiejętność szybkiego zrozumienia nowych informacji i sytuacji

6. Dokładność i jakość: przeglądy kodu, terminowość, wskaźnik emisji).