Lavoro su un ampio programma software in servizi finanziari. (15 project manager, 20 lead tecnici, 15 ambienti, 150 persone sul lato tecnico).
Facciamo molta integrazione a livello di Banca a centinaia di sistemi (assicurazioni, pagamento di bollette, fondi comuni di investimento, assicurazioni, rendicontazione fiscale, compravendita di azioni, ecc.), che spesso scendono negli ambienti di sviluppo. Sebbene esista un team ambientale, sono fondamentalmente amministratori di sistema che necessitano dell'assistenza di un lead Java per identificare la causa principale di un problema e risolverlo.
In team su scala ridotta su cui avevo lavorato in precedenza (un sistema di fondi di investimento) un singolo PM avrebbe posseduto un insieme di ambienti fino alla produzione e sarebbe stato responsabile della rimozione dei blocchi per una particolare caratteristica fino alla produzione .
In questo programma più ampio, i project manager hanno una tendenza a dimenarsi da questa responsabilità. Non ci sono punti per loro nel fissare gli ambienti. Inoltre, i lead tecnologici vengono sbattuti per aver lavorato su qualcosa che non è la funzionalità di spedizione.
I test manager alzano le mani perché i tester non possono accedere ad un sistema 1/3 del tempo.
Ora il modo in cui ho formulato la domanda può portarti alla risposta "beh, cambia il modo in cui le persone vengono misurate! Duh!" Se riesci ad articolare un modo concreto per misurare le persone che creano questo incentivo, sono ansioso di ascoltarlo. Sfortunatamente le cose non sono così semplici. I Project Manager si affidano al software di spedizione e una scheda kanban mostra le storie di spedizione di utilizzo di tutti, e quindi vi è un incentivo per massimizzare l'utilizzo e i punti della storia spediti.
Ora puoi utilizzare il radiatore di informazioni e mostrare tutte le storie come bloccate, ma la risposta che ritorna in quella situazione è " rendi il problema di qualcun altro, " invece di "< em> prenditi il tempo per trovare la soluzione e risolvila in un modo che non accada mai più. "
Un altro argomento è che questo genere di cose si ordina da sé. La persona che sente il dolore deve passare il tempo per risolvere il problema. È interessante notare come questo non impedisca loro di essere schiaffeggiati dal PM per aver lasciato che il loro utilizzo scenda.
Sto pensando di portarlo in cima al programma e di offrire un semplice "sistema di ripostiglio" che mette una coppia di PM / Tech Lead al fixing degli ambienti al giorno ogni quindici giorni. Il feedback che ho avuto su questo è che il capo del programma trova conveniente ignorare questi problemi, o licenziare una responsabilità operativa a breve termine "tu - fai andare via questo!" invece di pensare in modo strategico al problema. Portarlo in cima è fondamentalmente giocare con il fuoco.
Quando lo porto al responsabile dei test per chiedergli di parlare con il responsabile del programma, dice "Il responsabile del programma è un pensatore non operativo e strategico, non è interessato a una correzione sistemica o di medio termine. "
La mia idea attuale è quella di ottenere un accordo dal responsabile dei test sui costi di burn-rate associati agli ambienti che sono inattivi, quindi collegarli ai nostri report di disponibilità automatici. (Abbiamo rapporti che mostrano grafici di diverse parti del sistema su e giù). In questo modo possiamo avere una discussione sul costo del fixing vs non sul fixing. Il problema è che si sta tentando una reazione perché si basa sul fatto di far sembrare le persone finanziariamente cattive.
La mia domanda è: Quali sono le strategie su un ampio programma software (200 ingegneri) per convincere le persone a correggere gli ambienti quando le persone vengono misurate sulle funzionalità?
Modifica Grazie al feedback finora è stato enormemente costruttivo e utile. La domanda è stata sollevata su quale sia il problema ambientale. Questi includono, ma non sono limitati a:
- L'integrazione principale e il server web del cliente non hanno memoria
- Il server web di integrazione primario non ha caricato le sue cache
- Il server Web di integrazione principale ha avuto un avvio non riuscito e non sta visualizzando una pagina di accesso
- Il server Web di integrazione primario è fuori sistema con il sistema di gestione degli accessi Tivoli
- Uno dei multipli dei sistemi satellitari è inattivo (e-mail, dichiarazioni, commissioni, trading azionario, configurazione utente, fine giornata)
- Il database principale è inattivo o in esecuzione lento
Il punto più ampio è che il tasso di variazione del sistema è abbastanza alto perché questo sia più probabile che si verifichino nuovi problemi piuttosto che gli stessi problemi.
Qualcuno di utile ha suggerito di sistematizzarli e di misurarne l'occorrenza. Ho proceduto su diverse iniziative di "runbook leggero" che elencano problemi e cause principali su un wiki. I PM più velenosi lo considerano un fallimento di utilizzo.
Qualcuno ha chiesto informazioni sulla definizione di fatto. Attualmente questo è definito come il software che passa un test DEV / QA. (Vale a dire prima della fase di test SIT, della fase di test UAT e della fase di test delle prestazioni).