Skąd menedżerowie wiedzą, czy dana osoba jest dobrym czy złym programistą?

W większości firm, które tworzą zespoły i działy programistyczne, są programiści, którzy projektują i piszą kod, oraz menedżerowie, którzy ... no cóż, zajmują się zarządzaniem. Oprócz tego, że nie piszą kodu, menedżerowie zwykle nawet nie patrzą na kod opracowywany przez zespół i mogą nawet nie mieć zainstalowanego odpowiedniego IDE na swoich komputerach roboczych.

Mimo to menedżerowie muszą oceniać, czy dana osoba działa dobrze, czy powinna ona być za coś odpowiedzialna, czy też konkretny programista powinien zostać przypisany do zadania o najwyższym znaczeniu i odpowiedzialności. I wreszcie: menedżerowie zwykle przyznają kwartalne premie!

Aby skutecznie to zrobić, menedżer powinien wiedzieć, czy dana osoba jest dobrym programistą - oczywiście wśród innych cech. Pytanie brzmi: jak oni to robią? Nawet nie patrzą na kod, który piszą ludzie, nie mogą bezpośrednio ocenić jakości komponentów, które opracowują programiści ... ale ich szacunki dotyczące tego, kto jest dobrym koderem, a kto nie jest tak dobry, są jednak poprawne w większości przypadków!

Jaki jest sekret?

Zazwyczaj patrzy na to menedżer

• Czy programista załatwia sprawy?
• Co myślą o nich ich koledzy? Kod, który piszą?
• Czy programista komunikuje się wyraźnie z menedżerem?
• Czy programista lubi uczyć się nowych rzeczy? Czy dobrze mentują innych?
• Czy potrzebują dużo uwagi kierownictwa, aby załatwić sprawę?
• Czy programista wydaje się czerpać przyjemność ze swojej pracy?

Prawdą jest, że zwykle nie widzą (lub często nie rozumieją) kodu pracowników, ale dla nich powyższe służy jako rozsądny wskaźnik do pomiaru, jak dobrze pracownik pasuje do roli programistycznej narzuconej mu przez pracodawcę. Jeśli ktoś nie załatwia sprawy, dostaje niskie oceny od swoich kolegów, nie może dobrze się komunikować, denerwuje się inną technologią, to jest przyzwyczajony, zawsze wymaga nadzoru i zawsze jest niezadowolony, to dobra wskazówka, że ​​nie są T dobrze pasuje do tej pracy. *

* Być może jednak w innym kontekście i otoczeniu byliby bardzo szczęśliwi i entuzjastyczni. Może jej po prostu , że rodzaj programatora, że sprzeciwił się, a może robią bardzo dobrze programowania w innym kontekście. „Programista” może oznaczać bardzo różne zadania w różnych miejscach. Ale kierownik dba przede wszystkim o rolę „programisty” i to, jak dobrze pasuje pracownik.

Nie zgadzam się z twierdzeniem, że menedżerowie nie patrzą na kod. Kiedy zarządzałem zespołami, sprawdzałem wyniki każdego inżyniera - a dużym jest kod. Ale nie jedyny - e-maile, dokumenty projektowe, oficjalne dokumenty - wszystko to ma wpływ.

Ale to zdecydowanie nie jedyny czynnik. Jeśli jeden facet siedzi w kącie i pisze genialny kod, ale jest bestią do rozmowy, nie odpowiada na pytania, nie dzieli się statusem i nie idzie na kompromis, gdy pojawią się problemy z rozwojem - nie jestem pewien, czy jest zasób dla zespołu. Zwłaszcza w porównaniu z facetem, który pisze umiarkowanie przyzwoity kod, ale potrafi wykonać wszystkie powyższe czynności.

Oto kilka rzeczy, na które patrzę, kiedy jestem w stanie rozdawać nagrody, ale z ogromnym zastrzeżeniem, że jest to absolutnie reakcja jelit, ponieważ żadnej z tych rzeczy nie da się określić ilościowo:

