I processi del mio team sono fuori controllo?

Sono un caposquadra di sviluppatori di software (di recente ho preso il controllo di un nuovo team) e, in ultima analisi, sono responsabile del mantenimento di alta produttività, buona qualità e priorità organizzate.

Ho 6 sviluppatori senior nel mio team, ma qui le cose sembrano un casino. La situazione è che ho a che fare con le richieste JIRA provenienti da circa 10 diversi punti di contatto nella nostra azienda e che rappresentano tutti le diverse unità aziendali o clienti.

Il problema che ho è che il mio lavoro consiste principalmente nello spegnere gli incendi tutto il giorno e nell'assicurarmi che tutti i problemi vengano risolti. Sfortunatamente, la cultura della nostra azienda è stata alta produttività (versioni veloci) ma bassa qualità (bug di produzione) e i nostri clienti non accetteranno un improvviso ritardo nei risultati.

Quali sono alcuni buoni modi per gestirlo? Ho tonnellate di teorie, ma sto cercando una risposta da qualcuno che ha effettivamente un'esperienza lavorativa in una situazione come la mia.

Ecco un piccolo elenco di come funzionano le cose:

• Ogni sviluppatore è responsabile di un'applicazione e servizi specifici che interagiscono con essa;
• Le versioni vengono in genere testate dal client in un server di produzione simulato e quindi distribuite sul server live;
• Ogni applicazione è utilizzata da una media di 50-80 persone, con 8 applicazioni in totale.

Grazie

i nostri clienti non accetteranno un improvviso ritardo nei risultati

Bene, allora devono accettare la scarsa qualità che stanno ottenendo.

Quello che dovete fare per cambiare questo è ottenere i vostri clienti ad accettare la realtà dello sviluppo del software (o di qualsiasi altra produzione!): Che fretta le cose influisce negativamente sulla qualità.

Crea un grande elenco delle cose che vanno male - delle cose rotte, delle volte in cui hanno avuto motivo di lamentarsi. Spiega loro il motivo di questi problemi e dì loro cosa vorresti fare per cambiarlo. Assicurati di spiegare loro la percentuale di tempo che il tuo team impiega a supportare e correggere applicazioni live. Se non stai raccogliendo i dati su questo, ora è il momento di iniziare (e raccoglierli per un mese prima di presentare le informazioni ai clienti).

Porta gli stakeholder chiave in una stanza e dì: "vuoi X riparato o vuoi Y consegnato? Abbiamo solo tempo per uno dei due". Assicurarsi loro responsabile della definizione delle priorità, e essere chiaro che si hanno limitato la capacità. Se chiedono qualcosa di nuovo, chiedi loro cosa sono disposti a sacrificare dalla loro attuale tabella di marcia per raggiungerlo.

Chiedi al tuo team il tempo e le risorse di cui hanno bisogno per "sistemare le cose" (sia in termini di correzione dei bug di base, sia in termini di risoluzione di problemi più grandi in termini di qualità del codice / architettura / ecc.). Includere quegli elementi nell'elenco delle cose che le parti interessate devono dare la priorità.

La cosa migliore che abbia mai fatto nel mio attuale lavoro è stata quella di mettere contemporaneamente i primi 8 stakeholder in una stanza e disporre una pila di 16 schede indicanti le nuove funzionalità richieste. Ho fatto un passo indietro dal tavolo e ho detto: "possiamo consegnare uno di questi alla volta. In quale ordine li vuoi?" Lascia che discutano a vicenda sulla priorità aziendale invece che rimanere bloccato nel mezzo.

Stop, drop and roll. Gli incendi hanno bisogno di carburante e spesso si presenta sotto forma di panico. Dedica del tempo a gestire te stesso e il team in ordine. Valuta i tuoi sviluppatori e vedi se ne hai qualcuna che non è abbastanza abile e / o non lavora abbastanza per produrre i risultati desiderati. Decidi chi resta (e fai uno sforzo per tenerli), chi ha bisogno di una piccola spinta, il resto deve andare. Valuta il supporto e gli strumenti che i tuoi programmatori stanno ottenendo per assicurarsi che possano fare il loro lavoro. Assicurarsi che siano seguiti test audio, revisione, controllo del codice sorgente e documentazione. Le brave persone con buoni strumenti devono essere responsabili per fare un buon lavoro.

Deve esserci un sistema per sapere cosa deve fare il tuo team, su cui sta attualmente lavorando e quando si aspettano di essere completato. Molte metodologie, teorie, software, lavagne a secco e bigliettini, documenti ed e-mail per farlo. Fai funzionare qualcosa facendo in modo che tutti si attengano ad esso. Se tutti hanno qualche input nel sistema, c'è più incentivo a seguirlo.

