Come organizzare lo sviluppo in una startup software snella

Categorizzazione dello sviluppo in azienda

Uno degli elementi che possono aiutare a strutturare lo sviluppo è quello di suddividere in categorie i diversi tipi di compiti di sviluppo dell'azienda, in modo da avere un'idea migliore della definizione delle priorità, della delega e dell'organizzazione all'interno del team. 🤝

Di seguito sono riportate le tre categorie di sviluppo di Salesflare:

Problemi sono cose che non funzionano e che devono essere sistemate nel prodotto.

Ma cosa ha la priorità? E come si organizzano? Ecco perché abbiamo suddiviso i problemi in tre ulteriori categorie: problemi immediati, stadio immediato e problemi non immediati.

I problemi immediati sono quelli che, come avete capito, devono essere affrontati immediatamente. Possono essere cose che sono veramente rotte, cose che gli utenti notano, cose nell'app che devono essere sistemate, ecc. 🚨

La messa in scena istantanea non è "istantanea" come i problemi istantanei, ma si tratta di problemi che devono essere risolti prima di rilasciare la versione più recente del software nell'ambiente di produzione. Si tratta per lo più di problemi che notiamo nel nostro ambiente di staging attraverso i test interni.

I problemi non immediati hanno una priorità inferiore e vengono discussi nella riunione di preparazione dello sprint (di cui si parlerà più avanti).

Miglioramenti UX hanno una priorità più alta rispetto ai problemi non immediati e comprendono tutto ciò che nello sviluppo riguarda l'esperienza e l'usabilità del prodotto. In sostanza, si tratta di cose che migliorano l'esperienza dei clienti.

Caratteristiche sono nuove funzionalità che vogliamo aggiungere al prodotto, come azioni di massa, filtri avanzati, ecc. Si tratta della priorità più bassa tra le attività pianificate durante uno sprint.

Sebbene la suddivisione dei tipi di sviluppo possa aiutare a organizzare meglio il team, come si fa a decidere chi si occupa di cosa?

Support Hero è qui per salvare la situazione!

Essendo noi stessi un'azienda SaaS, comprendiamo l'importanza di affrontare i problemi tempestivamente per offrire ai clienti la migliore esperienza possibile. Tuttavia, questo non significa che l'intero team debba passare le giornate a occuparsi dei problemi: non riusciremmo mai a fare altro! 👨‍💻👩‍💻

Ecco perché utilizziamo un sistema che elimina le distrazioni e aumenta la produttività del team di sviluppo. Lo chiamiamo "Support Hero".

Il Support Hero è una persona del team di sviluppo, a rotazione giornaliera, che si concentra sui problemi immediati che devono essere affrontati (e risponde a domande più approfondite e tecniche degli utenti), in modo che il team possa rimanere concentrato sui propri compiti. 💪

Tutti i problemi che non possono essere risolti in quel preciso momento dal Support Hero vengono registrati su GitHub, il software che utilizziamo per la gestione del codice e dei problemi, e vengono affrontati il prima possibile.

Il bello di avere un Support Hero è che, anche con un team ridotto, potete offrire un'assistenza di alta qualità ai vostri clienti: qualsiasi problema tecnico approfondito può essere risolto sul posto, evitando il frustrante processo di dover passare i problemi alla persona "giusta".

La parte migliore: avere un Support Hero avvicina gli sviluppatori ai clienti. 💛

È tutta una questione di struttura

Ora che abbiamo parlato dei tipi di sviluppo e di come delegare i problemi, parliamo di come organizzare la struttura. Tutti i diversi componenti che seguono si uniscono per informare il modo in cui il team procede.

Una visione del prodotto e una roadmap può aiutarvi a capire dove volete portare il prodotto, in modo da avere in mente le caratteristiche che vi permetteranno di raggiungerlo, che idealmente si sovrappongono a ciò che raccogliete dal vostro supporto. 👓

Supporto è tutto per ottenere il feedback dei clienti. Questo include le richieste di funzionalità, i problemi e i miglioramenti UX, che seguono la visione del prodotto e la roadmap di cui sopra. Registrate queste richieste e portatele alla riunione di preparazione dello sprint.

Un tracker di problemi segnala gli errori sia sul back-end che sul front-end. Inoltre, vi permette di vedere quali problemi appaiono anche senza che gli utenti ve lo dicano. Un suggerimento è Elastic APM, ma ci sono molte opzioni in circolazione.

