Come faccio a creare costosi programmatori?

Ho esperienza diretta di entrambe le teorie provate 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 di avere delle specifiche di buona qualità seguite pedissequamente da programmatori molto giovani.

Dopo oltre 6 mesi di sviluppo del progetto principale, ho assunto il ruolo di responsabile dello sviluppo. Una volta sistemati alcuni fattori igienici, il problema della qualità del codice è rimasto. Avevo un budget limitato e assunto un programmatore molto esperto (beh, più un Solution Architect) con competenze comunicative fuori dagli schemi e una vita da formatore in C # (la lingua in cui è stato scritto il progetto). L'idea era di migliorare la qualità degli altri programmatori fornendo un mentoring e un allenamento efficacemente gratuito.

Dopo un mese o due è diventato dolorosamente ovvio che anche questo non avrebbe funzionato, quindi il team originale è stato rimosso dal progetto e sono stati aggiunti un paio di programmatori top-drawer. Hanno consegnato il progetto che il team originale aveva completamente mancato di consegnare in 8+ mesi di tentativi in 3 sprint di un mese partendo da zero perché il codice originale era irredimibile.

Se le tue esigenze sono molto semplici, potresti riuscire a farla franca con un programmatore molto giovane, ma la probabilità è che a lungo andare costino molto di più. A volte le esigenze "semplici" si evolvono in una grande complessità.

Se non avessi fatto la difficile scelta di cambiare direzione, probabilmente ci lavorerebbero ancora :) - Più seriamente, in questo esempio, la mancanza di comunicazione e competenza da parte della squadra originale significava che non avrebbero sollevato problemi con le specifiche ma proveremmo a fare qualsiasi cosa fosse loro richiesto di fare se avesse senso dal punto di vista architettonico o meno. Uno sviluppatore più esperto e sicuro fece domande e scavò nei requisiti sottostanti e quindi finì la prima soluzione giusta .

Oh, un'altra cosa. Non dare per scontato che tu possa assumere immediatamente un grande programmatore. Ci sono un sacco di gente là fuori con un'esperienza pluriennale di mediocrità che fornirà un risultato quasi altrettanto brutto di uno junior ma costerà la stessa di una superstar (a volte anche di più). Ho un ottimo "tasso di successo", ma questo viene fornito con esperienza e ho molto. È 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 tenerli.

Se disponi di statistiche dettagliate sulle prestazioni, puoi fare il business case con la matematica. Questi potrebbero dimostrare che la velocità di sviluppo compenserebbe l'aumento del prezzo o, ancora meglio, che un design robusto potrebbe risparmiare di più nella manutenzione e nello sviluppo delle versioni successive. Sfortunatamente tali dati non sono disponibili così spesso, specialmente per le nuove tecnologie.

Un altro argomento può essere il time to market. Questo è più facilmente comprensibile dal management superiore. Tuttavia, se il tempo non è veramente critico, questo non aiuta.

In ultima analisi, trova un'immagine di Red Adair , il famoso pompiere, che è stato chiamato in un grave disastro dopo diversi tentativi infruttuosi di ragazzi meno esperti. La sua famosa citazione:

If you think it's expensive to hire a professional, wait until you've hired an amateur.

... merita di essere stampato a colori e visualizzato in posizione prominente sulla porta dell'ufficio, in modo che tutti capiscano di cosa si tratta; -)

Mi piace e ho alzato la risposta di mcottle, ma voglio coprire alcune altre dinamiche e argomenti che le altre risposte non hanno ancora sollevato.

In primo luogo, 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 trovi è dal tuo team che prova e fallisce, che è molto costoso. Dopo aver fallito, ci sono due possibili lezioni da imparare da questo. Un'opzione è che impari che hai bisogno di sviluppatori più competenti e così li assumi e completi il progetto con un budget eccessivo e una pianificazione eccessiva, ma almeno sei preparato in futuro. L'altra opzione è che un tale progetto è "troppo difficile" per il tuo team e tali cose non dovrebbero essere tentate in futuro, cioè rinunci al progetto e in modo efficace a qualsiasi altro simile. Ovviamente, raramente sarà espresso 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 altri. Quest'ultima visione può distorcere in modo significativo la prospettiva di un'azienda su cosa è possibile e per quanto tempo / costoso sviluppo dovrebbe essere. "Se ci vuole un anno per non fare X, forse sei mesi per fare la più semplice Y è ragionevole."

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

• Rendono competitivi i saldi per mantenere i dipendenti, nel qual caso perché dovrebbero avere un problema a pagare i tassi di sviluppo senior ora? Tornerò su questo però.
• Hanno tassi di stagnazione che significano che alla fine si "ridurranno" ai dipendenti che mancano di guida e / o abilità.
• Rimuovono più attivamente i dipendenti più anziani.

