Come lavora Mokap: prima il problema, poi il software

“Ci serve un gestionale nuovo.”

“Dobbiamo rifare la nostra piattaforma.”

“Vorremmo automatizzare questo processo.”

“E se utilizzassimo l’intelligenza artificiale?”

Sono richieste con cui può iniziare un progetto software. Ma hanno qualcosa in comune: partono già da una possibile soluzione.

Il punto è capire se quella soluzione sia davvero la più adatta.

In Mokap preferiamo iniziare con qualche domanda in più. Non per complicare il progetto, ma per evitare di costruire qualcosa che aggiunga complessità invece di risolverla.

Immaginiamo un’azienda che voglia sostituire il proprio gestionale perché alcune attività richiedono troppo tempo.

Approfondendo, potrebbe emergere che il gestionale funziona, ma non comunica con altri strumenti. Le persone copiano informazioni tra email e fogli Excel, aggiornano gli stessi dati più volte e ricorrono a procedure manuali per gestire le eccezioni.

Serve davvero un nuovo gestionale? Forse. Oppure bastano alcune integrazioni, un’interfaccia riprogettata o uno strumento specifico per determinate attività.

Per scoprirlo dobbiamo capire chi utilizza il software, come lavora oggi, dove perde tempo e quali difficoltà incontra.

È il principio che chiamiamo Understanding Before Building: comprendere prima di costruire.

Non chiediamo soltanto cosa vuoi realizzare. Cerchiamo di capire cosa dovrebbe funzionare meglio.

La prima parte del nostro lavoro è dedicata a ricostruire il contesto.

Parliamo con le persone coinvolte, analizziamo i processi, osserviamo gli strumenti esistenti e individuiamo passaggi ripetitivi, errori e punti di attrito.

Ci interessano soprattutto le eccezioni.

Un processo può sembrare lineare durante una riunione, ma funzionare diversamente nella pratica. C’è chi gestisce alcune richieste fuori dal sistema, chi mantiene un file parallelo, chi conosce procedure che nessun altro ha documentato.

Sono dettagli importanti. Spesso è proprio lì che si nascondono i limiti di un software.

Consideriamo anche obiettivi, dati disponibili, vincoli tecnici e budget.

Il risultato non è semplicemente una lista di funzionalità, ma una comprensione condivisa del problema e delle priorità.

Perché sviluppare velocemente è utile. Ma se abbiamo compreso male il problema, rischiamo soltanto di costruire più velocemente la soluzione sbagliata.

Una volta compreso il contesto, iniziamo a dare forma alla soluzione.

È qui che entrano in gioco Product Design e UX/UI Design.

Definiamo l’architettura del prodotto, organizziamo le informazioni, progettiamo i flussi e stabiliamo le funzionalità necessarie. Poi trasformiamo queste decisioni in wireframe, prototipi e interfacce.

Non si tratta semplicemente di scegliere colori e posizionare pulsanti.

Il design serve prima di tutto a decidere come deve funzionare il prodotto.

Se un responsabile deve approvare decine di richieste ogni giorno, non basta creare una schermata con un elenco e un pulsante “Approva”.

Bisogna capire quali informazioni servono per decidere, quali richieste hanno priorità e cosa succede quando qualcosa non va come previsto.

È questo il significato di Design Before Code. E anche di Clarity by Design: la chiarezza non viene aggiunta alla fine, ma guida il progetto fin dall’inizio.

Un prototipo permette di vedere e discutere il prodotto prima che sia completamente sviluppato.

Possiamo simulare operazioni, verificare i flussi con chi utilizzerà lo strumento e individuare funzionalità inutili, passaggi complicati o requisiti mancanti.

È anche il momento in cui possono emergere incomprensioni tra le persone coinvolte nel progetto.

Correggere un flusso in un prototipo è generalmente più semplice e meno costoso che modificarlo quando coinvolge già codice, database e integrazioni.

