Il team di ingegneria di Compass aveva un problema. Le nostre funzionalità erano tecnicamente valide, ma mancava qualcosa: il vero amore per i clienti. Siamo stati efficienti nella programmazione, ma stavamo risolvendo i problemi giusti?
In qualità di Senior Engineering Manager di Atlassian dedicato a Compass, ho dedicato anni a questa sfida. Io e il mio team ci occupiamo di creare strumenti che aiutino i team di sviluppo a gestire i componenti e le risorse software su larga scala. Quando sono entrato nel team, ho notato uno schema tipico di molte organizzazioni di ingegneristica: siamo bravi a fornire funzionalità, ma a volte non riusciamo a offrire valore.
Ho visto in prima persona come la cultura ingegneristica può determinare il successo o il fallimento di un prodotto. In Atlassian, non ci limitiamo a creare strumenti per i team software: viviamo e respiriamo le stesse sfide che i nostri clienti affrontano ogni giorno. Ciò ci offre un punto di vista unico sulla trasformazione della cultura ingegneristica, ed è per questo motivo che mi sta particolarmente a cuore condividere ciò che abbiamo imparato.
La tradizionale disconnessione ingegneristica
Parliamo di un ipotetico team di prodotto la cui storia potrebbe suonare familiare.
Tina è una senior developer nota per la sua eccellenza tecnica. Sebbene il suo codice fosse impeccabile, si è ritrovata intrappolata in un ciclo familiare: ricevere requisiti, scrivere codice e distribuire funzionalità. "Scrivevo codice nel vuoto", ammette Tina. "Non sapevo minimamente se quello che stavo costruendo risolvesse effettivamente i problemi reali dei clienti". Voleva un maggiore contesto dei clienti, ma si sentiva limitata dalla sua attenzione sulla sola implementazione.
Rita, la product designer del team, ha affrontato le proprie difficoltà. Trascorreva settimane a creare design perfetti, per poi ricevere, in fase di sviluppo, un feedback cruciale che la costringeva a importanti modifiche. "Quando gli sviluppatori sottolineano i vincoli tecnici, spesso è troppo tardi per mantenere la visione progettuale originale", spiega. Rita aveva bisogno di una migliore integrazione con il processo di sviluppo e di un modo per convalidare i progetti in una fase precedente.
Poi c'è Paul, il product manager, che cerca di tenere tutto insieme. Passava ore e ore a scrivere documenti dettagliati di requisiti, ma qualcosa andava sempre perso. "È un po' come nel gioco del telefono senza fili", dice Paul. "Quando le funzionalità arrivano ai clienti, si sono trasformate in qualcosa di diverso da quello che avevamo inizialmente previsto". Cercava disperatamente una migliore collaborazione tra i team di ingegneria e progettazione, ma il tradizionale processo di trasferimento continuava a creare ostacoli.
Rick, il program manager, ha avuto forse il ruolo più impegnativo di tutti. Ha passato notti insonni per coordinare le dipendenze tra più team e bilanciare velocità di consegna e qualità. "Quando i team lavorano in silos, semplici modifiche possono provocare settimane di ritardi", osserva Rick. Aveva bisogno di un modo per promuovere una maggiore collaborazione e una migliore visibilità tra i team.
Il compito di supervisionare tutto è spettato ad Anna, l'engineering leader, che ha dovuto faticare per trasformare il modo di lavorare dei team. Pur apprezzando l'eccellenza tecnica, sapeva che mancava qualcosa. "Abbiamo ingegneri di incredibile talento", osserva, "ma non siamo in grado di fornire costantemente il valore di cui i nostri clienti hanno bisogno". Anna voleva cambiare la cultura del team, ma il modello di sviluppo tradizionale rendeva difficile bilanciare l'eccellenza tecnica con il valore per i clienti.
L'esperienza di questo team riflette uno schema più ampio nello sviluppo software. Sebbene organizzato e prevedibile, il tradizionale approccio sequenziale crea un distacco naturale tra chi realizza il prodotto e chi lo utilizza.
Cultura: la chiave per la trasformazione
"La cultura si mangia la strategia a colazione". Sebbene questa citazione sia spesso attribuita al guru del management Peter Drucker, è diventata famosa quando Mark Fields l'ha esposta permanentemente nella war room di Ford nel 2006. Il messaggio non era solo una frase accattivante: racchiudeva una verità fondamentale che abbiamo visto più volte nel settore tecnologico, cioè che anche la strategia più brillante fallirà se è in conflitto con la cultura dell'organizzazione.
Quando abbiamo deciso di trasformare la nostra cultura ingegneristica in Compass, abbiamo scoperto qualcosa di profondo: l'eccellenza tecnica da sola non era sufficiente. Dovevamo colmare le distanze tra i nostri ingegneri e i clienti. I numeri lo confermano: le aziende con una cultura forte vedono una crescita dei ricavi quattro volte superiore rispetto alla concorrenza.
Il nostro percorso di trasformazione in Compass lo illustra perfettamente. Siamo passati da un processo tradizionale del ciclo di vita delle funzionalità il cui completamento richiedeva in genere 6-8 settimane a un processo di scoperta iterativo che ci ha avvicinato molto ai problemi dei clienti. Non è stato solo un cambiamento di processo, ma un passaggio fondamentale da una mentalità che mette al centro l'importanza di sapere tutto a una che invece ritiene essenziale imparare tutto, in cui ogni funzionalità è diventata un'opportunità per imparare dai nostri clienti.
L'evoluzione dell'ingegneria di prodotto
L'ingegneria software consiste da sempre nel trasformare i requisiti in codice funzionante attraverso progettazione, sviluppo e test sistematici. Gli ingegneri si concentrano principalmente sull'esecuzione tecnica: scrittura di codice efficiente, manutenzione dei sistemi e garanzia di qualità.
L'ingegneria di prodotto, tuttavia, rappresenta un cambiamento fondamentale nel modo di pensare alla creazione di software. Pur mantenendo il rigore tecnico dell'ingegneria software, aggiunge un elemento cruciale: una profonda comprensione dei clienti e un apprendimento continuo. Gli ingegneri di prodotto non si limitano a scrivere codice: partecipano alla scoperta e alla risoluzione dei problemi dei clienti, all'apporto di informazioni tecniche per le decisioni sui prodotti e alla gestione dei risultati del loro lavoro.
Il modello tradizionale di ingegneria software
Nel modello tradizionale, lo sviluppo segue un percorso lineare. I requisiti vanno dalla gestione del prodotto alla progettazione ai team di ingegneri che li implementano questi processi. È un po' come una staffetta, in cui ogni team passa il testimone al successivo.
Il vecchio flusso di lavoro del nostro team rifletteva questo approccio lineare:
- La creazione e l'approvazione dei documenti di requisiti richiedevano mesi.
- Architetti e designer lavoravano in isolamento.
- Gli ingegneri programmavano in base a specifiche esatte.
- Il test e la distribuzione arrivavano alla fine.
- Il feedback dei clienti veniva filtrato attraverso più livelli.
Questo approccio funzionava bene quando i requisiti erano stabili e il cambiamento era costoso. Ma negli odierni mercati in rapida evoluzione, avevamo bisogno di qualcosa di più flessibile e incentrato sul cliente.
Il ciclo continuo dell'ingegneria di prodotto
La nostra trasformazione si è incentrata sulla sostituzione di questo processo lineare con un ciclo di apprendimento continuo. Invece di trattare lo sviluppo come una staffetta, ora operiamo più come una squadra di calcio: tutti si muovono insieme, si adattano alle mutevoli condizioni e tengono d'occhio l'obiettivo di offrire valore al cliente.
In questo nuovo modello:
- Gli ingegneri partecipano ai colloqui con i clienti e alle sessioni di esplorazione.
- Sviluppo e progettazione avvengono in modo collaborativo, con prototipazione e test rapidi.
- Le decisioni tecniche vengono verificate rispetto alle esigenze dei clienti.
- La distribuzione diventa un'opportunità di apprendimento, non solo una milestone nelle consegne.
- I team misurano il successo in base all'impatto sui clienti, non solo alle metriche tecniche.
Dall'implementazione alla proprietà
Per ingegneri come Tina, questa trasformazione significava passare dalla pura implementazione alla vera proprietà. Ora gli ingegneri:
- partecipano alla definizione dei problemi e all'esplorazione delle soluzioni;
- offrono prospettive tecniche nelle discussioni iniziali;
- verificano le loro ipotesi direttamente con i clienti;
- sono responsabili dei risultati delle funzionalità oltre la semplice qualità del codice;
- tengono traccia delle metriche aziendali e dell'impatto sul mercato.
I risultati parlano da soli: le organizzazioni che adottano questo modello registrano un time-to-market più rapido e tassi di adozione delle funzionalità più elevati rispetto a quelle che utilizzano approcci ingegneristici tradizionali. E il fattore forse ancora più importante è che abbiamo visto un maggiore coinvolgimento del team, migliori decisioni tecniche e un più forte allineamento tra le nostre soluzioni tecniche e le esigenze dei clienti.
Come abbiamo reso possibile la nostra trasformazione
La trasformazione del modo di lavorare degli ingegneri ha richiesto più di un semplice cambio di mentalità: servivano le basi giuste. Per il nostro team, un elemento fondamentale di questa base era Jira Product Discovery, uno strumento che inseriva naturalmente il contesto del cliente nel nostro flusso di lavoro quotidiano.
La prima sfida che dovevamo risolvere era fare in modo che le informazioni sui clienti fossero accessibili a tutti. Prima, il feedback dei clienti e i requisiti dei prodotti erano contenuti nei documenti Confluence, nei thread Slack e nei ticket Jira. Jira Product Discovery ha inserito tutto questo contesto direttamente nel flusso di lavoro di sviluppo. Gli ingegneri hanno potuto così vedere i colloqui con i clienti, le sessioni di feedback e i modelli di utilizzo insieme al loro lavoro di sviluppo, così le esigenze dei clienti sono diventate tangibili e immediate invece di essere astratte e distanti.
Questa accessibilità ha trasformato radicalmente il modo di collaborare dei nostri team. Quando una designer come Rita ha creato nuovi progetti, ha potuto collegarli direttamente ai punti deboli dei clienti che gli ingegneri potevano vedere e comprendere. Quando Paul ha assegnato la priorità alle funzionalità, ha potuto facilmente collegare l'impatto sui clienti alla complessità tecnica, portando a decisioni più informate. Ma l'aspetto più importante è che i nostri ingegneri hanno potuto finalmente vedere il quadro completo: non solo ciò che stavamo costruendo, ma perché era importante per i clienti e come avrebbe influito sul loro lavoro.
Se il tuo team sta prendendo in considerazione questo genere di trasformazione, tieni presente che non è questione di scegliere tra eccellenza tecnica e attenzione al cliente, ma piuttosto di combinarle per creare prodotti che i clienti apprezzino davvero. Comprendere a fondo le esigenze del cliente aiuta l'ufficio tecnico a prendere decisioni migliori, trovare soluzioni più eleganti e dare più significato al proprio lavoro, poiché può constatarne l'impatto diretto.
Vuoi scoprire come abbiamo realizzato questa trasformazione? Dai un'occhiata al nostro webinar The Magic Behind Product Engineering: Turning Customer Problems into Features They Love (I segreti dell'ingegneria di prodotto: come trasformare i problemi dei clienti in funzionalità apprezzate), che approfondisce il percorso intrapreso e si concentra sulle strategie e le pratiche da implementare con il tuo team.