• Status - czy jest to jasne, dokładne i aktualne? Czy w omawianej sprawie osoba ma status lub jest nieco rozmyta w bieżących kwestiach? Czy osoba ma właściwy osąd, aby podnieść czerwoną flagę, gdy coś się zapali?
• Rozwiązywanie problemów - ważne jest zarówno pytanie, jak i odpowiedź. Czy dana osoba wie, kiedy poprosić o pomoc lub gdzie bez końca kręci się kołami? Jeszcze lepiej, gdy inni mają problemy, czy dana osoba pomaga znaleźć rozwiązanie lub staje się częścią problemu? Nawet dobry rozsądek, aby się wycofać, gdy problem nie leży w obszarze Twojej specjalizacji, jest wart kilku punktów. Są też punkty za wyjście poza grupę lub firmę i przejście do takich stron lub innych odpowiedzi internetowych.
• Uwaga na proces - zwykle jest to dość oczywiste - nawet w firmie, która nie zachowuje się analnie, jeśli ktoś oszukuje system, widać to w chaosie, który po sobie zostawiają. Jeśli inne osoby usuwają funkcje innej osoby, ponieważ nie stosują się do wskazówek lub architektury, mamy problem. Dodatkowe punkty iść do tych, którzy dowiedzieć się sposobów, aby spójność i jakość łatwiejsze .
• Wskaźniki ukończenia a błędy i złożoność - zrób rzeczy, ale zrób to dobrze. Każdy ma kilka błędów, ale jeśli facet szybko załatwi sprawę i będzie miał problemy, mamy problem. Generalnie uważam, że nie jest to coś, co można ocenić w codziennym sensie - musi to być spojrzenie na wydanie, fazę lub kwartał podatkowy.

I wkład innych ludzi. Często byłem na stanowisku, w którym różni inżynierowie byli odpowiedzialni za różne części projektu. Czasami kieruje zespołem, a czasem tylko właściciele danego produktu (np. „Facet od kompilacji”). Ludzie uwielbiają rozmawiać o skrajnościach - aktach heroizmu lub frustracji problematycznych dzieci. Zazwyczaj w trakcie rozwiązywania tych problemów dowiaduję się dużo o OBU imprezach.

Jest tu również czynnik związany z zarządzaniem ludźmi . Żaden inżynier nie jest dokładnie taki jak każdy inny. Więc nie wszystkie świecą w tym samym świetle. Jeden pisze genialny kod wolny od błędów, ale inny pomaga rozwiązywać problemy przekrojowe, które łamią kod każdego. Jeden jest świetny osobiście, drugi jest lepszy w pisaniu. Jeden jest niespójny o 9:00, jeden jest stąd przed 15:00. Istnieje pewna potrzeba wycofania się, ustalenia, co jest najbardziej korzystne dla zespołu i co może być czynnikiem osobistego uprzedzenia (na przykład chęć zabicia tego faceta o 4:00 rano, tylko dlatego, że nie mogę funkcjonować do 11: 00 rano).

Różni się to znacznie w zależności od wiedzy technicznej menedżera.

• W większości prawdopodobnie oceniają cię na podstawie tego, jak się komunikujesz . Jak komunikujesz się z menedżerem i jak widzisz komunikację z kolegami.
• Jeśli masz szczęście, że masz wiodącego programistę, który jest bliżej menedżera, menedżer może poprosić o informacje od głównego programisty.
• Pamiętaj, że głównym obowiązkiem menedżera jest załatwienie sprawy . Musi zobaczyć, jak generuje różne wyniki i cele, aby zrealizować biznesplan. Jeśli więc możesz wyglądać, jakbyś miał bezpośredni wpływ na wynik , dobrze ci to wróży.

Na ogół nie.

Dlatego programowanie jest „rynkiem cytryn”. http://en.wikipedia.org/wiki/The_Market_for_Lemons

Kod się psuje i na ogół nie trwa to 2-3 lata, zanim się zorientujesz. Programiści zwykle pozostają 18 miesięcy, więc nigdy nie widzisz winowajców po awarii.

Menedżerowie muszą wierzyć, że na przykład wydanie zajmuje cztery miesiące i sto iteracji. Może edytujesz ręcznie wiele plików wdrażania i odczytujesz ręcznie pliki dziennika pod kątem błędów pomieszanych ze statusem? Nie wiedzą, że można to zrobić lepiej.

Więc bądź uczciwy i profesjonalny i staraj się poprawić. Z doświadczeniem kierownik zacznie dostrzegać wzorce dobrych i złych zachowań.

Skąd menedżerowie wiedzą, czy dana osoba jest dobrym czy złym programistą?

Zacznę od rażącego uogólnienia: większość menedżerów nie może odróżnić „dobrego” programisty od „złego” programisty.

Poza tym to, co większość menedżerów (których spotkałem lub pracowałem) uważa za „dobre” u programisty, nie jest tym samym zestawem umiejętności, który inny programista uznałby za „dobry”.

jak oni to robią?