I secondi due casi implicano un notevole turn-over dei dipendenti, che significa perdita di conoscenza della società 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 programmi crescenti. Il modo in cui questo andrà a finire è che tutto va bene per il progetto X fino a quando Jim parte, che è stato uno dei migliori sviluppatori, perché non ha ottenuto un aumento in due anni, ora il progetto "comprensibilmente" durerà molto più a lungo è necessario assumere e formare nuovi sviluppatori junior che (presumibilmente) non saranno all'altezza di Jim. Ecco come ricalibrare le aspettative.

Anche nel caso in cui vengano forniti rilanci competitivi, se tutti voi avete sviluppatori junior dove e come dovrebbero imparare? In pratica, speri che uno di loro imparerà le buone pratiche da solo nonostante il loro ambiente di lavoro, e alla fine guida gli altri (invece di partire per i pascoli più verdi). Avrebbe molto più senso "innescare la pompa" con alcuni buoni sviluppatori. Più probabilmente svilupperai una cultura di Principianti esperti . Il risultato è che finirai per pagare alti tassi di sviluppo a persone che sono solo leggermente migliori degli sviluppatori junior e sono culturalmente tossiche.

Un vantaggio, in particolare, molto di buoni sviluppatori, che sono sorpreso che nessun altro abbia menzionato è che possono facilmente essere un fattore moltiplicativo . Potrebbe anche accadere che uno sviluppatore junior e uno sviluppatore senior impieghino lo stesso tempo per creare un tavolo. Tuttavia, un buon sviluppatore non lo farà. Creeranno un generatore di tabelle che riduce il tempo per tutti per creare una tabella. In alternativa / in aggiunta, aumenteranno il limite massimo 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 utenti di MapReduce non sono assolutamente in grado di creare una versione del loro algoritmo ampiamente distribuita, ora possono facilmente Riduci mappa. 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 'l'altro lato, forse i superiori hanno ragione. Forse gli sviluppatori più esperti non sono necessari. Se questo è il caso, tuttavia, sembrerebbe che lo sviluppo non sia una parte significativa dell'azienda. In tal caso, eliminerei completamente gli sviluppatori e utilizzerei software off-the-shelf o assumere appaltatori su richiesta. Potrebbe valere la pena esplorare perché non usano solo appaltatori piuttosto che un team interno. Se avrai comunque un sacco di dipendenti in abbandono, allora gli imprenditori non dovrebbero essere un problema.

Questa non è una o / o situazione.

Soprattutto su un progetto più ampio, di solito hai un po 'di persone relativamente esperte nei ruoli senior e un numero di persone meno esperte nei ruoli junior. In questo modo le persone anziane non solo possono aiutare direttamente sul progetto scrivendo codice e aiutando a prendere decisioni più difficili, ma possono anche aiutare indirettamente mentori juniores.

Con un po 'di attenzione, questo può anche aiutare a evitare che gli ingegneri senior si esauriscano rapidamente chiedendo di svolgere costantemente lavori che mancano di sfida o interesse per loro. Almeno nella mia esperienza, anche un po 'di tempo di mentoring di alcune persone entusiaste di livello junior (o anche di livello interno) può rendere lo sprint molto più interessante.

In tutta onestà, devo aggiungere che questo tipo di posizione probabilmente non si adatta a tutti gli ingegneri senior. Richiede una maggiore enfasi su architettura e design, comunicazione, documentazione e così via. Soprattutto all'inizio, richiede spesso molta disciplina - per qualcuno che ha fatto carriera nel codice della scrittura, si è tentati di inserire semplicemente il codice, piuttosto che insegnare ad un ingegnere junior come farlo. Spesso è anche tentato di eseguire una riscrittura completa da zero quando il codice non è come lo preferisci personalmente, anche se è perfettamente adeguato per il lavoro.

Se, tuttavia, non riesci davvero a convincere il management ad andare con un mix di livelli di esperienza, non c'è praticamente nessuna domanda che tu abbia per avere più esperienza. Se lasci un progetto interamente al personale junior, è molto probabile che semplicemente non avrai mai un prodotto utilizzabile. Peggio ancora, non si renderanno conto che quello che stanno facendo non sta fornendo alcun reale progresso verso un prodotto utilizzabile, quindi continueranno a lavorare nella direzione prescelta molto tempo dopo che una persona più esperta si sarebbe resa conto di aver fatto un errore fondamentale nella fase iniziale e necessità di eseguire il backup, raggruppare, orientarsi e iniziare in una nuova direzione per avere qualche speranza di arrivare a una destinazione significativa.

Qualsiasi progetto del mondo reale è guidato dalla domanda del cliente e quindi implica attività a bassa complessità (ad esempio la creazione di moduli CRUD) e un'elevata complessità (ad esempio la creazione di un sistema di notifica basato su eventi). L'unico modo per avere solo compiti di bassa complessità è di 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 vuol dire che sarai in grado di eseguire solo compiti di bassa complessità, e quindi solo in grado di costruire un prodotto di basso valore e di lottare più duramente nel mercato per differenziare i tuoi prodotti. Se si desidera differenziare, è necessario creare funzionalità di alto valore, che inevitabilmente si traducono in attività ad alta complessità. Dopotutto, se fosse facile non sarebbe prezioso. Ciò significa che hai bisogno di persone per eseguire queste attività di elevata complessità e hai bisogno di sviluppatori di livello senior.

