Jestem konsultantem ds. produktywności IT zatrudnionym w małej firmie tworzącej oprogramowanie (dwudziestu pracowników). Problemem jest starszy programista w zespole pięciu programistów, którzy pracują nad wiodącym produktem firmy.
Przez kilka lat założyciel był niezadowolony z umiejętności technicznych pracowników i niedawno zatrudnił starszy programista do podwójnej roli kierownika technicznego i kierownika projektu. Był jedynym, który przeprowadził rozmowę kwalifikacyjną i jedynym, który zdecydował się zatrudnić tę osobę.
Ten starszy programista ma imponujące CV z dwudziestopięcioletnią karierą w IT i wieloma udanymi projektami osiągnięty dla firm, od małych po międzynarodowe korporacje.
Jednak zespół znacznie mniej docenił jego profil w ciągu dwóch miesięcy. Miałem okazję porozmawiać z trzema z pięciu członków tego zespołu i wszyscy podkreślili trzy kwestie:
-
Według nich facet jest palantem i nie ma szacunku dla pozostali członkowie zespołu. Niedawny cytat, jak rozmawiał z młodszym programistą przed zespołem, jest bardzo obrazowy: „Pracowałem w tej branży przez dwadzieścia pięć lat, a ty? Co ty zrobiłeś? Od trzech lat jesteś małpą kodu. Więc zamknij się, kretynie! Nikt nie dba o twoją opinię, ******. ”
Warto zauważyć, że miałem kilka spotkań z tą osobą i wydawał się bardzo miły i uprzejmy. Nie uwierzyłbym, że to ta sama osoba, która nieustannie obraża swoich kolegów z drużyny, gdybym nie miał zeznań trzech członków zespołu.
-
W przeszłości decyzje były podejmowane przez wszystkich członków zespołu. Kiedy członkowie nie zgadzali się, dyskutowali o wszystkim razem i doszli do porozumienia lub przynajmniej wyjaśnili powody tym, którzy się nie zgodzą.
Teraz wszystkie ważne decyzje są podejmowane wyłącznie przez główny deweloper. Tych decyzji nie można kwestionować ani dyskutować, nawet jeśli cała piątka członków zespołu uzna, że decyzja nie ma sensu.
-
Umiejętności i praktyki starszego programisty wydają się nieco ... przestarzałe. Kilka przykładów:
-
Nienawidzi IDE, automatycznego uzupełniania i funkcji, które mają pomóc programistom w szybszym pisaniu kodu i twierdzi, że zespół powinien używać Notepad ++, aby być produktywnym. Chociaż ma to sens w różnych okolicznościach, trudno sobie wyobrazić programistów C # nagle porzucających Visual Studio dla Notepad ++.
-
Nie refaktoryzuje kodu i nie przejmuje się stylem (co jest niespójne w jego własnym kodzie), ponieważ „troszczy się tylko o rzeczy, które naprawdę mają znaczenie”. Na marginesie, styl był wcześniej sprawdzany przez nocną kompilację, która zaczęła zawodzić od czasu pojawienia się nowego lidera.
-
Odrzuca pomysł nocnej kompilacji, ponieważ a także testy automatyczne. Według niego „każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, aby tracić czas na pisanie testów automatycznych”. Według niego nocne kompilowanie to także strata czasu.
-
Uważa, że kontrola wersji jest w większości bezużyteczna i wydaje się, że źle rozumie, jak jej używać. Prowadzi to do sytuacji, w których samodzielnie rozwija jakąś cechę przez trzy do pięciu dni, a kiedy w końcu wprowadza zmiany, „bierze moje” za wszystkie konflikty. Jeśli inni członkowie zespołu narzekają, że ich kod został skasowany, zaprasza ich do przepisania go. Kilkakrotnie inni członkowie robili to samo, usuwając kod głównego programisty. Wyglądał na zaskoczonego (wygląda na to, że nie wie, jak używać
svn loglub diffs) i ponownie wprowadził zmiany, narzekając, że „zostały w tajemniczy sposób zagubione” i obwiniając SVN o spieprzenie. / p> -
Wyolbrzymia znaczenie optymalizacji kodu. Jego podejście jest poprawne, tzn. Prowadzi profiler, ustala wąskie gardło i naprawia je; problem polega na tym, że nie ma niefunkcjonalnych wymagań dotyczących wydajności i nie ma elementów wskazujących na to, że użytkownicy mogą uznać aplikację za powolną (i hostowana na maszynach wirtualnych o niskiej jakości, aplikacja jest bardzo responsywna). Z drugiej strony, spędza praktycznie połowę czasu na optymalizacji kodu.
-
Pisze ręcznie wszystkie SQL i odrzuca ideę ORM. Należy zauważyć, że obecny produkt jest oparty na ORM Entity Framework firmy Microsoft, a dwóch z pięciu programistów nigdy wcześniej nie korzystało z SQL.
-
Odrzuca frameworki i biblioteki innych firm, biorąc pod uwagę że dużo łatwiej jest pisać rzeczy od zera. Zdecydował się porzucić wszystkie biblioteki i frameworki JavaScript z wyjątkiem jQuery, twierdząc, że kiedy zaczął programować w JavaScript piętnaście lat temu, nie było żadnych frameworków, a życie było dużo łatwiejsze.
-
Uważa, że urządzenia mobilne (w tym tablety) to tylko hype, więc nie ma powodu, aby tracić cenny czas na zapewnienie kompatybilności strony z tymi urządzeniami i tworzenie responsywnego projektu. Produkt jest publiczną aplikacją internetową, z której nie oczekuje się częstego używania na urządzeniach mobilnych. Jednak projekt responsywny może być bardzo interesujący dla tej aplikacji, ponieważ nawet na komputerach stacjonarnych będzie on wyświetlany zarówno na monitorach 19-calowych, jak i dużych monitorach o wysokiej rozdzielczości.
-
Prosi zespół o zaprzestanie korzystania z Internetu (zwłaszcza StackOverflow) i poleganie na swoich mózgach, dokumentacji offline (nawet nie wiedziałem, że Microsoft nadal sprzedaje płyty MSDN!) i książkach.
-
Członkowie zespołu poskarżyli się założycielowi firmy na temat nowego kierownika w tych trzech kwestiach. Założyciel odpowiedział, że przesadzają i że na podstawie swojego CV i wywiadu ma absolutne zaufanie do umiejętności nowego lead'a, dlatego właśnie przypisał tej osobie w pierwszej kolejności rolę głównego programisty. .
Co zespół powinien zrobić, aby:
-
Albo wyrzucić prowadzenie z zespołu, albo z firmy,
-
Albo zmusić go do zmiany nastawienia do zespołu?
W komentarzach zadawano wiele pytań, więc oto dodatkowe informacje.
Jaka jest struktura firmy nad nim? Kto jest jego przełożonym?
Biorąc pod uwagę niewielki rozmiar firmy, konstrukcja jest dość płaska. Na samej górze jest założyciel firmy. Są też pracownicy, którzy podlegają bezpośrednio założycielowi. Z prawnego punktu widzenia nowy lider jest na tym samym poziomie, co pozostałych pięciu członków zespołu. Na przykład nie może zwolnić członka zespołu ani nawet przenieść go do innego zespołu.
-
Niektóre z tego, co mówisz w kulach jako punkty przeciwko niemu są dla niego punktami. Mam na myśli, że ma rację co najmniej w połowie z nich
Rzeczywiście, w ten sposób starałem się przedstawić temat. Osobiście uważam, że niektóre z tych dziewięciu punktów mają sens, ale nie w kontekście obecnego zespołu. Na przykład moim podstawowym środowiskiem programistycznym jest
vi, ale nie będę zmuszać programisty C # do używaniavizamiast Visual Studio, ani też nie będę używałvija podczas tworzenia aplikacji C # dla systemu Windows. -
Naprawdę nie rozumiem, dlaczego ten facet marnuje czas w Twojej małej firmie. Prawdopodobnie mógłby zarobić dużo więcej, pracując gdzie indziej jako „facet, który wciąż wie, jak utrzymywać nasz 25-letni, nieudokumentowany, krytyczny dla biznesu system, napisany w języku programowania, który wciąż rozumieją tylko 3 osoby we wszechświecie. "
Rzeczywiście, dla mnie też nie jest to zbyt jasne. Powinienem wspomnieć, że zna język COBOL? ...
-
Nie sądzę, aby to było prawdziwe pytanie. Moim zdaniem jest to post przeznaczony do trollingu . W zasadzie wziąłeś wszystkie możliwe złe nawyki, połączyłeś je razem i zapytałeś, co robić.
Moja rola konsultanta ds. Produktywności IT oznacza, że dzwonię, gdy firmy mają problemy ze swoimi zespołami programistów. Ponad połowa przypadków dotyczy niedoświadczonych i często zdemotywowanych programistów, którzy są zmuszeni pracować nad kiepskim kodem nudnego oprogramowania. Druga część dotyczy jednak sytuacji konfliktowych, silnej polityki, wzajemnych nieporozumień i ogólnego bałaganu. Dlatego rzeczywiście znacznie częściej spotykam się z sytuacjami w stylu TheDailyWTF niż zwykli programiści, ponieważ tak naprawdę moim zadaniem jest być tam, gdzie dzieje się WTF.
To już się zdarzyło. Opublikowałem pytanie opisujące sytuację WTF i niektórzy ludzie założyli (ich komentarze zostały usunięte), że trolluję. Wyobrażam sobie, że wiele sytuacji, z którymi się spotkałem, byłoby tutaj traktowanych tak samo, co jest zrozumiałe. Nawiasem mówiąc, sytuacja, którą tutaj opisuję, nie należy do najgorszych, jakie widziałem.
Niestety nie ma sposobu, abym mógł wykazać, że te sytuacje są prawdziwe. Na przykład z oczywistych względów nie mogę podać ani nazwy firmy, ani nazwy divy deweloperskiej w obecnym przypadku, a nawet gdybym mógł, nikt tutaj nie zna tej firmy ani tego dewelopera (chyba że niektórzy z Was pracowali w Francja w sektorze finansowym utrzymującym przestarzałe systemy).
-
Brzmi trochę dziwnie, że dostrzegany problem dotyczy nowego lidera i że nie ma postrzeganego problemu z ludźmi pracując pod nim (takim jak ty). Czy założyciel miał rację, że był niezadowolony z obecnego zespołu? Jeśli nie, dlaczego był?
Pamiętaj, że nie jestem członkiem zespołu, a jedynie konsultantem.
Myślę, że założyciel ma całkowitą rację, że jest niezadowolony z obecnego zespołu. Czterej deweloperzy mają ogólnie niewielkie doświadczenie w programowaniu, aw szczególności w języku C #. Piąty jest bardziej doświadczony i jest tym, który pierwotnie nalegał na używanie kontroli wersji, który przygotował nocną kompilację itp. Mimo to ogólny poziom zespołu nie jest tak wysoki, jak trzeba by dobrze zbudować produkt, który tworzą teraz.
Decyzja o zatrudnieniu kierownika technicznego była doskonałym pomysłem. Jednak byłoby znacznie lepiej, gdyby była to osoba, która uczyłaby obecny zespół zamiast go obwiniać i pracowała z obecnymi członkami, a nie przeciwko nim.
Dlaczego ktokolwiek miałby sprzeciwiać się korzystaniu z Internetu w celu uzyskania pomocy dotyczącej problemów z oprogramowaniem?
Nie znam oficjalnego powodu, ale przypuszczam, że główny programista zawsze robił to w ten sposób i uważa, że jakość StackOverflow jest gorsza od oficjalnej dokumentacji MSDN.
-
Czy kiedykolwiek zdarzyło się, że celem tego faceta jest odejście zespołu ?
Ciekawy pomysł. Zmuszanie członków zespołu do rezygnacji przyniosłoby ogromne korzyści finansowe małej firmie, której może nie stać na zwolnienie ich. Gdy ci programiści odejdą, firma może zatrudnić bardziej doświadczonych programistów i przenieść divę deweloperską do innego zespołu.
-
Więc nie wiem, jak długo członkowie Twojego zespołu poskarżył się szefowi na temat głównego dewelopera. Ale czy odbyłeś z nimi dobrą rozmowę przy stole?
Rzeczywiście, były indywidualne skargi, ale nie było rozmowy przy okrągłym stole. Dobra sugestia.