Jak pokazać kierownictwu, że przeciętni programiści szkodzą zespołowi [zamknięte]

82

Jestem na niepewnym stanowisku „zarządzania” zespołem programistów w małej firmie. Mówię „zarządzanie”, ponieważ chociaż przydzielam pracę i udzielam informacji zwrotnej na temat ich wykonania, nie mam możliwości zdyscyplinowania jednostki.

Niektórzy z mojego zespołu nie wiem, co zrobić, nie są w stanie pracować samodzielnie, wymagają ogromnej ilości trzymania się za ręce, a pozostawieni razem sieją spustoszenie w projekcie zwykle do punktu niepowodzenia. Kiedy zdarzy się niepowodzenie, jestem zmuszony uratować projekt i przepchnąć go (czasami kulejąc) przez linię mety.

Tym programistom nie tylko brakuje umiejętności programowania, ale ogólnie umiejętności formułowania rozwiązania problemu w kodzie. Proste rzeczy, takie jak pisanie pętli, są dla nich trudne, nie mówiąc już o zaprojektowaniu i wdrożeniu rozwiązania problemu.

Wypróbowaliśmy programowanie w parach, oferując opłacenie zajęć, kupowanie książek, przeznaczanie czasu w ciągu dnia na szkolenie, a nawet poświęcanie całych dni na szkolenie zespołu.

Razem z innym starszym programistą nie wiemy, co robić, ale nasza produktywność jest ograniczona z powodu konieczności radzenia sobie z tymi osobami na co dzień. Kierownictwo zmusza nas do dawania im pracy, a ich głównym zarzutem jest to, że sprawy nie są wykonywane wystarczająco szybko.

Żaden z członków naszego zespołu zarządzającego nie współpracuje bezpośrednio z żadnym z programistów poza mną i innym starszym programistą. Kierownictwo jest nietechniczne i uważa, że ​​każdy programista jest tworzony jednakowo, i że oczywiście potrzebujemy więcej osób w tych projektach, aby wykonać je szybciej.

Już przygotowuję dokument z sekcjami z „Miesiąca mitycznego człowieka” i „Ukończono kod”, który mam wysłać do kierownictwa, aby zilustrować statystykami, że to, co naprawdę nas powstrzymuje, to przeciąganie przeciętnych ludzi przez cykl rozwoju.

Jakie inne zasoby są dostępne? Książki, artykuły, ogólne porady byłyby pomocne.

