Come valgo per costosi programmatori?

Nella nostra azienda, dobbiamo fare molte cose apparentemente non complicate, come sviluppare l'interfaccia utente mobile.

Supponiamo che i programmatori esperti ci costino 4 volte tanto quanto i principianti.

Entrambi sono sostanzialmente in grado di completare le cose apparentemente semplici nello stesso lasso di tempo.

La differenza è che i programmatori esperti producono meno bug e il loro codice è più stabile ecc. I programmatori principianti perdono molto tempo di tutti gli altri (PM, clienti, ecc.). Ma sono significativamente più economici.

L'argomento contrario è che ci vuole tempo per principianti e principianti lo stesso tempo per creare una tabella in HTML. Pertanto, è un lusso assumere programmatori esperti da fare, cosa che anche i programmatori principianti possono raggiungere.

Dovremmo investire in più e migliori programmatori o più e migliori PM, dato che la differenza tra programmatore esperto e nuovo nel nostro campo può essere 4x.

Ho esperienza diretta di entrambe le teorie sperimentate nel mondo reale - nello stesso progetto in realtà.

Prima del mio arrivo, era stata presa la decisione di assumere BA più costosi e programmatori molto economici - l'idea era quella di avere specifiche di buona qualità seguite con slancio da programmatori molto più giovani.

Dopo più di 6 mesi di arretramento del progetto principale, ho assunto l'incarico di responsabile dello sviluppo. Dopo aver corretto alcuni fattori di igiene, il problema della qualità del codice è rimasto. Avevo un po 'di budget libero e ho assunto un programmatore di grande esperienza (beh, più di un Solution Architect) con abilità comunicative fuori dagli schemi e una vita precedente come trainer in C # (la lingua in cui è stato scritto il progetto). L'idea era di migliorare la qualità degli altri programmatori fornendo tutoraggio e formazione efficacemente gratuita.

Dopo un mese o due è diventato dolorosamente ovvio che anche quello non avrebbe funzionato, quindi il team originale è stato rimosso dal progetto e sono stati aggiunti un paio di programmatori di primo livello. Hanno consegnato il progetto che il team originale non era riuscito a realizzare in 8+ mesi di tentativi in ​​3 sprint di un mese a partire da zero perché il codice originale era irriducibile.

Se le tue esigenze sono molto semplici, potresti riuscire a cavartela usando un programmatore molto giovane, ma la probabilità è che a lungo andare costerà molto di più. A volte i requisiti "semplici" si evolvono in grande complessità.

Se non avessi fatto la difficile scelta di cambiare direzione, probabilmente avrebbero comunque lavorato su di esso :) - Più seriamente, in questo esempio, la mancanza di comunicazioni e competenza da parte del team originale significava che non avrebbero sollevato problemi con il specifica, ma proverebbero semplicemente a fare tutto ciò che è stato loro chiesto di fare, dal punto di vista architettonico o meno. Uno sviluppatore più esperto e fiducioso ha posto domande e approfondito i requisiti sottostanti e ha quindi finito per produrre la soluzione giusta per la prima volta.

Oh, un'altra cosa. Non dare per scontato che puoi assumere immediatamente un grande programmatore. Ci sono un sacco di gente là fuori con molti anni di esperienza di mediocrità che produrrà un esito quasi negativo come uno junior ma costerà lo stesso di una superstar (a volte anche di più). Ho un "hit rate" molto buono, ma questo viene fornito con esperienza e ne ho molti. Questo è l'argomento di una conversazione completamente diversa che è fuori tema qui ...

TL; DR I buoni programmatori sono un vero affare. Il difficile è trovarli e creare un ambiente di lavoro abbastanza attraente per mantenerli.

Se disponi di statistiche estese sulle prestazioni, puoi creare il caso aziendale con la matematica. Ciò potrebbe dimostrare che la velocità di sviluppo compenserebbe l'aumento del prezzo, o anche meglio, che un design robusto potrebbe risparmiare di più nella manutenzione e nello sviluppo delle versioni successive. Purtroppo tali dati non sono disponibili così spesso, soprattutto per le nuove tecnologie.

Un altro argomento può essere il time to market. Questo è più facilmente comprensibile da parte dell'alta direzione. Tuttavia, se il tempo non è davvero critico, questo non aiuta.

In ultima istanza, trova una foto di Red Adair , il famoso pompiere, chiamato in un grave disastro dopo diversi tentativi falliti di ragazzi meno esperti. La sua famosa citazione:

Se pensi che sia costoso assumere un professionista, aspetta di aver assunto un dilettante.

