Lubię i głosowałem za odpowiedzią Mcottle'a, ale chcę przedstawić inne dynamiki i argumenty, których inne odpowiedzi jeszcze nie poruszyły.
Po pierwsze, w odpowiedzi mcottle ukryty jest fakt, że poniżej pewnego poziomu umiejętności niektóre problemy są po prostu niemożliwe. Niestety, sposób, w jaki się o tym dowiadujesz, polega na tym, że twój zespół próbuje i kończy się niepowodzeniem, co jest bardzo ważnekosztowny. Po porażce można wyciągnąć z tego dwie lekcje. Jedną z opcji jest to, że dowiadujesz się, że potrzebujesz bardziej kompetentnych programistów, więc zatrudniasz ich i realizujesz projekt znacznie przekraczając budżet i przekraczając harmonogram, ale przynajmniej jesteś przygotowany w przyszłości. Inną opcją jest to, że taki projekt jest „zbyt trudny” dla twojego zespołu i nie należy próbować takich rzeczy w przyszłości, tj. Rezygnujesz z projektu i skutecznie podobnych. Oczywiście rzadko będzie to wyrażone jako „jesteśmy zbyt głupi, aby to zrobić”, ale zamiast tego zostanie zracjonalizowane, ponieważ „nasze systemy są bardzo złożone” lub „mamy dużo starszego kodu” lub niektórych innych. Ten ostatni pogląd może znacznie wypaczyć perspektywę firmy na to, co jest możliwe i jak długi / drogi powinien być rozwój. „
Jedno pytanie brzmi: jaki dokładnie jest plan twojej firmy? Ok, wynajmą tanie, młodszych programistów. Minęły trzy lata, a teraz co? Co robią z programistami, którzy byli z nimi przez te trzy lata? Czy po prostu nigdy go nie podnieśli? Dostępne są tutaj następujące opcje:
- Podnoszą stawki w sposób konkurencyjny, aby zatrzymać pracowników. W takim przypadku dlaczego mieliby teraz problem z płaceniem stawek dla starszych programistów? Wrócę do tego.
- Mają stagnację, co oznacza, że ostatecznie „sprowadzą się” do pracowników, którym brakuje popędu i / lub umiejętności.
- Bardziej aktywnie usuwają więcej starszych pracowników.
Drugie dwa przypadki wiążą się z dużą rotacją pracowników, co oznacza utratę wiedzy firmy i ciągłe wynagradzanie pracowników. W drugim przypadku wybierasz złych programistów, więc koszty będą rosły w postaci rosnących harmonogramów. Sposób, w jaki to się potoczy, polega na tym, że wszystko idzie dobrze w projekcie X, aż nagle Jim odchodzi, który był jednym z lepszych programistów, ponieważ nie dostał podwyżki od dwóch lat, teraz projekt „zrozumiale” potrwa znacznie dłużej, ponieważ musisz zatrudnić i przeszkolić nowych młodszych programistów, którzy (prawdopodobnie) nie będą tak dobrzy jak Jim. W ten sposób rekalibrujesz oczekiwania.
Nawet w przypadku zapewniania podwyżek konkurencyjnych, jeśli wszystko, co masz, to młodsi programiści, gdzie i jak mają się uczyć? Zasadniczo masz nadzieję, że jeden z nich samodzielnie nauczy się dobrych praktyk, pomimo swojego środowiska pracy, i ostatecznie będzie mentorem dla innych (zamiast wychodzić na zielone pastwiska). Bardziej sensowne byłoby „zalanie pompy” niektórymi dobrymi programistami. Bardziej prawdopodobne jest, że rozwiniesz kulturę początkujących ekspertów . W efekcie płacisz wyższe stawki programistom osobom, które są tylko nieznacznie lepsze od młodszych programistów i są toksyczne kulturowo.
Jedną z korzyści, szczególnie bardzo dobrych programistów, której nie dziwi nikt inny nie wspomniał, jest to, że mogą one z łatwością stać się czynnikiem multiplikatywnym . Może się zdarzyć, że młodszy programista i starszy programista poświęcą tyle samo czasu na przygotowanie stołu. Dobry programista tego jednak nie zrobi. Zrobią generator tabel, który skróci czas, aby każdy mógł zrobić tabelę. Alternatywnie / dodatkowo podniosą pułap tego, co jest możliwe dla wszystkich . Na przykład programiści, którzy wdrożyli platformę MapReduce Google, byli prawdopodobnie wyjątkowo wykwalifikowani, ale nawet jeśli użytkownicyMapReduce nie są w stanie samodzielnie stworzyć masowo rozproszonej wersji swojego algorytmu, teraz z łatwością mogą to zrobić dzięki MapReduce. Często ta dynamika jest mniej rażąca. Na przykład lepsza kontrola źródła, testowanie i praktyki wdrażania sprawiają, że wszyscy są lepsi, ale odnalezienie konkretnej osoby może być trudniejsze.
Aby trochę się kłócić po drugiej stronie, być może wyższe raty mają rację. Być może bardziej doświadczeni programiści nie są potrzebni. Jeśli tak jest, wydaje się, że rozwój nie jest znaczącą częścią firmy. W takim przypadku po prostu całkowicie wyeliminowałbym programistów i korzystałbym z gotowego oprogramowania lub wynajmowałem kontrahentów na żądanie. Warto zastanowić się, dlaczego nie korzystają tylko z kontrahentów, a nie z wewnętrznego zespołu. Jeśli i tak będziesz mieć dużo pracowników, to zwiększanie liczby kontrahentów nie powinno stanowić problemu.