Jaka jest rola starszego programisty w zespole? [Zamknięte]

Z zespołem 3 innych programistów internetowych mam tytuł wiodącego programisty internetowego od roku. To moja pierwsza praca jako lead.

Jestem dość nastawiony na to, jakie są moje role związane z zarządzaniem. Jestem ciekawy, co robią inni programiści na wyższym poziomie. Zastanawiam się przede wszystkim, na czym polegają obowiązki innych osób jako główny / starszy programista w innych organizacjach; ponieważ spotkałem się tylko z pracą w małej / średniej firmie.

(a) Czego można oczekiwać od starszego / wiodącego programisty WWW organizacji (niezależnie od wielkości)?

(b) Czy istnieje różnica między liderem rozwoju sieci a starszym programistą?

Przejrzałem kilka wątków i był tylko jeden, który omawiał, kiedy powinieneś nazwać siebie starszym programistą, ale nie omawia kompleksowo ról, co starszy programista powinien zrobić ze swoim zespołem.

Punkt widzenia kierownika projektu

Jesteś jedynym (lub domyślnym) punktem kontaktowym w sprawach związanych z techniczną stroną rzeczy. Oczekuje się, że praca innych programistów będzie się poruszać siłą, prowadząc przez przykład lub jakąkolwiek inną metodą.

Punkt widzenia dewelopera niebędącego leadem

Jesteś wzorem do naśladowania. Spodziewaj się, że mniej doświadczeni programiści spojrzą na ciebie i zadadzą pytania techniczne, gdy utkną.

Myśleć

Jeśli naprawdę pytasz internet o określenie swojej roli / pracy, przestań. Porozmawiaj z zarządem, aby uzyskać prawdziwą odpowiedź.

Jako wiodący programista masz dwie podstawowe role: być rzecznikiem swojego zespołu po stronie biznesowej działalności i zapewniać zespołowi wskazówki techniczne.

Jako adwokat powinieneś pomagać w przekazywaniu wymagań zespołowi, odsuwając się, gdy strona biznesowa (kierownictwo, kierownicy projektu lub sprzedawcy) wysyła nierealistyczne żądania lub wymagania, i ogólnie radzisz sobie ze wszystkim, co powstrzymuje Twój zespół od pisania kodu.

Jako mentor techniczny musisz pomagać swojemu zespołowi w podejmowaniu właściwych decyzji, pomagać mu w rozwiązywaniu problemów technicznych i kierować je do właściwych rozwiązań. Powinieneś zachęcać ich do podnoszenia swoich umiejętności i bezwzględnie upierać się przy przestrzeganiu odpowiednich standardów rozwoju.

Co najważniejsze, musisz być nieskazitelnym wzorem do naśladowania. Twój kod powinien być na najwyższym poziomie, twoje projekty powinny być dostarczone na czas i najwyższej jakości. To, co robisz, będzie o wiele ważniejsze niż to, co mówisz.

EDYCJA: Jeszcze jedna rzecz. Musisz być proaktywny w kwestiach technicznych. Nie czekaj, aż twój zespół przyjdzie do ciebie z problemami. Bądź świadomy tego, nad czym pracują i idź do nich, jeśli zajmują zbyt dużo czasu, jeśli wiesz, że są na trudnych zajęciach lub poza zestawem podstawowych umiejętności, lub jeśli wyglądają na sfrustrowanych. Słuchaj, kiedy ludzie w twoim zespole zaczynają omawiać problemy techniczne bez ciebie i wkraczaj, jeśli (i tylko wtedy) czujesz, że zaczynają odchodzić od przyzwoitego rozwiązania, lub jeśli krąży w kółko i niczego nie osiągają.

Wyjaśnijmy ... przywództwo .

Wszystkie błędy twojego zespołu są teraz Twoim winem.

To samo dotyczy sukcesów, ale tak naprawdę jest to rozwój oprogramowania, sukces jest skromny, z trudem poradzisz sobie z nadmiarem sukcesu.

Skoncentruj się na tych błędach. Unikaj ich, minimalizuj je, staraj się je kontrolować.

I nie daj się zwieść, twój zespół popełnia więcej błędów, jeśli to zrobisz .

IMO pełni rolę przewodnika. Przebywałeś już cały blok, więc jeśli inny (nie młodszy, ale nie starszy) programista ma pytanie lub napotyka problem w module Foobar, jesteś facetem, który pyta: „Próbuję zrobić X z Foobar, jakieś pomysły? ”. Powinieneś także komunikować cele zespołu i wysiłek kierownictwa, będąc po stronie zespołu w kwestiach technicznych (np. Jeśli ty i zespół sądzicie, że projekt zajmie 4 miesiące, nie zawiedźcie się i powiedzcie dyrektorowi, że to będzie w ciągu 1 miesiąca, a następnie zmusić wszystkich do pracy w nadgodzinach). Powinieneś być również odpowiedzialny za upewnienie się, że kod jest odpowiedniej jakości, a inni członkowie zespołu robią wszystko dobrze, a nie tylko hakują śmieci, które spadną w dół drogi.

Oczywiście to wszystko teoretycznie. To zależy od zespołu; Pracowałem u „seniorów”, którzy nie wiedzieli nic o żadnym nowoczesnym rozwoju w ciągu ostatnich 5 lat i byli „Smithers” dla kierownictwa wyższego szczebla i powiedzieli „Sir, tak jest!” na każde żądanie, bez względu na to, jak absurdalna, stłumiona kreatywność innych członków zespołu, i zachęcała do bardzo słabego środowiska pracy zamiast ciągłego uczenia się i kunsztu. Pracowałem również pod bardzo doświadczonymi starszymi programistami, którzy brali czynną rolę, upewniając się, że wszystko jest tak, jak to tylko możliwe, i nigdy nie ulegali presji kierownictwa.

