Czy możesz być jednocześnie menedżerem i programistą? [Zamknięte]

Zarządzanie innymi programistami, gdy sam jesteś częścią siły roboczej zajmującej się programowaniem.

To bardzo popularny schemat, przynajmniej w firmach, w których pracowałem.

Czy potrafisz być dobrym programistą lub dobrym menedżerem, jeśli robisz to jednocześnie?

Kwestionuję skuteczność osoby, która musi odgrywać dwie bardzo różne role, wymagające bardzo różnych umiejętności, środowiska, koncentracji, organizacji itp.

AKTUALIZACJA : moje pytanie obejmuje zarządzanie firmą (co w moim przypadku), a nie zarządzanie zespołem. Ale interesują mnie oba.

Zależy to od ilości i rodzaju programowania, jakie musisz wykonać, oraz od ilości i rodzaju obowiązków kierowniczych, które musisz wykonać.

Bycie menedżerem oznacza wiele przerw, zmian w halsie i takich rzeczy jak spotkania itp.

Jeśli twoje programowanie jest „ograniczone” do drobnych prac niepilnych, możesz dopasować je do swoich obowiązków kierowniczych. Jeśli musisz poświęcić znaczną ilość „jakościowego” czasu na zadanie programistyczne, nie dostaniesz tego czasu ze względu na obowiązki kierownicze.

Jeśli twój zespół jest duży i / lub złożony, będziesz musiał poświęcić więcej czasu na zarządzanie niż gdybyś był małym zespołem poświęconym jednemu lub dwóm produktom / projektom. Przekonasz się, że po prostu nie masz czasu na sensowne programowanie - nawet na małe zadania.

W poprzedniej pracy miałem tę rolę i działało to dla mnie, ponieważ utrzymywałem małe zadania programistyczne. To faktycznie działało na naszą korzyść.

Po pierwsze, mogłem ocenić wszystkie otrzymane żądania i jeśli byłyby małe, dodaj je do mojej kolejki (która zawsze była krótka) lub wróć do klienta (w tym przypadku innego menedżera) z dokładniejszym harmonogramem czasu, w którym praca będzie będzie zrobione.

Po drugie, oznaczało to, że programiści w zespole nie byli ciągle usuwani z bieżącej pracy, aby naprawić drobne błędy lub wprowadzić drobne ulepszenia.

Po trzecie, klienci byli zadowoleni, ponieważ ich pilne problemy zostały naprawione dość szybko.

Utrzymywałem kontakt z bazą kodu, dzięki czemu mogłem prowadzić znaczące rozmowy z moim zespołem na temat problemów, a także z menedżerami i klientami na temat terminów bez konieczności ciągłego angażowania zespołu.

Należałem do zespołu programistów, w którym jeden programista był również naszym menedżerem. Doprowadziło to do całkowitego załamania wszystkiego, co przypominało produktywność. Krótko mówiąc, wszystkie decyzje zostały podjęte przez tego faceta + był kompletnym mikro menedżerem. Wszelkie pomysły i sugestie, z którymi się nie zgadzał, zostały zestrzelone lub zignorowane. To ostatecznie zabiło wszelką kreatywność i motywację.

Myślę, że to zły pomysł, aby ktokolwiek w zespole deweloperów zajmował „wyższą” pozycję. W moim przypadku facet był menedżerem dowodzenia i kontroli, ale nawet świetny menedżer (niechcący) wpłynie na innych programistów, co ostatecznie doprowadzi do obniżenia wydajności. Przynajmniej raportuje mu zespół.

Tak
, widziałem kilku menedżerów, którzy byli jednocześnie programistami i menedżerami. Uwierzcie, że praca pod tymi facetami była cudowna.
Bycie menedżerem i programistą nie tylko pozwala menedżerom prowadzić z przodu, ale także motywuje podwładnych do dawania z siebie wszystkiego.
Większość Pracowników narzeka na swoich menedżerów, że menedżerowie są bezwartościowi, ale menedżer, który nie tylko zarządza, ale także pisze kod, zawsze zapewnia najlepsze wyniki.
Dwóch menedżerów, o których wspomniałem, programowanie było ich pasją, która nie tylko pomogła innym, ale także stworzyła jedną prawie bezbłędną aplikację.

