La scorsa settimana, in risposta ad una delle mie newsletter (puoi iscriverti alla newsletter da QUI ), una persona mi ha scritto dicendomi:
“Ciao Marco, […] stiamo valutando Slope ma il nostro vecchio software aveva questa funzionalità, perché Slope non ce l’ha?”
Solo per dare un po’ di contesto, anche se non è un dettaglio determinante per il messaggio dell’articolo, si trattava di una funzionalità che consentiva di visualizzare un dato specifico in un report. Senza entrare troppo nel merito, una specifica camera di una certa tipologia andava analizzata attraverso KPI dedicati.
Aggiungere un filtro nel report di Slope non è qualcosa di tecnicamente complesso, e quando sei in trattativa di vendita con una struttura ricettiva, che apparentemente sembra essere in target, l’animo commerciale ti sale e la tentazione di rispondere “la aggiungeremo nella prossima release, non c’è problema!” diventa forte.
In fin dei conti si tratta di un’aggiunta semplice al software, modifica che ti fa chiudere il contratto, rende felice il cliente e porta pure in cassa del grano $. Ma assecondare queste implementazioni è esattamente quello che NON devi fare se vuoi sviluppare un software che cresca in modo sano e resti eccellente nel tempo.
Dopo un attimo di iniziale tentazione abbiamo risposto onestamente al potenziale cliente: quella funzionalità non sarà mai integrata in Slope, per un motivo molto semplice, perché non è una funzione che serve al cliente/hotel a cui ci rivolgiamo.
Nota bene: esiste comunque sempre una soluzione, quel dato può essere estratto tramite le API di Slope creando un report esterno al software. Puoi sviluppare il report in autonomia oppure affidarti ad una delle nostre aziende partner che occupano di sviluppo di connettori e cruscotti.
Il problema della “collezione di figurine”
Parlando ogni anno con tantissimi hotel, molti dei quali sono alla ricerca di una nuova soluzione software per la loro struttura, ne sento di cotte e di crude.
Uno di questi stereotipi è il “direttore collezionista“, ossia quella persona che si presenta alla prima demo con noi e porta con sé una check-list di funzionalità come quando da bambini scambiavamo le figurine Panini: “ce l’ho, ce l’ho, mi manca“. Ma ragionare così ti condanna a non evolvere mai.
Slope ormai ha la solidità per rispondere anche alle richieste più particolari, ma la riflessione che voglio proporre oggi va oltre questo aspetto.
Se ti basi solo su quello che avevi prima, non migliorerai mai i processi del tuo hotel. Il mercato evolve, le aspettative degli ospiti cambiano, la tecnologia avanza. Un software moderno dovrebbe guidarti verso l’efficienza, non replicare le inefficienze del passato digitalizzandole.
La vera domanda non è “il nuovo software fa tutto quello che faceva il vecchio?”, ma “il nuovo software mi fa lavorare meglio di prima?”.
Eppure molte software house cadono nella trappola della “feature factory“: misurano il successo dal numero di funzionalità rilasciate anziché dal valore creato. L’effetto è sempre lo stesso: software che nascono con un’idea chiara e diventano progressivamente un minestrone che non eccelle in nulla.
Ogni funzionalità che si aggiunge ad un software porta un bagaglio nascosto: manutenzione, testing per ogni rilascio, documentazione da aggiornare, formazione del supporto, complessità dell’interfaccia. Non è solo il tempo di sviluppo iniziale, è tutto quello che viene dopo.
Ma questo costo non lo paga solo la software house che sceglie di andare dietro alle richieste dello specifico cliente, come un ape che passa da un fiore all’altro senza un’apparente strategia, ma il costo lo paga il cliente che progressivamente si ritrova un software che si rallenta e si complica.
Il framework della scelta (spietata)
Ovviamente non sto dicendo di dire no ad ogni richiesta di nuova funzionalità, la differenza la fa la visione e la direzione che si sta dando al prodotto. Si aggiungono funzionalità e si ottimizzano parti del sistema solo se vanno verso la direzione (visione) che si sta dando al prodotto software.
Per restare pratici possiamo dire che ogni richiesta di nuova funzionalità deve rispondere a 4 domande.
Risolve un problema reale del nostro target?
Se serve solo a una nicchia di una nicchia, o se ci serve per chiudere solo un contratto allora si rimanda ad una implementazione ad hoc. Con le API aperte un hotel può incaricare una software house per automatismi specifici, senza complicare l’esperienza per tutti.
Si integra nell’ecosistema esistente?
Deve risolvere un problema per la nicchia di hotel che serviamo, non ottimizzeremo mai funzionalità per un motel o per un ostello, non sono il nostro target.
Mantiene la semplicità d’uso?
Se l’aggiunta che stiamo per fare stravolgere l’interfaccia utente, allora alt, si torna al tavolo di disegno. Prendere scorciatoie è pericoloso, si accumula debito che poi si paga, meglio fare un passo indietro, ristrutturare bene ed evitare di creare interfacce inconsistenti.
Il valore supera il costo di manutenzione?
Ogni riga di codice ha un costo di manutezione, teniamone conto e valutiamo se il rapporto costo/beneficio è vantaggioso.
È naturale che, così facendo, alcune trattative non vadano a buon fine: c’è sempre chi non acquista il software se non prometti di implementare la funzionalità esattamente come la desidera. Va bene così: probabilmente non sarebbe stato comunque un buon cliente. Dire di no a certe richieste porta infatti con sé diversi vantaggi:
- Interfaccia pulita. Solo quello che serve, senza pulsanti nascosti o menu infiniti che il 90% non usa mai.
- Stabilità superiore. Meno codice significa meno bug. Ogni test è più approfondito, ogni rilascio più sicuro.
- Clienti competenti. Un software intuitivo migliora l’esperienza dei clienti, la formazione del loro personale.
- Roadmap mirata. Ogni funzionalità nasce da esigenze reali del target, non da richieste casuali.
Il coraggio di non essere per tutti
Apple non fa smartphone per tutti i budget.
Tesla non fa auto per tutti i percorsi.
Slope non fa software per tutti i tipi di strutture ricettive.
Ammettere che il tuo prodotto non è universale richiede coraggio. Significa rinunciare a contratti, dire no a richieste apparentemente ragionevoli, resistere alla tentazione di inseguire ogni opportunità.
Ma è questa scelta che crea eccellenza. I nostri clienti sanno che ogni euro che investiamo va verso funzionalità che loro useranno davvero, verso un software che migliora costantemente nel risolvere i loro problemi specifici.
Quando un software non ha quella funzionalità che ti aspettavi, non considerarlo automaticamente un limite. Chiediti se quella mancanza sia proprio il motivo per cui eccelle in quello che fa. Se ci sono modi migliori per arrivare allo stesso risultato, magari in modo più efficiente e più scalabile.
E se la risposta è sì, probabilmente hai trovato il partner giusto.