deleteme
źródło
20
Na zamkniętych: No dalej! Weź się w garść!
Peter
6
Dodanie tego pytania do moich ulubionych nie wystarczy. Muszę ustawić to jako tapetę.
Manos Dilaverakis
5
cholera, powinienem zagłosować za zamknięciem, ale podoba mi się pytanie :(
IAdapter
3
Jedną bardzo ważną rzeczą, którą musisz zrobić, jest przekonanie kierownictwa, że ​​Ty i / lub Twój starszy odpowiednik programisty macie wpływ na to, kto zostanie zatrudniony (i zwolniony lub zdyscyplinowany). Jeśli masz być odpowiedzialny za kierowanie nimi, powinieneś mieć przynajmniej jakiś wpływ na to, czy są oni częścią Twojego zespołu.
Michael Todd,
5
Głosowano na bliskie, subiektywne i kłótliwe. Powinna być wiki społeczności, jeśli ludzie chcą po prostu dać upust.
Joe

Odpowiedzi:

26

Czy problem wynika z braku umiejętności lub zdolności, problemów z nastawieniem programistów, czy też z kultury korporacyjnej, która nie promuje dobrej etyki pracy?

Jeśli chodzi o umiejętności, już wiesz, że pewnych rzeczy nie możesz nauczyć. Jeśli firma jest chętna (i wydaje się, że tak) i możesz wykazać poprawę, przyspieszyłbym szkolenie i zobaczył, którzy programiści staną na wysokości zadania. Ci, którzy tego nie robią, będą musieli odpuścić. Nie zatrudniłbym dodatkowych programistów, dopóki nie wiesz, że zwolnisz niektórych z istniejących.

Jeśli jest to lenistwo lub inne problemy z nastawieniem ze strony programistów, będziesz musiał przekonać swoje kierownictwo, aby poparło Cię w działaniach dyscyplinarnych. Dokumentuj wszystkie problemy, jak opisuje Scott Vercuski . Stopniowo eliminuj tych programistów, którzy nie mogą stanąć na wysokości zadania. Niech pozostali programiści wiedzą, że oczekuje się od nich nauczenia się dobrych technik programowania i najlepszych praktyk oraz ich stosowania.

Miej przegląd kodu, jeśli jeszcze tego nie robisz. Istnieje wiele zasobów, które wyjaśniają, jak to zrobić poprawnie. Nie powinni wykrzykiwać meczów, ale raczej traktować je jako sesje strategiczne, aby przynieść pożądane rezultaty. Omów kod. Jak można to poprawić? W razie potrzeby napisz nowy kod w recenzji.

Jeśli zarządzanie jest problemem, powiedz im, że jest problemem i pokaż, jak mogą go naprawić. Ale musisz być elokwentny i przekonujący. Musisz być ich adwokatem. Napisz artykuł o problemie. Zrób prezentację i pokaż ją. Odwołuj się do motywów zysku.

Wreszcie, bądź dla swoich ludzi najlepszym przywódcą, jakim możesz być. Pomóc im. Nie blokuj ich, aby mogli wykonywać swoją pracę. Częścią twojej pracy jest chronienie swoich ludzi przed polityką wyższego kierownictwa i utrzymywanie przyzwoitego środowiska pracy, tak aby mogli skupić się na wykonywaniu najlepiej, jak potrafią. Innymi słowy, upewnij się, że Twoi ludzie mogą Ci ufać.

Robert Harvey
źródło
Zainteresowany tutaj Robert. Czy masz jakieś linki lub zasoby dotyczące „Jak nie robić przeglądu kodu”? Pytam, ponieważ uważam, że byłem w jednym, który ostatnio bardzo się nie udał ... Chciałbym mieć zewnętrzną dokumentację na temat tego, kiedy będę (po raz kolejny) przejść do kierownictwa o tym Starszym Inżynierze. (Posunąłem się nawet do tego, że odrzuciłem scenariusz od innego seniora, pod którym kiedyś pracowałem, i zgodził się, że odpowiedź, którą otrzymałem, „wydawała się trochę niefortunna”.)
Jason D
@Jason: Nie jestem pewien, co się stało podczas przeglądu kodu, ale ten artykuł może dostarczyć pewnych informacji: it.toolbox.com/blogs/puramu/…
Robert Harvey
nie do końca to, na co liczyłem, ale wskazało inne fundamentalne błędy w tym, jak przeprowadzamy proces recenzji. (np. nie mając strony „Dorosły” / nie posiadającej uprawnień jako osoby prowadzącej recenzję ...) Użyję tego linku między innymi do omówienia ulepszeń naszego procesu przeglądu kodu z kierownictwem i wykorzystam moje ostatnie osobiste doświadczenia jako przykład, dlaczego bezstronny mediator powinien tam być ...
Jason D,
32

Zabawne, że nikt ci nie powiedział, że może brak Ci umiejętności zarządzania.

Kiedyś skończyło się na pracy z ludźmi, którzy po półtorarocznym szkoleniu nie potrafili zakodować pętli. Szkoliłem ich, dopóki nie byli w stanie korzystać z pełnego frameworka internetowego, a zajęło to tylko miesiąc.

Może pan powinien dostać szkolenia.

Może pan powinien przeczytać raport o ciebie .

Nie mówię tego, żeby cię zaatakować. Ani trochę. Bardzo dobrze rozumiem problem, ponieważ w przeszłości nie udawało mi się również zarządzać zespołami.

Ale nie unikaj piłki, jesteś głównie odpowiedzialny za to, co dzieje się w Twoim zespole, bez względu na to, ile literatury dobrych praktyk przeczytałeś w swoim życiu.

W takim razie przestań narzekać i zabierz się do pracy. Nie jako programista, ale jako menedżer.

Wreszcie mogę się mylić. Może wszystko zrobiłeś dobrze. W takim przypadku możesz i prawdopodobnie powinieneś zrezygnować. Próba zapobieżenia rozbiciu się samolotu poprzez poruszanie rękami jest bezużyteczna, bez względu na to, jak silny jesteś. Jest wiele niezobowiązujących drużyn, które czynią cuda swoimi umiejętnościami, aby jak najlepiej je wykorzystać.

e-satis
źródło
6
Nie rozumiem, dlaczego ludzie głosowali na ciebie w dół. Podnosisz słuszną kwestię, że liderzy / menedżerowie, którzy wyewoluowali z normalnych inżynierów, prawie nigdy nie otrzymują żadnego szkolenia w zakresie zarządzania ludźmi. Stary błąd: „Jesteś świetnym inżynierem, będziesz więc wielkim menedżerem”.
Erich Mirabal
1
Cóż, ponieważ nie jest politycznie poprawne mówienie komuś proszącemu o pomoc, że może to on jest przyczyną jego sytuacji. Muszę powiedzieć, że sam nie lubię, gdy mi się to mówi, ale zwykle jest to przydatny elektrowstrząs.
e-satis
4
Dziękuję za zwrócenie uwagi - i nie otrzymuję głosów negatywnych. Nigdy nie miałem żadnego szkolenia z zarządzania. Zostałem postawiony w tej (niepewnej) pozycji bez żadnego wcześniejszego doświadczenia. W pełni przyznaję, że mogę być częściowo winny. Nieraz prosiłem o zatrudnienie prawdziwego menedżera ds. Rozwoju, kogoś z doświadczeniem w kierowaniu zespołem programistów. Wygląda na to, że prośba nie dotarła do nas.
1
Znalazłem naprawdę dobre wskazówki dotyczące zarządzania na stronie manager-tools.com. Podcasty są podzielone na przydatne tematy. Może znajdziesz tam coś, co ci pomoże.
Paul Hildebrandt,
@Paul - dzięki za to, na pewno to sprawdzę!
15

Dokumentacja jest Twoim największym źródłem informacji ... mój stary kierownik powiedział mi: „Jeśli tego nie zapiszesz, to się nie wydarzyło”. Jeśli twoi programiści podają ci pisemne oszacowanie czasu potrzebnego do wykonania zadania i stale (i poważnie) przekraczają te terminy, należy to udokumentować.

Czy masz jakiś system pomiaru czasu? czy programiści rejestrują swój czas? Jeśli stwierdzą, że problem zajmie im X dni, a po X dniach nie zostanie rozwiązany, możesz zapytać, dlaczego tak się nie stało.

Powtarzam ... dokumentacja jest kluczowa, jeśli nagle kogoś wykończysz i nie masz odpowiedniej dokumentacji, co do powodu, dla którego możesz dostać się na terytorium pozwu. Im więcej masz dokumentacji, tym kierownictwo powinno łatwo zauważyć, że młodsi programiści nie robią nic i powinni zostać zastąpieni.

Powodzenia, obawiam się, że jesteś na bardzo wyboistej drodze ... Byłem tam i jest to długotrwały proces.

user26901
źródło
Używamy systemu śledzenia czasu i narzędzia do śledzenia błędów, ale nie mam dostępu do przeglądania czasu innych ludzi. Zdecydowanie zacznę dokładniej dokumentować swoje doświadczenia.
Jeśli zbierzesz wystarczającą ilość dokumentacji na temat ich szacunków, możesz przekazać te szacunki swojemu kierownikowi i poprosić go o porównanie grafików, co miejmy nadzieję pokaże, że programista oszacował X dni i spędził X + Y dni konsekwentnie, dając ci więcej amunicji za twoją decyzję.
2
Jeśli problemem są szacunki, pamiętaj, że dobre szacunki wymagają czasu. Aby oszacować, jak długo zajmie problem z kodowaniem, musisz zejść do poziomu zastanawiania się, które wiersze kodu musisz zmienić, jakie klasy i metody musisz napisać itd., I oczywiście musisz wziąć pod uwagę na czas do testów. Dobrą wiadomością jest to, że ustalenie tych rzeczy i tak musiałbyś zrobić, więc tak naprawdę nie potrzebujesz dodatkowego czasu na oszacowanie.
Ryan Lundy
6

Byłem już w takiej sytuacji i na pewno potrafię wczuć się w to. Zrobiłem to, aby odciąć się od małego, samodzielnego zadania, które powinno zająć mnie lub innemu starszemu programistowi nie więcej niż 2 dni. W tym zadaniu utworzyłbym dokumentację określającą sposób wdrożenia rozwiązania, wszelkie zmiany w bazie danych itp. Następnie siadałem z programistą, przedstawiałem mu ogólny opis zadania i przypisywałem go z terminem 1 tygodnia. Pod koniec tygodnia masz coś namacalnego, do czego możesz porównać ich pracę: Czy spełniali specyfikację? Jak oni są gotowi? Ile błędów wykryła kontrola jakości? Czy w jakikolwiek sposób złamali kompilację lub proces?

Gdy to zrobisz, zakładając, że zawiedli, masz bezpośrednie i celowe spotkanie z nimi, wyjaśniając, jak nie wypełniają swoich obowiązków. Zrób to samo raz lub dwa razy i tak długo, jak dokumentujesz i komunikujesz się w łańcuchu, powinieneś być w stanie je wypchnąć. Może to być trudne, ale wygląda na to, że potrzebujesz ludzi do podjęcia działań, a po prostu nie masz odpowiednich ludzi do tego.

Upewnij się również, że weźmiesz udział w rozmowie kwalifikacyjnej z nowymi kandydatami.

Jacob G
źródło
5

Moja rada jest taka:

Jeśli jesteś menedżerem, musisz mieć prawa, które idą w parze z Twoją odpowiedzialnością. Prawa te obejmują dyscyplinę osób podlegających Tobie. Jeśli wyższe kierownictwo odmówi Ci przyznania tych praw, odmów przyjęcia na siebie tej odpowiedzialności.

Nie musisz koniecznie być tak surowy dla swoich przełożonych, ale to jest istota tego, co musi się wydarzyć.

Paul Nathan
źródło
2

Moja rada to zaimplementowanie narzędzia do śledzenia błędów i przydzielenie zadań. To pokaże produktywność każdego członka zespołu. Za pierwszym razem udaje nam się uporządkować zespół i mierzyć czas, jaki poświęcamy na pracę nad zadaniami. Jedną z rzeczy, które mi się podobały, było to, że kiedy ktoś przydzielał zadanie, wysyłał e-mail do pracownika i kopię do kogoś innego, aby sprawdzić zadanie.

Przy okazji korzystaliśmy z BugTracker.Net .

Nelson Miranda
źródło
Mamy narzędzie do śledzenia błędów i system śledzenia czasu, ale nie są one zintegrowane. Pozostawiamy również indywidualnemu programistowi wprowadzenie czasu spędzonego na zadaniu. Być może będę musiał sprawdzić, czy uda nam się prześledzić łączny czas spędzony między wykonaniem zadania w narzędziu do śledzenia błędów w porównaniu z szacowanym czasem.
Myślę wtedy, że jest to kwestia etyki pracowników, na której musiałbyś się skoncentrować.
Nelson Miranda,
Brzmi jak cudowne miejsce na spędzenie 8 godzin dziennie ... NIE! Od kiedy my, programiści, zostaliśmy pracownikami fabryki! Jaka jest rotacja personelu w Twojej organizacji i ile pieniędzy marnujesz, ponieważ nie możesz dostosować się do ludzkiej natury! Czy ktoś tam pracujący ma nadciśnienie! Jedyne, czym możesz zarządzać, to swatshop. Nikt nie chciałby pracować w takim środowisku. Ups, czas na przerwę na kawę. ;-)
Sam
2

