Il concetto di coda lunga è ormai ben noto. Coniato per la prima volta nel 2004 da Chris Anderson, caporedattore della rivista Wired, sintetizza l’importanza in termini di business delle nicchie di mercato generate dalla frammentazione della domanda.
Quella di spostarsi sempre più da un focus su un numero relativamente piccolo di “hit” (prodotti e mercati tradizionali) all’inizio della curva di domanda verso un numero enorme di nicchie nella coda è ormai un must del business, grazie anche alla diminuzione dei costi di produzione e distribuzione, soprattutto online.
Il concetto di coda lunga nella vita del software
Anche il software, come gli altri beni di consumo, è interessato da questo concetto. La questione presenta poi delle caratteristiche particolarmente interessanti se vista in parallelo con le fasi del ciclo di vita del prodotto digitale.
Abbiamo già discusso del ciclo di vita di un software. Un servizio digitale viene sviluppato in un preciso momento della storia di un’azienda per supportarne il business e viene calibrato sulla base delle esigenze di business del momento. Tuttavia, queste sono tutt’altro che stabili nel tempo e la loro evoluzione fa sì che un software, per non veder decadere la sua utilità, debba venir evoluto nel tempo.
Ma come evolvono le esigenze di business? Ovviamente non esiste una regola unica. Quello che accade molto di frequente però è che l’esigenza iniziale vada sviluppandosi lungo più direzioni. Di conseguenza, anche il software dovrà essere in grado di rispondere a esigenze divergenti. Ecco dunque che la fase di evoluzione del servizio digitale si configura a tutti gli effetti in un’ottica di coda lunga: il prodotto iniziale, una volta risposto alla una domanda di massa per cui è nato, ha la necessità di vedersi aggiungere nuove feature per intercettare interessi sempre più di nicchia e, così, continuare a essere appealing dal punto di vista commerciale.
Ti piace leggere?
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'
Abilitare la coda lunga
Come assicurarsi che un servizio digitale sia idoneo a venire evoluto per cogliere le opportunità di business della long tail? Indubbiamente, è essenziale che si possa mettere mano su di esso con tranquillità, senza rischiare che gli interventi causino malfunzionamenti ad altre parti del prodotto, ed in modo sicuro, disponendo del know how sul prodotto e della giusta comprensione sulla sua architettura.
Il software deve essere agevole da comprendere, evitando quelli che gli addetti ai lavori chiamano cruft, ovvero discrepanze tra il codice ideale e quello reale, ma anche ben suddiviso in moduli separati, per poter trovare rapidamente le righe di interesse per gli interventi futuri, e caratterizzato da una denominazione chiara, per capire rapidamente cosa fanno le sue singole parti del codice.
Un altro aspetto fondamentale per garantire che il software sia manutenibile, testabile e si presti a venire evoluto mantenendo la sua robustezza, è la sua modularità – che tra l’altro, è fondamentale anche per permettere a più persone di collaborare su di esso accelerando i processi di sviluppo.
La modularità è ottenibile in diversi modi: strutturando un servizio digitale basato su microservizi oppure mantenendo un’architettura unitaria ma ben organizzata in moduli – il cosiddetto “monolite modulare”, a seconda delle specifiche caratteristiche ed esigenze dell’applicazione.
Esistono dei metodi e delle pratiche precisi e ben rodati per garantire la robustezza e la modularità del software. Bottega52 investe attivamente risorse nella ricerca e definizione di queste pratiche, garantendo la robustezza necessaria a prodotti software di livello enterprise, e attivando modelli di gestione del rischio di malfunzionamenti uniche sul mercato.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'