Od lat jestem kierownikiem projektów programistycznych, w różnych firmach, projektach i zespołach.

Zarządzanie projektami i programowanie to tak różne rodzaje zadań / ról, że argumentowałbym, że nie można wykonywać obu jednocześnie na „doskonałym” poziomie. To kompromis - mistrz żadnego, walet wszystkich branż, coś w tym rodzaju.

Dla mnie największym problemem jest zmiana kontekstu między trybem menedżera i programisty. Wydaje się, że angażują różne części mózgu (lub coś w tym rodzaju). Pewnego dnia programowanie, pewnego dnia zarządzanie mogę sobie dobrze poradzić, ale ciągłe przełączanie między tymi rolami jest trudne.

Widziałem oba scenariusze. Menedżerowie programistów wykonują {pewien procent swojego czasu} kodowania, a menedżerowie programistów w ogóle nie kodują.

Problem polega na tym, że im wyższy jesteś, tym bardziej prawdopodobne jest, że będziesz chciał dostać więcej, a jedynym sposobem na uzyskanie tego w wielu miejscach jest przejście do zarządzania. (nie wszystkie oczywiście, ale wiele miejsc). Może to prowadzić do tego, że ludzie, którzy tak naprawdę nie są przygotowani do zostania menedżerami, utkną w takiej sytuacji.

(Oczywiście są firmy, w których możesz przejść przez Dev, Dev Lead - inaczej niż oczywiście Dev manager - na stanowiska takie jak Architect itp.)

Szanse są, jako techniczny, ty może być bezużyteczny na ludzi-zarządzania, a także, że zabierze Cię dalej od kodu. Stajesz się złym menedżerem i robisz mniej rzeczy, które lubisz i prawdopodobnie zacząłeś się rozwijać!

Dla mnie, jako menedżera, powinieneś naprawdę odrywać ręce od kodowania, ale absolutnie bądź na bieżąco z technologią, abyś mógł przynajmniej nadal spójnie rozmawiać o problemach.

Tak się składa, że ​​zacząłem freelancing właśnie z tego powodu. Nie interesuję się zarządzaniem ludźmi i myślę, że nie byłbym w tym szczególnie dobry, a ponadto nie dostałbym tyle kodu.

Można to zrobić, ale jest pełne pułapek. Wielkość grupy i poziom zakłóceń odgrywają dużą rolę, ale najbardziej znaczącym ryzykiem jest to, że menedżer będzie również liderem technicznym. Zbyt dużo opiniotwórczych opinii, gdy nie ma wystarczająco dużo czasu / wysiłku, aby uzasadnić opinię, może prowadzić do złych decyzji. A debata na temat kierunku nie jest bardzo wyrównana dla menedżera i reszty zespołu.

Dla osób rozważających tę ścieżkę, kilka porad:

• Wyjdź z roli architektury i zidentyfikuj potencjalnych klientów w grupie.

• Nie pracuj na elementach ścieżki krytycznej. Napraw błędy, pracuj nad prototypami lub innymi przedmiotami, które można szybko odrzucić, gdy twój szef znajdzie o wiele więcej „ważnych rzeczy”, aby cię rozproszyć.

• Podnieś swój poziom uwagi i skoncentruj się na ogólnej wydajności, obronie i promowaniu zespołu, procesie, morale i innych aspektach niezbędnych do sukcesu zespołu. Twój cel prawdopodobnie będzie czymś więcej niż tylko udanym projektem (niezależnie od tego, co powie szef, premier lub inny).

• Pomóż swojemu zespołowi się rozwijać: stać się bardziej niezależnym, samoorganizującym się, specjalistą technicznym, wyższy poziom świadomości.

• Pod wieloma względami jesteś pomostem między drużyną a światem zewnętrznym. Znaczna część twojego zainteresowania powinna znajdować się poza zespołem.

Aby odpowiedzieć na pytanie, tak, można to zrobić. Nie, nie jest to łatwe i zdecydowanie zbyt wielu nowych menedżerów ze strony technicznej domu, którzy mogli być świetnymi leadami, nie mogą przejść na stanowisko odnoszącego sukcesy menedżera.

