Nel mio studio di questa situazione, ci sono altri problemi, problemi reali che devono essere esaminati. Le persone semplicemente non si demotivano per aver lavorato 2+ anni allo stesso progetto, si demotivano quando si sentono

• Non sono apprezzate
• Il loro lavoro non è valutato
• La loro opinione non è apprezzata
• Non vedono alcuna opportunità di crescita per la loro carriera personale e professionale

ecc.

Dato che sei il manager in carica , esegui tu stesso quanto segue o segnala / delega in modo che qualcuno abbia il diritto di farlo:

1. Organizza un incontro formale 1: 1 con gli ingegneri demotivati. Ascolta i loro problemi / reclami.
2. Chiedi loro come pensano che i problemi possano essere risolti senza spostarli fuori dai compiti attuali.
3. Pensa e rifletti.

Qualche suggerimento su come posso motivarli?

Gli hack days sono un ottimo modo per motivare gli sviluppatori. Una volta al mese consenti al team di trascorrere il giovedì pomeriggio lavorando a un progetto di hacking. Chiedi al tuo capo un budget per comprare birra e pizza.

Inizia facendo un brainstorming di idee su R&D, quale nuova tecnologia vogliono provare? quale cosa interessante potresti costruire con le tue abilità combinate?

All'inizio i giorni di hacking possono servire semplicemente come strumento di motivazione. Gli sviluppatori sanno che una volta al mese si mettono a lavorare su quel fantastico progetto secondario. Ma col tempo questi progetti potrebbero trasformarsi in prodotti fattibili che la tua azienda potrebbe utilizzare o vendere.

Essendo io stesso un cercatore di posti di lavoro, posso testimoniare dei motivi per cui la mia motivazione diminuisce quando sono nello stesso progetto per molto tempo. Questo di solito ha poco a che fare con la retribuzione o il riconoscimento del mio lavoro:

• Lavorare nello stesso progetto per molto tempo manca di opportunità di apprendimento . C'è molto da imparare dal cambiamento: impari come i progetti sono diversi e come non lo sono, impari ad adattare diversi team e tecnologie, hai la possibilità di imparare da più persone e più situazioni. Ogni tanto un biscotto nuovo mi piace, sfida la mia capacità di apprendere, si aggiunge al mio CV, mi fa sentire meglio con le mie capacità. Questo di solito è il problema principale da risolvere.
• I progetti di lunga durata non sono nuovi e brillanti. La loro tecnologia resta indietro. Il loro codice diventa grande e legacy. I loro compiti diventano ripetitivi.

Questo è il motivo per cui, a parità di condizioni, molte persone apprezzano il cambiamento per il gusto di farlo. Alcuni più di altri, e tu sei impotente su questo.

Se qualcosa dovrei prendere sul serio ciò che hanno detto, considera che cambiare loro progetti potrebbe essere meglio che perderli (o potrebbe non esserlo). È probabile che ciò accada, perché i tuoi sviluppatori potrebbero non essere contenti da molto tempo e potrebbero già cercare altrove.

A parte correzioni temporanee come inviarli a meetup o altri approcci "giocosi":

Quelle persone hanno bisogno di un nuovo progetto, punto. Presumibilmente sono persone tecniche molto intelligenti, a cui piace giocare con la tecnologia ei progetti. Niente che puoi fare in modo fattibile lo cambierà (e non vuoi cambiarlo comunque). Se gli dai sempre le stesse cose da fare, si annoiano e non importa cosa fanno.

Se non trovi una soluzione, lo faranno, il che significa andando in un'altra azienda. Almeno nel mio paese (e non so dell'India), questa è una forte motivazione per il top management a sostenere regolarmente il passaggio di persone tra i progetti. Perdere un dipendente stimato solo perché tu (non tu personalmente, ma la direzione) non sei riuscito a fornire loro un lavoro interessante è semplicemente vergognoso per l'azienda e può essere risolto con una politica attiva di guardare a questo regolarmente.

Quindi, prendi questo "di sopra" e vedi se riesci a inserirli in altri progetti. Se non puoi e non sei effettivamente il manager, almeno ci hai provato.

Se ricontrollo i motivi per cui ho intrapreso nuove sfide, ecco i motivi e cosa avrebbe dovuto cambiare per farmi restare:

• Usare un vecchio stack che non sono mai state modernizzate in alcun modo. Non c'era niente di nuovo da imparare, il che significa la morte per la carriera di uno sviluppatore.
  • Cosa avrebbe dovuto cambiare: migrare a uno stack più moderno per mantenerlo interessante e risolvere problemi tecnici e limitazioni del vecchio sistema.
• La regressione dall'utilizzo di uno stack molto interessante e moderno che ho imparato a fondo durante il lavoro, a un mucchio di eredità utilizzando una tecnologia obsoleta dopo che il progetto che utilizzava lo stack interessante è stato cancellato per motivi non tecnici.
  • Che cosa avrebbe dovuto cambiare: migrare a uno stack più moderno per mantenerlo interessante e risolvere problemi tecnici e limitazioni del vecchio sistema.