Menedżer zorientowany na wyniki będzie szukał takich rzeczy, jak „inteligentny” i „załatwia sprawy”. Nie będą się przejmować, jeśli przyjdziesz do pracy w spodniach dresowych, o ile wykonasz zadania na czas i zgodnie z budżetem.

Menedżer zorientowany na proces jest bardziej zainteresowany „tym, jak się to robi”. Oznacza to dotarcie do pracy na czas, noszenie odpowiedniej odzieży i czy masz odpowiedni arkusz tytułowy w raporcie TPS.

osoba działa dobrze, jeśli ona lub ona powinna być za coś odpowiedzialna

Bycie „odpowiedzialnym” wymaga innych umiejętności niż pisanie kodu. Jeśli dana osoba posiada umiejętności potrzebne do kierowania zespołem, należy ją wykorzystać. Jeśli awansujesz ludzi na podstawie kluczowych elementów stanowiska, które obecnie wykonują, ostatecznie osiągną poziom, na którym są teraz niekompetentni. Nazywa się to zasadą Piotra .

Oczywiście zawsze pomaga posiadanie umiejętności programistycznych, którzy potrafią czytać kod, a co ważniejsze, zagłębić się w system śledzenia błędów i zrozumieć, co się dzieje, wiedz, że nie wszystkie błędy są równe, a samo dostarczanie złego kodu na czas się nie liczy. za dużo.

Ale to idealny przypadek. Dla menedżera, aby uzyskać miarę programisty z nietechnicznej perspektywy, mam kilka sugestii.

• Czy szybko / regularnie / konsekwentnie zwracają uwagę na to, gdzie występują problemy z wykonaniem zadań w celu spełnienia aktualnie określonych wymagań ... i są z tego powodu bardzo denerwujące (w końcu jest to tworzenie oprogramowania, jeśli nie jest wystarczająco skomplikowane, aby mieć takie problemy, to nie jest prawdziwy projekt rozwojowy).
• Jeśli nie są czegoś pewni, od razu to mówią - tylko programista pewny swoich umiejętności faktycznie by to zrobił (i wie, że jeśli ci się nie spodoba, może łatwo dostać inną pracę). I odwrotnie, ktoś, kto wie, że są naprawdę poza swoją głębokością, ma tendencję do ukrywania się i szukania schronienia.
• Co inni programiści w zespole mówią / sugerują o innych programistach? Jeśli jesteś w połowie przyzwoitym menedżerem, jesteś w okopach ze swoim zespołem programistycznym - szczególnie podczas testów integracyjnych / naprawiania błędów. Więc jeśli nie otrzymujesz tego rodzaju informacji zwrotnych, ktoś inny powinien wykonywać Twoją pracę.
• I moje ulubione: to, co nazywam programistą „tomcat”. Jeśli po jakimś czasie ciągle zauważasz, że różni programiści zawsze kręcą się wokół tego samego biurka programisty (zakładając, że wykonują pracę i dyskutują o niektórych problematycznych kwestiach, a nie rezydenta znajdującego fajne i zabawne strony internetowe) ... to istnieje powód, dla którego inni programiści grawitują na biurku tej osoby. Jeśli nie są jeszcze liderem zespołu, prawdopodobnie powinni zostać jak najszybciej postawieni.

Jeśli którekolwiek lub wszystkie z nich mają zastosowanie, prawdopodobnie masz dobrego programistę na rękach. Zauważ, że przez dobrego programistę nie tylko oceniam ich zdolność kodowania, ale także inne przydatne rzeczy, takie jak możliwość komunikowania się z innymi ludźmi ;-)

Menedżer może nie wiedzieć, kiedy kod, który piszesz, jest genialny, czy też może zostać ulepszony przez ogromny czynnik, ale wie, że: czy dotrzymałeś terminu z działającym kodem? Czy jesteś osobą, której można zaufać w rozwiązywaniu problemów, które stwarzają inni ludzie? Czy klient lub użytkownik zauważył problem, który został eskalowany do jego menedżera? Czy na twoim zegarku wystąpiła poważna katastrofa (usunąłeś tabelę użytkowników, zapomniałem skonfigurować kopie zapasowe, wysłałem e-mail do klientów z zastrzeżonymi danymi innego klienta, których nie powinni byli widzieć itp. Czy ktoś pochwalił twoją pracę dla niego (szczególnie na piśmie) )? Czy ludzie mówią za tobą dobre lub złe rzeczy?

