Domanda:
Qual è il normale tasso di turnover tra gli sviluppatori e ha un impatto sulla produttività?
MapleLeafsFan
2020-04-16 03:53:29 UTC
view on stackexchange narkive permalink

Non un tecnico, ma sappi che i tecnici si trovano qui, quindi chiedo qui. Sono una persona relativamente nuova e generalizzata per l'acquisizione di risorse umane / talenti presso una banca in cui continuiamo ad assumere più sviluppatori e recentemente sono stato trasferito a quel progetto. Abbiamo circa 25 sviluppatori in totale e abbiamo bisogno di fornirne 35 all'anno.

L'assunzione è diventata un progetto perché il gruppo è afflitto da ritardi nel progetto e perché un senior manager ha urlato al manager del gruppo tecnico per non essere in grado di consegnare i progetti in tempo. Ciò ha innescato un reclamo e poiché il manager è una donna e il senior manager è un uomo, il problema delle urla deve essere risolto. Il manager vuole più sviluppatori dato che tutti sono nuovi alla base di codice.

Per me, quel tasso di turnover è folle e penso che qualcosa non va nel dipartimento stesso. Comunque è il mio istinto. Vedo che causa molti ritardi durante l'onboarding di sviluppatori e quant'altro. Ma l'amico sviluppatore che ho nel team dice che "siamo fortunati a tenerli così a lungo". È qui da appena 6 mesi e gli ha chiesto informazioni sul processo per referenze.

Sono a Toronto in Canada per chiunque me lo chieda.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/106813/discussion-on-question-by-mapleleafsfan-what-is-the-normal-rate-of-turnover-amon).
Volevo modificare questo, il titolo in particolare, poiché non corrisponde realmente alle risposte seguenti, ma non sono sicuro di cosa vuoi effettivamente ottenere qui.È semplicemente per confermare se questo tasso di turnover è folle?O vuoi anche capire come trovare la causa principale / risolvere il problema?
La tua direzione sa che non è lì per costringere le persone a rispettare le scadenze, ma a fare tutto ciò che è in loro potere per aiutare le persone a lavorare in modo ottimale per rispettare le scadenze?Penso che il problema sia che il tuo manager pensa di poter stare seduto e aspettare mentre anneghi nei problemi invece di fare effettivamente la gestione per aiutarti.Il problema non è da parte dello sviluppatore.
Esci dalle interviste.Cosa stanno dicendo?Questo ti darà le risposte di cui hai bisogno.
@Lilienthal Questo è stato il motivo del mio voto favorevole.La domanda posta nel titolo è troppo specifica per fornire una risposta adeguata a domande e risposte e ha raccolto una serie di risposte interessanti a domande adiacenti senza affrontare quella che è stata posta.
Dieci risposte:
Daniel
2020-04-16 04:18:39 UTC
view on stackexchange narkive permalink

Qual è il normale tasso di turnover tra gli sviluppatori

Il tuo tasso di turnover mi sembra folle. È più quello che mi aspetto con gli agenti callcenter. Se davvero intendi che devi procurarti 35 dipendenti per mantenere il tuo costante livello di 25 sviluppatori attivi, avresti un tasso di fluttuazione del 140%. Dovrebbe essere tra il 10 e il 20%. (Nel 2017 nel settore IT ho riscontrato un tasso di turnover complessivo del 16% per la Germania e del (2) 18% negli Stati Uniti nel 2016)

e ha un impatto sulla produttività?

Sì, ha un impatto profondo sulla produttività. Solo una stima rapida e sporca:

  1. I tuoi nuovi sviluppatori devono imparare lo stack tecnologico, il processo di sviluppo, i requisiti aziendali, ecc. Diciamo che impiegano metà del loro tempo per i primi 6 mesi (100% -0% in una degressione lineare). Sono ~ 3 mesi persi proprio lì.

  2. Creare un'atmosfera lavorativa, le dinamiche del team e la giusta configurazione dell'ufficio può influire notevolmente sulla produttività degli sviluppatori: alcune ricerche (1) suggeriscono di un fattore 10!

Quindi, se il tuo sviluppatore medio rimane solo per circa 8,5 mesi prima ad imparare e poi a demotivarsi rapidamente, il tuo team di 25 persone ha circa la produttività di un team di 2 persone felice e professionale -3 sviluppatori!


Modifica a causa dei commenti: alcuni lavori hanno solo un tasso di turnover naturale più elevato. Di solito si tratta di lavori con salario basso e bassa qualificazione. Questi lavori sono spesso svolti dalle persone finché non hanno qualcosa di meglio, ad esempio dagli studenti, ecc. Questo non vuol dire che sia una buona cosa ovunque. Sostituire un dipendente ti costa sempre denaro e normalmente danneggia sia la qualità che la produttività!

Qualsiasi attività che considera le persone sacrificabili si farà male!

Se ne parli con la direzione, a volte è utile esprimerlo in termini monetari. Oltre ai costi di reclutamento, investi anche denaro nello sviluppo professionale e nell'apprendimento della conoscenza del dominio di ciascun dipendente costantemente nel tempo. Questo è il capitale umano dell'azienda. Una volta che il dipendente lascia, perdi questo investimento. Questo è più o meno come non fare il cambio dell'olio sulla flotta aziendale e invece far rompere e sostituire i veicoli ogni sei mesi. Puoi facilmente perdere milioni in questo modo!


