La Storia di Jibble
Creare un software che si distingua, sia affidabile e abbia un impatto non è facile. Molti team possono realizzarne uno, pochi due, ma raramente vediamo un team che ne realizza tre.
Questo è quanto ho osservato in Jibble.
Una rapida ricerca su Google confermerà la mia tesi: il software dell’azienda ha un impressionante punteggio di 4,9 su GetApp e Capterra e di 4,7 sull’App Store di Apple.
Sono sicuro che ci sono molte cose che l’azienda può migliorare, ma il team sta certamente facendo qualcosa di giusto se questi sono i punteggi. Volevo capire esattamente cosa stavano combinando, così ho deciso di scoprire come e perché l’azienda stava ottenendo questi risultati sorprendenti.
Riconosco che i software di timesheet e di time tracking non sono poi così allettanti; non è certo come lavorare per un’azienda di videogiochi come Activision che sta sviluppando il nuovo gioco di Spider-man.
Tuttavia, Jibble si presenta come “Il Nuovo Punto di Riferimento nel Time Tracking”, un’affermazione audace, ma che ho trovato fondata. Questo è il risultato di sforzi estenuanti per rendere interessante qualcosa di banale ma significativo.
Sono i settori tradizionali quelli che la maggior parte delle startup cambierà, dato che l’innovazione più immediata e più evidente è stata raggiunta. Questo è il motivo per cui credo che Jibble si trovi in una posizione unica per conquistare un mercato che è stato a lungo trascurato dai giovani fondatori e dai più esperti investitori di venture capital.
A prima vista, Jibble può sembrare un concetto banale che segue la linea del “Ok, hai trovato un problema, mettiamo insieme un po’ di codice, creiamo un’interfaccia utente, aggiungiamo un gateway di pagamento e lo lanciamo nel mondo”.
Almeno, questo era quello che pensavo all’inizio, prima di entrare a far parte del team, ma come ho imparato rapidamente, le aziende SaaS che sviluppano prodotti complessi come i software di timesheet funzionano in modo diverso.
Ci sono MOLTI processi da seguire e, sebbene Jibble non sia Google, vanta sicuramente un team di persone davvero eccezionale che guida lo sviluppo. Questi eroi spesso passano inosservati.
Forse avrai sentito dire che gli ingegneri di software non sono grandi comunicatori. Sono generalmente introversi, esperti nel loro campo e raramente vogliono essere disturbati da interazioni umane. Questo stereotipo è vero in una certa misura.
La maggior parte degli ingegneri, per essere bravi nel proprio lavoro, deve passare innumerevoli ore chini sui propri monitor ad affinare costantemente le proprie capacità alla tastiera, e il nostro team non è da meno.
Avendo lavorato in entrambi i settori dell’azienda, quello a contatto con i clienti e quello dello sviluppo dei prodotti, mi trovo in una posizione unica per poter esprimere un’opinione sul perché le cose qui funzionano e sul perché vale la pena dedicare del tempo a questa start-up.
Il Nostro Processo di Sviluppo
Il nostro team passa innumerevoli ore a perfezionare ogni singolo aspetto del processo di sviluppo, che è il seguente:
1. Ideazione: Trovare un Punto Critico
Il nostro team impiega una quantità enorme di tempo prima di scrivere la prima riga di codice, per essere sicuri di non impiegarne il doppio una volta che abbiamo iniziato a sviluppare. Come disse Abraham Lincoln:
“Datemi sei ore per abbattere un albero e passerò le prime quattro ad affilare la mia ascia.”
2. Ricerca Esterna
Dopo aver individuato un punto critico all’interno del nostro software di monitoraggio del tempo, il team si mette subito al lavoro per confrontare i feedback dei clienti esistenti, le tendenze di mercato attuali e quell previste, e infine le tecnologie pertinenti, al fine di trovare punti in comune che possano aiutare nella preparazione dei dati necessari per prendere una decisione informata.
3. Ricerca Interna: Discussioni con il Team
Una volta raccolti i dati, vengono coinvolti gli azionisti interessati, tra cui i responsabili di prodotto, i product manager, i CTO, i lead designer e i team leader di tutte le sezioni.
Dopo che il team ha discusso internamente i pro e i contro, le risorse in rapporto al tempo e il ROI atteso dalla decisione che stiamo per prendere, a tutti viene chiesto di prendere tempo per esprimere le proprie preoccupazioni e indicare quale direzione riteniamo dovremmo prendere e perché o perché no.
4. Processo Decisionale: Farlo ora o farlo dopo – quali saranno le conseguenze per l’azienda?
Una volta che la situazione si è calmata e si è giunti a una conclusione, il team sceglie la decisione che si allinea alla visione dell’azienda e ai suoi obiettivi immediati o previsti. Se la decisione non soddisfa tali criteri, non viene presa in considerazione.
Le decisioni sono spesso (ma non sempre) legate al miglioramento delle funzionalità esistenti o allo sviluppo di nuove. Dopo aver dato il via libera a una di queste, si tratta di decidere dove inserirla nella tabella di marcia: lo facciamo ora, il mese prossimo, il prossimo trimestre o la mettiamo in standby?
Qui esaminiamo l’impatto che la nostra decisione avrà sui clienti esistenti, sui potenziali clienti e sulle capacità attuali, dpodiché decidiamo.
5. Ricerca del Design
Una volta stabilita la timeline delle funzionalità, dobbiamo trovare idee su come sarà. Questo è qualcosa che molti nuovi imprenditori e titolari di prodotti software sbagliano. Sono troppo concentrati su come dovrebbe funzionare quando dovrebbero anche preoccuparsi di assicurarsi che tutte le funzionalità si incastrino nel loro puzzle grafico.
6. Specifiche
Il passo successivo è la croce e la delizia degli sviluppatori software: la documentazione. Nelle specifiche scriviamo l’ambito del progetto che stiamo sviluppando. È qui che l’idea viene scritta e sviluppata su un documento che sarà la base per lo sviluppo, il collaudo e il controllo dei bug.
Essa indica in cosa consisterà l’intera funzionalità, spiega come sarà e descrive l’obiettivo finale (in questo momento non prestiamo molta attenzione alle metriche). C’è anche la documentazione tecnica che viene redatta dai nostri sviluppatori. Questo è il modo in cui attualmente procediamo per scrivere le specifiche:
- Bozza iniziale da parte del Product Manager (PM)
- I responsabili del team esaminano le specifiche iniziali e lasciano commenti sulla realizzabilità tecnica o suggerimenti alternativi
- Modifiche apportate dal PM
- Un’altra discussione (i passaggi 2-3 possono essere ripetuti alcune volte a seconda della complessità del progetto)
Il team si assicura che durante questo periodo vengano presi in considerazione anche tutti i casi limite, ma se il progetto è stato finalizzato, interrompiamo definitivamente le discussioni sulle specifiche. Fino ad allora, sono possibili iterazioni.
7. Design del Prodotto
I nostri fantastici designer progettano vari modelli con diverse opzioni di visualizzazione. Tutto viene creato tenendo presente la tavolozza dei colori di Jibble.
In questa fase viene preso in considerazione ogni possibile display (mobile, web, tablet) e una vasta gamma di dimensioni dello schermo.
8. Implementazione del Back-End e Test Unitari
La maggior parte delle funzionalità parte dal backend. Il nostro backend deve supportare la funzionalità prima che aggiungiamo l’interfaccia utente e la logica sul lato cliente e aggiungiamo la nostra API.
Quindi, le sessioni di grooming vengono svolte con il team BE per perfezionare i ticket e le attività in base alle specifiche e quindi l’assegnazione dei ticket viene effettuata durante la pianificazione della fase del backend.
Il team BE è anche responsabile dello sviluppo di test unitari per il codice che scrive, per assicurarsi che tutte le funzionalità operino come previsto. A questo punto viene creata l’architettura delle funzioni. Un buon modello di funzionalità faciliterà il processo di sviluppo per i clienti.
9. Implementazione dei Clienti e Test Unitari
Ora che il nostro BE è stato implementato, i team di sviluppo mobile e web inizieranno le rispettive implementazioni FR. Il processo è più o meno lo stesso del BE, tuttavia, la definizione dei ticket viene effettuata principalmente al di fuori delle call di pianificazione.
I clienti fanno riferimento principalmente alle specifiche, ai progetti e alla struttura del modello BE per implementare il loro codice. Per quanto riguarda i dispositivi mobili, abbiamo due team diversi per l’interfaccia utente che seguono un insieme di logiche condivise; questo aiuta a ottimizzare la consegna e a ridurre la ridondanza. I test iniziali vengono eseguiti dal team di sviluppo e poi passati al controllo qualità per i controlli manuali.
10. Test di Accettazione per il Controllo Qualità
Man mano che le funzionalità vengono sviluppate, vengono implementate nei nostri ambienti per i test, dove il team di controllo qualità esegue rigorosi test di accettazione. Questo è un modo un po’ elaborato per dire che testiamo le funzionalità del software di time tracking per assicurarci che funzionino secondo le aspettative. Se vengono riscontrati dei problemi, si torna in fase di revisione e miglioramento.
11. Test di Regressione per il Controllo Qualità
Se tutte le funzionalità operano come previsto, vengono inviate alla produzione dove vengono nuovamente testate, questa volta per assicurarsi che le correzioni esistenti non compromettano ciò che funzionava prima.
Il test di regressione è un tipo di test del software che serve a confermare che una recente modifica al programma o al codice non abbia influito negativamente sulle funzionalità esistenti.
Qui in Jibble eseguiamo due tipi di Test di Regressione: uno è un test di regressione informale o minore, che viene eseguito nell’ambito dei ticket di test di accettazione che presentano problemi e devono essere riparati. L’altro è il test di regressione a iterazione completa del ciclo, che viene eseguito verso la fine della fase, noto come ciclo con maggiore copertura, il quale si concentra sul percorso critico delle funzionalità selezionate.
Al momento lo stiamo eseguendo manualmente prima che gli script di automazione siano completamente pronti.
12. Test Esplorativi
Poiché il team è abile nello sviluppo de proprio software di timesheet, tutte le attività sopra descritte vengono svolte in cicli di due settimane. Al di fuori di questi cicli, o durante i periodi in cui il carico di lavoro è relativamente basso, il team esegue test esplorativi, il che significa semplicemente tenere d’occhio tutto e segnalare eventuali miglioramenti che devono essere corretti.
Eseguiamo anche test esplorativi mentre testiamo i ticket per il collaudo di accettazione, che riguardano lo scopo più ampio del ticket stesso.
13. Rilascio
Finalmente, dopo tutti questi sforzi, la nostra creazione viene lanciata nel mondo. Non ti aspettavi che ci volesse così tanto tempo per creare un software di timesheet, vero?
L’Insegnamento
Per creare un prodotto eccellente, è necessario avere una visione eccellente e non deviare da essa quando il vento cambia. Il team di Jibble che si occupa del time tracking comprende il valore di non cedere troppo rapidamente alle mode; è determinato ma costantemente alla ricerca di miglioramenti.
Allo stesso tempo, sta attuando strategie nel tentativo di rimanere fedele alla propria visione di quello che dovrebbe essere “Il Nuovo Punto di Riferimento nel Time Tracking”. QUESTO, secondo me, gioca un ruolo importante nel loro recente successo.
L’insegnamento finale per i team che cercano di replicare il successo di Jibble nella creazione di un software affidabile per il monitoraggio del tempo è questo: creare team veloci, forti e snelli che dedichino il tempo necessario alla ricerca basata sui dati prima di prendere decisioni e impieghino ingegneri brillanti che utilizzino le migliori pratiche e la collaborazione globale per costruire, testare, migliorare e distribuire funzionalità come un timbratore. Poi, mettiti comodo e guarda la magia avvenire.
