Jak zbudować zespół programistów

Jestem menedżerem zespołu 11 programistów, którzy opiekują się stronami internetowymi / aplikacjami internetowymi mojej firmy, prowadząc do 4 jednoczesnych projektów oraz codzienne wsparcie w dowolnym momencie. Wśród 11 programistów jest połączenie umiejętności technicznych, stanowisk i doświadczenia, chociaż struktura zespołu jest płaska, a wszyscy 11 programistów podlega mi bezpośrednio.

Cały zespół mający jednego menedżera zaczyna słabo skalować. Zaczynam być zbyt cienki, więc chcę zmniejszyć liczbę bezpośrednich zgłoszeń. Wszystkie sposoby, w jakie mogę to zrobić, mają znaczące wady:

• Poproś młodszych programistów o raport dla starszych. To skraca czas poświęcony na rozwój przez najlepszych techników.
• Podziel zespół według oprogramowania, np. Programiści 1-6 pracują w intranecie, a 7-11 pracują w zewnętrznych witrynach, przy czym każda sekcja ma nowego kierownika zespołu (być może nowy opis stanowiska z większą odpowiedzialnością za zarządzanie / mentoring / coaching niż w przypadku obecnych starszych programistów ). Dodaje to sztuczne silosy i może utrudnić pozyskanie „programisty intranetowego” do pracy na zewnętrznej stronie internetowej, jeśli tego chcę.
• Utrzymaj strukturę na płasko i dodaj wsparcie menedżerskie w kształcie kierowników projektów / administratorów zespołów, aby odciążyć się od presji. To nie rozwiązuje problemu, ponieważ zespół nie może dalej rosnąć w ten sposób.

Czy istnieje standardowy sposób rozwiązania tego problemu, którego mi brakuje?

Jeśli nie, to jak inni z was rozwiązali ten problem?

Kilka szybkich myśli:

• Podgrupy są dobrym pomysłem: 11 bezpośrednich raportów bez żadnej struktury jest zbyt duże dla sprawnego zespołu (nie będziesz mieć wystarczająco dużo czasu na bezpośredni coaching, a spotkania zespołu z tak wieloma osobami będą zwykle nieproduktywne).
• Zastanów się nad oddzieleniem operacji od programowania - jest to nieco inny zestaw umiejętności, a ciągłe przerywanie ich problemami operacyjnymi może poważnie zaszkodzić wydajności rozwoju projektów.
• W wyniku dwóch pierwszych punktów uważam, że powinieneś mieć chyba 3 podgrupy - intranet, witryny zewnętrzne i operacje. Operatorzy zajmą się wszystkimi codziennymi problemami / poprawkami konserwacyjnymi itp., Podczas gdy dwa zespoły programistów koncentrują się na dostarczaniu nowych projektów / wartości dla biznesu.
• Regularnie przełączaj ludzi między zespołami. Może to być okazjonalne (np. Zmuszanie ludzi do przeglądu kodu w innym podzespole), dla projektu lub na stałe. Ale upewnij się, że rozumie się, że role zespołów będą się zmieniać, ilekroć zajdzie taka potrzeba biznesowa - nikt nie będzie „posiadał” określonej roli na zawsze.
• Nie dodawaj więcej menedżerów / administratorów - jest to pewny sposób na zmniejszenie ogólnej efektywności / produktywności twoich zespołów. Niech najbardziej doświadczona osoba w każdym podgrupie pełni rolę lidera / trenera zespołu. Upewnij się, że widzą w tym swoją rolę coachingu i sukcesu całego zespołu, i upewnij się, że są odpowiednio przygotowani, aby zachowywać się w ten sposób, a nie działać jako „menedżer zadań”.
• Twoja rola powinna koncentrować się na zewnętrznym zarządzaniu zainteresowanymi stronami, ustalaniu priorytetów w zakresie zasobów / zadań w grupie i działaniu jako „główny trener”. Będziesz musiał poradzić sobie z okazjonalnie eskalowanym problemem od podgrup, ale ogólnie powinieneś zachęcać ich do samodzielnego rozwiązywania problemów bez zgłaszania się do ciebie.
• Jeśli sam jesteś wysoce techniczny, możesz również odegrać rolę architekta / projektanta. Jeśli nie, znajdź kogoś, kto może, w zespole lub gdzie indziej .....

Ponadto zawsze warto iść i (ponownie) przeczytać Manifest Agile , a zwłaszcza dwanaście zasad .