Dobry menedżer może być, tak. Dopóki jesteś asertywny i konsekwentny, zazwyczaj nie ma problemu.

Jeśli powiedziano pracownikom, aby zgłaszali problemy z kolegami z zespołu ze swoim przełożonym .. a kierownik jest również kolegą z zespołu, może się kleić. Ważne jest, aby obiektywnie przeglądać wszystkie opinie i zdawać sobie sprawę, że od czasu do czasu możesz się mylić. Powinieneś także zapewnić anonimowy sposób przekazywania opinii.

Jest to bardzo powszechne (jak powiedziałeś) w firmach typu start-up.

Myśle że nie.

Oba zadania wymagają dużego skupienia, energii i poświęcenia. Wykonanie obu jest bardzo trudne. Kiedy musiałem przejąć obowiązki kierownika zespołu, zmniejszyłem czas poświęcony na programowanie (a co za tym idzie ilość pracy związanej z programowaniem).

Znam innego kolegę, który objął kierownicze stanowisko w zespole i całkowicie przestał kodować w ciągu miesiąca (choć próbował zrobić oba te elementy).

Znam również architekta, który został poproszony o objęcie stanowiska kierownika. Przestał też kodować w ciągu miesiąca po objęciu obowiązków kierowniczych. Ten sam architekt po 8 miesiącach musiał wrócić do kodowania z powodu krytycznych problemów w terenie. Znacząco przyczynił się do naprawy błędów, ale w ciągu miesiąca musieli znaleźć menedżera zastępczego, aby przejąć jego obowiązki kierownicze.

Z mojego ograniczonego doświadczenia nie spotkałem nikogo, kto zarządzałby innymi programistami i kodami jak pełny programista.

Moim zdaniem, chociaż jest to możliwe w większości scenariuszy, nie jest to dobre ustawienie. Istnieje wiele artykułów na temat tego, jak ludzie, którzy są biegli jako programiści, są zauważani i wychowywani do roli kierownika zespołu, nawet jeśli nie jest to ich konkretny zestaw umiejętności ani nawet pożądana pozycja. Zmagają się z utrzymaniem koncentracji na „zarządzaniu”, ponieważ widzą, że „praca” to robienie programowania, a nie tworzenie raportów i chodzenie na spotkania.

W swoim artykule na temat warstwy abstrakcji programisty Spolsky napisał :

„W firmie produkującej oprogramowanie priorytetem zarządzania musi być tworzenie tej abstrakcji dla programistów”.

W artykule (zdaniem, ale dobrze uzasadnionym) rola menedżera nie polega na wchodzeniu w kod lub programowaniu, ale na tworzeniu środowiska, w którym twórcy mogą się na nim całkowicie skoncentrować.

Mój były szef próbował. Było zbyt wiele przerw w jego roli kierowniczej.

Nadal jest jednym z najlepszych programistów, jakich znam.

Oczywiście, że możesz, ale to nie znaczy, że to łatwe. Pewien rodzaj osoby wymaga dobrego dewelopera, określony typ osoby to dobry menedżer, a pewna osoba to jedno i drugie. Jeśli możesz znaleźć tę osobę (lub tę osobę), istnieją określone zalety. Menedżerowie programistów pierwszego lub drugiego poziomu muszą naprawdę rozumieć, co robią ich ludzie i na co dzień się spotykają. Trudne, jeśli nie jesteś programistą i trudno jest pozostać w kontakcie / na bieżąco bez dalszego rozwoju.

Najlepszy menadżer, jakiego kiedykolwiek miałem (byłem w wieku około 25 lat), był aktywnym programistą, moim menedżerem i pół-właścicielem firmy (około 40 emps). Był wyjątkowy, ale wyraźnie mu się to udało.

NA PEWNO NIE !!

Możesz spróbować, ale skończysz zarządzanie bardziej niż cokolwiek innego. Problem polega na tym, że nie można kodować, gdy ludzie dzwonią do ciebie co 5 minut lub próbują organizować spotkania „statusowe” co godzinę. To śmieszne ... Robię to teraz i dlatego natknąłem się na ten wątek.