Zastanawiam się, jak ci ludzie w ogóle dostali się do firmy:

Tym programistom nie tylko brakuje umiejętności programowania, ale ogólnie umiejętności formułowania rozwiązania problemu w kodzie.

Proste rzeczy, takie jak pisanie pętli, są dla nich trudne ...

Twoja firma bez wątpienia potrzebuje więcej czasu i wysiłku w rekrutację siły roboczej, jak głosi stare powiedzenie: pośpiech to marnotrawstwo.

Teraz, gdy znajdziesz się w takiej sytuacji, jak opisujesz, zakończ raport (jak sugerowali inni), zrób go zwięźle i podkreśl, ile pieniędzy to kosztuje firmę, prześlij i poczekaj na najlepsze (jak powiedziałeś, że „nie masz odwołanie się do rzeczywistego dyscyplinowania jednostki. ”).

Peter Perháč
źródło
3
Deweloperzy nie zostali włączeni do procesu rekrutacji, tak się dostali.
2

Czytałem to jakiś czas temu o zachęcaniu programistów do bycia najlepszymi.

Nerd Herding

Andy Joiner
źródło
Niesamowity artykuł. Dobre połączenie +1
Smalltown2k
Brawo za rozpoznanie okazji, a nie przeszkody.
Sam
1