... merita di essere stampato a colori e esposto in modo evidente sulla porta del tuo ufficio, in modo che tutti capiscano di cosa si tratta ;-)

Mi piace e ho votato a favore della risposta di mcottle, ma voglio coprire alcune altre dinamiche e argomenti che le altre risposte non hanno ancora sollevato.

Primo, implicito nella risposta di mcottle è il fatto che al di sotto di un certo livello di abilità, alcuni problemi sono semplicemente impossibili. Sfortunatamente, il modo in cui lo scopri è che la tua squadra prova e fallisce, il che è moltocostoso. Dopo aver fallito, ci sono due possibili lezioni da imparare da questo. Un'opzione è che impari che hai bisogno di sviluppatori più competenti e quindi li assumi e completi il ​​progetto in modo significativo con budget eccessivo e scadenze eccessive, ma almeno sei pronto in futuro. L'altra opzione è che un progetto del genere è "troppo difficile" per il tuo team e tali cose non dovrebbero essere tentate in futuro, cioè rinunciare al progetto ed effettivamente a progetti simili. Certo, raramente sarà definito come "siamo troppo stupidi per farlo", ma invece sarà razionalizzato come "i nostri sistemi sono molto complessi" o "abbiamo un sacco di codice legacy" o alcuni altri. Quest'ultima visione può deformare in modo significativo la prospettiva di un'azienda su ciò che è possibile e su quanto dovrebbe essere lungo / costoso lo sviluppo. "

Una domanda è: qual è esattamente il piano della tua azienda? Ok, assumeranno programmatori junior a basso costo. Passano tre anni, e adesso? Cosa fanno con lo sviluppatore che è stato con loro in questi tre anni? Non gli hanno mai dato un aumento? Le opzioni qui sono le seguenti:

• Danno aumenti competitivi per trattenere i dipendenti, nel qual caso perché avrebbero problemi a pagare le tariffe degli sviluppatori senior adesso? Tornerò su questo però.
• Hanno tassi stagnanti, il che significa che alla fine si "ridurranno" ai dipendenti che mancano di unità e / o abilità.
• Rimuovono più attivamente i dipendenti più anziani.

I secondi due casi implicano un sacco di turn-over dei dipendenti, il che significa perdita di conoscenza dell'azienda e pagamento continuo per aumentare i dipendenti. Nel secondo caso, si sta essenzialmente selezionando per gli sviluppatori cattivi e quindi i costi aumenteranno sotto forma di pianificazioni crescenti. Il modo in cui andrà a finire è che tutto andrà bene nel progetto X fino a quando all'improvviso Jim non se ne andrà, che è stato uno dei migliori sviluppatori, perché non ha ottenuto un aumento da due anni, ora il progetto "comprensibilmente" richiederà molto più tempo in quanto devi assumere e formare nuovi sviluppatori junior che (presumibilmente) non saranno bravi come Jim. Ecco come ricalibrare le aspettative.

Anche nel caso in cui vengano forniti aumenti competitivi, se tutto ciò che hai sono sviluppatori junior dove e come dovrebbero imparare? In pratica, speri che uno di loro apprenda da solo le buone pratiche nonostante il proprio ambiente di lavoro, e alla fine guidi altri (invece di partire per pascoli più verdi). Avrebbe molto più senso "innescare la pompa" con alcuni buoni sviluppatori. Più probabilmente svilupperai una cultura di esperti principianti . Il risultato è che finirai per pagare le tariffe degli sviluppatori senior a persone che sono solo leggermente migliori degli sviluppatori junior e sono culturalmente tossiche.

Un vantaggio, in particolare, di sviluppatori molto bravi, che sono sorpreso che nessun altro abbia menzionato è che possono facilmente essere un fattore moltiplicativo . Può darsi che uno sviluppatore junior e uno sviluppatore senior impieghino lo stesso tempo per preparare un tavolo. Tuttavia, un buon sviluppatore non lo farà. Faranno un generatore di tabelle che riduce il tempo per tutti di creare una tabella. In alternativa / in aggiunta, aumenteranno il limite di ciò che è possibile per tutti . Ad esempio, gli sviluppatori che hanno implementato il framework MapReduce di Google erano probabilmente estremamente qualificati, ma anche se gli utentidi MapReduce non sono assolutamente in grado di creare autonomamente una versione distribuita in maniera massiccia del loro algoritmo, ora possono farlo facilmente con MapReduce. Spesso questa dinamica è meno evidente. Ad esempio, un migliore controllo del codice sorgente, test e pratiche di implementazione rendono tutti migliori, ma può essere più difficile rintracciare una persona specifica.

