Servizi · software su misura
Vendiamo licenze Jmix in Italia. Due dei quattro sistemi presenti su questo sito sono costruiti su altro.
Quella frase è qui perché è l’unica cosa utile che un fornitore può dire sulla scelta tecnologica, e perché potete verificarla in quattro clic. Un’applicazione di pagamento in C# e .NET MAUI sopra un backend PHP e Laravel. Un sistema di rilevamento in Python. Una piattaforma di compliance su Jmix. Un sistema comunale sul framework che è diventato Jmix.
Discovery, architettura, costruzione, lancio e passaggio di consegne — su qualunque di quegli stack il sistema richieda davvero. La pagina che segue riguarda come si prende quella decisione, dato che tutto il resto della consegna end to end è la stessa promessa che fa ogni fornitore.
I quattro casi sono la parte pubblicata. Dietro di essi ci sono incarichi che non possiamo nominare: un prodotto le cui quattro applicazioni Flutter girano su un unico backend Node.js e TypeScript, una piattaforma con 3D interattivo nel browser su React e Next.js sopra .NET 6, e un portale costruito dal primo frame Figma alla produzione su Django, Vue e PostgreSQL. Le tecnologie sono elencate nella pagina the servizi; i clienti no, e questo è l’accordo che facciamo con tutti.
Il metodo effettivo
Ciò che il sistema è in prevalenza decide in che cosa è scritto
Non ciò che è di moda, non ciò in cui abbiamo ingegneri fermi, e non ciò che porta una licenza che per caso rivendiamo. La domanda è di che cosa il sistema è fatto in prevalenza — e poi una regola che prevale sulla risposta.
Interesse dichiarato
La parzialità che abbiamo, e cosa le impedisce di decidere la vostra architettura
Far Rainbow è venditore delle licenze Jmix in Italia. È un interesse commerciale reale in una delle quattro risposte qui sopra, e un fornitore che non lo dichiara vi sta chiedendo di scoprirlo da soli.
Tre cose la tengono onesta, e potete verificarle tutte e tre:
- Lo storico pubblicato. Due dei quattro sistemi presenti su questo sito non sono su quella piattaforma, e uno di essi è un’applicazione di pagamento che manteniamo ancora.
- Una revisione che può finire con un no. La revisione dell’architettura che precede una costruzione è impostata perché "non questa piattaforma" sia un esito normale, e il ragionamento vi arriva in un documento che potete portare a un altro fornitore.
- La licenza è il numero piccolo. Una decisione di piattaforma vi impegna per anni di ingegneria e di assunzioni. Sbagliarla costa un ordine di grandezza più di qualunque cosa guadagniamo su un abbonamento, il che rende il nostro interesse di lungo periodo e il vostro la stessa cosa.
Le cinque situazioni in cui diciamo no alla nostra piattaforma
Non sempre da zero
Prendere in carico codice scritto da altri
Una buona parte del lavoro che arriva qui non è un sistema nuovo. È un sistema esistente i cui autori sono andati via, il cui framework è stato abbandonato dal suo fornitore, o il cui rapporto con il fornitore è finito male. È un incarico diverso da una costruzione e inizia in modo diverso.
- Due settimane di lettura prima di qualsiasi progettazione. Il primo deliverable è un resoconto scritto di ciò che il sistema fa davvero, che con regolarità non è quanto dice la documentazione e spesso non è nemmeno quello che l’azienda crede.
- Prima la scadenza più rischiosa. Un framework non più supportato, un certificato in scadenza, un termine imposto dalla policy di uno store. Queste cose hanno una data attaccata, e le date non negoziano.
- Niente si spegne. Gli utenti continuano a usare il sistema mentre cambia sotto di loro. Sull’applicazione di pagamento che manteniamo, la migrazione del framework è avvenuta senza mettere giù il servizio.
Il caso: sostituire le fondamenta sotto un’app di pagamento mentre la gente ci pagava
L’incarico
Come si svolge davvero una realizzazione
01 · Prima la discovery
Da due a cinque giorni con le persone che conoscono il dominio e con quelle che manterranno il risultato. Produce l’ambito del primo rilascio, un elenco dei rischi e una raccomandazione — compresa la raccomandazione di non procedere.
02 · Un primo rilascio piccolo
Un solo flusso di lavoro, end to end, usato da persone reali in produzione. Il punto è che sia piccolo: è il solo modo affidabile di scoprire che cosa l’organizzazione fa davvero prima che il budget sia impegnato su una supposizione.
03 · Qualcosa da vedere, ogni due settimane
Una dimostrazione funzionante ogni due settimane, non un rapporto sullo stato. Un progetto in cui la prima sorpresa arriva alla fine è un progetto in cui nessuno stava guardando, ed è una mancanza del fornitore, non del cliente.
04 · Il vostro repository, dal primo commit
Non all’ultima fattura, e non come importazione di un codebase finito con la storia appiattita. La storia è il modo in cui il prossimo ingegnere scopre il perché.
05 · La vostra infrastruttura
Dove già vivono i vostri altri sistemi, con il vostro monitoraggio e i vostri backup. Possiamo ospitarlo durante la costruzione; andare in produzione sull’infrastruttura di un fornitore crea una dipendenza che nessuno ha scelto e che poi tutti mal tollerano.
06 · Un passaggio di consegne utilizzabile da altri
Verificato da una persona che non ha mai visto il progetto: clonare, compilare, distribuire, rilasciare una modifica, ogni passo senza chiedere a noi. La prova in cinque passi, per intero
Domande adiacenti
Tre casi in cui siamo il fornitore sbagliato
Un pacchetto lo fa già
Allora compratelo. Vi diremo in quale categoria cercare e che cosa verificare, e la conversazione vi costa una telefonata invece di un progetto. Scrivere software che esiste già è il modo più costoso di non distinguersi.
Avete il team, non le braccia
Se la conoscenza del dominio e la direzione tecnica sono vostre, comprare un’intera consegna significa comprare ciò che avete già — ingegneri dentro il vostro processo
Il fattore decisivo è la tariffa giornaliera
C’è sempre un team più economico, e su un sistema di due anni la tariffa giornaliera non è dove finiscono i soldi — finiscono nelle rilavorazioni causate dalla discovery che nessuno ha fatto. Se questo argomento non convince, il team più economico è la scelta giusta.
Domande
Quelle che decidono il contratto
Vendete licenze Jmix. Come sappiamo che non proporrete Jmix per tutto?
In parte chiedendolo, cosa che dovreste fare. Soprattutto guardando ciò che è già pubblicato qui: dei quattro sistemi presenti su questo sito, due sono costruiti su quella piattaforma e due no — un’applicazione di pagamento in C# e .NET MAUI con un backend PHP e Laravel, e un sistema di rilevamento in Python. La revisione dell’architettura che precede una costruzione può finire con "non questa piattaforma", e quando succede quella è la raccomandazione che ricevete per scritto. Preferiamo essere il fornitore che chiamate per il sistema successivo piuttosto che quello che vi ha venduto una piattaforma non adatta a questo.
Dovremmo proprio costruirlo, o comprare qualcosa?
Comprare, se il processo che descrivete è uno che migliaia di aziende gestiscono allo stesso modo — paghe, contabilità, CRM generico, helpdesk. Il software a pacchetto è enormemente più economico di qualunque cosa potremmo scrivere, e la mossa giusta è di solito cambiare il processo per adattarlo al pacchetto. Il su misura conviene quando il processo è l’azienda: quando ciò che fate in modo diverso è la ragione per cui i clienti scelgono voi, e un pacchetto vi costringerebbe a farlo come tutti gli altri.
Potete prendere in carico un sistema scritto da altri?
Sì, e lo abbiamo fatto — compresa un’applicazione di pagamento che girava su un framework che Microsoft aveva smesso di supportare un anno prima, che abbiamo preso in carico, migrato e mantenuto in produzione per tutto il tempo. Prendere in carico è un incarico diverso dal costruire: inizia con due settimane di lettura invece che di progettazione, e il primo deliverable è di solito un resoconto scritto di ciò che il sistema fa davvero, che raramente coincide con quanto dice la documentazione.
Come lo quotate?
Un prezzo fisso per fase, per una fase il cui ambito è noto. Prima la discovery, poi il primo rilascio, poi ogni ondata quotata su ciò che la precedente ha insegnato. Un prezzo fisso per un intero sistema i cui requisiti sono ancora in corso di scoperta è una scommessa, e chi la perde paga in margine o in un anno di discussioni su che cosa significasse "incluso".
Chi lo gestisce in produzione?
La vostra infrastruttura, per impostazione predefinita e per preferenza, con il vostro monitoraggio e la vostra policy di backup. Possiamo ospitarlo durante la costruzione se non avete ancora dove metterlo, ma un sistema che va in produzione sull’infrastruttura del fornitore tende a restarci, e questa è una dipendenza che nessuno ha scelto.
In che cosa consiste davvero il passaggio di consegne?
Un repository con la sua storia, una build che funziona su una macchina pulita, migrazioni di database da vuoto, un runbook e i registri delle decisioni. Lo verifichiamo facendo sì che qualcuno che non ha mai visto il progetto lo cloni, lo compili, lo distribuisca e rilasci una modifica, ogni passo senza dover chiedere a noi. Quella prova è scritta per intero sulla pagina Jmix ed è la stessa prova qualunque sia lo stack, ed è per questo che è enunciata una volta e non due. È lo standard a cui lavoriamo, non una promessa su un numero di ore.
Prossimo passo
Partite dal flusso di lavoro, non dal sistema
Il processo che fa più male, e la persona che ne è responsabile. È abbastanza per una discovery, e una discovery è abbastanza per sapere se valga la pena fare il resto — o se invece dovreste comprare qualcosa.
Discovery, poi un numero
L’ambito del primo rilascio, un elenco dei rischi e un prezzo fisso per la fase — o la raccomandazione di non costruirlo, che costa uguale.
ProveQuattro sistemi, quattro stack
Che cosa è stato costruito, che cosa è stato misurato, che cosa no, e che cosa non possiamo dire per contratto.