Il puffin (puffin in inglese) è un profilo che, guidando un team di sviluppatori, ha infinite funzioni software con un impatto minimo o nullo sull'azienda, sui clienti o sugli altri dipendenti.
A PUFFIN —( Piani infinite iniziative di fabbrica di funzionalità), in spagnolo equivarrebbe a infiniti piani di iniziative di funzionalità.
Questo termine di profili presuppone costi e nessun beneficio, oltre a una grande frustrazione dei team che non hanno visibilità nell'organizzazione.
Il termine Feature Factory è nato quando un mio amico sviluppatore di software si è lamentato di essere "solo seduto in fabbrica, a creare funzionalità e a spedirle ad altri sviluppatori".
Come sapere se stai lavorando in una fabbrica di funzioni? Ci sono chiari sintomi che consentono di identificare queste strutture.
- Peccato metrica. I team non devono misurare l'impatto del loro lavoro. Oppure, se la misurazione viene eseguita, viene eseguita isolatamente dal team di gestione del prodotto e condivisa selettivamente. Non è noto se il lavoro svolto abbia funzionato correttamente.
- Mix rapido di team e progetti (noto anche come Team Tetris). Invece di missioni o iniziative sensate e comprensibili, i team si occupano di assegnazioni di ruoli e progetti senza sapere perché o chi dovrebbe essere responsabile di cosa. Multitasking in tutte le operazioni e uso eccessivo delle risorse.
- Teatro di successo intorno alla "spedizione" con poche discussioni sull'impatto. Si può dire molto di un'organizzazione dalle sue domande festeggia.
- Guasti rari (riconosciuti) e lavori scartati. Senza eliminare o migliorare significativamente le funzioni precedenti. La misura principale del successo sono le funzionalità fornite, non i risultati forniti. Raramente il lavoro viene licenziato alla luce dei dati e dell'apprendimento. L'apparecchiatura non dispone della misura necessaria per ammettere i guasti di produzione.
- Nessun collegamento alle metriche aziendali. Le conversazioni sui clienti o sui risultati aziendali non esistono o sono rare. Il team non è in grado di mettere in relazione il lavoro con le principali metriche aziendali e di soddisfazione dei clienti. Impossibile collegare il lavoro con lo affari importanti.
- Nessuna analisi di impatto. I product manager non riesaminano periodicamente la qualità delle decisioni sui prodotti e quindi non confrontano i benefici attesi con i benefici effettivi ottenuti. Gli sviluppatori hanno "requisiti approvati", ma i product manager non hanno obiettivi di affari. Solo la velocità e la produzione vengono prese in considerazione come indicatori chiave di prestazione
- Ossessione per la definizione delle priorità. Emergono discrepanze tra il rigore della definizione delle priorità (decidere su cosa lavorare) e il rigore della convalida (decidere se, in effetti, fosse la cosa giusta su cui lavorare). Il rigore della definizione delle priorità è concepito unicamente per moderare le agende interne in modo che le persone "si sentano al sicuro". Molto lavoro è necessario per determinare su quali idee lavorare, lasciando poco spazio per aggiustamenti e improvvisazioni basate sui risultati. Roadmap, piani, mostrano un elenco di funzionalità, non aree di interesse e/o risultati.
- nessun aggiustamento. Una volta "fatto" il lavoro (secondo i principi dei responsabili dello sviluppo), il team passa immediatamente al "progetto" successivo, senza lasciare il tempo di iterare con dati qualitativi e quantitativi che portano a piani di miglioramento e miglioramento della qualità.
- Cultura del trasferimento del deliverable. Il team non è direttamente coinvolto nella ricerca, nell'esplorazione dei problemi/sfide da affrontare o nella sperimentazione e successiva validazione. Una volta terminato il lavoro, lo sviluppatore ha pochi contatti con il supporto, la soddisfazione del cliente e i risultati aziendali.
- Grandi set di pacchetti. Senza l'obbligo di sperimentare, le funzionalità vengono fornite in pacchetti di funzionalità di grandi dimensioni, anziché in versioni incrementali. Se viene applicata la metodologia agile, può darsi che, lavorando ancora negli sprint, ma niente di nuovo raggiunga i clienti alla fine di ogni consegna.
- Cerca il reddito in anticipo. Vengono implementate le funzioni per chiudere nuovi accordi una tantum. Sebbene questo approccio non sia intrinsecamente sbagliato, le giustificazioni economiche sono spesso deboli (nella migliore delle ipotesi) e non tengono conto dell'aumento non lineare della complessità del prodotto (benefici a breve termine che maturano in seguito). Ancora una volta, viene rafforzata l'idea che le caratteristiche siano l'unità di misura del valore. Le decisioni sui prodotti mancano di una solida visione e strategia economica.
- progetti "star".. La fornitura costante di nuove funzionalità mette in ombra altri tipi di iniziative necessarie. La riprogettazione, la riduzione dei costi e il lavoro di consegna del valore hanno una visibilità ridotta. Concentrarsi su quelle caratteristiche principali sminuisce le attività sull'impatto delle nuove funzionalità su usabilità, manutenibilità, scalabilità e così via.
