Jakie praktyki zarządzania / rozwoju zmienisz, gdy zespół 1-3 programistów wzrośnie do 10+?


14

Mój zespół zbudował stronę internetową dla klienta kilka lat temu. Witryna rośnie bardzo szybko, a nasz klient prosi nas o powiększenie zespołu, aby zaspokoić potrzeby związane z konserwacją i funkcjami.

Zaczęliśmy od niewielkiej liczby programistów, a nasz zespół powiększył się - teraz mamy podwójne cyfry.

Jakie zmiany w zarządzaniu / programowaniu są najbardziej korzystne, gdy zespół rośnie z małego zespołu „garażowego” do ponad 10 programistów?


1
Możesz podzielić część pytania dotyczącą zarządzania i zadać ją na pm.stackexchange.com
blueberryfields

2
Jakie praktyki zarządzania stosował wcześniej zespół?
chrisaycock

Początkowo mieliśmy 2 programistów wyższego szczebla, więc zwykle rozmawiali. Gdy zespół i projekt zaczynały się rozwijać, pojawili się młodsi programiści, dlatego wprowadziliśmy WIKI, system śledzenia błędów, kontrolę źródła itp. Teraz wydaje się, że zespół jest zbyt duży, aby zarządzać nim jeden starszy programista, więc może powinniśmy zacząć dzieląc go na mniejsze zespoły.
Mag20

Kup więcej kawy.
haylem

1
Cóż za wspaniały „problem”. Gratulacje dla rosnącej drużyny!
Agile Scout

Odpowiedzi:


8

Powiedziałbym, że są w przybliżeniu dwie główne drogi:

  • Podziel zespół na dwie lub trzy grupy, z których każda odpowiada za określoną dziedzinę / aspekt. ma to tę zaletę, że nadal możesz pracować tak, jak jesteś przyzwyczajony, w mniejszych grupach.
  • „Zespół chirurgiczny”, o którym można przeczytać w The Mythical-Man-Month . również ten link ma wspaniały rysunek na ten temat.

Powodzenia!


4

W ciągu ostatnich 7 lat wzrosła z około 10 do prawie 200. Pierwszą rzeczą, którą należy zmienić, jest to, że będziesz potrzebować lepszej dokumentacji i bardziej standardowych procesów. Wymagania mogą być również bardziej formalne.

W miarę rozwoju powinieneś również rozważyć zatrudnienie specjalistów. Jeśli masz zaplecze bazy danych, powinieneś mieć co najmniej jednego specjalistę ds. Baz danych. Prawdopodobnie powinieneś wydać pieniądze na testera.

Będziesz mieć więcej projektów i większą potrzebę zarządzania nimi, więc jeśli nie używasz teraz jednego, potrzebujesz systemu zarządzania projektami i narzędzia do śledzenia błędów. Musisz utworzyć porcję wdrożenia i ograniczyć prawo do produkcji tylko do tych osób, które będą przeprowadzać wdrożenia, bez wprowadzania dalszych zmian bezpośrednio na prod. Twoi programiści będą musieli ograniczać się do wybranych praw tylko do prod.

Ponieważ masz większe zespoły, będziesz mieć więcej problemów z ludźmi i będzie bardziej prawdopodobne, że zatrudnisz mniej wykwalifikowanych pracowników (stosunkowo łatwo jest zdobyć trzech dobrych programistów, gdy to wszystko, co masz, znacznie trudniej zatrudnić 30 na raz). Nawet jeśli starasz się pozyskać najlepszych ludzi, im więcej zatrudnisz, tym bardziej prawdopodobne jest, że dostaniesz niewypał, więc bądź przygotowany na to, że ludzie też odejdą.

Koordynacja między ludźmi jest kluczowa. Dwa zespoły dokonujące wzajemnie wykluczających się zmian produktu to zła rzecz.

Mając tylko dwóch lub trzech programistów, nie możesz sobie pozwolić na młodszych ludzi - wszyscy muszą pracować na wyższym poziomie. Mając wielu programistów, nie możesz sobie pozwolić na brak młodszych ludzi. Zatrudnij kilku juniorów i trenuj ich tak, jak chcesz. Zwykle lepiej jest pracować w miejscu, w którym ścieżka kariery nigdy nie jest na tym samym poziomie.

W miarę rozwoju zespołu wielu obecnych programistów zostanie nowymi pracownikami zarządzającymi. Niektórzy będą tego nienawidzić, upewnij się, że mają oni możliwość awansu do starszego programisty, a nie kierownictwa. Nie trać całej wiedzy technicznej na zarządzanie. Nagradzaj tych, którzy nie zajmują się zarządzaniem, ponieważ potrzebujesz ich szczegółowej wiedzy na temat obecnego systemu, aby przyspieszyć rozwój nowych ludzi.


4

Jeśli projekt jest wystarczająco duży dla ponad 10 programistów, powinno być łatwo podzielić go na mniejsze obszary. Podziel zespół na mniejsze zespoły po 3-5 osób i daj im autonomię na danym obszarze. Interfejsy API będą musiały zostać opracowane między zespołami. Zalecam, aby każdy zespół ustalił swoje wymagania, a jedna lub dwie osoby z każdego zaangażowanego zespołu spotkają się, aby omówić API. Łatwiej jest prowadzić dyskusję i podejmować decyzje, gdy zaangażowanych jest mniej osób.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.