I processi della mia squadra sono fuori controllo?

our clients won't accept a sudden delay in results

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

Ciò che tu hai a fare per cambiare questo è quello di convincere i tuoi clienti ad accettare la realtà dello sviluppo del software (o qualsiasi altra produzione!): le cose impetuose incidono sulla qualità.

Crea una grande lista di cose che stanno andando male, delle cose che sono state infrante, delle volte in cui hanno avuto motivo di lamentarsi. Spiega loro la ragione di questi problemi e di 'loro cosa ti piacerebbe fare per cambiarlo. Assicurati di spiegare loro la percentuale di tempo che il tuo team spende per supportare e correggere le applicazioni live. Se non stai raccogliendo i dati, ora è il momento di iniziare (e raccoglierlo per un mese prima di presentare le informazioni ai clienti).

Ottieni gli stakeholder chiave in una stanza e dì: "vuoi X riparato, o vuoi Y consegnato? Abbiamo solo il tempo per uno dei due". Rendi loro responsabile per l'impostazione delle priorità e sii chiaro che hai una capacità limitata. Se chiedono qualcosa di nuovo, chiedi loro cosa sono disposti a sacrificare dalla loro attuale tabella di marcia per raggiungerlo.

Chiedete al vostro team quale 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 nella qualità del codice / architettura / ecc.). Includere questi elementi nell'elenco delle cose che i tuoi stakeholder devono dare priorità.

La cosa migliore che abbia mai fatto nel mio attuale lavoro è stato quello di ottenere i primi 8 stakeholder in una stanza allo stesso tempo e disporre una pila di 16 carte indice che rappresentano le nuove funzionalità richieste. Mi allontanai dal tavolo e dissi: "Possiamo consegnare uno di questi alla volta: in che ordine li vuoi?" Lascia che discutano eachother sulla priorità del business invece di essere bloccato nel mezzo.

Stop, drop and roll. Gli incendi hanno bisogno di carburante e spesso si presenta sotto forma di panico. Metti da parte il tempo per gestire te stesso e la squadra in ordine. Valuta i tuoi sviluppatori e verifica se hai qualcuno che non è abbastanza esperto e / o non lavora abbastanza per produrre i risultati desiderati. Decidi chi rimane (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 facendo per assicurarti che possano svolgere il loro lavoro. Assicurati che vengano eseguiti test del suono, revisione, controllo del codice sorgente e documentazione. Le brave persone con buoni strumenti devono essere responsabili di fare un buon lavoro.

Deve esserci un sistema per sapere cosa deve fare la tua squadra, al momento sta lavorando e quando si aspettano di essere completati. Un sacco di metodologie, teorie, software, schede cancellabili a secco e note adesive, documenti e e-mail per ottenere questo risultato. Fai funzionare qualcosa facendo in modo che tutti si attengano a esso. Se tutti hanno qualche input nel sistema, c'è più incentivo a seguirlo.

Ottieni una migliore comprensione di ciò che i clienti si aspettano. Questo potrebbe non essere una parte del tuo lavoro. Ci possono essere altre persone che fingono 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, niente è un'emergenza perché non sarà tutto fatto. Offri di partecipare alle discussioni con i clienti occasionalmente. Scoprirai che molti "simpatici abbienti" diventano "sfondatori" quando arrivano alla squadra di sviluppo. Sii il liason tecnico o qualche altra scusa per dare una mano. Fare promesse che non puoi mantenere è peggio che dirgli 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 istruire i tuoi clienti sullo 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 contenti del primo, non saranno (o non dovrebbero) essere contenti di quest'ultimo.

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

L'utilizzo del processo Agile potrebbe aiutare in quanto suggeriscono (e in alcuni casi di implementazione) che il cliente sia incluso come parte del team. Se coinvolgi i clienti molto da vicino, vedrai cosa funziona e cosa puoi produrre in prima persona.

La mia opinione (limitata): penso che ci siano due problemi da risolvere. Innanzitutto, il processo di qualità. Usi mischia / cascata / qualcosa in mezzo? In mischia, puoi aggiungere compiti aggiuntivi per ogni storia: 1 per creare uno script / programma di test, 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. Cioè aumentando il tempo da qualcuno che urla che hanno bisogno di un pulsante per fare X per averlo consegnato.

Se puoi aggiungere ulteriori passaggi al processo e fare un grande annuncio sulla fanfara [stiamo implementando questo processo di qualità: il che significa meno tempo per correggere i bug! e risultati di qualità migliore! grandi e-mail / riunioni ecc per farglielo sapere], e fornire risultati regolarmente (ala scrum), l'idea è che coloro che stai consegnando apprenderanno e vedranno il valore nelle fasi extra del processo, e compreranno in esso. Meno errori di correzione del tempo = più tempo per implementare e testare le funzionalità.

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

Anche in questo caso, se usi mischia o simili, potresti mirare a uno sprint di una settimana in modo da ottenere consegne regolari dei risultati. Ciò placherà le persone tanto quanto un rapido turnaround.

Spero che questo aiuti in una certa misura ... spero di non aver mancato il punto.

Ciò che hai descritto suona molto normale e in realtà non è affatto allarmante.

• I clienti di solito hanno una mentalità diversa su ciò che è importante degli ingegneri. Ci piace che le cose abbiano ragione, ma i clienti si trovano di fronte a una realtà che premia la puntualità sulla purezza. Hanno bisogno che i loro problemi siano risolti rapidamente per essere competitivi, ed è esattamente ciò per cui ti pagano.
• Stabilire le priorità è troppo grande e peloso perché una persona possa gestire da sola, avendo un arretrato di problemi importanti (quindi stai utilizzando JIRA), con i luogotenenti che gestiscono ogni area di interesse è la migliore opzione che abbiamo per mantenere un lavoro impotante la parte anteriore del programma.

Non c'è niente di cui preoccuparsi. Detto questo, puoi risparmiare un sacco di dolore spostando il maggior numero possibile di compiti di gestione verso il cliente pagante, coinvolgendoli nel processo di sviluppo delle priorità di impostazione e fino alla tecnologia, automatizzando tanto della routine come possibile.