1. W większości przypadków, gdy twój kod nie jest oceniany przez twojego menedżera, jest oceniany przez twoich rówieśników (formalnie lub nieformalnie, gdy próbują pracować z twoim kodem). Twój szef do pewnego stopnia wykorzysta opinie twoich rówieśników (ponownie formalne lub nieformalne).
2. Twoja ogólna niezawodność oraz szybkość wykonywania zadań i ich wykonywania jest często bardzo ważnym czynnikiem, niezależnym od umiejętności kodowania.
3. Porozumiewanie się. Jeśli robisz dużo i robisz to dobrze, Twój menedżer musi o tym wiedzieć! (Oczywiście unikaj przechwalania się). Naucz się „zarządzać swoim menedżerem”, a nie po prostu być pasywnym. Pomóż swojemu szefowi wiedzieć, jak pracujesz.

Menedżerowie sami są programistami i dlatego, po prostej obserwacji, mogą dowiedzieć się, czy programista jest dobry, czy nie.

Jeśli twoi menedżerowie nie są programistami (a zajmujesz się oprogramowaniem), masz problemy.

Jako menedżer, oto kilka rzeczy, na które patrzyłem, oceniając moich programistów:

• Wzajemna opinia. Poprosiłem programistów z mojego zespołu oraz programistów z innych zespołów o przesłanie opinii na temat moich ludzi.

• Szacunek rówieśników . Kiedy moi programiści napotkali problem, którego nie potrafią rozwiązać, mówią „chodźmy poprosić o radę takich i innych”.

• Wykonuje zadania . Mówię „chcę X”, a następnego dnia X jest skończone.

• Sprawia, że ​​wszystko jest inteligentne . Mówię „chcę X” i następnego dnia X jest nie tylko gotowe, ale wszystkie rzeczy podobne do X zostały rozwiązane i nie wymagają dalszej uwagi.

• Rozwiązuje mnie . Mówię „chcę X”, a programista mówi „X nie ma racji, powinniśmy zrobić Y, i oto dlaczego”.

Nie ma tam wielu dobrych menedżerów (patrz powiązane pytanie: skąd programiści wiedzą, czy dana osoba jest dobrym czy złym menedżerem?). Dobre zarządzanie ludźmi jest trudne i wymaga dużo czasu i ciężkiej pracy. Gdy tylko zarządzałem 5 osobami, prawie nie miałem czasu na programowanie. Kiedy zarządzałem ponad 8 osobami, nie mogłem nimi zarządzać tak dobrze, jak na to zasłużyli.

Myślę, że przesłanka twojego pytania jest nieco błędna, ponieważ zapewnia, że ​​menedżerowie tak naprawdę nie patrzą na kod. Pracowałem w wielu sytuacjach, w których moi menedżerowie byli współpracownikami i aktywnie uczestniczyli w przeglądach kodu.

Zdecydowanie jednak istnieje wiele sytuacji, w których inżynierowie oprogramowania zajmują się osobami nietechnicznymi i nie są oni w stanie polegać na własnej wiedzy i doświadczeniu.

W takich przypadkach odpowiedzialni menedżerowie zwrócą się do inżynierów o poradę. Poprosą osoby nietechniczne w organizacji, z którymi inżynier wchodzi w interakcję, o sprawdzenie, czy ma dobre umiejętności ludzi, które są zgodne ze zwiększoną odpowiedzialnością.

Te nieodpowiedzialne po prostu pójdą ze swoimi „jelitowymi” reakcjami, używając jakichś ogólnie nieobsługiwanych „wskaźników”.

To bzdura, ale zawsze możesz zrezygnować i mieć nadzieję na coś lepszego gdzie indziej.

Kiedy pracuję, kiedy pojawiają się oceny pracowników, kierownicy wysyłają nieformalne, anonimowe pytania do tych, którzy regularnie wchodzą w interakcje z pracownikiem; zarówno deweloperzy, jak i klienci. Daje to innym programistom możliwość wniesienia wkładu w wydajność jako programista, którego menedżerowie mogliby przeoczyć.

Kierownik musi spojrzeć na mierzalne. Jakie aspekty pracy są mierzalne pod względem wykonywanej pracy, jakości pracy. Mogą nie wiedzieć, czy wykonujesz dobrą pracę, chyba że wygenerujesz wiele błędów lub nie pozwoli użytkownikowi końcowemu zrobić tego, co powinien.

Twoja praca kosztuje kierownika kosztami, dlatego musisz być opłacalny, aby kontynuować zatrudnienie.

