Jak przekonać drogich programistów?

W naszej firmie musimy robić wiele pozornie nieskomplikowanych rzeczy, takich jak tworzenie mobilnego interfejsu użytkownika.

Powiedzmy, że doświadczeni programiści kosztują nas 4x tyle, co początkujący.

Oba są w zasadzie w stanie wykonać pozornie proste rzeczy w tym samym czasie.

Różnica polega na tym, że doświadczeni programiści produkują mniej błędów, a ich kod jest bardziej stabilny itp. Początkujący programiści marnują dużo czasu na innych (PM, klienci itp.). Ale są znacznie tańsze.

Argument przeciwny polega na tym, że przygotowanie tabeli w HTML zajmuje doświadczonym i początkującym tyle samo czasu. Dlatego luksusem jest zatrudnianie doświadczonych programistów, co mogą osiągnąć również początkujący programiści.

Czy powinniśmy inwestować w coraz więcej lepszych programistów, czy więcej i lepiej PM, biorąc pod uwagę, że różnica między doświadczonym i nowym programistą w naszej dziedzinie może wynosić 4x.

Mam doświadczenie z pierwszej ręki obu teorii wypróbowanych w prawdziwym świecie - w rzeczywistości w tym samym projekcie.

Przed moim przyjazdem podjęto decyzję o zatrudnieniu droższych licencjatów i bardzo tanich programistów - chodziło o to, aby specyfikacje dobrej jakości były niewolniczo przestrzegane przez bardzo młodszych programistów.

Po ponad 6 miesiącach kręcenia się wokół głównego projektu objąłem stanowisko kierownika ds. Rozwoju. Gdy naprawiłem kilka czynników higieny, problem z jakością kodu pozostał. Miałem trochę wolnego budżetu i zatrudniłem bardzo doświadczonego programistę (cóż, bardziej architekta rozwiązań) z nieszablonowymi umiejętnościami komunikacyjnymi i wcześniejszym życiem jako trener w C # (języku, w którym napisano projekt). Chodziło o to, aby poprawić jakość innych programistów, zapewniając mentoring i skutecznie bezpłatne szkolenie.

Po miesiącu lub dwóch stało się boleśnie oczywiste, że nawet to nie zadziała, więc pierwotny zespół został usunięty z projektu i dodano jeszcze kilku programistów z najwyższej półki. Dostarczyli projekt, którego pierwotny zespół kompletnie nie dostarczył przez ponad 8 miesięcy prób w 3 jednomiesięcznych sprintach, zaczynając od zera, ponieważ oryginalny kod był nie do naprawienia.

Jeśli twoje wymagania są bardzo podstawowe, możesz uciec od korzystania z bardzo młodszego programisty, ale prawdopodobieństwo jest, że w dłuższej perspektywie będą kosztować znacznie więcej. Czasami „proste” wymagania zmieniają się w wielką złożoność.

Gdybym nie dokonał trudnego wyboru zmiany kierunku, prawdopodobnie nadal by nad tym pracowali :) - Co ważniejsze, w tym przykładzie brak komunikacji i kompetencji ze strony oryginalnego zespołu oznaczał, że nie będą zgłaszać problemów z specyfikacji, ale po prostu spróbują zrobić wszystko, o co ich poproszono, czy ma to sens architektoniczny, czy nie. Bardziej doświadczony i pewny siebie programista zadał pytania i zapoznał się z podstawowymi wymaganiami i dlatego po raz pierwszy opracował właściwe rozwiązanie.

Och, jeszcze jedna rzecz. Nie zakładaj, że możesz natychmiast zatrudnić świetnego programistę. Istnieje wielu ludzi z wieloletnim doświadczeniem przeciętności, która zapewni prawie tak zły wynik jak junior, ale będzie kosztować tyle samo, co supergwiazda (czasami nawet więcej). Mam bardzo dobry „współczynnik trafień”, ale to ma doświadczenie i mam dużo. To temat zupełnie innej rozmowy, która jest tutaj nie na temat ...

TL; DR Dobrzy programiści to okazja. Trudno jest je znaleźć i stworzyć wystarczająco atrakcyjne środowisko pracy, aby je zachować.

Jeśli masz obszerne statystyki wydajności, możesz zrobić uzasadnienie biznesowe z matematyki. Mogłyby one wykazać, że szybkość rozwoju zrekompensowałaby wzrost ceny, a nawet lepiej, że solidna konstrukcja mogłaby zaoszczędzić więcej na konserwacji i rozwoju kolejnych wersji. Niestety takie dane nie są dostępne tak często - szczególnie w przypadku nowszych technologii.

Kolejnym argumentem może być czas wprowadzenia na rynek. Jest to łatwiejsze do zrozumienia dla wyższej kadry zarządzającej. Jednak jeśli czas nie jest tak naprawdę krytyczny, to nie pomoże.

W ostateczności znajdź zdjęcie Red Adaira , słynnego strażaka, który został wezwany w poważnej katastrofie po kilku nieudanych próbach mniej doświadczonych facetów. Jego słynny cytat:

Jeśli uważasz, że zatrudnienie profesjonalisty jest drogie, poczekaj, aż zatrudnisz amatora.