Jestem starszym devloper'em i mam kilku technicznych liderów, z którymi pracuję. Różnica polega na tym, że są to kierownicy projektów technicznych. Jeśli między deweloperami występuje konflikt dotyczący kwestii technicznych, podejmują decyzję, co robić. Jeśli sprawy są opóźnione, decydują, jak rozwiązać ten problem. Są odpowiedzialni za dopilnowanie, aby ludzie poświęcali swój czas na projekt, aby żądano więcej godzin w razie potrzeby, przydzielano nowe zadania, dokonywano przeglądów kodu (jako starszy mogę wykonać recenzje kodu) itp. Jako starszy, Generalnie przydzielono mi trudniejsze zadania. Jako starszy jestem konsultowany i oczekuje się, że będę mentorem młodszych ludzi. Kierownicy techniczni też to robią, ale mają moc decyzyjną i odpowiedzialność za ogólny sukces projektu. Jako starszy jestem odpowiedzialny tylko za moją część projektu.

Jak wspomniano powyżej Jonathan, może istnieć wiele różnych punktów widzenia.

Jako starszy programista możesz podejmować decyzje architektoniczne dla swojej grupy i działać jako przedstawiciel zespołu na spotkaniach grupy programistów wyższego poziomu. Możesz także służyć jako mentor i kierować działaniami technicznymi członków swojego zespołu.

Często możesz być także łącznikiem z kierownictwem projektu i użytkownikami biznesowymi. Pomożesz zdecydować, w jaki sposób i kiedy dostarczyć wyniki projektu, i możesz mieć możliwość negocjowania priorytetów elementów projektu w dłuższej perspektywie.

Krótko mówiąc, twoja rola jest tym, co wybierzesz, biorąc pod uwagę granice ustalone przez twoje własne kierownictwo (zarówno techniczne, jak i biznesowe).

Inni ludzie omówili podstawowy aspekt tego pytania dotyczący przywództwa, dlatego postaram się skupić moje uwagi na zadanych bezpośrednich pytaniach:

(a) Czego można oczekiwać od starszego / wiodącego programisty WWW organizacji (niezależnie od wielkości)?

Oczekiwałbym osoby o silnym charakterze i bazie wiedzy technicznej. Spodziewałbym się kogoś, kto nie tylko zburzy pomysły, ale zaproponuje nowe pomysły, które zastąpią te, które uznają za niedoskonałe. Spodziewałbym się kogoś, kto nie naciska ani nie nęka podległych programistów, ale próbuje znaleźć sposoby, które motywują, uczą, kierują każdą osobą. Oczekiwałbym, że ktoś chętnie weźmie na siebie odpowiedzialność za projekty, koncepcje i decyzje. „Tak” i „ścienne kwiaty” nie muszą mieć zastosowania. Senior / lead musi być w stanie radzić sobie z ludźmi tak samo skutecznie, jak robi to z kodem ... w niektórych przypadkach nawet lepiej.

(b) Czy istnieje różnica między liderem rozwoju sieci a starszym programistą?

Zasadnicza różnica, którą zaobserwowałem, dotyczy zakresu i nigdy nie widziałem jej nigdzie zapisanej. Dowód zwykle odpowiada za wydajność jednego zespołu. Senior może być odpowiedzialny za kilka zespołów, jeden zespół lub brak zespołu. Ołów ma pomóc swoim podległym programistom w osiągnięciu ich celów w ramach konkretnego projektu lub zadania. Przez podwładnego rozumiem po prostu deweloperów, którzy zostali przypisani do projektu, za który kierownictwo jest technicznie „odpowiedzialne”. Często uważam, że jestem liderem w projektach, w których kilku programistów jest równych lub ma więcej stażu pracy niż ja, więc nie jest oczywiste, że liderem będzie najbardziej „starszy” członek zespołu. Biorąc pod uwagę ten zakres, starszy programista to ktoś, na kogo cała organizacja może liczyć, aby mieć niezbędną wiedzę i doświadczenie, aby pomóc każdemu. Senior powinien być wzorem do naśladowania (jak ktoś inny powiedział) dla każdego programisty w organizacji, a także powinien pomagać młodszym programistom w kwestiach technicznych.

Krótko mówiąc, dla mnie: trop pomaga. Senior uczy.

Starsi programiści mogą być postrzegani jako osoby, które mogą podjąć problem, znaleźć różne rozwiązania i wdrożyć najlepsze samodzielnie. W pewnym sensie armia jednoosobowa. Mentor młodszych programistów, aby poprawić ogólną wydajność zespołu. Można go również wykorzystać w celu wykorzystania wiedzy specjalistycznej w różnych pakietach oprogramowania, ponieważ w niektórych przypadkach można się spodziewać, że senior będzie wiedział coś lepszego niż inni programiści. Zasadniczo umiejętności, które programista wykorzystał dla maksymalnych korzyści, którymi może być połączenie mentoringu, konsultacji, kodowania, projektowania i tworzenia procesów.

Wiodący twórcy stron internetowych mogą przychodzić mi na myśl w kilku różnych formach. Kierownikiem zespołu jest kierownik administracyjny i to on przeprowadzi ogólny przegląd wydajności, będzie wiedział, jakie projekty przydzielono programistom i zajmie się niektórymi formalnościami, a jednocześnie będzie programistą. Istnieje również podstawa projektu, w którym koncentracja osoby jest znacznie węższa, ponieważ to właśnie na tym projekcie osoba ta jest odpowiedzialna za egzekwowanie standardów i praktyk w zespole. Pojawia się zatem pytanie, co tak naprawdę prowadzi? Projekt czy grupa programistów z perspektywy administracyjnej?