• Durante le interviste bugie sfacciate su di cosa tratta il lavoro e quale stack viene utilizzato la maggior parte del tempo. Non assumeresti un autista di Main Battle Tank per guidare un autobus di una piccola città aspettandoti che sia felice.
  • Cosa avrebbe dovuto cambiare: usa lo stack che mi hai assunto per lavorare sopra. Uno sviluppatore! = Sysadmin, il lavoro è completamente diverso.

Penso che vedrai uno schema qui :) La vita di uno sviluppatore è incostante, poiché devi sempre imparare nuove tecnologie se vuoi rimanere occupabile. Nel momento in cui smetti di imparare cose nuove, affonderai. E se rimani in un progetto che utilizza una tecnologia obsoleta, sei quasi morto se rimani più di 1-2 anni prima di passare a un nuovo lavoro che coinvolge la tecnologia moderna.

Io stesso sono incline a questo problema. Mi ritrovo facilmente demotivato a causa della noia. Il motivo per cui sono rimasto più a lungo nella mia ex azienda era perché mi tenevano sfidato ed ero libero di esplorare cose nuove. Ecco alcuni suggerimenti:

• Hack days
• Chiedere agli ingegneri di esplorare nuove cose che contribuiscono indirettamente allo sviluppo. Se non hanno già configurato la pipeline CI / CD, chiedi loro di lavorare su quella
• Rotazione dei ruoli. Inseriscili nell'assistenza clienti per 1 settimana o 1 sprint. Possono imparare cose nuove, l'azienda beneficia della loro esperienza ritrovata di lavorare direttamente con i clienti.
• Sfidali ad essere l'ambasciatore dell'azienda. Chiedi loro di parlare in pubblico, condividere le conoscenze tra i diversi reparti e iniziare a farlo internamente.

Nel progetto che guido, ho suddiviso i compiti e ho utilizzato un ciclo di sviluppo a spirale.

Le attività erano piccole in modo che ogni sviluppatore potesse avere un senso di realizzazione.

