Co sprawia, że ​​dobry architekt / manager / główny programista?

Jestem głównym programistą małej firmy programistycznej. W ciągu ostatnich dwóch lat mój zespół urósł z jednego programisty (mnie) do grupy około dziewięciu osób. Większość z nas to bardzo zdolni, starsi inżynierowie (ponad 20 lat doświadczenia w tworzeniu oprogramowania na osobę), więc generalnie konieczne jest bardzo małe trzymanie się za ręce. Używamy Scruma do zarządzania naszymi wysiłkami i zwykle dużo robimy szybko przy minimalnych pisemnych wymaganiach.

W miarę rozwoju zespołu doszedłem do momentu, w którym trudno mi utrzymać nadzór techniczny nad całym projektem, a także napisać znaczną ilość nowego kodu, więc nadszedł czas, abym dostosował swoją rolę. Jak mogę się najbardziej przydać zespołowi, gdy nie spędzam już więcej czasu na rozwoju?

Moim celem jest umożliwienie mojej grupie dalszego rozwoju (tj. Zwiększenie prędkości Scruma) poprzez dodanie większej liczby programistów , więc nie chcę po prostu zostać „architektem policji”, który narzuca moją wolę zespołowi. Innymi słowy, chcę być facetem, który pomaga rzeczy działać lepiej / płynniej, niż być facetem, który spowalnia rzeczy poprzez dodanie niepotrzebnej warstwy biurokracji. Jedno z naszych głównych zagrożeń polega na tym, że sytuacja wymknie się spod kontroli, jeśli dodamy więcej osób bez wystarczającej struktury, aby utrzymać nas wszystkich na tej samej stronie.

Jaki jest najlepszy sposób na osiągnięcie mojego celu?

Gdybyś był w takiej drużynie, co chciałbyś, żeby twój szef zrobił ze swoim czasem?

1. Usuń przeszkody na drodze do postępu.
2. Mediować spory między członkami zespołu.
3. Współdziałaj z ludźmi biznesu, więc nie musimy.
4. Informuj nas o sprawach biznesowych / projektowych na wyższym poziomie, abyśmy nie czuli się odizolowani.
5. Zachowaj nas uczciwie, zwłaszcza jeśli / gdy do zespołu dostanie się złe jabłko.
6. Bądź orędownikiem zespołu w innych działach.
7. Bądź jednolitym głosem odepchnięcia od nieuzasadnionych żądań biznesowych.
8. Ułatwienie komunikacji między zespołem.

Jest pewna grupa, o której zapominam, ale to jest jej sedno. Nie wdrażaj procesu, radz sobie z niektórymi z tych kosztów ogólnych / nieefektywności, które naturalnie rozwijają się wraz ze wzrostem wielkości zespołu.

Nie miałbym problemów z kierownictwem zespołu, który byłby w stanie zrównoważyć obowiązki kierownicze i techniczne, ale ciężko jest znaleźć ludzi, którzy dobrze sobie radzą z zarządzaniem tą równowagą.

Gdybym musiał wybierać między dwiema skrajnościami z kierownika zespołu w rosnącym zespole ... to naprawdę trudny wybór, ale ostatecznie myślę, że chciałbym, aby zespół stał się bardziej menedżerem. W sporym zespole miałbyś nadzieję, że będą inni kandydaci, którzy wkroczą na stanowisko starszego programisty, który może wychowywać nowych członków zespołu i nadal ciężko pracować nad rozwojem.

Ale w rosnącym zespole zdecydowanie chcesz też dobrego menedżera. W rzeczywistości posiadanie dobrej osoby z tytułem kierowniczym jest ważne, ponieważ chcesz, aby miała ona wystarczającą moc, aby podejmować dobre decyzje. Dobry menedżer ma duży wpływ na szczęście zespołu i dokładnie z powodów, które wskazujesz; pomagając utrzymać ich produktywność - i dobre dla Ciebie, jeśli myślisz tak jak Ty. Jest wielu menedżerów, którzy nie dają szczura tyłkowi.

Poleciłbym kilka innych postów tutaj w Programmers. Chociaż są bardziej nastawieni na kierowanie zespołem niż na oficjalną rolę kierowniczą, mogą pomóc:

Przejście do Team Leadera

Jak odnieść sukces jako główny programista?

Jak zdobyć szacunek członków zespołu jako lidera zespołu?

Myślę, że jest to równowaga między tymi cechami:

• Umiejętności techniczne : Nie chcesz, aby ktoś prowadził, który nie byłby w stanie ocenić jakości pracy, którą kieruje.
• Samodzielny : potrafi definiować cele i nie reagować.
• Wie, jak wykorzystać konflikt : Konflikt wywołuje rozmowy
• Auto-dydaktyka : Nie jest ważne, że on / ona wie wszystko, ale umie się uczyć.
• Dobre podejście i energia : chcesz kogoś, kto motywuje i ułatwia wszystkim pracę, a nie divę, która szczeka na rozkazy.
• Doświadczenie z porażką : być może najważniejszy. Widziałem bardzo młodych liderów, którzy mogą nie mieć problemu ze wszystkimi poprzednimi, ale przy pierwszych oznakach porażki zamrażają lub unikają odpowiedzialności. Starszeństwo nie ma nic wspólnego z wiekiem, ale właściwa ilość odpowiedniego doświadczenia, a porażka jest zdecydowanie czymś do rozważenia.

OTOH, wywiad jest ważną częścią pozyskania właściwej osoby, polecam zadać następujące pytania podczas wywiadu:

• „Powiedz mi projekt, w którym doświadczyłeś porażki, jak sobie poradziłeś i czego się nauczyłeś”
• „Opowiedz mi, jak kiedyś złamałeś zasady, aby załatwić sprawę”
• Zastosuj test Fizz Buzz , z dowolnym nieznacznym zwrotem akcji.

Test FizzBuzz jest absolutnie koniecznością, ponieważ mając rację lub nie, nie jest tak ważny jak:

• Czas potrzebny na odpowiedź : średnio 15 minut, granica min 30 minut,> 30 min NIE OK
• Jeśli on / ona jest w stanie debugować swój własny kod : kiedyś miałem faceta z 15-letnim doświadczeniem ubiegającym się o wyższe stanowisko ... zajęło mu 40 minut, aby wykonać test ... w pseudokodzie ... dostał to źle i nie mogłem dowiedzieć się, dlaczego. Miałem inny przypadek, w którym inny facet spędził około 5 minut usprawiedliwiając się i nie mógł zaakceptować, że się mylił.