Chociaż menedżer w firmie technologicznej POWINIEN .. nie ... MUSI wiedzieć, jak kodować. Po prostu nie będziesz w stanie oszacować ani zrozumieć problemów klienta. Kodowanie i zarządzanie to dwa typy ludzi. Jedna strona to maniacy i niezręczni w kontaktach z ludźmi (spójrz prawdzie w oczy, maniacy wiedzą o czym mówię), a druga są dobrzy dla ludzi. Musisz wybrać stronę. Jeśli zrobisz oba, nigdzie nie dojdziesz do kodowania. Jeśli uwielbiasz kodować i potrafisz to robić 24 godziny na dobę, 7 dni w tygodniu, jeśli twoja żona Ci nie przeszkadza, ZATRZYMAJ SIĘ OD ZARZĄDZANIA. W razie potrzeby skorzystaj nawet z obniżki wynagrodzenia. Zaraz to zrobię, ale nie sądzę, by szefom się to spodobało, ponieważ ułatwiam im życie, zajmując się zarządzaniem. Będę musiał wrócić do freelancingu, jeśli się nie zgodzą, ponieważ szczęście i robienie tego, co kochasz, jest ważniejsze niż pieniądze i iluzje, które kupuje.

Pozdrawiam serdecznie i proszę o dalsze publikowanie tych postów. Jesteście niesamowici.

Przeczytaj sekcję „Brak ścieżki kariery zorientowanej na programowanie” na tej stronie. Całkiem dobre rzeczy i bardzo istotne: http://c2.com/cgi/wiki?ProgrammingIsNotFun

Możliwe, że dana osoba ma zarówno dobre umiejętności menedżerskie, jak i dobre umiejętności programistyczne, chociaż przychodzi na myśl powiedzenie „walet wszystkiego jest mistrzem niczego” ...

Jednak łączenie obu funkcji jednocześnie wydaje mi się skłonne do wykonania obu zadań tylko w połowie. Zależy to od ilości zarządzania, które należy wykonać, ale nieuchronnie żonglujesz dwoma zadaniami o zupełnie innym charakterze, a przesunięcie uwagi, którego wymaga, jest dość duże. Zauważam, że w sekcji kodowania wykonuję znacznie mniej zadań, gdy mam również zadania związane z zarządzaniem (w moim przypadku zarządzanie kursami i pisanie raportów).

Kolejną pułapką jest to, że zarządzasz grupą, ale jesteś także bezpośrednio zaangażowanym podmiotem. Czasami to się opłaca, a czasem może powodować duże problemy. Jeśli inni programiści nie zgadzają się z twoją pracą, fakt, że jesteś menedżerem, może uniemożliwić im całkowitą otwartość.

Z drugiej strony, kiedy kodujesz w tym samym projekcie, którym zarządzasz, czujesz się trochę lepiej z samym kodem, więc w takim przypadku bit programowy może naprawdę pomóc bitowi zarządzającemu. Wszystko zależy od tego, czym musisz zarządzać, ile czasu to wymaga i ile pozostaje związane z kodem, nad którym pracujesz.

Sądzę więc, że nie ma jednoznacznej odpowiedzi, ale staram się unikać zbytniego mieszania się obu. Moje 2 centy

Cóż, czytałem, że menedżerowie projektów oprogramowania zdecydowanie powinni być programistami.

Myślę, że menedżer jest menedżerem z jednego powodu - zarządzania. Uznałbym to za ogólną zasadę ... niektóre mogą być mieczem obosiecznym.

Znam jeden przypadek, w którym to działa. Ten człowiek jest trochę pracoholikiem, więc pracuje na pełny etat jako menedżer, a prawie na pełny etat jako programista.

Biorąc pod uwagę normalne godziny pracy, nie sądzę, aby taka podwójna rola była dobrym pomysłem. Programiści zarządzający (lub menadżer programowania) zawsze mają pokusę, aby samodzielnie wykonywać większość zadań programistycznych, zamiast zmuszać ich do tego. Zawsze istnieje taka wymówka: „wyjaśnienie zajmuje więcej czasu niż zrobienie”, ale na dłuższą metę 50% pracy programisty, którą wykonuje, brakuje w części zarządzania, więc inni programiści są mniej wydajni.