Motivare gli sviluppatori in un progetto percepito come noioso?

Per i progetti in modalità di manutenzione, pensa a cosa verrà dopo. Cosa li renderà poco interessanti per i tuoi clienti? Per evitare l'obsolescenza, hanno bisogno di nuove funzionalità, prestazioni migliori o di essere semplificati? Se ricomincia, alcuni progetti possono essere unificati? Dovrebbero essere costruiti con strumenti, linguaggi o processi diversi? Ci sono miglioramenti o indicazioni che nessuno ha considerato? Chiedi ai tuoi sviluppatori di rispondere ad alcune di queste domande. Costruisci prototipi. Prova una nuova lingua o struttura. Offri a un progetto una nuova interfaccia mobile.

È più facile sperimentare alternative quando non c'è una scadenza incombente. Usa i tempi noiosi per mettere fuori strada i tuoi concorrenti.

Devi offrire loro qualcosa per occupare il loro tempo. I progetti in modalità di manutenzione spesso non richiedono 40 ore settimanali da ogni sviluppatore. Se lo fa, probabilmente c'è qualcosa di sbagliato nel software, ma in base al modo in cui hai posto la domanda, suppongo che tu stia cercando un'idea per occupare i tuoi sviluppatori mentre non c'è molto da fare. Non so qual è il tuo budget finanziario, ma penso che alcuni incentivi come inviarli a una conferenza software potrebbero essere utili. Un altro suggerimento potrebbe includere esplicitamente permettendo loro di esplorare i propri interessi per dire 15 ore a settimana. Qualcuno potrebbe essere interessato all'esplorazione di algoritmi di ordinamento o progettazione di database. Potrebbe non essere direttamente correlato alla tua attività, ma non posso immaginare che non trarrai beneficio dalla loro maggiore conoscenza alla fine. Basta non costringerli a lavorare senza niente da fare. Consenti loro di occupare il loro tempo con qualcos'altro se non c'è molto lavoro da fare. Penso sia giusto chiedere un riassunto di ciò che stanno facendo per assicurarci che non stiano semplicemente navigando nel web casualmente, ma permettano loro di esplorare un po '.

Divertiti a lavorare sul progetto.

In realtà i progetti interessanti sono piuttosto rari. E gli studi dimostrano che la felicità dei dipendenti dipende in gran parte dal sociale e dal divertimento. Menzionano in modo massiccio colleghi quando viene loro chiesto perché non lascerebbero il lavoro attuale.

Ecco perché dovresti essere sempre felice quando senti ridere nel tuo edificio invece di urlare.

Per me, il miglior motivatore in questa situazione sono obiettivi molto chiari, specialmente sotto forma di una buona specificazione. O, piuttosto che meglio, è una delle poche cose che hai lasciato da offrire. Il ragionamento è che se il lavoro in sé non è interessante, sapendo che sarò rielaborare un mucchio di cose noiose è un enorme demotivatore. Ciò può tuttavia dipendere dal fatto che il programmatore riconosce chiaramente il valore di una specifica.

Devi cambiare la percezione del progetto "noioso". Se genera reddito sano, non può essere molto difficile da fare.

Spesso, questi progetti fanno bene ai programmatori che sono mediocri e sono contenti di essere mediocri. Sai, le persone che non sono appassionate di programmazione e che la vedono solo come un modo per pagare le bollette. Ora, capisci qualcosa: non sto dicendo questo perché sono programmatori più deboli e tu vuoi rendere le loro vite miserabili. Dico questo perché di solito sono i tipi di persone che semplicemente non si aspettano che il loro lavoro sia una fonte di realizzazione nelle loro vite. Dai suoni di ciò, questi suoni come bassa pressione, flussi di reddito costante. Più che probabile, questi lavoratori sono più che felici di fare un lavoro facile, a bassa pressione.

Ovviamente, questo non significa che puoi semplicemente dare loro compiti noiosi e dimenticarti di loro. Forse potresti dare ai tuoi "A giocatori" un 80% di compiti divertenti / 20% di compiti noiosi, i tuoi "giocatori B" potrebbero essere 50/50 e i tuoi "giocatori C" potrebbero essere 20/80.

Lascia che i tuoi sviluppatori guadagnino tempo a pagamento lavorando sui propri pet / progetti open source / interessanti facendo un po 'di lavoro. Offri loro un certo sostegno con questi tipi di progetti, specialmente se il lavoro è su un progetto o un programma interno. Questa è una strategia che Google usa, credo?

Devo ammettere che non ho mai lavorato a un progetto noioso e poco interessante, quindi non sono sicuro di capire la tua domanda. E sviluppo sistemi aziendali per vivere. :) Scherzi a parte, in pratica ho scoperto che i programmatori sono infastiditi dal lavoro "noioso" molto meno di quanto mi aspettassi. Lavoro inutile, come compilare i fogli di lavoro che nessuno controlla mai è un problema molto più grande. Detto questo:

Conosci le preferenze dei tuoi programmatori; alcuni programmatori non amano la GUI, alcuni si allontanano da SQL. Cerca di rispettare queste preferenze, dal momento che un'attività noiosa per un programmatore potrebbe essere divertente per un'altra. Se non è possibile dividere il lavoro in alcun modo, per qualsiasi ragione, rendilo interessante aumentando la competizione - permetti loro di competere chi sarà il primo a finire la sua parte, o di fare un tabellone con la parte del codice che ha la minima quantità di bug in QA. Microsoft è nota per la sua cultura aziendale, che fa sì che i programmatori competano su approcci diversi e scelgano il migliore alla fine o incorporino le parti migliori di ciascun approccio nel prodotto finale.

Possedere una parte del prodotto e avere il controllo su di essa aumenta drasticamente il proprio impegno. Al contrario, non c'è niente di più noioso che avere qualcuno che gestisce il tuo lavoro. Inoltre, se c'è un compito ricorrente che tutti odiano, spiegando il quadro più ampio - che è qualcosa che deve essere fatto e perché e la rotazione della persona che lo fa ogni settimana è in genere più che sufficiente.

Ho avuto / visto successo nell'usare questo tipo di progetto come percorso per i più interessanti.

Se i tuoi sviluppatori di nuovi e di medio livello iniziano tutti i progetti "noiosi", ponendo domande agli sviluppatori senior (che si trovano negli altri progetti la maggior parte del tempo) e chiarisci che il meglio è nella manutenzione più probabile sarà il coinvolgimento futuro nel nuovo lavoro, quindi, presumendo di avere una squadra decente e in effetti seguire occasionalmente il cambio di squadra e coinvolgendo di tanto in tanto i principali sviluppatori sul nuovo lavoro, i team si allineeranno.

Se hai una squadra cattiva o un ottimo team questo approccio potrebbe non funzionare per te.