Le attività sono state ordinate in pietre miliari. Ogni pietra miliare per mostrare qualcosa di tangibile, ad esempio, ottenere una stampa "Hello World" su un dispositivo incorporato (questo è stato utilizzato per far funzionare l'ambiente di sviluppo). Il prossimo traguardo sarebbe un sistema di comando tramite una porta di debug. Il terzo traguardo potrebbe essere una funzionalità minima (o un test del dispositivo hardware).

Le pietre miliari sarebbero i punti di controllo del progetto. Potremmo utilizzare le pietre miliari per mostrare alle parti interessate i progressi che stavamo facendo. Il modello di sviluppo a spirale ci ha permesso di adattarci ai requisiti di cambiamento o sviluppo (in pratica, l'unica garanzia è che i requisiti cambierebbero).

Questo ha dato agli sviluppatori un senso di responsabilizzazione e responsabilità. Se il compito era troppo per loro da gestire, erano o allenati da un mentore o il compito era diviso in più parti (potevano anche scegliere un compito diverso, forse più semplice).

Quindi, per una data pietra miliare, gli sviluppatori hanno scelto i compiti che volevano.

Dopo che il prodotto è maturato, si è sviluppato un database di difetti. I difetti sono stati assegnati agli sviluppatori in base alla priorità del difetto, all'area di competenza o per fornire allo sviluppatore la conoscenza in un'area diversa del codice.

Abbiamo molti progetti, quindi alcuni sviluppatori sono passati a compiti diversi dopo circa 2 anni, per fare qualcosa di diverso.

Organizza un incontro con ogni sviluppatore. Scopri quali sono i loro interessi.

Suddividi i progetti in piccole attività.

Consenti agli sviluppatori di scegliere le attività, in base ai loro interessi (non necessariamente alla loro esperienza).

Preparati a perdere sviluppatori a causa dell'attrito, poiché questo è normale.

Sono d'accordo con la risposta di Sourav Ghosh. Tuttavia, vorrei aggiungere alcune cose.

Sono uno di quegli sviluppatori che possono annoiarsi quando si lavora sulla stessa cosa per lunghi periodi di tempo e / o si sbatte la testa contro un muro cercando di portare a termine le cose.

sbattere la testa contro un muro cercando di portare a termine le cose

Intendo questo nel senso di:

• In passato ho cercato di ottenere la gestione sistemi acquisiti / installati / utilizzati almeno per la parte di sviluppo, es controllo delle versioni, sistemi di gestione dei ticket, ecc. Dopo mesi, è stato fatto, mentre la necessità di base è estremamente ovvia. Per me, questo è un grande demotivatore
• Avvio di processi per condividere informazioni, ad es memorizzare documentazione / informazioni in sistemi come Confluence, ottenere stand-up quotidiani

Ci sono ovviamente fattori aggiuntivi, come i colleghi e l'interazione. Soprattutto, è personale per ogni individuo.

ci si annoia quando si è sulla stessa cosa per lunghi periodi di tempo

Secondo me, questa è una delle cose più facili a cui rimediare. Inoltre, è personale ed è qui che entra in gioco la risposta di Sourav: chiedi ai tuoi sviluppatori!

Cose semplici che possono essere fatte per aiutare a rimediare alla noia:

• Vai ai meetup! Forse la cosa più semplice. I tuoi sviluppatori possono discutere, con persone che non conoscono, delle tecnologie utilizzate da ciascuno, dei metodi e dei processi, dei progetti su cui stanno lavorando, ecc. Ecc. Questo è divertente e condivide le conoscenze, qualcosa che gli sviluppatori amano fare. Inoltre: apporta ulteriori conoscenze in (!) all'azienda
• Organizza meetup! Wow, al contrario. Sì, costerà denaro (gli sviluppatori adorano la pizza), ma se lasci che gli sviluppatori se ne occupino, darà loro qualcosa che è correlato al lavoro, ma non la loro routine quotidiana (sì, dopo 2,5 anni, un il progetto è una fatica)
• Avere hackaton interni (e possibilmente organizzati come un meet-up)! (pizzaaahh !!) Pensa a un tema, ordina la pizza. Partire. Potrebbe non produrre qualcosa di grande valore, ma è divertente, nuove tecnologie vengono provate, ecc. Ecc.
• Cambia un po 'i team. Se hai alcune isole all'interno dei tuoi sviluppatori, ad es. quel ragazzo fa devOps, quelli sono back-end, quelli 2 sono front-end, accendili un po '. Condividi compiti / responsabilità. Spingere verso tutti almeno capendo tutto (diverso dal poter fare tutto). Potrebbe rallentare un po 'lo sviluppo, ma promuove l'apprendimento e la condivisione delle conoscenze.
• Se il tuo datore di lavoro si sente generoso, ruba un'idea da Google e dedica del tempo settimanale a progetti di sviluppo personale, ad es. ogni mercoledì pomeriggio, a partire da 2 ore prima dell'orario di chiusura, tutti gli sviluppatori non lavorano su progetti di lavoro, ma sui propri. Dipende dalla tua azienda se quei progetti debbano essere o meno qualcosa che l'azienda potrebbe in seguito anche trarre profitto, puro auto-miglioramento per gli sviluppatori o completamente non correlato (ad esempio lavorazione del legno o qualsiasi cosa sia possibile in ufficio)

Alcune idee. Potrebbe non aiutarti completamente, ma sicuramente alcune di queste cose sarebbero possibili, divertenti per i tuoi sviluppatori e porterebbero variazione nella routine che è il lavoro.

In un progetto di lunga durata, è probabile che ci siano processi che possono essere automatizzati o altri lavori ripetitivi che possono essere refactoring. Prenditi del tempo per affrontare problemi come questi, anche se non sono requisiti diretti.

Sono divertenti da lavorare, semplificano la vita di tutti e faranno risparmiare tempo durante la vita del progetto.

E sono molto più facili da vendere alla direzione che un "giorno di hacking".

Lavorare su un vecchio progetto spesso non è così interessante come creare qualcosa da zero. Alcuni dei motivi potrebbero essere:

1. Lo stack tecnologico è diventato vecchio e gli sviluppatori vogliono lavorare e imparare nuove tecnologie.
2. Il progetto è troppo grande ed è diventato difficile da mantenere.
3. Il prodotto è veramente maturo e non c'è molto da fare oltre alla semplice manutenzione. Questi lavori possono essere ripetitivi.
4. Vogliono semplicemente fare qualcosa di nuovo.

Parla con il tuo team per trovare il motivo. In base ai motivi per cui puoi provare,

1. Migra il progetto a tecnologie più recenti.
2. Suddividi il progetto in microservizi.
3. È possibile ruotare i ruoli un po 'per poco tempo? Questo potrebbe ravvivare le cose se il lavoro è molto ripetitivo. Assicurati che gli sviluppatori siano d'accordo con i nuovi ruoli.
4. Puoi provare a fare qualcosa di nuovo con il processo di sviluppo interno. Se CI / CD non è ancora implementato, implementalo.

Nel nostro team, ci sono 3-4 sviluppatori che partecipano a questo progetto negli ultimi due anni e mezzo.

Questi sviluppatori sono altamente demotivati ​​e questo sta davvero influenzando il loro lavoro. Personalmente penso che possano fare meglio di quello che stanno facendo attualmente.

Hai un manager a cui riferire? Sono sicuro che non sei tu quello che riferirebbe direttamente al CEO / CTO. Quel manager ti chiede delle prestazioni della squadra? Se sì, allora organizza un incontro con gli sviluppatori e il manager. Decidi su quali tecnologie le persone vogliono lavorare.

A volte l'azienda ha un prodotto duraturo e non è sempre possibile dare a tutti sempre nuovi progetti.