Inoltre, non vuoi arrivare a zero fluttuazioni. Un piccolo afflusso di nuove idee è una buona cosa e non tutte le persone si adatteranno alla squadra per sempre. La cosa pericolosa è che, con un ambiente di lavoro così tossico, probabilmente stai perdendo le brave persone e mantieni solo coloro che non riescono a trovare un lavoro migliore o hanno trovato un modo per continuare a essere pagati mentre si allontanano così tanto dall'azienda che prendono scarso interesse per i suoi obiettivi (si sono dimessi all'interno). (3)


(1) Come spiegato nel libro "Peopleware" di Tom de Marco e Timothy Lister

(2 ) https://www.glassdoor.com/employers/blog/turnover-retention-rates/

(3) Articolo del blog sulla perdita del talento, grazie a @Josh Johnson

Probabilmente puoi ridurlo ulteriormente perché un team di 2-3 sviluppatori può comunicare in modo più efficace di 25.
+1 per i requisiti di apprendimento, ecc. E una grande opportunità per citare un altro libro: The Mythical Man Month.Non sarai mai in grado di sapere quanti sviluppatori impiegano quanto tempo per sviluppare [inserire qualsiasi software] quando lanciano costantemente nuovi sviluppatori all'attività.Pensa solo a come dovrebbe essere la documentazione ** **, quando cerchi di avere successo con un turnover così alto!
Per aggiungere alla tua risposta, c'è il costo aggiuntivo che con così tanto fatturato su così tanti sviluppatori, la base di codice probabilmente sembra una merda (poiché non ci sarebbe modo di coordinare tutto quel lavoro).Anche se i problemi di gestione vengono risolti, sembra che tutti i progetti debbano essere gettati nel cestino e ricominciati da zero per non far fuggire ogni nuova recluta nel panico.E più a lungo ritardano la risoluzione dei problemi di gestione, maggiori saranno i costi futuri.
@Echox Come regola generale, [non buttare mai via una base di codice esistente.] (Https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)
@Alexander Il tuo link è molto interessante ma parla di vecchio codice "normale", testato e funzionante da tempo.E una regola pratica significa che è molto spesso vero, non sempre.Il costo del refactoring deve essere confrontato con il costo di non essere in grado di mantenere uno sviluppatore per più di pochi mesi.So che non toccherei la base di codice di OP con un bastone nemmeno per il doppio del mio stipendio.
@Echox: Cosa farei se questa fosse la mia azienda, manterrei il Team in funzione così com'è.Allo stesso tempo, avrei trovato un buon IT-Manager con l'autorità per creare un team off-site di 3-4 persone.Quindi avrei iniziato a dare loro un compito dopo l'altro in ordine di importanza fino a quando non avevo più bisogno del Team originale.
Gli sviluppatori dovrebbero essere considerati come agenti di call center in quanto possono essere facilmente scambiati?
@MapleLeafsFan: È quello che hai ottenuto dalla mia risposta?Scusa, sono un po 'scioccato qui!nessuno dovrebbe essere pensato come scambiato facilmente.Almeno non se vuoi un'attività sana.Ha lavorato qui in Germania per un call center per un po 'di tempo e ha svolto un'analisi statistica.La sostituzione di un agente ci è costata ~ 10.000 €, quindi ridurre le fluttuazioni è stato un obiettivo di risparmio di denaro reale.Sostituire un programmatore ti costa sicuramente tra i 50.000 ei 300.000 a seconda dello stipendio, della competenza e del tempo in azienda.Quindi, oltre a far male alla produttività, è dannatamente costoso!
@MapleLeafsFan No. No, non dovrebbero.Questo è, purtroppo, apparentemente un atteggiamento comune tra alcuni manager ed è esso stesso un indicatore principale di altri atteggiamenti e pratiche tossiche sul posto di lavoro.
@MapleLeafsFan non per la maggior parte delle operazioni;le aziende hanno perso molti soldi cercando di fingere che la competenza non fosse richiesta.Sono più vicini ai professionisti abilitati come avvocati e contabili, anche se la professione non è registrata.C'è un motivo per cui Google paga ai propri sviluppatori diverse centinaia di migliaia di dollari.
La tua risposta è ok, ma è anche bello sapere che la Germania è un po 'specifica quando si tratta della durata media delle persone che rimangono al lavoro.No, non ho esaminato le statistiche, ma ho lavorato in diversi paesi e in nessun altro le persone che cambiano lavoro sono disapprovate così tanto come in Germania.
@BigMadAndy Hai qualche prova empirica a sostegno della tua affermazione?Lavoro da 25 anni in Germania nel settore IT.Non ho mai sperimentato che sia disapprovato - a parte il salto di lavoro che è disapprovato ovunque almeno se credi alla risposta alle numerose domande su questo argomento qui.
@BigMadAndy Ho finanziato un numero per gli Stati Uniti del 18% che è circa nella mia gamma e può probabilmente essere ampiamente spiegato dalle leggi sul lavoro "a volontà" negli Stati Uniti, rispetto a un tipico periodo di preavviso di 3 mesi nei contratti tedeschi.
Il processo mediante il quale i buoni dipendenti partono per pascoli più verdi lasciando dietro di sé i dipendenti meno talentuosi con meno prospettive si chiama Effetto del Mar Morto http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effetto/
Grazie @JoshJohnson!Non conosco questo termine.Dare un'occhiata e magari aggiungerlo ai riferimenti.
usr-local-ΕΨΗΕΛΩΝ
2020-04-16 12:16:22 UTC
view on stackexchange narkive permalink

