Questo profilo WoLF (funziona sull'ultimo "incendio"/problema, Funziona sull'ultimo fuoco) è generato, o dalle motivazioni proprie della persona che sono scarsamente focalizzate, o da una direzione delle squadre in direzioni disparate. In ogni caso, producono sempre lavoro aggiuntivo risolvendo problemi a cui non si presta attenzione lungo il percorso fino a quando prima o poi devono essere affrontati con il conseguente costo economico e perdita di opportunità, tra gli altri.
Se con lo sviluppo software si volesse creare un film come quelli sulla mafia, l'argomento potrebbe essere il seguente:
…Julia, la proprietaria di "The Home for the Care of Abandoned Bambinos" vuole salvarlo dal pignoramento e le viene in mente di implementare rapidamente la nuova app di gioco "Abandoned-Child Finder" in tempo per le festività natalizie. La sua speranza è che gli abbonamenti e le entrate pubblicitarie salvino la giornata per l'orfanotrofio. Sfortunatamente, perché la sua app esca con successo in tempo, imbroglia un po' assumendosi la responsabilità di un debito di definizione tecnica derivante da un elemento di incentivo per i giocatori di livello epico. Tutto sembra perfetto, la casa per i bambini sembra sicura, i suoi inquilini stanno ancora una volta le prove per l'annuale concorso di Natale... finché Carmen del Servizio Clienti non fa una segnalazione di bug che metterebbe fine a quell'ottimismo e rovinerebbe il reddito relativo a detto debito. definizione. Poiché il team di Julia è già sulla buona strada per fornire le nuove funzionalità necessarie per raccogliere capitali di rischio, ignorano il rapporto di Carmen... fino a quando Luis, l'esattore tecnico dei debiti, lo Scrum tra Scrum, con un Post-it® rosso brillante... inchiodato all'estremità di una mazza da baseball. Inutile dire che il resto del film implica che Julia ha passato le sue giornate a capire e poi appianare tutte le implicazioni del non aver corretto quegli errori di definizione in primo luogo, sottraendo le entrate dell'app necessarie per evitare che i bambini venissero scaricati. al freddo la vigilia di Natale.
Sì, è evidente, un cliché molto usato, ma molto familiare ai professionisti dello sviluppo prodotto. È chiaro che Julia sta svolgendo compiti di WoLF. Se uno o più profili vengono aggiunti a questo profilo PUFFIN (Pianifica iniziative di fabbrica senza fine) il caos e il conflitto sono già quelli di un film apocalittico.
Come si arriva a questa situazione
Come la nostra eroina Julia, anche noi mettiamo da parte il debiti tecnici con la promessa che lo pagheremo più tardi, quando ci sarà più tempo.
Il problema è che non c'è mai abbastanza tempo per vari motivi. Alcuni esempi reali potrebbero essere i seguenti (senza nomi o dettagli facilmente identificabili ovviamente):
- Il vicepresidente di Incredible Sales ha promesso al cliente di Big Fish la funzione "XYZ" entro una data fissa che è stata probabilmente offerta con una consulenza minima da parte del team responsabile della consegna dei prodotti.
- Il partner di venture capital ansioso che cerca di uscire vuole assicurarsi che un determinato dominio o verticale sia coperto prima della prossima IPO.
- Il programmatore annoiato che crea il proprio curriculum ha bisogno di esperienza pratica nella creazione di report BI basati su API forniti tramite Angular, sfruttando la più recente tecnologia di apprendimento automatico su un cluster Apache Spark.
- Il Product Owner affamato di promozioni che vuole stupire il capo con fantastiche funzionalità di front-end nei quattro mesi precedenti la revisione delle prestazioni.
Sembrano tutti candidati per la definizione delle priorità non basata sui dati, che avrà un prezzo potenzialmente enorme da pagare e un enorme costo opportunità.
Allora perché lo razionalizziamo in questo modo? Forse perché lavorare con il debito tecnico è divertente, per la prima settimana circa. Dopodiché, diventa un gioco sinistro di corrompere ed estorcere compagni di squadra, oltre a truffare qualche altro membro del team ignaro facendogli fare il lavoro sporco.
Come evitare di raggiungere questi scenari
Per quei (pochi) che devono ancora provare la "gioia" di una visita di un amichevole esattore tecnico, vale la pena tenere a mente questi 7 principi a cui prestare attenzione durante il processo.
Supportare, indagare e dare priorità a questi principi o situazioni:
- Se un ingegnere è alle prese con un debito tecnico per finire un lavoro.
- Se crei una funzionalità con un evidente debito di User Experience (UX).
- Se la ricerca è necessaria perché i dati non esistevano.
- Il lavoro non sta contribuendo al valore per il cliente, quando era previsto che accadesse.
- Si pubblicava una storia e poi bisognava giocare per giustificare quanto detto.
- Impossibile convalidare l'impatto.
- Ti viene l'idea, ma stai ancora creando più attività, rifacendole, tagliando funzioni, aumentando il carico operativo,... ad ogni passaggio diventa meno impressionante.
Audacia e sincerità sono essenziali nell'agire in modo che il team, il management, le parti interessate, gli sponsor e, se possibile, i clienti siano consapevoli che le versioni future del prodotto o servizio includeranno i debiti contratti. Almeno è necessario stabilire una corretta gestione delle aspettative spiegando gli “sfortunati incidenti” che potrebbero verificarsi se le responsabilità acquisite non venissero pagate.
Sia che tu decida di pagare semplicemente gli interessi o di pagare per intero, tieni presente che, proprio come uno strozzino, il prezzo del tuo accumulo tecnico probabilmente aumenterà di costo nel periodo di tempo in cui rimane instabile.
Riferimenti
- Accelerare: La scienza del software snello e del DevOps: creazione e ridimensionamento di organizzazioni tecnologiche ad alte prestazioni' — Nicole Forsgren e Jez Humble
- 'Il manuale DevOps: Come creare agilità, affidabilità e sicurezza di livello mondiale nelle organizzazioni tecnologiche'— Gene Kim, et.al.