Comprendi meglio cosa si aspettano i clienti. Questo potrebbe non far parte del tuo lavoro. Potrebbero esserci altri individui che fanno finta che i loro capelli siano in fiamme, i loro clienti sono infelici e il cielo sta cadendo. È quello che fanno e alcuni sono davvero bravi. Se tutto è un'emergenza, allora niente è un'emergenza perché non sarà tutto fatto. Offri di partecipare a discussioni con i clienti occasionali. Scoprirai che molti "simpatici" si trasformano in "rompiscatole" quando arrivano al team di sviluppo. Sii il liason tecnico o qualche altra scusa per dare una mano. Fare promesse che non puoi mantenere è peggio che dire loro quello che non vogliono sentire in primo luogo. Vogliamo fare un buon lavoro, quindi abbiamo bisogno di 8 settimane e non di 5. Saranno più felici a lungo termine.

In definitiva, devi educare i tuoi clienti allo sviluppo del software e coinvolgerli nel processo il più possibile. Quello che stanno vedendo ora è la rapida consegna di nuove funzionalità ma anche bug nel software. Mentre saranno felici con il primo, non saranno (o non dovrebbero) essere soddisfatti con il secondo.

Devi spiegare loro che con processi migliori mentre la consegna di nuovo software sarà ritardata di un breve importo, ci saranno meno bug (non ci sarà mai zero). Se riesci a trovare un accordo sul fatto che questa è la strada da percorrere, sarai in grado di iniziare a introdurre i processi necessari per riprendere il controllo del tuo sviluppo.

L'uso del processo Agile potrebbe essere di aiuto in quanto suggeriscono (e in alcuni mandati di implementazione) che il cliente è incluso come parte del team. Se coinvolgi i clienti molto da vicino, vedranno cosa funziona e cosa puoi produrre in prima persona.

La mia opinione (di esperienza limitata): penso che ci siano due problemi da risolvere. Innanzitutto, il processo di qualità. Usi mischia / cascata / qualcosa nel mezzo? Nella mischia, puoi aggiungere attività aggiuntive per ogni storia: 1 per elaborare uno script / piano di prova, un altro per eseguirlo, un altro per una revisione del codice, ecc. In cascata, puoi semplicemente aggiungere questi passaggi?

L'altro problema è l'enorme problema principale che esiste ovunque nel software. Gestire le aspettative. Vale a dire aumentare il tempo da qualcuno che grida che hanno bisogno di un pulsante per fare X per averlo consegnato.

Se puoi aggiungere ulteriori passaggi al processo e fare un grande annuncio di fanfara al riguardo [stiamo implementando questo processo di qualità: il che significherà meno tempo per correggere i bug! e risultati di migliore qualità! grandi e-mail / riunioni ecc. per farli sapere] e fornire risultati regolarmente (ala scrum), l'idea è che quelli a cui stai consegnando impareranno e vedranno il valore nelle fasi di processo extra e loro compreranno. Meno tempo per correggere i bug = più tempo per implementare e testare le funzionalità.

I clienti non accetteranno un improvviso ritardo nei risultati? Devono praticamente. È chiaro che non può continuare così com'è. Forse puoi aggiungere ulteriori passaggi di QA e, se necessario, aggiungere altri membri del team? Ma i passaggi di qualità sono assolutamente richiesti.

Ancora una volta, se usi la mischia o simili, potresti puntare a uno sprint di una settimana, quindi ci sono consegne regolari di risultati. Ciò placherà le persone tanto quanto una rapida inversione di tendenza.

Spero che questo aiuti in qualche modo ... spero di non aver perso il punto.

Quello che hai descritto sembra molto normale e non è affatto allarmante.

• I clienti di solito hanno una mentalità diversa su ciò che è importante degli ingegneri. Ci piace che le cose siano giuste, ma i clienti devono affrontare una realtà che premia la puntualità sulla purezza. Hanno bisogno di risolvere rapidamente i loro problemi per essere competitivi, ed è esattamente quello per cui ti stanno pagando.
• Stabilire le priorità è troppo grande e peloso per una persona da gestire da solo, avendo un arretrato di questioni importanti (quindi stai usando JIRA), con i tenenti che gestiscono ogni area di interesse è l'opzione migliore che abbiamo per mantenere il lavoro impotente davanti il programma.

Non c'è nulla di cui preoccuparsi. Detto questo, puoi risparmiare un sacco di dolore spostando il maggior numero di compiti di gestione possibile verso il cliente pagante, coinvolgendolo nel processo di sviluppo di definizione delle priorità e fino alla tecnologia, automatizzando la maggior parte della routine possibile.