Wspomniałeś, że dla swojego zespołu „przekazujesz opinię na temat ich wyników”.

Więc:

  1. Usiądź ze swoim zespołem.
  2. Rozdaj im wydruki tej strony i powiedz, że o nich opublikowałeś.
  3. Niech to przeczytają.
  4. Poproś ich o pomoc w rozwiązaniu problemu.
  5. Posłuchaj i zapisz to.
  6. Zabierz to do swojego zespołu zarządzającego.
user271471
źródło
1

Peopleware to kolejna książka, która powinna dołączyć do Twojej listy.

Jednak gdy go przeczytałem, nie uznałem go za praktyczny, ponieważ nikt w firmie nie chciał wypróbować jego rekomendacji.

aaaa bbbb
źródło
Ostatnim razem, gdy byłem w takiej sytuacji - rzuciłem i poszedłem gdzie indziej, teraz o wiele lepiej jest pracować z innym zespołem deweloperskim, który faktycznie ma kotlety na prawdziwy rozwój.
James
0

Wygląda na to, że jesteś na dobrej drodze.

Jeśli pokażesz im trudne liczby, zobaczą wszystko jaśniej - utwórz zadanie związane z kodowaniem i przekaż je kilku różnym programistom, aby każdy z nich pracował samodzielnie. Zrób to samodzielnie.

