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

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.

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ć.

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ć.

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.

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.

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ć.

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 .

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. ”).

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

Nerd Herding

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.

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.

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.

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.

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

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).

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.

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.

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.