[...] il gruppo è afflitto da ritardi nei progetti e perché un senior manager ha urlato al manager del gruppo tecnico di non essere in grado di consegnare i progetti in tempo e ciò ha provocato un reclamo e perché il manager una donna e il senior manager è un uomo, quel problema con le urla deve essere risolto.

Non è assolutamente un problema con il turnover o gli sviluppatori. È un ambiente tossico e il conseguente problema di PM-ing sbagliato !!. Deve essere risolto al più presto affinché il progetto sia salvabile”.

Il manager vuole più sviluppatori dato che tutti sono nuovi alla base di codice.

la legge di Brooks (grazie @Benjamin ma ho usato un link diverso) dimostra che il meglio che puoi fare per uccidere il progetto è assumere più personale, nella falsa convinzione che recupererà i ritardi accumulati .

Ogni nuova assunzione è nuova per il codice di base e tutti hanno bisogno di accelerare.

Lasciami aggiungere una citazione iconica su ciò che sta accadendo nella tua azienda

Se metti incinta 9 donne oggi, avrai 9 bambini alla fine dei 9 mesi, non 1 bambino dopo un mese

Nell'ambito della gestione del progetto, aggiungere nuove risorse richiede di mettere in pausa una risorsa esistente dall'attività (codifica) per formare i nuovi assunti. Questo ha l'effetto immediato di ritardare il progetto, che è l'opposto delle aspettative del tuo manager.

Un progetto che soffre non beneficia di risorse aggiuntive, specialmente nell'industria del software: semplicemente subirà i nuovi assunti. Non sarò intenzionalmente scortese, ma sembra che la tua gestione provenga dal mondo dell'agricoltura e dell'agricoltura, dove puoi noleggiare una nuova mietitrice durante la notte.

Alla fine, il tuo fatturato è folle perché il il progetto ha problemi di gestione. Non sono in grado di entrare nei dettagli della strategia di riparazione, ma sicuramente rinegoziare le scadenze sarebbe la mia prima scelta. E alla fine, a questo punto il progetto è così critico che deve essere salvato o ucciso.

È mia esperienza che alcuni progetti, per motivi politici o di marketing, non possono permettiti solo un ritardo.

noto anche come https://en.wikipedia.org/wiki/Brooks%27s_law -> l'aggiunta di manodopera a un progetto software in ritardo lo rende più tardi
L'esempio agricolo non si adatta.Nella crisi della Corona, gli agricoltori tedeschi mancano di mietitrici addestrate dall'Europa orientale.La formazione degli studenti tedeschi o dei disoccupati che forse se ne vanno dopo qualche mese (a causa del duro lavoro) richiede molto tempo agli agricoltori.Pertanto, alcuni agricoltori non vogliono impiegare mietitrici tedesche non addestrate.Almeno nella zona degli asparagi e delle fragole questo è il caso.Non so se la raccolta delle mele sia influenzata in modo simile ...Comunque: l'agricoltura è un cattivo esempio ;-)
@daniel.neumann: Penso che difenderei il confronto agricolo.Supponiamo che mietitrici addestrate, non completamente inesperte.Qualcuno che può raccogliere gli asparagi in una fattoria può essere produttivo in un giorno in un'altra.Ma anche i programmatori esperti e formati avranno un tempo di avvio di ~ 6 mesi per essere produttivi in un altro negozio di software.
Questa è una buona risposta.Sfortunatamente l'errore di pensare che aggiungere altre persone significhi accelerare un progetto in ritardo è incredibilmente comune nell'IT ma anche in altre aree / settori funzionali.
"Metti incinta 9 donne oggi" - credimi, ci sto provando.È più difficile di quanto sembri!
@DanielR.Collins Devi confrontare le raccoglitrici di asparagi addestrate con le raccoglitrici di fragole addestrate ;-).Ma, certo, il tempo necessario per addestrare i mietitori è più breve.
Un "Progetto", dai libri di testo, è "Una risorsa unica e irripetibile che richiede un insieme di compiti complessi che presenta novità e rischi [...]".L'agricoltura non è un progetto, guidare un treno non è un progetto (ma richiede qualificazione e certificazione), governare un aereo non è un progetto (qualifica richiesta per tipo di aeromobile), il software è sempre un progetto
Matthew Gaiser
2020-04-16 20:48:52 UTC
view on stackexchange narkive permalink

Se li perdi a 8 mesi, decidono di lasciarli a 6.

Presumo che la maggior parte delle persone lasci altri lavori. Di solito ci vuole del tempo per trovarne un altro che cerchi part-time e assumendo che siano in qualche modo selettivi. Diciamo un mese supponendo che siano un buon sviluppatore. Aggiungi un altro mese per raccogliere una busta paga in attesa dell'inizio del nuovo lavoro. Questo prende la decisione di partire a 6 mesi.

I tuoi sviluppatori stanno praticamente concedendogli il periodo di prova e decidendo di andare altrove in seguito.

Ma l'amico dev che ho nel team dice che "siamo fortunati a tenerli così a lungo."