Per discutere un po 'dall'altra parte, forse i piani alti hanno ragione. Forse non sono necessari sviluppatori più esperti. In tal caso, tuttavia, sembrerebbe che lo sviluppo non sia una parte significativa dell'azienda. In tal caso, eliminerei completamente gli sviluppatori e utilizzerei software standard o assumevo appaltatori su richiesta. Potrebbe valere la pena esplorare perché non usano solo appaltatori piuttosto che un team interno. Se hai un sacco di dipendenti che cambiano comunque, allora gli appaltatori in aumento non dovrebbero essere un problema.

Questa non è una situazione né / né.

Soprattutto su un progetto più ampio, di solito hai poche persone relativamente esperte in ruoli senior e un numero di persone meno esperte in ruoli junior. In questo modo le persone anziane possono non solo aiutare direttamente il progetto scrivendo codice e aiutando a prendere le decisioni più difficili, ma possono anche aiutare indirettamente guidando i giovani.

Con un po 'di attenzione, questo può anche aiutare a prevenire che gli ingegneri senior si esauriscano rapidamente quando viene loro chiesto di svolgere costantemente lavori che non presentano sfide o interessi per loro. Almeno nella mia esperienza, anche un po 'di tempo che fa da mentore ad alcune entusiaste persone di livello junior (o persino di livello internato) può rendere uno sprint molto più interessante.

In tutta onestà, dovrei aggiungere che questo tipo di posizione probabilmente non si adatta a tutti gli ingegneri senior. Richiede un'enfasi notevolmente maggiore su architettura e design, comunicazione, documentazione e così via. Soprattutto all'inizio, spesso richiede anche molta disciplina: per qualcuno che ha fatto una carriera nella scrittura di codice, è allettante tentare semplicemente di scrivere il codice, piuttosto che insegnare a un ingegnere junior come farlo. Inoltre è spesso allettante fare una riscrittura completa da zero quando il codice non è come lo preferiresti personalmente, anche se è perfettamente adeguato per il lavoro.

Se, tuttavia, davvero non si può convincere l'amministrazione ad andare con una miscela di livelli di esperienza, non c'è praticamente alcun dubbio a tutti che si deve andare per più esperienza. Se lasci un progetto interamente a personale junior, è molto probabile che non otterrai mai un prodotto utilizzabile. Peggio ancora, non si renderanno conto che ciò che stanno facendo non sta fornendo alcun reale progresso verso un prodotto utilizzabile, quindi continueranno a lavorare nella direzione prescelta per molto tempo dopo che una persona più esperta si sarebbe accorta di aver realizzato un errore fondamentale nelle fasi iniziali e necessità di eseguire il backup, raggruppare, orientarsi e iniziare in una nuova direzione per avere qualche speranza di arrivare a una destinazione significativa.

Ogni progetto del mondo reale è guidato dalla domanda dei clienti e quindi coinvolge attività che sono a bassa complessità (ad esempio la creazione di moduli CRUD) e ad alta complessità (ad esempio la costruzione di un sistema di notifica guidato dagli eventi). L'unico modo per svolgere solo attività a bassa complessità è dire ripetutamente ai clienti la parola "no", che nessun reparto vendite di cui abbia mai sentito parlare è disposto a fare.

Se hai solo sviluppatori di livello junior significa che sarai in grado di svolgere solo compiti a bassa complessità, e quindi solo di costruire un prodotto di basso valore e lottare più duramente sul mercato per differenziare i tuoi prodotti. Se si desidera differenziare, è necessario creare funzionalità di alto valore, che inevitabilmente si traducono in attività di elevata complessità. Dopotutto, se fosse facile non sarebbe prezioso. Ciò significa che hai bisogno di persone per eseguire quelle attività ad alta complessità e hai bisogno di sviluppatori di livello senior.

Se hai solo sviluppatori di livello senior, sprecherai le loro abilità in lavori di basso valore, avrai difficoltà a trattenerli quando li costringerai a fare tali lavori, oltre a rischiare di andare nel mondo dell'astronomia nel tentativo di rendere più semplici compiti interessante su cui lavorare. Ciò significa che è necessario disporre anche di sviluppatori inesperti per raccogliere tali compiti.

Un team in buona salute che lavora su prodotti orientati al cliente è di solito un mix. Il rapporto tra sviluppatori junior e senior dipende dal rapporto tra attività a bassa complessità e ad alta complessità, e ciò dipende dalla vostra strategia aziendale. Se cerchi attivamente grandi volumi di lavoro di cookie cutter di facile comprensione a basso margine, non avrai molte attività ad alta complessità e probabilmente assumerai sviluppatori per lo più di livello junior. Se cerchi attivamente di differenziare e indirizzare le nicchie sottoservite a margini di profitto più elevati, avrai molte attività ad alta complessità e cercherai principalmente sviluppatori di livello senior.