... zasługuje na wydrukowanie w kolorze i wyeksponowanie go na drzwiach biura, aby wszyscy zrozumieli, o co w tym chodzi ;-)

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.

To nie jest sytuacja ani.

Zwłaszcza w przypadku większego projektu dość rutynowo masz kilku stosunkowo doświadczonych ludzi na wyższych stanowiskach i kilka mniej doświadczonych osób na niższych stanowiskach. W ten sposób osoby starsze mogą nie tylko pomóc bezpośrednio w projekcie, pisząc kod i pomagając w podejmowaniu trudniejszych decyzji, ale mogą również pośrednio pomagać mentorując juniorów.

Z pewną ostrożnością może to również pomóc zapobiec szybkiemu wypaleniu się starszych inżynierów, prosząc ich o ciągłą pracę, która nie jest dla nich wyzwaniem ani zainteresowaniem. Przynajmniej z mojego doświadczenia, nawet trochę czasu mentoring dla entuzjastycznych ludzi na poziomie młodszym (lub nawet na poziomie wewnętrznym) może sprawić, że sprint będzie o wiele ciekawszy.

Szczerze mówiąc, powinienem dodać, że tego rodzaju stanowisko prawdopodobnie nie będzie pasować do wszystkich starszych inżynierów. Wymaga to znacznie większego nacisku na architekturę i projekt, komunikację, dokumentację itd. Szczególnie wcześnie często wymaga to dużej dyscypliny - dla kogoś, kto zajął się pisaniem kodu, kusi go, aby po prostu wskoczyć do pisania kodu, zamiast uczyć młodszego inżyniera, jak to robić. Często kuszące jest też całkowite przepisanie od podstaw, gdy kod nie jest tak, jak osobiście wolisz - nawet jeśli jest to całkowicie odpowiednie do zadania.

Jeśli jednak naprawdę nie może przekonać zarządzania iść z mieszaniną poziomach doświadczenia, nie ma w zasadzie żadnych wątpliwości w ogóle, że mają iść do bardziej doświadczonych. Jeśli zostawisz projekt w całości dla młodszego personelu, są całkiem spore szanse, że po prostu nigdy nie dostaniesz użytecznego produktu. Co gorsza, nie zdadzą sobie sprawy, że to, co robią, nie zapewnia żadnego rzeczywistego postępu w kierunku użytecznego produktu, więc będą kontynuować pracę w wybranym kierunku długo po tym, jak bardziej doświadczona osoba zorientuje się, że dokonała fundamentalny błąd na wczesnym etapie i trzeba wykonać kopię zapasową, przegrupować się, obrać orientację i rozpocząć nowy kierunek, aby mieć nadzieję na dotarcie do sensownego miejsca docelowego.

Każdy projekt w realnym świecie jest napędzany popytem klientów, a zatem obejmuje zadania o niskiej złożoności (np. Budowanie formularzy CRUD) i wysokiej złożoności (np. Budowanie systemu powiadomień sterowanego zdarzeniami). Jedynym sposobem na wykonywanie zadań o niskim stopniu złożoności jest powtarzanie klientom słowa „nie”, czego nie chciałby żaden dział sprzedaży, o którym słyszałem.

Jeśli masz tylko programistów na poziomie młodszym, oznacza to, że będziesz w stanie wykonywać zadania o niskiej złożoności, a zatem będziesz w stanie zbudować produkt o niskiej wartości i trudniej walczyć na rynku, aby wyróżnić swoje produkty. Jeśli chcesz różnicować, musisz zbudować funkcjonalność o wysokiej wartości, co nieuchronnie przekłada się na zadania o dużej złożoności. W końcu, gdyby było to łatwe, nie byłoby cenne. Oznacza to, że potrzebujesz ludzi do wykonywania zadań o wysokim stopniu złożoności i potrzebujesz programistów wyższego szczebla.

Jeśli masz tylko programistów wyższego szczebla, zmarnujesz ich umiejętności na pracę o niskiej wartości, będziesz miał problemy z zatrzymaniem ich podczas zmuszania ich do wykonania wspomnianej pracy, a także ryzykujesz, że odejdą do architektury astronomicznej, próbując wykonać proste zadania więcej ciekawe do pracy. Oznacza to, że musisz mieć także niedoświadczonych programistów, którzy podejmą się tych zadań.

Zdrowy zespół pracujący nad produktami zorientowanymi na klienta to zwykle mieszanka. Stosunek między młodszymi i starszymi programistami zależy od stosunku między zadaniami o niskiej złożoności i wysokim stopniu złożoności, a to zależy od strategii biznesowej. Jeśli aktywnie poszukujesz dużych ilości łatwych do zrozumienia, łatwych do wycinania plików cookie, nie będziesz mieć wielu zadań o dużej złożoności i prawdopodobnie zatrudnisz głównie programistów młodszego poziomu. Jeśli aktywnie dążysz do rozróżnienia niedocenianych nisz i ukierunkowania ich na wyższe marże zysku, będziesz mieć wiele zadań o dużej złożoności i poszukasz głównie programistów wyższego poziomu.

