{"id":55846,"date":"2018-05-03T07:32:04","date_gmt":"2018-05-03T07:32:04","guid":{"rendered":"https:\/\/blog.salesflare.com\/?p=55846"},"modified":"2026-02-23T16:13:28","modified_gmt":"2026-02-23T15:13:28","slug":"how-to-organize-development-in-a-lean-software-startup-108bf51ab123","status":"publish","type":"post","link":"https:\/\/blog.salesflare.com\/it\/come-organizzare-lo-sviluppo-in-una-startup-software-snella-108bf51ab123-2","title":{"rendered":"Come organizzare lo sviluppo in una startup software snella"},"content":{"rendered":"
\n
<\/header>\n

Come organizzare lo sviluppo in una startup software snella<\/h1>\n

Interno Salesflare<\/h2>\n
\n
\n
\n
\n

L'avvio di un'azienda tecnologica pu\u00f2 essere un processo caotico, stressante e gratificante.<\/p>\n

Ma una delle cose che pu\u00f2 davvero aiutare fin dall'inizio \u00e8 la presenza di strutture che consentano al team di lavorare in modo efficace ed efficiente, soprattutto sul fronte dello sviluppo. L'ultima cosa di cui la vostra azienda ha bisogno \u00e8 il caos nella costruzione del vostro prodotto. \ud83d\ude31<\/p>\n

Quindi, come iniziare? E dovete esternalizzare o assumere internamente<\/a>?<\/p>\n

Di seguito una guida rapida per costruire e strutturare il vostro team di sviluppo SaaS<\/a>; se decidete di esternalizzare, potete usare questa guida anche come quadro di riferimento. \ud83e\udd29<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Categorizzazione dello sviluppo in azienda<\/strong><\/h4>\n

Uno degli elementi che possono aiutare a strutturare lo sviluppo \u00e8 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\u00e0, della delega e dell'organizzazione all'interno del team. \ud83e\udd1d<\/p>\n

Di seguito sono riportate le tre categorie di sviluppo di Salesflare:<\/p>\n

Problemi <\/strong>sono cose che non funzionano e che devono essere sistemate nel prodotto.<\/p>\n

Ma cosa ha la priorit\u00e0? E come si organizzano? Ecco perch\u00e9 abbiamo suddiviso i problemi in tre categorie aggiuntive: problemi immediati, stabilizzazione immediata<\/a> e problemi non immediati.<\/p>\n

I problemi immediati sono quelli che, come avete capito, devono essere affrontati immediatamente. Possono essere cose che sono veramente<\/em> rotte, cose che gli utenti notano, cose nell'app che devono essere sistemate, ecc. \ud83d\udea8<\/p>\n

<\/figure>\n

\"ragazzo.<\/p>\n

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

I problemi non immediati hanno una priorit\u00e0 inferiore e vengono discussi nella riunione di preparazione dello sprint (di cui si parler\u00e0 pi\u00f9 avanti).<\/p>\n

Miglioramenti UX <\/strong>hanno una priorit\u00e0 pi\u00f9 alta rispetto ai problemi non immediati e comprendono tutto ci\u00f2 che nello sviluppo riguarda l'esperienza e l'usabilit\u00e0 del prodotto. In sostanza, si tratta di cose che migliorano l'esperienza dei clienti.<\/p>\n

Caratteristiche <\/strong>sono nuove funzionalit\u00e0 che vogliamo aggiungere al prodotto, come azioni di massa, filtri avanzati, ecc. Si tratta della priorit\u00e0 pi\u00f9 bassa tra le attivit\u00e0 pianificate durante uno sprint.<\/p>\n

Sebbene la suddivisione dei tipi di sviluppo possa aiutare a organizzare meglio il team, come si fa a decidere chi si occupa di cosa?<\/p>\n

\n
\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Support Hero \u00e8 qui per salvare la situazione!<\/strong><\/h4>\n

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! \ud83d\udc68\u200d\ud83d\udcbb\ud83d\udc69\u200d\ud83d\udcbb<\/p>\n

Ecco perch\u00e9 utilizziamo un sistema che elimina le distrazioni e aumenta la produttivit\u00e0 del team di sviluppo. Lo chiamiamo \"Support Hero\".<\/p>\n

\n
<\/div>\n<\/figure>\n

\"superman\"<\/p>\n

Il Support Hero \u00e8 una persona del team di sviluppo, a rotazione giornaliera, che si concentra sui problemi immediati che devono essere affrontati (e risponde a domande pi\u00f9 approfondite e tecniche degli utenti), in modo che il team possa rimanere concentrato sui propri compiti. \ud83d\udcaa<\/p>\n

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.<\/p>\n

Il bello di avere un Support Hero \u00e8 che, anche con un team ridotto, potete offrire un'assistenza di alta qualit\u00e0 ai vostri clienti: qualsiasi problema tecnico approfondito pu\u00f2 essere risolto sul posto, evitando il frustrante processo di dover passare i problemi alla persona \"giusta\".<\/p>\n

La parte migliore: avere un Support Hero avvicina gli sviluppatori ai clienti. \ud83d\udc9b<\/strong><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00c8 tutta una questione di struttura<\/strong><\/h4>\n

Dopo aver parlato dei tipi di sviluppo e di come delegare i problemi, parliamo di come organizzare la struttura<\/em>. Tutti i diversi componenti che seguono si uniscono per informare il modo in cui il team procede.<\/p>\n

Una visione del prodotto e una roadmap <\/strong>pu\u00f2 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\u00f2 che raccogliete dal vostro supporto. \ud83d\udc53<\/p>\n

Supporto<\/strong> \u00e8 tutto per ottenere il feedback dei clienti<\/a>. Questo include le richieste di funzionalit\u00e0, 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.<\/p>\n

Un tracker di problemi<\/strong> 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 \u00e8 Elastic APM, ma ci sono molte opzioni in circolazione.<\/p>\n

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

Hotjar <\/strong>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\u00e9 potete vedere cosa fanno senza che debbano spiegarvelo.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00c8 ora di sprintare!<\/strong><\/h4>\n

Strutturate il lavoro del vostro team di sviluppo in sprint, una metodologia agile. Come linea guida generale, gli sprint di due settimane sono pi\u00f9 comuni per lo sviluppo di prodotti IT e software.<\/a> \ud83c\udfc3\u200d<\/p>\n

Tuttavia, \u00e8 consigliabile prepararsi prima delle riunioni di sprint, altrimenti le cose possono diventare un po' caotiche e fuori tema.<\/p>\n

Questo problema pu\u00f2 essere affrontato organizzando riunioni di preparazione allo sprint. Il CTO, il product owner e il product manager (per saperne di pi\u00f9 sulla differenza tra product owner vs product manager<\/a>) partecipano a questa riunione e utilizzano questo tempo per esaminare i problemi immediati che rimangono, i miglioramenti UX, i problemi non immediati e le funzionalit\u00e0. Questo aiuta a stabilire l'agenda e le priorit\u00e0 per lo sprint successivo senza dover sottrarre tempo alla riunione dello sprint stesso. \u2705<\/p>\n

Poi, naturalmente, \u00e8 il momento della riunione di sprint! La riunione di sprint approfondisce tecnicamente ci\u00f2 che \u00e8 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<\/a>. Possono partecipare anche il proprietario del prodotto e il team di supporto, ma in questa fase sono meno necessari.<\/p>\n

All'inizio di questa riunione \u00e8 bene riflettere sullo sprint precedente: cosa \u00e8 andato bene, cosa \u00e8 andato male, ecc.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Cosa c'\u00e8 nel vostro kit di strumenti?<\/strong><\/h4>\n

Gli strumenti che utilizzate all'interno dell'azienda possono garantire il successo del vostro team di sviluppo. Abbiamo gi\u00e0 parlato di Hotjar e Elastic APM, ma altri strumenti da considerare per una comunicazione pi\u00f9 snella e per la gestione delle attivit\u00e0<\/a> includono:<\/p>\n

Slack - <\/strong>per discussioni interne, aggiornamenti\/notifiche, condivisione di file e occasionalmente gif divertenti.<\/p>\n

Trello - <\/strong>per il compito\/gestione e monitoraggio dei progetti<\/a> chi fa cosa in un determinato sprint<\/p>\n

GitHub - <\/strong>dove teniamo traccia dei problemi, delle richieste di funzionalit\u00e0, ecc.<\/p>\n

Intercom - <\/strong>per comunicare con i clienti<\/p>\n

Un aspetto positivo dell'utilizzo di questi strumenti \u00e8 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. \ud83c\udf10<\/p>\n

Inoltre, possiamo collegare GitHub alle conversazioni di Intercom, in modo da avere sempre a portata di mano il contesto; e quando inviamo funzionalit\u00e0 o risolviamo problemi, possiamo comunicarlo senza errori.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Indipendentemente da come si decide di strutturare lo sviluppo in azienda, \u00e8 sempre importante assicurarsi che il team, piccolo o grande che sia, possa lavorare all'interno dei processi che si decide di utilizzare. \ud83d\ude80<\/p>\n

Non abbiate paura di cambiare le cose se non funzionano! La chiave \u00e8 trovare ci\u00f2 che funziona per voi e per la vostra azienda e seguire questa strada.<\/p>\n

Speriamo che questa rapida guida vi abbia dato un po' di ispirazione su come costruire e strutturare il vostro team di sviluppo!<\/p>\n

Avete altre idee fantastiche? Ditecelo nei commenti! \u2728<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Ti piace questo post? Date un'occhiata al resto del nostro <\/em>Interno Salesflare<\/em><\/a> serie.<\/em><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Per ulteriori informazioni su startup, growth marketing e vendite<\/em><\/p>\n

\ud83d\udc49<\/em><\/strong>iscriviti qui<\/em><\/strong><\/a><\/p>\n

\ud83d\udc49follow @salesflare on <\/em><\/strong>Twitter<\/em><\/strong><\/a> o <\/em><\/strong>Facebook<\/em><\/strong><\/a><\/p>\n<\/div>\n<\/div>\n<\/section>\n<\/section>\n