Sta commentando la tua azienda, non il mercato degli sviluppatori in generale. Scommetto che è lui stesso a cercare lavoro.

Per quanto riguarda il fatto che un elevato tasso di abbandono degli sviluppatori danneggi il progetto, ho lavorato solo su un sistema negli ultimi 8 mesi. L'altro sviluppatore del progetto è qui da un anno. Il progetto ha 4 anni. Stimerei che 1/4 del lavoro che ho fatto è stato duplicato in un modo o nell'altro poiché non sapevamo che la funzionalità fosse già stata costruita. Abbastanza problematico per te?

"Scommetto che è lui stesso a cercare lavoro".Non c'è bisogno di scommettere, la domanda dice "È stato qui da soli 6 mesi e ** ha chiesto informazioni sulla procedura per i riferimenti. **"
Un ottimo punto.Se si stima un tempo normale di accelerazione della produttività di ~ 6 mesi, ciò porta alla possibilità che nessuno abbia svolto alcun lavoro produttivo nella memoria recente.Mi chiedo: questo team ha mai prodotto risultati finali?
@BenVoigt Non sono riuscito completamente a leggere la riga successiva.Sì, sta già uscendo ...
@DanielR.Collins i miei amici delle banche si sono affrettati a spingere rapidamente il codice, quindi sospetto che la risposta sia sì, ma ... Non mi hanno fornito molti dettagli sul codice, ma un altro amico è junior in un'azienda e hannouna pagina web che effettua il caricamento di 160 chiamate API poiché nessuno si è preoccupato di consolidare nulla.Quindi sospetto che spediscano qualsiasi cosa.
Joel Etherton
2020-04-17 02:27:12 UTC
view on stackexchange narkive permalink

È chiaro quando fai la domanda che sai di avere un problema di turnover. Non sono informazioni nuove. Molte risposte sono state orientate agli impatti e descrivendo il costo che questo tipo di fatturato sostiene. Sono tutte informazioni davvero fantastiche e nessuna di esse ti aiuta a risolverlo.

Ottimo, il tuo problema ha un impatto enorme e devi risolverlo. Qual è il tuo problema, però? Il fatturato è un sintomo, non è il problema.

Hai un problema culturale.

Hai persone che non si fidano né si rispettano a vicenda, e loro " chiaramente non sei incoraggiato a farlo. Mentre le statistiche mostrano il turnover per l'organizzazione, quante persone hai che ci sono state 5+ anni? Queste potrebbero essere alcune delle tue aree problematiche. Quali sono i tuoi piani di sviluppo? In che modo i tuoi quadri intermedi migliorano i tuoi collaboratori individuali? Qual è il loro percorso verso l'empatia per i loro coetanei?

  1. Devi eliminare immediatamente i comportamenti ostili o tossici.
  2. Identifica le persone più anziane. Sono affidabili? Sono rispettosi? Come sollevano le persone intorno a loro? Se non puoi rispondere positivamente a queste domande, questo è il tuo primo punto di soluzione. Devono essere aumentati di livello in competenze trasversali, leadership ed empatia. In caso contrario, devono essere sostituiti.
  3. Ascolta i punti deboli. I tuoi contributori individuali avranno MOLTI reclami. Legali insieme in punti di processo comuni e usali per identificare i miglioramenti del processo che allevieranno quel dolore.
  4. Separare le persone dal problema. Descrivi il problema a qualcuno che non ha idea di cosa stai parlando. Non usare nomi; usa solo ruoli. Se non riesci a separare la persona dal problema, il problema è la persona .

Ottimo, hai iniziato a risolvere il processo - Cosa delle persone?

Le persone in generale vogliono sentirsi necessarie e apprezzate. Vogliono che il loro lavoro sia importante per qualcun altro. Vogliono migliorare in quello che fanno e vogliono essere in grado di fare di più. Lo fanno attraverso i loro manager e supervisori.

  1. Che aspetto hanno i tuoi programmi di formazione?
  2. Quali incentivi sono disponibili per il progresso?
  3. Come vengono premiate le azioni di successo?
  4. In che modo le persone sono ritenute responsabili degli errori?
  5. Come il loro lavoro viene promosso a un posto di valore?

Devi essere in grado di rispondere a queste domande in modo molto convincente. Se non puoi, i tuoi dipendenti se ne vanno perché l'azienda non li valuta nel modo in cui vogliono essere valutati.

E le persone tossiche / arrabbiate?

Molte persone ti diranno che devono essere licenziate. Molte persone sono pronte a rinunciarvi. Qualcuno che si arrabbia o si sente frustrato è qualcuno che ti sta mostrando quanto gli importa. Potrebbero non interessarsi delle cose giuste al momento, ma sono investiti in ciò che fanno e in chi sono nella loro posizione. Ti incoraggio a non rinunciare a queste persone. In passato ho investito nei miei individui tossici e ne ho ricavato enormi dividendi. Queste persone sono diventate alcune delle mie migliori performance.

  1. Devi ascoltarle. Ascolta i loro problemi. Aiutali a superarli. Questo richiede tempo. Ci vuole incoraggiamento.
  2. Mettili in contatto con i loro colleghi. Istruiscili su come il loro comportamento influisce sulle persone che li circondano. Aspettati di meglio da loro. Di 'loro che non è accettabile e che hai bisogno del loro aiuto.
  3. Trova i loro punti di valore e aiutali a raggiungerli. Se si tratta di ottenere lavoro di fronte a un cliente, fai il possibile per aiutarlo a farlo. Se interagisce con altre aree dell'organizzazione, trova le opportunità per realizzarlo.
  4. Identifica il loro comportamento tossico e affrontalo subito quando accade. Non devi martellare le persone. Metti solo in chiaro che stai guardando e aspettati di meglio.

