Jak należy rozdzielać umiejętności między zespołami?

Po przeczytaniu tego, Zauważyłem, że wydaje się, że istnieje duża różnica zdań co do struktury zwinnych zespołów w grupie programistów o różnych umiejętnościach (czyli prawie wszystkie zespoły). Czy wszyscy najlepsi programiści powinni być zatrudnieni w swoich zespołach i mieć najwyższy priorytet pracy? Zapewni to prawie wykonanie najważniejszych zadań. Jednocześnie pozostawiasz zespoły „mniej niż doskonałe”, które gdzie indziej zwiększają zadłużenie techniczne, nawet jeśli dotyczą tylko zadań o niskim priorytecie. Z drugiej strony, równomiernie rozmieszczone zespoły mogą skorzystać z tego, że Twoi opóźnieni programiści będą nieco lepsi, ale mogą potencjalnie zdemotywować Twoich najmocniejszych hiterów. Ponadto, jeśli połączysz kilka dobrych wzorów z wieloma okropnymi anty-wzorami, możesz naprawdę skończyć z czymś, co równie dobrze może być zbiorem anty-wzorów.

Istnieje kilka znanych zagrożeń związanych z A-Teams, ale jeśli dynamika jest odpowiednia, to myślę, że tak, skierowałbym moich najsilniejszych ludzi na najważniejsze projekty wraz z młodszymi programistami o największym potencjale. W przypadku projektów o niższym priorytecie potrzebujesz dobrego lidera zespołu, jeśli to w ogóle możliwe, aby powstrzymać ich przed zejściem daleko od torów. Dług techniczny stanie się bez względu na wszystko. Nie wszystkie zadłużenia techniczne są równe; koszt / odpowiedzialność długu technicznego jest przede wszystkim proporcjonalna do wartości biznesowej projektu, więc podczas gdy projekty o niższym priorytecie mogą mieć więcej brodawek, ich koszty są prawdopodobnie znacznie mniejsze niż znaczące problemy w projektach o wysokim priorytecie być.

Pamiętam, kiedy byłem na uniwersytecie, jeden z naszych profesorów opowiadał nam anegdotę o strukturach zespołu (szukałem artykułu, o którym teraz mówił, ale nie mogę go znaleźć).

Zasadniczo historia wyglądała następująco:

Grupa programistów została podzielona na grupy na podstawie umiejętności, przy czym najgorsze x programistów zostało zgrupowanych razem, następne x zgrupowane razem itp., A najlepsi zgrupowani razem.

Wszystkim przydzielono to samo zadanie i ustalono ramy czasowe jego wykonania.

Pod koniec ram czasowych organizatorzy przyjrzeli się rozwiązaniom zadań i, ku ich zaskoczeniu, odkryli, że najlepiej działające rozwiązanie pochodzi od zespołu złożonego ze zwykłych ludzi. Natomiast zespół złożony z programistów A * opracował jedno z najgorszych rozwiązań, ponieważ cały czas spędzali na kłótni o to, co było najlepszym rozwiązaniem .

Jeśli potrzebujesz zespołu, który będzie się zajmował, zdobądź grupę przeciętnych facetów i dominującego faceta, który może poprowadzić, to było zakończenie badania (jeśli dobrze pamiętam), w przeciwnym razie bardziej dominujący członkowie spędzą więcej czasu na walce niż na zdobyciu rzeczy zrobione!

Zdecydowana większość niedoświadczonych programistów może nie być w stanie samodzielnie opracować solidnych, eleganckich projektów, ale może je rozpoznać i zrozumieć, gdy je zobaczy. Jeśli nie mogą, to zazwyczaj brakuje im umiejętności lub przygotowania do zatrudnienia.

Istnieje również kilku bardziej doświadczonych programistów, którzy są w stanie zrozumieć bardzo złożone projekty oprogramowania, ale brakuje im dyskrecji, aby wiedzieć, kiedy coś prostszego byłoby lepsze.

Z mojego doświadczenia wynika, że ​​zwykle masz stałe problemy z zespołami mieszanymi, jeśli zawierają nieprzygotowanych członków, niepotrzebnie złożonych członków lub jedno i drugie. W przeciwnym razie, jeśli Twój zespół ma problemy, zwykle można je rozwiązać za pomocą lepszej komunikacji lub przypisania odpowiednich ról.

Grupowanie najlepszych ludzi w jednym zespole może wyglądać jak świetne rozwiązanie krótkoterminowe, ale jest to porażka w długim okresie i wiąże się z dodatkowymi kosztami. Na przykład moja firma woli, gdy ludzie uczą się od swoich bardziej wykwalifikowanych kolegów zamiast płacić za szkolenia. Jeśli wyodrębnisz najlepszych ludzi, nie będą oni mogli przekazywać wiedzy mniej wykwalifikowanym osobom. W krótkim okresie najlepsze zespoły mogą osiągać dobre wyniki, ale z powodu braku transferu wiedzy liczba wykwalifikowanych osób nie wzrośnie. O wiele lepiej jest mieć mniej skuteczny zespół na początku i zwiększać wydajność we wszystkich zespołach, gdy ludzie stają się bardziej wykwalifikowani.

Co ponadto stanie się, jeśli wykwalifikowani ludzie zdecydują się na wyjazd? Kto podejmie ich projekty?

Inną kwestią jest to, że zespół powinien składać się z osób o różnych umiejętnościach. Zawsze będziesz mieć łatwe zadania (i nudne), które są zbyt drogie, aby mogły je wykonać najbardziej zaawansowani programiści.

Ci, którzy nie potrafią uczyć, ...

Myślę, że jest więcej czynników do rozważenia.

Największą wartość uzyskasz, dystrybuując osoby, które mogą uczyć jako prowadzący zespół. Mogą uczyć innych członków zespołu i pomagać w podnoszeniu jakości ich pracy.

Nie wszyscy starsi programiści osiągną dobre wyniki. Ta umiejętność przekazywania informacji jest umiejętnością samą w sobie. Ta umiejętność nie rozwija się dzięki doświadczeniu programistycznemu. Rozwija się poprzez nauczanie i wyjaśnianie.

Przypisanie zespołu „A” wiąże się z dwoma istotnymi problemami. Pierwsza to kompatybilność. Posiadanie zespołów, które dobrze się dogadują i dobrze ze sobą współpracują, jest o wiele ważniejsze niż ich „zdolność”. Może to być dwóch programistów „o wysokich umiejętnościach”, dwóch programistów „o niskich umiejętnościach” lub połączenie. Fakt, że mogą ze sobą dobrze współpracować, oznacza, że ​​będą bardziej produktywni.

Druga kwestia dotyczy wzrostu. Dwóch programistów o „niskich” umiejętnościach niewiele się od siebie uczy, oprócz złych nawyków. Podobnie dwóch „wysoko” wykwalifikowanych programistów nie nauczy się wiele od siebie. Jednak mieszanie „niskich” i wysokich ”poziomów umiejętności poprawi umiejętności„ niskich ”umiejętności. Poprawią także umiejętności„ wysokich ”umiejętności. W jaki sposób? Próba nauczenia przedmiotu szybko znajdzie słabe punkty w tym temat. Nie uważałem umiejętności za „opanowaną”, dopóki nie nauczysz jej kogoś innego.

Z drugiej strony monety uważam, że sensowne jest utrzymywanie zespołów, które mogą „nadążać” ze sobą. Twoi programiści typu A-Team nie chcą czekać na typy B-Team, aby wykonać swoje zadania. Twój typ B-Team może być intimowany przez przepływ pracy w stylu A-Team.