Test interni consente a tutto il team di testare le nuove funzionalità prima che diventino operative. Effettuiamo test attivi prima di rilasciare gli aggiornamenti dallo staging alla produzione. E poiché utilizziamo Salesflare internamente, possiamo individuare anche noi eventuali problemi e miglioramenti del prodotto. È sempre bene che il vostro team utilizzi il vostro prodotto ogni volta che è possibile, in modo da poter toccare con mano eventuali problemi che possono sorgere e avere una conoscenza approfondita del vostro prodotto.

Hotjar Le sessioni di registrazione possono aiutare il team a vedere come le persone interagiscono con il prodotto e dove le cose vanno male (o bene). Le registrazioni degli utenti, anche se non sono necessarie su base giornaliera, possono fornirvi ulteriori informazioni su come le persone utilizzano il vostro prodotto, poiché potete vedere cosa fanno senza che debbano spiegarvelo.

È ora di sprintare!

Strutturate il lavoro del vostro team di sviluppo in sprint, una metodologia agile. Come linea guida generale, gli sprint di due settimane sono più comuni per l'IT e lo sviluppo di prodotti software. 🏃‍

Tuttavia, è consigliabile prepararsi prima delle riunioni di sprint, altrimenti le cose possono diventare un po' caotiche e fuori tema.

Questo problema può essere affrontato organizzando riunioni di preparazione agli sprint. Il CTO, il product owner e il product manager (per saperne di più sulla differenza tra product owner vs product manager) partecipano a questa riunione e usano questo tempo per esaminare i problemi immediati che rimangono, i miglioramenti UX, i problemi non immediati e le funzionalità. Questo aiuta a stabilire l'agenda e le priorità per lo sprint successivo senza dover sottrarre tempo alla riunione dello sprint stesso. ✅

Poi, naturalmente, è il momento della riunione di sprint! La riunione di sprint approfondisce tecnicamente ciò che è stato discusso durante la riunione di preparazione dello sprint, in modo che il team di sviluppo sappia esattamente come procedere. Inoltre, offre una piattaforma per rivedere i problemi immediati insieme al team. Questa riunione dovrebbe includere il CTO e il team di sviluppo. Possono partecipare anche il proprietario del prodotto e il team di supporto, ma sono meno necessari in questa fase.

All'inizio di questa riunione è bene riflettere sullo sprint precedente: cosa è andato bene, cosa è andato male, ecc.

Cosa c'è nel vostro kit di strumenti?

Gli strumenti che utilizzate all'interno della vostra azienda possono determinare il successo del vostro team di sviluppo. Abbiamo già parlato di Hotjar e Elastic APM, ma tra gli altri strumenti da prendere in considerazione per una comunicazione e una gestione delle attività più snella ci sono:

Slack - per discussioni interne, aggiornamenti/notifiche, condivisione di file e occasionalmente gif divertenti.

Trello - per il compito/gestione e monitoraggio dei progetti chi fa cosa in un determinato sprint

GitHub - dove teniamo traccia dei problemi, delle richieste di funzionalità, ecc.

Intercom - per comunicare con i clienti

Un aspetto positivo dell'utilizzo di questi strumenti è che possono interagire tra loro. Ad esempio, riceviamo gli aggiornamenti da Trello e Github in Slack. E in Trello utilizziamo un power-up di GitHub che integra le informazioni di GitHub in Trello. 🌐

Inoltre, possiamo collegare GitHub alle conversazioni di Intercom, in modo da avere sempre a portata di mano il contesto; e quando inviamo funzionalità o risolviamo problemi, possiamo comunicarlo senza errori.

Indipendentemente da come decidiate di strutturare lo sviluppo della vostra azienda, è sempre importante assicurarsi che il vostro team, grande o piccolo che sia, possa lavorare all'interno dei processi che decidete di utilizzare. 🚀

Non abbiate paura di cambiare le cose se non funzionano! La chiave è trovare ciò che funziona per voi e per la vostra azienda e seguire quella strada.

Speriamo che questa rapida guida vi abbia dato un po' di ispirazione su come costruire e strutturare il vostro team di sviluppo!

Avete altre idee fantastiche? Ditecelo nei commenti! ✨

Ti piace questo post? Date un'occhiata al resto del nostro Interno Salesflare serie.