Nella mia risposta sosterrò che i programmatori senior non necessariamente programmano più velocemente degli sviluppatori junior. In effetti, i programmatori più veloci sono in media ragazzi che hanno appena lasciato l'università.

La conoscenza del dominio è una chiave per gli sviluppatori senior. Un buon sviluppatore senior dovrebbe avere una forte conoscenza del campo, qualcosa che un programmatore junior potrebbe non avere. Gli sviluppatori esperti comprendono il problema, cosa risolvere e come risolverlo. Possono risolvere il problema più complicato per l'azienda rispetto alla maggior parte degli sviluppatori junior.

La programmazione è un insieme di abilità relativamente economico, è la conoscenza degli esperti che conta.

Non cercare di "fare il caso" Il mercato stabilisce il prezzo per i dipendenti. Se il mercato è disposto a pagare 4x in più per esperienza, è perché le aziende nel loro complesso hanno capito che c'è un aumento della produttività di 4x.

Ora, ovviamente, il mercato potrebbe essere sbagliato, forse 3,5 o 5x, ma a meno che tu non sia un'agenzia digitale, in competizione con il mercato o qualcosa del genere non è importante.

Il tuo vero problema è che sei abbastanza bravo a intervistare da essere in grado di distinguere tra un buon dev esperto e solo un vecchio dev che lo sta incolpando.

La tua seconda domanda sul budget PM vs Developer. Direi che uno sviluppatore può fare a meno di un PM, ma un PM non può fare a meno di uno sviluppatore. Prendi prima il tuo motore di sviluppo, quindi ottieni un PM per togliere l'amministratore dalle loro mani.

Non troverai nessuno nel tuo paese per un quarto del costo di uno sviluppatore davvero bravo. Potresti trovare qualcuno per metà dello stipendio e questo sarà un principiante assoluto. Per qualcuno a un quarto dello stipendio, devi andare fuori dal paese e quindi avrai problemi con le comunicazioni, le persone che seguono ciecamente le specifiche e tutti i tipi di problemi.

Hai bisogno di un buon sviluppatore. Se aggiungi più programmatori junior, hai bisogno di un buon sviluppatore con forti capacità comunicative, che sia disposto e capace di tenere d'occhio i ragazzi. Senza un buon sviluppatore, ti sei perso. Potresti essere fortunato a trovare un principiante di talento straordinario, ma una volta capito che sono bravi, vorranno uno stipendio più grande.

Se non hai un buon sviluppatore, non hai nessuno che veda il quadro generale e nessuno in grado di risolvere i problemi che non possono essere risolti utilizzando StackOverflow. E avrai un codice che puzza ed è irrintracciabile, perché gli sviluppatori junior non sanno come creare un codice gestibile. Possono impararlo, ma non lo faranno senza un buon sviluppatore nel team.

Ci sono alcuni ostacoli che la tua azienda dovrebbe superare prima di poter decidere se assumere programmatori migliori sarebbe conveniente. Scusami se sto facendo delle ipotesi negative su dove lavori, ma non sono convinto che sappiano cosa stanno facendo.

1. Hanno valutato accuratamente la complessità del software che costruisci? Sembra che non pensino che quello che stai facendo sia molto difficile, quindi perché assumere persone migliori? Hai fatto il caso in cui vengono commessi errori e in che modo soluzioni e produttività migliori farebbero soldi? Risparmiare tempo è grandioso, ma molte aziende preferiscono perdere un'intera settimana di un programmatore piuttosto che dare loro i soldi per acquistare un tappetino per il mouse.
2. La tua azienda è attraente per i buoni programmatori? Sono in grado di identificarli? Niente di peggio che assumere un Senior Dev, pagare loro più soldi e trascinare giù l'intera squadra a causa della loro mancanza di abilità e / o leadership.
3. La tua azienda può utilizzare un buon programmatore? Se tutto ciò che faranno è lanciare loro specifiche scadenti e dirgli semplicemente di andare a costruirlo, qual è il punto? Daranno loro la libertà di fare le cose a modo loro? Dopotutto, un buon programmatore per definizione sa come sfruttare al meglio il suo tempo. Hanno un impatto su coloro che li circondano e fanno migliorare altri programmatori. Presentano progetti e architetture migliori che gli altri si basano sul rendere il prodotto molto migliore.

Mi dispiace, ma mi sento come se la tua azienda non sapesse cosa fare con un buon programmatore, quindi potresti voler convincerli ad assumere prima manager migliori e risolvere questi problemi interni.