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

[...] 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.

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?

È 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.

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)

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.

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.

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.

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.

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.