Non tutto può essere previsto. Ma chiarire le decisioni importanti prima dello sviluppo aiuta a ridurre errori, modifiche e lavoro da rifare.

In molti progetti, il design viene trattato come un’attività separata: qualcuno disegna le schermate, consegna un file Figma e qualcun altro si occupa di trasformarlo in codice.

In Mokap lavoriamo diversamente.

Siamo una Software Design Company: uniamo Product Design, UX/UI Design e Software Development nello stesso percorso di lavoro.

Designer e sviluppatori si confrontano fin dalle prime decisioni.

Una scelta tecnica può influenzare il comportamento di un’interfaccia. Una soluzione progettuale può semplificare lo sviluppo. Un vincolo emerso durante la costruzione può suggerire un modo migliore di organizzare un flusso.

Non consideriamo il design un documento intoccabile, né il codice una semplice esecuzione di istruzioni.

Design e sviluppo sono competenze diverse che lavorano sullo stesso problema.

Questo approccio guida il nostro lavoro nello sviluppo software su misura: realizzare prodotti che rispondano ai processi reali delle aziende, considerando insieme esperienza d’uso, fattibilità tecnica e sostenibilità nel tempo.

Durante un progetto è facile aggiungere qualcosa.

Un nuovo filtro. Un’automazione in più. Un’altra schermata. Una funzione che potrebbe tornare utile in futuro.

Ma ogni elemento introduce complessità: deve essere progettato, sviluppato, mantenuto e compreso da chi utilizza il prodotto.

Per questo ci chiediamo sempre se una funzionalità generi un valore sufficiente a giustificare ciò che aggiunge.

È il principio Complexity Must Earn Its Place.

Non significa eliminare funzioni importanti per avere un prodotto minimalista. Alcuni processi sono complessi per natura.

Significa distinguere ciò che è necessario da ciò che è superfluo.

A volte la scelta migliore non è aggiungere una funzione, ma eliminare un passaggio o automatizzare un’operazione ripetitiva.

La semplicità non significa fare meno. Significa rendere più semplice fare ciò che serve.

Linguaggi, framework, infrastrutture e integrazioni sono decisioni importanti. Influenzano prestazioni, sicurezza, manutenzione e possibilità di evoluzione.

Ma devono essere scelti in funzione del prodotto, non il contrario.

Lo stesso vale per l’intelligenza artificiale.

Non ogni processo ha bisogno di AI. A volte bastano regole chiare, dati organizzati o un’automazione tradizionale. In altri casi, l’AI può offrire vantaggi concreti.

La domanda non è quale tecnologia possiamo utilizzare, ma quale tecnologia aiuta davvero a risolvere il problema.

Il lancio non è la fine del prodotto. È il momento in cui il software inizia a confrontarsi con il lavoro quotidiano.

Le persone lo utilizzano, emergono nuove esigenze e alcune priorità cambiano.

Possiamo osservare quali attività richiedono ancora troppo tempo, dove si verificano errori e quali parti del prodotto possono essere migliorate.

Evolvere, però, non significa aggiungere continuamente funzionalità.

A volte significa semplificare ciò che esiste, migliorare le prestazioni o riprogettare un flusso.

L’obiettivo rimane quello iniziale: aiutare le persone a lavorare meglio.

Quando un’azienda decide di sviluppare un software su misura, è naturale concentrarsi su funzionalità, tempi e tecnologie.

Sono aspetti importanti. Ma prima c’è una domanda da affrontare: abbiamo capito davvero cosa deve cambiare?

È da qui che partiamo in Mokap.

Comprendiamo il problema, progettiamo la soluzione, la costruiamo facendo lavorare insieme design e sviluppo, poi la miglioriamo attraverso ciò che impariamo dall’utilizzo reale.

Non è una formula da applicare rigidamente. È semplicemente il modo in cui crediamo debba essere costruito un buon software.

Prima le persone. Prima i processi. Prima la comprensione.

Poi il codice.