Se hai solo sviluppatori di livello senior, sprechi le loro competenze su lavori di basso valore, hai difficoltà a trattenerli quando li costringi a fare quel lavoro, oltre a rischiarli di andare in astronomia architettonica nel tentativo di fare compiti semplici più interessanti su cui lavorare. Ciò significa che devi anche avere alcuni sviluppatori inesperti per riprendere queste attività.

Un team sano che lavora su prodotti guidati dai clienti è solitamente un mix. Il rapporto tra gli sviluppatori junior e senior dipende dal rapporto tra la complessità bassa e le attività ad alta complessità e dipende dalla strategia aziendale. Se cerchi attivamente grandi volumi di lavori di taglio di cookie facilmente comprensibili a basso margine, non avrai molti compiti ad alta complessità e probabilmente assumerai principalmente sviluppatori di livello junior. Se si cerca attivamente di differenziare e indirizzare nicchie poco servite a margini di profitto più elevati, si avranno molti compiti ad alta complessità e si cercheranno principalmente sviluppatori senior-level.

Non troverai nessuno nel tuo paese per un quarto del costo di uno sviluppatore davvero bravo. Puoi trovare qualcuno con metà del salario, e questo sarà un principiante assoluto. Per qualcuno a un quarto del salario, è necessario andare al di fuori del paese, e quindi si avranno 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 altri programmatori junior, hai bisogno di un buon sviluppatore con forti capacità di comunicazione, che sia disposto e capace di tenere d'occhio i giovani. Senza un buon sviluppatore, sei perso. Potresti essere fortunato a trovare qualche principiante straordinario di talento, ma una volta che lui o lei capirà che sono bravi, vorranno uno stipendio più grande.

Se non hai uno sviluppatore valido, non hai nessuno che veda l'immagine più grande e nessuno che possa risolvere problemi che non possono essere risolti usando StackOverflow. E avrai un codice che trasuda ed è irraggiungibile, perché gli sviluppatori junior non sanno come creare codice mantenibile. Possono impararlo, ma non lo faranno senza un buon sviluppatore del team.

Nella mia risposta discuterò che i programmatori senior non codificano necessariamente 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 è la chiave per gli sviluppatori senior. Un buon sviluppatore senior dovrebbe avere una conoscenza approfondita del campo, qualcosa che lo sviluppatore junior potrebbe non avere. Gli sviluppatori esperti comprendono il problema, cosa risolvere e come risolverlo. Possono risolvere problemi più complessi per il business rispetto alla maggior parte degli sviluppatori junior.

La programmazione è un set di abilità relativamente economico, è la conoscenza esperta che conta.

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

Ora ovviamente il mercato potrebbe essere sbagliato, forse il 3.5 o il 5x ma a meno che tu non sia un'agenzia digitale, competendo contro il mercato o qualcosa di simile non è importante.

Il tuo vero problema è Sei abbastanza bravo a intervistare per essere in grado di distinguere tra un dev esperto con esperienza e solo un vecchio dev che lo sta bloggando.

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. Ordina prima il tuo motore di sviluppo, quindi chiedi a un PM di togliersi l'amministratore dalle mani.

Ci sono alcuni ostacoli che la tua azienda dovrebbe superare prima di poter decidere se assumere programmatori migliori sarebbe economicamente vantaggioso. Scusa se sto facendo alcune ipotesi negative su dove lavori, ma non sono convinto di sapere cosa stanno facendo.

1. Hanno valutato con precisione 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 sono stati commessi degli errori e in che modo le soluzioni e la produttività migliori farebbero soldi? Il risparmio di tempo è notevole, ma molte aziende preferirebbero sprecare il tempo di programmazione di un'intera settimana piuttosto che dare loro i soldi per acquistare un tappetino per il mouse.
2. La tua azienda è interessante per i bravi programmatori? Sono in grado di identificarli? Nulla di peggio che assumere un Senior Dev, pagarli di più e trascinano tutta la squadra a causa della loro mancanza di capacità e / o leadership.
3. La tua azienda può utilizzare un buon programmatore? Se tutto quello che stanno per fare è buttare loro delle specifiche scadenti e dirgli semplicemente di costruirlo, qual è il punto? Daranno loro la libertà di fare le cose a modo loro? Dopo tutto, un buon programmatore per definizione sa come utilizzare al meglio il suo tempo. Hanno un impatto su quelli che li circondano e fanno sì che altri programmatori migliorino. Introducono progetti e architetture migliori che il resto si basa sul miglioramento del prodotto.

Ci dispiace, ma credo che la tua azienda non saprebbe cosa fare con un buon programmatore, quindi potresti voler convincerli ad assumere gestori migliori per primi e risolvere questi problemi interni.