W mojej odpowiedzi twierdzę, że starsi programiści niekoniecznie kodują szybciej niż młodsi programiści. W rzeczywistości najszybsi programiści to przeciętnie faceci, którzy właśnie opuścili uniwersytet.

Znajomość domen to klucz do starszego programisty. Dobry starszy programista powinien mieć dużą wiedzę w tej dziedzinie, czego młodszy programista może nie mieć. Doświadczeni programiści rozumieją problem, co należy rozwiązać i jak go rozwiązać. Mogą rozwiązać bardziej skomplikowany problem dla firmy niż większość młodszych programistów.

Programowanie jest stosunkowo tanim zestawem umiejętności, liczy się wiedza ekspercka.

Nie próbuj „uzasadniać sprawy” Rynek ustala cenę dla pracowników. Jeśli rynek jest skłonny zapłacić 4x więcej za doświadczenie, to dlatego, że firmy jako całość doszły do ​​wniosku, że istnieje wzrost wydajności 4x.

Teraz oczywiście rynek może się mylić, może jego 3.5 lub 5x, ale jeśli nie jesteś agencją cyfrową, konkurowanie z rynkiem lub coś takiego niuanse nie są ważne.

Twoim prawdziwym problemem jest to, czy jesteś wystarczająco dobry w przeprowadzaniu wywiadów, aby móc odróżnić dobrego doświadczonego programistę od starego, który go oszukuje.

Twoje drugie pytanie dotyczące PM a budżetu programisty. Powiedziałbym, że programista może obejść się bez PM, ale PM nie może obejść się bez programisty. Najpierw posortuj silnik programistyczny, a następnie poproś o PM, aby zdjął administratora z ich rąk.

Nie znajdziesz nikogo we własnym kraju za ćwierć kosztu naprawdę dobrego programisty. Możesz znaleźć kogoś za połowę pensji, a to będzie absolutnie początkujący. Dla kogoś za jedną czwartą pensji musisz wyjechać za granicę, a wtedy będziesz miał problemy z komunikacją, osoby, które na ślepo przestrzegają specyfikacji, i wszelkiego rodzaju problemy.

Państwo potrzebują jednego dobrego programistę. Jeśli dodasz więcej młodszych programistów, potrzebujesz jednego dobrego programisty z silnymi umiejętnościami komunikacyjnymi, który będzie chętny i zdolny mieć oko na młodszych. Bez jednego dobrego programisty jesteś zgubiony. Możesz mieć szczęście, znajdując niezwykłego utalentowanego początkującego, ale kiedy on lub ona odkryje, że są dobrzy, będą chcieli wyższego wynagrodzenia.

Jeśli nie masz jednego dobrego programisty, nie ma nikogo, kto widziałby większy obraz, i nikogo, kto mógłby rozwiązać problemy, których nie można rozwiązać za pomocą przepływu stosu. Będziesz miał kod, który cuchnie i jest niemożliwy do utrzymania, ponieważ młodsi programiści nie wiedzą, jak utworzyć kod, który można utrzymać. Mogą się tego nauczyć, ale nie obejdą się bez dobrego programisty w zespole.

Jest kilka przeszkód, które Twoja firma musiałaby pokonać, zanim zdecydujesz, czy zatrudnienie lepszych programistów byłoby opłacalne. Przepraszam, jeśli przyjmuję negatywne założenia dotyczące miejsca pracy, ale nie jestem przekonany, czy wiedzą, co robią.

1. Czy dokładnie ocenili, jak złożone jest oprogramowanie, które budujesz? Wygląda na to, że nie uważają, że to, co robisz, jest bardzo trudne, więc po co zatrudniać lepszych ludzi? Czy popełniłeś przypadek, w którym popełniane są błędy i jak lepsze rozwiązania i wydajność przyniosłyby pieniądze? Oszczędność czasu jest świetna, ale wiele firm wolałoby marnować cały tydzień na programistę niż dawać pieniądze na zakup podkładki pod mysz.
2. Czy Twoja firma jest atrakcyjna dla dobrych programistów? Czy potrafią je zidentyfikować? Nic gorszego niż zatrudnienie starszego dewelopera, zapłać im więcej pieniędzy, a oni ściągną cały zespół z powodu braku umiejętności i / lub przywództwa.
3. Czy Twoja firma może korzystać z dobrego programisty? Jeśli wszystko, co zamierzają zrobić, to rzucić na nich tandetne specyfikacje i po prostu powiedzieć im, żeby po prostu je zbudowali, o co chodzi? Czy dadzą im jakąkolwiek swobodę robienia rzeczy po swojemu? W końcu dobry programista z definicji wie, jak lepiej wykorzystać swój czas. Wpływają na otoczenie i powodują poprawę w innych programistach. Wprowadzają lepsze projekty i architektury, na których opiera się reszta, dzięki czemu produkt jest o wiele lepszy.

Przykro mi, ale wydaje mi się, że Twoja firma nie wiedziałaby, co zrobić z dobrym programistą, więc możesz przekonać ich, aby najpierw zatrudniali lepszych menedżerów i rozwiązali te wewnętrzne problemy.