Wow, c'è molto da fare qui. Sono io il problema?

Potresti esserlo. È possibile che non si fidino dell'azienda o della leadership. Se sei nella gestione, è fondamentale identificarlo. Tante volte questo è il risultato dei messaggi di leadership che non corrispondono alle azioni di leadership. Spesso è solo la percezione della mancanza di rispetto che deriva dalla separazione delle informazioni.

  1. Sii il più onesto e trasparente possibile con i tuoi colleghi.
  2. La leadership deve mantenere un atteggiamento coeso e messaggio consolidato.
  3. La direzione deve rispettare i propri contributi individuali e fare tutto il necessario per elevarli.

La leadership al servizio ha sempre lavorato per me. Se i tuoi contributori individuali credono che il lavoro della direzione sia svolto a loro vantaggio, solleveranno montagne. Ci vuole onestà. Ci vuole convinzione. Se ci si aspetta che le persone si comportino secondo uno standard più elevato, i loro leader devono esemplificare quello standard. Se vuoi che i tuoi collaboratori individuali siano rispettosi ed empatici, allora devi essere rispettoso ed empatico. Se vuoi che lavorino sodo, devi lavorare sodo. Coltiverai la cultura che meriti, non la cultura che desideri.

Finché la cultura non sarà fissata, le persone continueranno ad andarsene e il turnover continuerà a essere a livelli epici.

Se non lavorassi già con un team fantastico, lavorerei per te in un batter d'occhio.
@psaxton - Grazie, lo apprezzo.
Penso di avere una comprensione molto diversa delle "persone tossiche".Ai miei occhi c'è un'enorme differenza tra le persone che sono arrabbiate / si lamentano / criticano / ... e le persone che sono effettivamente tossiche per l'ambiente.Lavorare con i reclamanti può effettivamente farti fidelizzare e aiutarti a migliorare come organizzazione (o individuo) in modo sostanziale.Le persone effettivamente tossiche, tuttavia, (e ce ne sono poche) devono semplicemente essere rimosse.
@fgysinreinstateMonica: Se non puoi riabilitare una persona tossica o non sei disposto a investire lo sforzo necessario, allora - Sì, è assolutamente corretto.Se hai il lusso del tempo e un po 'di pazienza, una persona tossica può essere riabilitata e molte volte quella persona può essere restituita a una fonte di valore significativa.C'è anche la valutazione del valore di decidere se il valore alla fine vale l'investimento stesso.Il tentativo di riabilitazione vale più o meno che trovare un sostituto?Francamente, ci sono alcune persone per le quali quell'investimento non ripagherà.
gnasher729
2020-04-16 20:47:48 UTC
view on stackexchange narkive permalink

Occorrono 35 persone all'anno per mantenere 25 posizioni occupate.

Anche con il lavoro più noioso e insoddisfacente che si possa immaginare, alla fine dovresti ritrovarti con un gruppo di persone a cui non importa e che sono felici di arrivare la mattina, partire la sera e prendi i loro soldi alla fine del mese.

Non l'hai fatto. Ciò significa che il tuo lavoro non solo non attira le persone, c'è qualcosa che allontana attivamente le persone. Due capi che molestano sessualmente tutti senza eccezioni? Violenza reale sul posto di lavoro? Un cattivo odore in ufficio che mi fa pensare a persone morte sotto le assi del pavimento? Deve esserci qualcosa del genere. Il tasso di abbandono del 140% non è normale.

Ha un impatto sulla produttività? Quale produttività? Non mi aspetto affatto che ci sia alcuna produttività lì. Ci sono nuovi arrivati ​​che devono prima imparare l'ambiente e non c'è nessuno esperto che possa insegnar loro. Nessuna produttività da parte delle nuove persone e ridotta produttività da quelle non proprio nuove per quattro mesi. Quindi, quando sono quasi pronti per fare un po 'di lavoro, la generazione precedente se ne va e il gruppo successivo deve essere istruito. Una volta fatto, ne hanno avuto abbastanza e se ne vanno. Nessun lavoro è finito.

Hai del duro lavoro davanti a te. Direi che hai bisogno di otto o dieci veri professionisti con buoni stipendi che siano all'altezza, qualunque cosa accada. Devono avere mano libera per combattere contro qualsiasi ostacolo (ad esempio, se il CEO grida loro, per rimuoverlo fisicamente senza timore di ripercussioni). Con mano libera per prendere decisioni di sviluppo (nel caso tu abbia una gestione idiota che non può mantenere gli obiettivi invariati per una settimana)