Nie twierdzę, że to najlepszy sposób, aby to zrobić, ale mogliby opierać się na zadowoleniu klientów. Jeśli podoba im się aplikacja, zaakceptuj liczbę błędów i poczujesz, że dodajesz nowe funkcje w odpowiednim czasie, czy twoi programiści naprawdę mogą być tacy źli?

Oczywiście, że mogli. Są w stanie brutalnie naciskać na kodowanie, ponieważ 10 osób wykonuje pracę dwojga. Lub klienci są zadowoleni, ponieważ sprzedajesz swoją aplikację tak tanio.

Innym problemem związanym z tym podejściem jest to, że musisz poczekać, aż aplikacja zostanie prawie ukończona, zanim nietechniczny menedżer będzie mógł uzyskać opinie klientów. Zbuduj aplikację tylko na rok, aby ją wydać i nikomu się nie spodoba.

Życie byłoby prostsze, gdybyś mógł polegać na mówieniu ludziom: „Po prostu spraw, aby działało”. Kiedy zrozumiesz i zmusisz ludzi do przestrzegania właściwego procesu, wyeliminujesz wiele problemów. Możesz mieć wymagające terminy, które są realistyczne. Każdy głupiec może wymyślić nierealistyczne wymagania i ryzykować utratę utalentowanych ludzi.

Myślę, że większość z nas w zespole technicznym wie, kto rządzi, a kto jest do bani. Chyba że masz ogromny obrót, krem ​​wznosi się do góry, a ciężar własny spada. Crummy Devs zawsze mają jakieś kłopoty - zapominają przetestować swój kod, zanim go sprawdzą, więc kompilacja się psuje, zawsze mają pretekst, gdy coś nie jest zrobione i tak dalej.

Myślę, że nie wiem, czy ktoś jest dobry programista , beucase nie mają umiejętności, aby to zrobić. Sprawdzają, czy ktoś jest dobrym programistą . Programowanie jest działaniem rozwojowym, ale rozwój ma wiele innych. Sprawdzają więc, czy zdążysz na czas, czy twoje oceny są dobre, czy w systemie śledzenia błędów jest wiele usterek, twoje umiejętności miękkie, zaangażowanie, komunikacja itp.

To, co niektórzy guru czasami zapominają i denerwują, to fakt, że nasza praca to nie tylko programowanie, mamy wiele innych rzeczy do zrobienia, które są również bardzo ważne. Chociaż Twój menedżer nie przyjrzy się temu, jak wygląda Twój kod (ponieważ jest to dla niego zupełnie nieważne), sprawdzi, czy jesteś graczem zespołowym, odpowiedzialny, pełen szacunku i ogólnie wykonujący dobrą pracę .

Czasami myślę, że kod jest przereklamowany.

Myślę, że jest bardzo mało osób (nie mówiąc już o menedżerach), którzy nie mają dobrego ogólnego zrozumienia kolejności dziobania dla programistów. Wszyscy myślą, że są programistami najwyższej klasy, jedynymi ludźmi, którzy nie wiedzą, kim są źli programiści, sami są ci źli programiści. W każdym razie, jeśli miałbyś się rozejrzeć i poprosić kogoś o ocenę programistów, z którymi współpracuje, jestem pewien, że dla większości osób byłoby to łatwe zadanie. Więc nie ma magii w określaniu, kto osiąga bardzo dobre wyniki, a kto osiąga wyniki średnie, czy złe itp. Jedyną przeszkodą, z którą deweloperzy i menedżerowie się nie zgadzają, są ci sprzedawcy, głośni, którzy brzmią, jakby wiedzieli, o czym mówią o, ale naprawdę nie. Większość menedżerów jest przez nich oszołomionych, ale nie są to programiści.

Następnie to ranking twojego menedżera określa uprzedzenia twojego menedżera. Dla niektórych kodowanie jest zadaniem na poziomie podstawowym, więc chociaż możesz być doskonały w kodowaniu, nie dostarczy ci promocji, której szukasz. Inni uważają, że najważniejsze są aspekty projektowe lub architektoniczne. Inni uważają, że najważniejsze jest zdefiniowanie i zebranie wymagań (tj. Analiza biznesowa). Jeśli chcesz wiedzieć, co jest ważne dla swojego menedżera, a nie uzyskałeś rankingu najlepszych wyników, zapytaj go, co muszę zrobić, aby uzyskać ranking najlepszych wyników? Dowiesz się, co jest dla nich ważne w tej odpowiedzi, a następnie od Ciebie zależy, czy osiągniesz cel w tych ważnych obszarach.