I nostri principi
Regole operative non negoziabili. Definiscono cosa accettiamo di fare e, soprattutto, cosa rifiutiamo.
I valori dicono chi siamo, i principi dicono cosa facciamo e cosa rifiutiamo di fare. Questi quattro non descrivono un'aspirazione: sono i criteri che applichiamo quando un nuovo progetto si presenta, quando una scelta tecnica ha più di una strada possibile, quando il cliente ci chiede qualcosa che potremmo fare ma che riteniamo sbagliato. Sono regole operative, e come tutte le regole hanno un costo: ogni principio elencato qui sotto, in qualche occasione, ci ha fatto perdere un'opportunità commerciale. Le abbiamo lasciate andare volentieri.
Niente soluzioni preconfezionate
Non abbiamo un "prodotto" da vendere, non riutilizziamo template spacciandoli per progetti su misura, non forziamo i problemi del cliente dentro framework che ci fanno comodo. Ogni intervento parte da zero nella comprensione del contesto, anche se il problema tecnico è simile a uno già affrontato. Perché il contesto cambia tutto: le stesse tecnologie, applicate in organizzazioni diverse, producono risultati radicalmente diversi. La personalizzazione non è un extra: è l'unico modo per fare le cose bene.
Diciamo no quando non siamo la risposta giusta
Non ogni problema è un nostro problema. Se il cliente ha bisogno di un team di sviluppo stabile da venti persone, non siamo noi. Se il problema è puramente gestionale e non tecnologico, non siamo noi. Se la soluzione esiste già sul mercato e non ha senso costruirla da zero, lo diciamo e indirizziamo altrove. Accettare un progetto che non possiamo gestire al meglio è un danno per il cliente e per la nostra reputazione. Preferiamo un no onesto oggi a un fallimento domani.
La tecnologia è un mezzo, non il fine
Non scegliamo una tecnologia perché è nuova, popolare o intellettualmente stimolante. La scegliamo perché risolve il problema specifico del cliente nel modo più efficiente, manutenibile e sostenibile nel tempo. A volte la risposta giusta è un foglio Excel ben strutturato, non un data warehouse. A volte è un'integrazione tra strumenti esistenti, non un software nuovo. Il nostro lavoro è trovare la soluzione proporzionata al problema: non la più sofisticata, non la più economica, ma quella giusta.
Lavoriamo per renderci meno necessari nel tempo
L'obiettivo di ogni nostro intervento è l'autonomia del cliente. Documentiamo tutto, trasferiamo competenze, costruiamo sistemi che il team interno può gestire e far evolvere senza dipendere da noi. Non creiamo lock-in tecnologico, non usiamo strumenti proprietari che ci rendano indispensabili, non teniamo per noi il know-how critico. Se un cliente continua a lavorare con noi, deve essere per scelta, perché trova valore nella collaborazione, non per dipendenza. Questo approccio ci costa progetti nel breve termine, ma costruisce relazioni che durano anni.
Come si applicano nei progetti
Niente soluzioni preconfezionate in pratica
Lo stesso problema, raccontato a parole, può richiedere architetture opposte in due aziende diverse. Un sistema di gestione ordini per una società che fattura su pochi grandi clienti istituzionali ha vincoli di tracciabilità e auditabilità che non si presentano in un e-commerce ad alto volume con clienti retail; il primo richiede transazioni rigorose, log immutabili, separazione netta tra stati, mentre il secondo può tollerare consistenza eventuale in cambio di throughput. Quando un cliente ci dice "ci serve la stessa cosa che ha fatto la nostra concorrente", la prima cosa che facciamo è capire cosa rende la sua organizzazione effettivamente diversa: il modello di ricavo, la struttura del team, i vincoli regolatori, la maturità dei processi a monte e a valle del software. Riusare un'architettura che ha funzionato altrove senza questa verifica produce sistemi che superficialmente girano ma che sbattono contro la realtà del cliente al primo cambiamento. Questo non significa partire ogni volta dalla pagina bianca: riusiamo pattern, conoscenza, lezioni apprese. Riusare schemi mentali è utile, riusare implementazioni è quasi sempre un errore mascherato da efficienza.
Diciamo no in pratica
I no più frequenti che pronunciamo riguardano tre situazioni. La prima è la richiesta di una capacità di sviluppo continuativa che assomiglia più a un team interno esteso che a una collaborazione consulenziale: in quei casi consigliamo di assumere, e spesso aiutiamo a definire i profili. La seconda è il problema travestito da problema tecnologico ma in realtà organizzativo: quando un sistema "non funziona" perché non c'è chiarezza su chi decide cosa, nessuna piattaforma risolverà la questione, e dirlo apertamente è più utile che vendere un'integrazione. La terza è la richiesta di costruire da zero qualcosa che esiste già in versione matura sul mercato: un CRM, un sistema di ticketing, una piattaforma di pagamento. La conversazione con il cliente in questi momenti è asciutta: spieghiamo perché non siamo l'interlocutore giusto, indichiamo dove cercare, e ci offriamo eventualmente di assistere nella selezione. Il costo commerciale di queste scelte è reale, ma la reputazione costruita su no espliciti vale più di qualsiasi progetto che avremmo accettato malvolentieri.
La tecnologia come mezzo in pratica
La proporzionalità è una disciplina che si esercita rifiutando la sofisticazione gratuita. Quando una piccola azienda ci chiede una piattaforma di analisi dati per gestire qualche migliaio di record che cambiano una volta al mese, raramente la risposta è un data warehouse cloud con orchestratore: spesso un foglio strutturato, qualche script di consolidamento e una procedura chiara battono in robustezza e costo qualsiasi architettura più ambiziosa. Quando un sistema legacy funziona, la soluzione di default non è la riscrittura ma l'integrazione: aggiungere un'interfaccia moderna sopra il vecchio motore, esporre API mirate, intervenire chirurgicamente sulle parti che davvero bloccano l'evoluzione. Quando esiste un prodotto commerciale che copre il novanta per cento del bisogno, integriamo quel prodotto e costruiamo solo il dieci per cento mancante, invece di reinventare la ruota. La domanda che ci poniamo a ogni decisione è la stessa: qual è il sistema più semplice che può funzionare per i prossimi tre o cinque anni, dato il volume reale di dati, di utenti e di evoluzione attesa? Quasi sempre la risposta è meno tecnologia di quella che il primo istinto suggerirebbe.
Renderci meno necessari in pratica
L'autonomia del cliente si costruisce con piccoli atti coerenti, non con dichiarazioni di intenti. La documentazione è un deliverable di prima classe, non un'appendice: quando consegniamo un sistema, chi lo riceve trova architettura, decisioni rilevanti, runbook operativi e percorso di onboarding scritti per essere letti, non per riempire un tab di Confluence. Le code review e le sessioni di pair programming con il team del cliente, quando esiste, sono il canale principale di trasferimento: il codice si capisce scrivendolo insieme, non leggendolo a posteriori. Sulle scelte tecnologiche evitiamo strumenti che generano lock-in non necessario, sia verso un fornitore cloud sia verso una libreria proprietaria, e quando il lock-in è inevitabile lo dichiariamo apertamente con un'analisi del costo di uscita. Esiste un rituale finale che non saltiamo: la riunione di chiusura in cui il team interno ripercorre il sistema senza di noi presenti come autori, solo come osservatori. Se in quella riunione qualcuno deve chiamarci per rispondere a una domanda fondamentale, non abbiamo finito il lavoro. L'economia di lungo periodo per il cliente è chiara: pagare per costruire competenza interna costa meno che pagare per dipendere da noi a tempo indeterminato.
Hai un problema tecnologico da risolvere?
Raccontaci la situazione. Rispondiamo entro 24 ore nei giorni lavorativi.