35 persone per 25 posti non significa che stanno sostituendo TUTTI.Potrebbero facilmente avere un / i dipendente / i velenoso / i con una cattiva gestione.
@DarkMatter: Se non sostituiscono tutti ogni 8 mesi, sostituiscono metà del team ogni 4 mesi.Questo difficilmente lo rende migliore.
Mi aspetto che abbiano un nucleo di 6-12 dipendenti tossici, una gestione disfunzionale e le nuove persone impiegano 2-3 settimane per rendersi conto di quanto sia brutto questo e alcuni mesi per trovare un nuovo impiego.Quindi sì, "meglio" non è la parola giusta, ma probabilmente è quello che è.
Echox
2020-04-16 15:50:19 UTC
view on stackexchange narkive permalink

Anche se non esiste una risposta perfetta alla domanda "Cos'è un normale turnover con gli sviluppatori?" (varierà da azienda ad azienda e ognuno è diverso), direi che la maggior parte delle volte gli sviluppatori cercheranno di rimanere almeno 2 o 3 anni nella stessa azienda, se possono.

Sembra buono sul curriculum, hai il tempo per imparare l'argomento e costruire un buon rapporto con le persone. Dopo 2 o 3 anni, puoi cambiare lavoro per avere un bel aumento di stipendio e andare a lavorare su nuovi progetti con nuovi tecnici.

Se uno sviluppatore non rimane più di un anno, significa che qualcosa non gli stava bene. Partire così presto potrebbe danneggiare la sua carriera:

  • dovrà giustificare un soggiorno così breve in futuri colloqui.
  • sarà difficile usare questi pochi mesi di esperienza in qualsiasi trattativa salariale. Per quanto riguarda la carriera, è tempo perso.

Quindi direi che qualsiasi azienda con un fatturato inferiore a un anno fa le cose davvero, davvero male. Ma poi le risposte di Daniel e usr-local-ΕΨΗΕΛΩΝ danno spiegazioni migliori su questo argomento.