Ta struktura będzie głównie depend on project specifications

Idealnie byłoby, gdyby każdy starszy programista w zespole składał się z 3 juniorów. W związku z tym na ścieżkę nauczania jest 2-3 starszych programistów.

W związku z tym tylko kierownicy ds. Technicznych będą informować PM o statusie postępu projektu. Opisana struktura nadal zakłada, że ​​w przypadku problemów nietechnicznych (urlop, przerwa, konflikty itp.) Każdy może mieć dostęp do PM.

Jeden ze względnie odnoszących sukcesy zespołów programistów , w których uczestniczyłem, opracował coś takiego:

Menedżer ds. Rozwoju oprogramowania / Starszy programista / Mentor, do którego wszyscy inni zgłaszali się bezpośrednio.

• Kierownik projektu, który zachowywał harmonogramy, ułatwiał negocjacje wymagań i akceptacji oraz dokonywał komunikacji. Każda linia przerywana również zgłosiła się tej osobie. Osoba zajmująca się dokumentacją (która czasami była także premierem, ale tylko wtedy, gdy ekspertyza była dozwolona).
• Mieszanka 1-3 programistów lub starszych programistów, w zależności od potrzeb projektu.
• Młodszy programista, jeśli jest dostępny.
• Ktoś przypisany z puli kontroli jakości.
• Osoba związana z infrastrukturą (rolę tę często pełni menedżer, ponieważ ma także solidne kompetencje SA).

Działało idealnie dobrze i podobała mi się ta organizacja. Z drugiej strony byłem kierownikiem ds. Rozwoju oprogramowania, a struktura organizacyjna zespołu ewoluowała.

Rozważ zastosowanie schematu organizacji funkcjonalnej personelu . To przemawia za drugą opcją podziału zespołu według oprogramowania.

Aby zacytować artykuł w swoim kontekście:

Największą siłą organizacji funkcjonalnej jest to, że łączy struktury społeczne z dostarczaniem wartości biznesowej. Moim zdaniem projekty oprogramowania odnoszą sukcesy, ponieważ poprawiają efektywność wspieranej działalności - przynosząc wartość biznesową. Organizując swoje zespoły w ten sam sposób, masz zespół nastawiony na zadowolenie ich użytkowników biznesowych.

Rzeczywista struktura zarządzania / HR jest poza tym nieistotna.

Czy istnieje standardowy sposób rozwiązania tego problemu, którego mi brakuje?

Nie całkiem. Będzie to zależeć od twojego zespołu, ciebie, tego, co musisz zrobić i jakie zasoby firma ci udostępni.

Osobiście najlepszym rodzajem zmiany jest rozdzielenie zarządzania technicznego od zarządzania administracyjnego. Rzadko zdarza się, że ludzie są dobrzy w obu przypadkach i rzadko mają skłonność do interakcji.

Jedna osoba zajmuje się aspektami technicznymi. Co trzeba zrobić, kto to zrobi, jak sprawy muszą się ułożyć. Drugi obsługuje aspekty administracyjne. Recenzje, spotkania budżetowe, planowanie produktu itp. Następnie współpracują, aby przekazywać spostrzeżenia z jednej strony na drugą i zapewnić jednolity front.

To, jak to jest podzielone, może przebiegać na kilka różnych sposobów. Najczęstszym jest kierowanie inżynierem po stronie administracyjnej, a po stronie technicznej. Są rówieśnikami i zgłaszają się do dyrektora / wiceprezesa.

Kolejną pracą, jaką widziałem, jest kierowanie inżynierem, a następnie kierownictwo zespołu jako osoba techniczna. Jest to trudniejsze i wymaga od właściwych ludzi działania (głównie) rówieśników, nawet jeśli raportowanie jest hierarchiczne.

W twoim konkretnym scenariuszu zaleciłbym posiadanie 2-3 zespołów i poprowadzenie technicznych aspektów technicznych, a ty skupisz się na administracji. Tak, skraca to czas od potencjalnych klientów, którzy faktycznie piszą kod, ale powinni (jeśli wykonują dobrą robotę) zrekompensować ten czas, czyniąc młodszych programistów bardziej wydajnymi / produktywnymi. Daje im to większą motywację i poczucie spełnienia przy samej promocji. I, w praktyce, łatwiej jest sprzedać kierownictwu niż otwieranie nowej pozycji.