Przechowuj szczegółowe informacje o tym, jak długo trwa każde z nich, ile błędów generuje kod.

Pokaż liczby wyższemu kierownictwu, teraz powinni być przekonani.

Oded
źródło
0

Książka

Code Complete: Praktyczny podręcznik budowy oprogramowania autorstwa Steve'a McConnella

to dobre źródło, które może pomóc w poznaniu najlepszych praktyk.

Wymaganie od każdego programisty przeczytania i nauczenia się tego w trakcie dyskusji może trochę pomóc, ale najważniejszą rzeczą jest ilościowe określenie wyników. Weź pensje dla siebie i reszty zespołu, a następnie oblicz, ile dodatkowego czasu musisz poświęcić na naprawianie innych błędów, z dodatkowym kosztem programistów, którzy zepsuli wszystko na początek.

Następnie pokaż, jak zespół lepszych programistów może poprawić zwrot z inwestycji.

Todd Moses
źródło
OP już twierdzi, że używa Code Complete. Jakieś inne dobre książki?
aaaa bbbb
0

Raport powinien być zwięzły. Nie rób tego rozwlekle. Ujmij to w kategoriach tego, ile pieniędzy tracą na tym.

Dean J.
źródło
0

Mamy teraz narzędzie, które mierzy złożoność naszych modułów kodu. Działa na naszych modułach PL / SQL, ale uważam, że istnieją narzędzia dostępne w innych środowiskach.

Istnieją różne sekcje, ale kierownictwo otworzyło oczy, gdy kilka naszych kluczowych modułów zostało oznaczonych jako „niemożliwe do przetestowania”.

Połączyliśmy z narzędziem do analizy imact, które pomaga wskazać zduplikowaną funkcjonalność, i podeszliśmy do tego wszystkiego jako oceny „długu technicznego”.

Ponieważ moglibyśmy przedstawić to na podstawie modułu po module, łatwo byłoby zidentyfikować sprawców (zrobiliśmy to, ale nie zgłosiliśmy). W obecnej sytuacji organizacja była bardziej nastawiona na poprawę, niż wskazywanie palcem.

(Nawiasem mówiąc, cały kod jest teraz przesyłany do przeglądu, a towarzysząca mu analiza kodu musi zostać dostarczona. Tutaj sytuacja zdecydowanie się poprawia).

James Wiseman
źródło
0

Nie jest to po prostu możliwe, chyba że masz dobrą przyczepność do zarządzania. Z mojego doświadczenia wynika, że ​​jeśli spróbujesz to wymusić, możesz wpaść w kłopoty.

fastcodejava
źródło
0

Tylko pomysł.

Zakładam, że używasz systemów kontroli wersji źródeł, takich jak SVN. Stwórz więc politykę przeglądania zatwierdzeń i odrzucania złych. Następnie pokaż innym menedżerom statystyki odrzuconych zatwierdzeń, aby udowodnić, że przeciętni programiści są dla firmy dużo kosztowni.

Siergiej
źródło
0

Oto kolejny pomysł dla Ciebie: nie naprawiaj tego, co się psują. Odeślij go do ponownej pracy w wiadomości e-mail, informując, co jest nie tak i jak to naprawić (tylko ogólnie) i jak zarządzać CC. Upewnij się, że kierownictwo dokładnie rozumie, jak wpłynie to na ostateczny termin. Tworzy to dokumentację problemów z wydajnością, a niektóre z nich mogą przestać być tak złe, gdy będą musiały naprawić swój własny bałagan.

HLGEM
źródło