Esistono statistiche per il fatturato medio in un determinato campo.Potrebbe essere considerato "normale"
Dipenderà dal campo, dalle dimensioni dell'azienda, dall'esperienza delle reclute, dal paese ... Forse qualcuno troverà le statistiche del fatturato degli sviluppatori junior nelle banche di Toronto (che è proprio la situazione di OP) ma mi sento come la mia rispostasta dando una media abbastanza buona.
Se la media del settore è di circa il 15% e tu hai circa il 20%, puoi dire che è superiore al ** normale **, forse spiegato dalla differenza regionale o demografica o più probabilmente dalla cultura aziendale. Inoltre, dove hai scoperto che OP sta assumendo solo sviluppatori junior?
Intervenendo io stesso come sviluppatore .. Considero un periodo minimo di 2 anni in un'azienda.Le uniche volte che me ne sono andato prima di allora sono state quando l'azienda non poteva supportarmi (uno ha chiuso, l'altro ha esaurito il lavoro per me), gli unici altri motivi per cui me ne andrei prima è se fosse unambiente di lavoro veramente ostile o tossico, o se qualcosa è venuto fuori nella mia vita personale.
@Daniel Non è scritto ma ho fatto un'ipotesi sul fatto che le persone esperte abbiano più difficoltà a individuare le aziende tossiche ed evitarle.Inoltre, mi sento come se avessimo speso troppe parole nell'introduzione di una frase alla mia risposta.Non sei d'accordo con la stima di 2 o 3 anni?Vuoi aggiungere qualcosa?
@Echox Voglio votare questa domanda in quanto evidenzia la prospettiva dei dipendenti.Ma è semplicemente sbagliato dire che non c'è "normale" per la fluttuazione per quanto riguarda la mia comprensione della parola inglese come in (normale = conforme a uno standard; usuale, tipico o previsto). Direi anche che, sulla base dei dati empirici e dell'esperienza, 2-3 anni possono essere tipici per il primo lavoro, ma la media del settore è più compresa tra 5 e 7 anni.
d_hippo
2020-04-16 21:48:45 UTC
view on stackexchange narkive permalink

Se devi assumere 35 sviluppatori all'anno per ricoprire 25 posizioni, il tuo dev medio rimane per 8,6 mesi. Questo è, in effetti, follemente breve.

Tassi di fatturato come questo possono avere un enorme impatto sulla produttività. Ci sono diversi fattori che contribuiscono a questo:

  • A seconda della complessità del progetto e della sua esperienza, uno sviluppatore ha bisogno di qualcosa tra poche settimane e pochi mesi prima di raggiungere il suo massimo rendimento, perché deve ottenere abituato alla base di codice esistente, allo stile di programmazione dei suoi collaboratori, agli standard aziendali, ai componenti esterni e alle cose in quanto tali. Per semplificare la matematica, supponiamo che l'onboarding richieda 2 mesi e uno sviluppatore rimanga per 8 mesi. In 2 anni, sono 6 mesi di onboarding. Avresti risparmiato 4 mesi di onboarding se fosse rimasto 2 anni.
  • Anche il resto del team deve abituarsi al nuovo sviluppatore. Ciò include tutto ciò che devi sapere per motivi di gestione del progetto: quanto è veloce? Quanto è competente? Comunica bene? Ha esigenze particolari? Senza tutte queste informazioni, la gestione del progetto sarà basata su presupposti traballanti.
  • Un turnover elevato amplifica alcuni tipici problemi di sviluppo del software, come processi scadenti o documentazione scarsa. Se tutti sanno cosa ci si aspetta da lui e hanno familiarità con la base di codice comunque questi punti sono ancora importanti, ma su di essi puoi scendere a compromessi. Se lo fai in un ambiente ad alto turnover, ciascuno dei tanti nuovi sviluppatori sprecherà molte, molte ore del suo (e altri!) Tempo, cercando di capire come funziona tutto e cosa deve fare esattamente.
  • La conoscenza si perde e quindi deve essere riacquistata. "Oh, hai bisogno di sapere come integrare X e Y? Beh, Dave l'ha fatto 2 anni fa, ha scavato nelle specifiche per un mese. Se ne è andato, e così hanno fatto tutti quelli con cui ha parlato di questo. rifallo. Qui puoi trovare le specifiche ... ".
  • È molto più difficile trovare processi che funzionino per il tuo team, perché il tuo team è una cosa molto volatile.

L'altra parte della tua domanda, ovvero "Qual è il normale tasso di turnover tra gli sviluppatori", è molto più difficile da rispondere. Quindi farò una sorta di sfida ai fotogrammi: non chiedermi cos'è un tasso normale, chiediti quale vuoi che sia il tuo tasso e come ottenerlo. La tua azienda è diversa da ogni altra azienda, quindi la tua risposta potrebbe differire dalla norma. Ci sono anche alcune rare circostanze in cui un alto turnover non è affatto un problema.

mpasko256
2020-04-17 00:23:21 UTC
view on stackexchange narkive permalink

Avviso! È principalmente basato sull'opinione. Può essere soggetto a pregiudizi di "prove aneddotiche" sulla base delle mie esperienze e delle mie conoscenze. Presupposti più oggettivi sono nella sezione "riepilogo".

Vorrei pubblicare una risposta da un punto di vista totalmente opposto.

Hai detto che si tratta di una banca o altro istituto finanziario. È abbastanza normale che possano avere un ambiente di lavoro tossico e possano avere un grande turnover. Quello che offrono in cambio è uno stipendio leggermente più alto. Non so perché Forse alcuni bankster hanno ancora la mentalità corrotta di poter ottenere tutto con il denaro, o semplicemente l'attività bancaria è così redditizia.

Racconterò un po 'della mia storia. Lavoro nel settore bancario da un breve periodo (solo 4 mesi). È stato poco dopo gli studi perché hanno reclutato studenti attraverso una sorta di mercato della carriera organizzato nella mia università.

Posso dire che lo stipendio era piuttosto impressionante ma non offriva una posizione dove ho potuto sviluppare le mie capacità come volevo e l'ambiente era un po 'tossico. Mi ha fatto cambiare i miei piani. Ho deciso di trovare un lavoro con uno stipendio più basso ma maggiori opportunità per imparare nuovi strumenti / tecnologie di programmazione e per un ambiente di lavoro amichevole.

Ma alcuni dei miei amici sono rimasti fermi in quell'azienda e gli è piaciuto. Hanno apprezzato lo stipendio e si sono semplicemente abituati a un posto di lavoro stressante.

Ho anche incontrato alcune persone che hanno cambiato lavoro dalla mia azienda presente a quella passata e a loro piace di più. È incredibile, ma ognuno ha le proprie preferenze personali con cui è difficile discutere.

Riepilogo

Per riassumere, un alto turnover potrebbe non essere un male cosa a determinate condizioni:

  • Assumono un carico enorme di giovani lavoratori, principalmente neolaureati.
  • Hanno un efficiente processo di onboarding e tutorial aggiornati e pronti per l'uso. Di solito i lavoratori che hanno lavorato per un tempo medio-breve e sono freschi formano solo colleghi più giovani reclutati. I Veterani restano concentrati sui propri compiti importanti. Sono infastiditi solo quando necessario.
  • La maggior parte dei lavoratori che hanno lasciato l'azienda sono persone che lavorano lì da meno di un anno.
  • Le persone che si adattano a un ambiente di lavoro specifico rimangono lì per anni.
  • Le persone che hanno acquisito una conoscenza specifica e importante del dominio / aziendale di solito rimangono in azienda. Di solito sono motivati ​​da aumenti / promozioni più elevati.
Uh ... quindi sei * solo * nel mondo del lavoro e hai esperienza con * una banca in particolare * - e sei disposto a pronunciare giudizi non solo sui lavori bancari in generale, ma che le persone che accettano quei lavori devonoessere motivato dall'avidità.Geez.Mia moglie lavora in una banca ed è l'atmosfera più rilassata che ci sia.Ho amici che lavorano nella programmazione nelle banche e dicono che sia una cultura piuttosto "squallida / noiosa".
Sono d'accordo con @Kevin in quanto le organizzazioni Fintech variano notevolmente nei loro ambienti e culture.Alcuni sono estremamente rilassati e sono davvero ottimi posti in cui lavorare.Altri sono carri armati di squali.
Buah, ho lavorato in diversi settori e sicuramente non descriverei il settore bancario come il peggiore.È anche difficile generalizzare cose come la cultura.Una volta ho lavorato nella stessa azienda in due paesi e la cultura era molto diversa (conosco i due paesi abbastanza bene da sapere che le differenze nelle culture aziendali non erano basate sulle differenze culturali tra i paesi).
joojaa
2020-04-17 14:00:53 UTC
view on stackexchange narkive permalink

Considera che hai una discrepanza tra ciò che chiedi alle persone di fare e il modo in cui assumi e fai le cose. La tecnologia non è di regola una scienza morbida. Se lo chiedi all'impossibile, le persone smetteranno. Quindi assicurati che:

  1. che le aspettative riposte sui tuoi sviluppatori siano realistiche.
  2. Che i tuoi dipendenti abbiano abbastanza tempo per eseguire queste attività.

Ciò che le persone non abituate al lavoro tecnico non capiscono è che: niente può effettivamente prepararti esattamente per il lavoro che devi fare. Tranne fare quel lavoro. Ora, è molto difficile valutare quanto tempo avresti bisogno per diventare produttivo. Ma è anche difficile svolgere un compito che è infinitamente grande dal tuo punto di vista.

Quindi è molto importante che tu abbia effettivamente uno sviluppatore senior il cui compito è dividere le attività in parti gestibili. E sembra davvero che tu abbia perso tutto il tuo talento di coordinazione, quindi non c'è nessuno a portare le nuove persone al passo con i tempi.

La soluzione probabilmente non è aumentare il numero di persone, ma diminuirlo. Non puoi semplicemente pompare nuovi sviluppatori a un ritmo infinito. Renderanno semplicemente impossibile a quei pochi che potrebbero lavorare efficacemente di lavorare in modo efficace.

Un altro può essere costantemente sopraffatto cambiando ambito. I lavoratori devono sapere che stanno facendo qualcosa. Quindi devono essere in grado di prendere un pezzo di lavoro e fare quel pezzo di lavoro. Avendo fatto il pezzo deve essere riconosciuto.

Solo perché il blocco è ora considerato obsoleto non è colpa dei lavoratori. È colpa della leadership. Il lavoratore ha raggiunto il pezzo che si era prefissato di fare e dovrebbe essere corretto. Ad esempio: non è colpa dei pittori se il muro dell'ufficio è verde quando gli hai chiesto di dipingere di verde. Anche se dopo aver iniziato a dipingere potresti aver deciso che dovrebbe essere rosa. Painter può eseguire solo su cose che sono state concordate. Anche così puoi tirare il tappeto sotto la persona solo tante volte.

Le persone possono andarsene semplicemente perché il tuo processo non funziona.

Neville Kuyt
2020-04-23 13:54:04 UTC
view on stackexchange narkive permalink

Ho lavorato in una serie di aziende, in diversi paesi; nella mia esperienza, gli sviluppatori in genere si aspettano di rimanere in un ruolo per 2-3 anni; poi cercano una promozione o se ne vanno. Nella maggior parte delle aziende in cui ho lavorato, questo sembrava portare a un tasso di turnover annuo intorno al 20%; potremmo ridurlo aumentando le ricompense finanziarie, migliorando le opzioni di sviluppo della carriera e trovando progetti interessanti su cui lavorare.

Le eccezioni erano le aziende con un problema culturale: come altre risposte hanno suggerito, tu hai una cultura problema.

Hai anche un problema di circolo vizioso.

  Il senior management ha aspettative elevate, forse irrealistiche. Esercitano pressioni sul middle management affinché soddisfi tali aspettative. prova quello che possono; aggiungendo più sviluppatori (andando così a sbattere contro la legge di Brooks), e poi gridando. Urlare porta a un abbassamento del morale tra il team. Un morale ridotto riduce la produttività: le persone infelici non lavorano così duramente. La crescita del team porta a una riduzione della produttività attraverso gli sforzi di reclutamento e la legge di Brooks. La produttività ridotta aumenta ulteriormente il divario tra aspettative e output.  

Sciacquare e ripetere ...

Rompere questo ciclo è incredibilmente difficile. Questo tipo di ambiente crea incentivi per le persone a investire in politica, piuttosto che nella realizzazione: la strategia di sopravvivenza diventa "non essere incolpato per risultati negativi", piuttosto che "lavorare per creare buoni risultati".

È non abbastanza per fermare le urla (necessario, ma non sufficiente) - la squadra continuerà a rispondere agli incentivi e se ne andrà se non gli piace l'ambiente. Gli sviluppatori di Toronto hanno molte opzioni.

Il primo passo è ottenere il consenso del senior management che hai un problema e che continuare a fare ciò che stai facendo non farà sì che il progetto si risolva magicamente da solo. I problemi culturali e i circoli viziosi di solito hanno bisogno degli alti dirigenti per guidare il cambiamento: il più delle volte, definiscono la cultura e hanno le leve da tirare per rompere il circolo vizioso.

Il modo migliore per me Sapere di rompere il circolo vizioso è trovare un modo per ristabilire le aspettative e portare agli sviluppatori un obiettivo raggiungibile. Ho ereditato una situazione come questa una volta e abbiamo convenuto che, anziché preoccuparci dell'intero ambito del progetto di 18 mesi, avremmo scelto un orizzonte temporale di 3 mesi e concordato cosa avremmo potuto fare in quel lasso di tempo. Abbiamo negoziato una serie di prodotti "must / should / won't" tra la direzione e gli sviluppatori e abbiamo concordato modi per risolvere i problemi sollevati dagli sviluppatori ("i requisiti non sono abbastanza buoni", "non riceviamo mai feedback utili" "l'ufficio è troppo rumoroso") ecc. Abbiamo utilizzato questo mini progetto di 3 mesi per ripristinare la cultura e ricostruire un po 'di fiducia.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...