La checklist ha otto parti. Ogni voce è una domanda con risposta sì o no. Un «no» non è un motivo per rifiutare il sistema. È una riga del piano.
Il guaio più comune nelle prese in carico è scoprire, dopo settimane, che un account critico appartiene a qualcuno che se n’è andato.
Se anche una sola risposta è «non lo sappiamo», fermatevi e scoprite la risposta prima di cambiare qualsiasi cosa.
Il repository dice cosa era previsto. La produzione dice cosa è vero.
I dati sono la parte di un sistema che non si può rigenerare.
Durante la revisione ripristinate un backup in un luogo sicuro. Un backup che non è mai stato ripristinato è una speranza, non un backup.
Dovrete modificare il sistema. Scoprite quanto è pericoloso farlo.
Se l’ultima risposta è no, sistemare quel percorso è il primo compito tecnico, prima di qualsiasi funzionalità.
Non è un penetration test. È il minimo che dovete sapere prima di diventare proprietari del sistema.
Fate domande sulle decisioni, non sul codice: perché questo database, perché questo hosting, cosa cambierebbero, di cosa avevano paura. Registrate le risposte.
Scrivete le risposte in un unico documento, con un elenco dei «no» ordinato per rischio. L’ordine diventa le prime settimane di lavoro: prima accessi e fatturazione, poi backup e deploy, poi le parti fragili, poi quelle desiderate. Una presa in carico fatta in questo ordine mostra all’azienda una nuova funzionalità più tardi di quanto sperasse e un’interruzione del servizio mai.
Se preferite che siamo noi a eseguire questa revisione e a prendere in carico il sistema in seguito, è proprio ciò che fa il nostro servizio di presa in carico del software. Se volete eseguirla da soli, la checklist è vostra.
]]>Se state confrontando più fornitori, chiedete a ciascuno un preventivo per lo stesso ambito di lavoro. Un canone mensile che esclude deploy, aggiornamento delle dipendenze e analisi degli incidenti non è confrontabile con uno che li include.
Il prezzo della realizzazione originale non dice a un nuovo fornitore se i vostri backup si ripristinano, se le dipendenze sono ancora supportate o se l’integrazione dei pagamenti fallisce in silenzio. Prima di considerare una stima come un impegno, stabilite cosa gira in produzione e quali parti richiedono attenzione.
Annotate:
Se lo sviluppatore originale se n’è andato, usate la checklist per la presa in carico del codice per individuare gli accessi e le conoscenze che mancano. Potete raccogliere queste informazioni anche senza aver ancora scelto un nuovo fornitore.
Un nuovo team deve capire cosa gira in produzione, verificare gli accessi, impostare un deploy ripetibile e controllare che il ripristino funzioni. Documentazione mancante o un framework non più supportato possono aggiungere lavoro prima che inizi la manutenzione ordinaria.
Chiedete cosa consegna l’ambito iniziale e cosa comporterebbe una revisione della stima. Tenetelo separato dall’impegno mensile continuativo, così entrambe le parti vedono il costo di ereditare il sistema.
Elencate il lavoro pianificato: aggiornamenti delle dipendenze e di sicurezza, controlli sui rilasci, prove di ripristino dei backup, monitoraggio e documentazione operativa. Concordate con che frequenza avviene ciascuna attività e quali riscontri ricevete.
Anche le fatture di hosting, database, email e altri fornitori rientrano nel budget di esercizio. Specificate se le pagate direttamente o tramite il fornitore della manutenzione. Il tempo di sviluppo e le fatture dell’infrastruttura sono costi diversi.
Specificate gli orari di copertura, il fuso orario, il canale di contatto e cosa si considera urgente. Il tempo di risposta indica che qualcuno inizia a valutare il problema; non significa che il problema sia risolto entro quel tempo.
Per un’azienda che si affida a un team remoto, discutete la sovrapposizione degli orari in modo esplicito. Non date per scontato che un accordo di manutenzione mensile comprenda risposte notturne o nel fine settimana.
Separate la correzione dei difetti dalle modifiche al funzionamento del prodotto. Una nuova integrazione o una modifica importante a un flusso richiedono un ambito di lavoro, anche quando manutenzione e sviluppo sono affidati allo stesso team.
Concordate come si definiscono le priorità, come si approvano le stime e cosa succede quando in un mese c’è più lavoro della capacità disponibile. Questa discussione conta più dell’etichetta sul pacchetto.
Compilate queste voci prima di confrontare i preventivi:
Per ogni preventivo, chiedete al fornitore di indicare cosa è incluso, escluso o ancora non noto. Chiedete come vengono trattati la capacità non utilizzata e il lavoro oltre l’ambito concordato. Non date per scontato che l’una venga riportata al mese successivo né che l’altro sia fatturato automaticamente.
Un fornitore può legittimamente offrire un servizio circoscritto. Il rischio è un vuoto di cui nessuno è responsabile: assistenza all’applicazione senza aggiornamento delle dipendenze, monitoraggio senza una persona che riceva gli avvisi, backup senza una verifica di ripristino.
Chiedete chi è responsabile di ciascun vuoto. Potete tenere internamente un’attività, assumere uno specialista o includerla nell’ambito della manutenzione. Il risultato utile è una responsabilità esplicita.
Se l’applicazione è supportata e semplice da rilasciare, può bastare una manutenzione ordinaria ricorrente. Se prima serve un aggiornamento del framework, la riparazione del deploy o una migrazione dei dati, definite quel lavoro a parte.
La nostra guida riparare o riscrivere il software aiuta a distinguere un intervento mirato da una sostituzione. Il budget di manutenzione dovrebbe riflettere questa decisione, senza nascondere un progetto di modernizzazione dentro la manutenzione di routine.
AL+ offre servizi di manutenzione software per applicazioni web e prodotti SaaS esistenti, compresi i sistemi realizzati da un altro sviluppatore o da un’altra agenzia.
Scrivete a paul@alplustech.com della manutenzione software. Descrivete l’applicazione, il suo stack se lo conoscete, il vostro paese, il problema attuale e gli orari di assistenza di cui avete bisogno. Inviate prima una descrizione; password, chiavi API e dati dei clienti non vanno nell’email.
]]>Sono acquisti diversi. Una dimostrazione curata non comprende necessariamente la gestione dei dati, i permessi, il processo di rilascio o l’assistenza che servono a un prodotto funzionante. Prima di confrontare le proposte di sviluppo, indicate la domanda a cui volete che il lavoro risponda.
Le etichette cambiano da un team all’altro. Concordate il risultato atteso, invece di fidarvi del nome usato in una proposta.
Su uno schermo stretto, scorrete la tabella in orizzontale per leggere tutte le colonne.
| Cosa si consegna | A quale domanda risponde | Cosa dovreste poter osservare | Cosa non dimostra |
|---|---|---|---|
| Prototipo | Gli utenti capiscono e riescono a completare questa interazione proposta? | Le persone provano un percorso limitato; vedete dove esitano o fraintendono. | Integrazioni affidabili, funzionamento in produzione o disponibilità a pagare. |
| Proof of concept | Un determinato approccio tecnico può funzionare entro i vincoli rilevanti? | Un esperimento circoscritto dimostra una capacità, come leggere da un fornitore i dati necessari. | Un prodotto completo o un’esperienza utilizzabile dal cliente. |
| MVP | Un piccolo prodotto funzionante può offrire il valore previsto ai primi utenti? | Utenti reali completano il compito principale; raccogliete feedback e osservate l’uso. | L’adeguatezza al mercato, un’acquisizione clienti redditizia o la prontezza per ogni futuro cliente. |
Un prototipo può essere uno schizzo su carta, un design cliccabile o un’interfaccia programmata e limitata. La sua utilità sta in ciò che si impara, non nella quantità di codice. La guida GOV.UK sulla fase alpha (in inglese) fa la stessa distinzione pratica: mettere alla prova le ipotesi rischiose con prototipi, senza trattare il codice sperimentale come software di produzione.
Un MVP può essere offerto a un piccolo gruppo di invitati. Non ha bisogno di tutte le funzionalità, ma chi lo usa deve poter completare il compito promesso e ottenere aiuto quando qualcosa non funziona.
Chiedetevi che cosa potrebbe rendere sprecato il prossimo impegno di sviluppo.
Non siete obbligati ad acquistarli tutti e tre in sequenza. Se il flusso è già chiaro e la tecnologia è consolidata, un prototipo separato può aggiungere poco. Se un’integrazione necessaria non può funzionare, costruire prima il resto del prodotto è l’ordine sbagliato.
Pensate a un ipotetico prodotto di prenotazione. I clienti devono scegliere un appuntamento disponibile, ricevere una conferma e modificare la prenotazione se serve. È un esempio illustrativo, non un risultato ottenuto per un cliente di AL+.
Un prototipo potrebbe mostrare la scelta dell’appuntamento, la schermata di conferma e il percorso di annullamento. Verificate se le persone capiscono le scelte e se il personale riesce a usare la vista amministrativa proposta. Appuntamenti e conferme possono essere simulati, purché lo si spieghi ai partecipanti.
Un proof of concept potrebbe esaminare il fornitore del calendario. L’applicazione può leggere la disponibilità, creare una prenotazione e riconoscere una modifica in conflitto, con gli accessi che l’azienda può ottenere? Documentate cosa ha verificato l’esperimento, l’ambiente usato e cosa resta non verificato.
Un MVP potrebbe permettere a un gruppo limitato di fare prenotazioni reali per un servizio in una sede. Servirebbero anche le regole pertinenti su fusi orari, conflitti, annullamenti, accesso del personale e recupero dopo un guasto. Una grande dashboard di reportistica può aspettare; impedire che due persone prenotino lo stesso orario, no.
La decisione riguarda l’incertezza e il risultato promesso. «Solo cinque schermate» non basta a distinguere questi ambiti.
Compilate queste sei righe. Se non riuscite a rispondere a una, registratela come domanda aperta invece che come ipotesi.
Per l’esempio della prenotazione, una frase di accettazione potrebbe essere: «Un cliente invitato può prenotare un orario davvero disponibile, ricevere la conferma e annullarla; il personale vede la modifica». Descrive il comportamento del prodotto. «L’app ha una schermata di prenotazione» descrive un’interfaccia e lascia irrisolto il lavoro importante.
Usate la guida al costo di sviluppo di un MVP (in inglese) per confrontare le stime della stessa consegna e delle stesse esclusioni.
Un ambito ridotto non elimina le responsabilità che nascono con utenti e dati reali. Individuate quali valgono per voi prima del lancio:
Questi requisiti devono corrispondere al rilascio effettivo. Non aggiungete infrastruttura per una scala immaginaria, ma non tralasciate un percorso di recupero per informazioni che non potete permettervi di perdere. La guida GOV.UK sulla fase beta (in inglese) offre un modello utile: invitare un gruppo limitato, imparare dall’uso reale e pianificare la capacità di sostenere quell’apprendimento.
A volte sì. Prima verificate che cosa contiene davvero il prototipo. L’interfaccia può essere riutilizzabile, mentre dati simulati, autenticazione provvisoria o configurazioni solo locali vanno sostituiti. Il codice scritto per un esperimento può costare meno da scartare che da rendere affidabile.
Chiedete allo sviluppatore di separare il lavoro riutilizzabile, il lavoro di produzione che manca e le ipotesi non risolte. Un prototipo realizzato con l’AI richiede la stessa revisione; una dimostrazione convincente prova che la dimostrazione funziona, non che il prodotto sia pronto per i clienti.
AL+ offre lo sviluppo di MVP a chi avvia un’attività e ha bisogno di un primo percorso completo e di una proprietà chiara dopo il lancio. Inviateci il brief di sei righe, l’eventuale prototipo esistente e i vincoli di budget o di tempo.
Scrivete ad AL+ del vostro prototipo o MVP. Potremo discutere quale tipo di consegna risponde alla domanda a cui dovete rispondere.
]]>Usate questa checklist prima di chiedere una proposta. Vi aiuta a confrontare ciò che i fornitori consegneranno davvero, invece di confrontare i prezzi di interpretazioni diverse della stessa idea.
Scrivete una frase: «Un [utente] deve [svolgere un compito] per ottenere [un risultato utile]». Ad esempio, un responsabile operativo deve approvare una prenotazione senza copiare le informazioni tra tre sistemi. È un flusso a titolo illustrativo, non un risultato ottenuto per un cliente.
Elencate le altre persone coinvolte. Un cliente, un amministratore e un addetto all’amministrazione possono avere bisogno di permessi diversi anche quando lavorano sullo stesso record.
Spiegate il processo attuale, compresi fogli di calcolo, email e controlli manuali. Indicate il passaggio che fa perdere tempo o provoca errori. Aggiungete un esempio anonimizzato dei dati in ingresso e del risultato atteso.
Non inviate password, anagrafiche dei clienti o credenziali di produzione nella prima email. Descrivete i sistemi coinvolti; gli accessi opportuni si organizzano dopo l’accordo sul progetto.
Scegliete un flusso che un utente reale possa portare a termine. Specificate cosa lo avvia, cosa fa il software e come l’utente capisce che è andato a buon fine. Includete il percorso di errore: cosa succede quando un dato è sbagliato, un’approvazione viene rifiutata o un’integrazione non è disponibile?
Mettete tutto il resto in un elenco separato, per dopo. Un primo rilascio piccolo può avere meno funzionalità, ma richiede comunque una gestione affidabile dei dati, il controllo degli accessi e un modo per ripartire dopo un guasto.
Indicate ogni servizio esterno, le informazioni scambiate e chi controlla l’accesso. Dite se il fornitore ha un’API documentata e se esiste un accesso di prova. Sono domande da chiarire, non capacità da dare per scontate.
Se i dati devono essere spostati da un vecchio sistema, descrivetene il formato, le dimensioni approssimative, i problemi di qualità e il periodo in cui i due sistemi potrebbero dover funzionare insieme. La migrazione è un lavoro in più rispetto alla realizzazione delle nuove schermate.
Indicate i limiti di budget, l’eventuale scadenza fissa e il suo motivo, i requisiti di accessibilità, i vincoli sulla localizzazione dei dati e chi userà il sistema. Se i requisiti richiedono una consulenza legale o di sicurezza specialistica, dite chi la fornirà.
Per il lavoro a distanza, concordate come verranno registrate le decisioni, chi può approvare l’ambito di lavoro e quale sovrapposizione di orari è necessaria. Una decisione ferma può ritardare la consegna anche quando la realizzazione è lineare.
Il costo dello sviluppo software dipende dai flussi, dalle regole sui permessi, dalle integrazioni, dal lavoro sui dati e dai requisiti di esercizio. Lo stesso numero di schermate può nascondere quantità di lavoro molto diverse.
Chiedete a ogni fornitore di separare l’ambito noto dalle ipotesi. Confrontate queste cinque voci:
Un prezzo senza questi confini è difficile da confrontare. Questa checklist non fornisce un prezzo universale per i progetti: una stima credibile richiede i requisiti reali.
Scrivete le verifiche in termini d’uso: «Un operatore può approvare una richiesta, il cliente riceve l’aggiornamento corretto e la decisione viene registrata». Definite esempi rappresentativi e gli errori che il sistema deve gestire.
Concordate come seguire l’avanzamento e provare i rilasci. Concordate anche a chi appartengono il repository, gli account dell’infrastruttura, la documentazione, il processo di deploy e i backup. La checklist per la consegna del software (in inglese) descrive i materiali che dovreste poter ricevere.
La prima email può essere breve: l’utente, il flusso, ciò che esiste oggi, l’integrazione importante e i vincoli di budget o di tempo. Non serve una specifica completa.
AL+ offre servizi di sviluppo di software su misura, con il codice che resta vostro dopo il lancio. Scrivete a paul@alplustech.com con questi dettagli per parlare del vostro progetto con le persone che lo realizzerebbero.
]]>Le riscritture raramente si propongono perché il sistema è tecnicamente irrecuperabile. Si propongono perché nessuno nel team attuale capisce il sistema, e ricostruirlo sembra l’unico modo per riavere quella comprensione.
È una motivazione onesta. È anche il modo più costoso di raggiungere l’obiettivo. Una riscrittura ricrea la conoscenza ricreando il software, e tutto ciò che il vecchio sistema ha imparato in anni di produzione, ogni caso limite e ogni correzione, va imparato da capo.
Il secondo motivo più comune è la frustrazione. Modifiche lente, incidenti ricorrenti e uno stack poco conosciuto rendono allettante ripartire da zero. La frustrazione è reale. Il rimedio, di solito, è una responsabilità chiara, non la sostituzione.
Non rispondiamo alla domanda «riparare o riscrivere?» nel primo incontro. Rispondiamo dopo una revisione che copre cinque aspetti.
Cosa fa il sistema. Non ciò che dice la documentazione o che ricorda il fondatore. Ciò che fa in produzione, per quali utenti e con che frequenza. Molte riscritture vengono dimensionate su un uso immaginato.
Dove sta il rischio. Quali parti si rompono, quali non le tocca nessuno e quali contengono dati che non si possono perdere. Di solito il rischio è concentrato in una piccola parte del codice.
Se si può modificare in sicurezza. C’è un modo per rilasciare una modifica e sapere che ha funzionato? Ci sono test, ambienti di staging, backup e rollback? Se non ci sono, vengono prima di tutto, qualunque sia la decisione finale, perché una riscrittura senza di essi è solo una versione più grande dello stesso problema.
Quanto costa mantenere lo stack. Framework e runtime arrivano a fine vita. Le spese di hosting crescono. Per alcuni stack è difficile trovare sviluppatori. Sono costi reali, ma misurabili, e spesso più piccoli di una riscrittura.
Di cosa avrà bisogno l’azienda in futuro. Un sistema che richiede tre piccole funzionalità all’anno ha esigenze diverse da uno che deve raddoppiare le proprie capacità. La decisione sulla riscrittura dipende dalla destinazione, non solo dallo stato attuale.
La riparazione è la risposta giusta più spesso di quanto i team si aspettino. I segnali:
Riparare significa stabilire la responsabilità, aggiungere le protezioni (test attorno alle parti rischiose, monitoraggio, deploy affidabili) e poi migliorare il sistema sul posto, una modifica circoscritta alla volta. Gli utenti vedono prima la stabilità e poi i miglioramenti. Nulla viene buttato finché il suo sostituto non è dimostrato.
Alcuni sistemi devono davvero essere sostituiti. I segnali sono specifici:
Anche in quel caso, dove è possibile riscriviamo per parti. Un nuovo sistema che rileva una responsabilità alla volta dal vecchio mantiene l’azienda in funzione e lascia la decisione reversibile.
I cinque aspetti della revisione si riducono a una piccola tabella. Assegnate un punteggio a ogni riga per il sistema che avete davanti; la colonna con più segni indica la raccomandazione, e un solo «sostituire» nella riga della piattaforma prevale sul resto.
| Domanda | Indica la riparazione | Indica la modernizzazione sul posto | Indica la riscrittura o la sostituzione |
|---|---|---|---|
| La piattaforma è supportata? | Sì, versioni attuali | Sì, ma con diversi passaggi di aggiornamento arretrati | No, e non si può aggiornare |
| Il modello dei dati è adatto all’azienda? | Sì | In gran parte; alcune strutture ostacolano le nuove funzionalità | No; ogni funzionalità lo aggira |
| Esiste un modo sicuro per modificarlo? | Sì | In parte; per alcune parti ci sono test e rollback | No, e aggiungerli costa più di quanto valgano le parti |
| Dov’è il rischio? | Concentrato in due o tre moduli | Distribuito su uno strato che si può sostituire da solo | Ovunque; non c’è un progetto coerente da preservare |
| Quanto se ne usa ancora? | La maggior parte | La maggior parte, con aree inutilizzate da eliminare | Una minoranza; il resto serve casi che non esistono più |
| Di cosa ha bisogno l’azienda dopo? | Piccole funzionalità e stabilità | Nuove capacità significative sulla stessa base | Un prodotto diverso |
Riparare è manutenzione con un piano. Modernizzare sul posto è il nostro servizio di riparazione e modernizzazione. Una riscrittura si fa comunque per parti dove possiamo, con il vecchio sistema in funzione finché ogni parte non si è dimostrata valida.
Capire il sistema, renderlo sicuro da modificare, poi decidere. I team che saltano direttamente alla riscrittura saltano la parte in cui si impara che cosa si sta sostituendo, e quella conoscenza è la cosa più costosa da ricostruire.
]]>«Le persone la useranno da mobile» non risolve la decisione. Un’applicazione web può funzionare in un browser mobile. Neanche «ci serve l’accesso offline» basta: il comportamento offline va progettato, e alcune applicazioni web possono supportarlo. La domanda utile è quale approccio può realizzare il vostro flusso reale con vincoli accettabili.
Un’applicazione web gira in un browser. Gli utenti di solito la raggiungono tramite un URL, e l’interfaccia può adattarsi a telefono, tablet o computer. Le sue capacità dipendono dai browser e dai dispositivi che decidete di supportare.
Un’applicazione mobile nativa è costruita per una piattaforma specifica, come iOS. Si installa sul dispositivo e usa le convenzioni di interfaccia e le API disponibili di quella piattaforma. Supportare un’altra piattaforma nativa comporta ulteriore lavoro di consegna e di verifica.
Una progressive web app, o PWA, usa tecnologie web con funzioni aggiuntive come l’installazione e un comportamento offline progettato. La documentazione MDN sulle PWA (in inglese) ne spiega le possibilità. Disponibilità e comportamento vanno comunque verificati sui dispositivi di destinazione; «PWA» non è una promessa che ogni funzione nativa funzioni ovunque.
Usate i requisiti qui sotto per scegliere il primo canale del prodotto.
Su uno schermo stretto, scorrete la tabella in orizzontale per leggere tutte le colonne.
| Requisito | Web app: cosa verificare | App nativa: cosa verificare |
|---|---|---|
| I clienti arrivano tramite un link | Possono completare il percorso nei browser supportati senza installare nulla? | Installare un’app è un passaggio accettabile prima che ricevano valore? |
| Il lavoro si svolge tra computer e telefono | Layout e interazioni sono adatti a entrambi? | Gli utenti da computer avranno bisogno anche di un’interfaccia web? |
| Una funzione del dispositivo è essenziale | L’API necessaria è disponibile e affidabile sui browser esatti che dovete supportare? | La piattaforma offre la funzione, e quali permessi e restrizioni si applicano? |
| La connessione non è affidabile | Quali azioni funzionano offline e come si sincronizzerà il lavoro salvato? | Valgono le stesse domande; l’installazione da sola non fa funzionare offline le azioni che dipendono dal server. |
| Servono più piattaforme | Verificate il comportamento sulle combinazioni di browser e dispositivi supportati. | Definite l’ambito di ogni piattaforma e i test, il lavoro di rilascio e la manutenzione che richiede. |
| I rilasci devono cambiare spesso | Pianificate deploy, compatibilità e ripristino per le modifiche al servizio in esecuzione. | Considerate anche distribuzione, revisione dove prevista e utenti con versioni dell’app più vecchie. |
Non trattatela come un punteggio in cui vince chi ha più segni. Una sola funzione essenziale può determinare l’approccio. Molte preferenze non bastano a giustificare canali di prodotto in più.
Un portale di approvazione per i clienti: i clienti ricevono un link, esaminano documenti, approvano il lavoro e a volte completano il compito dal telefono. Il personale gestisce i dati alla scrivania. Una web app responsive è una prima candidata ragionevole. Prima di costruire un’app, verificate se l’installazione migliorerebbe in qualche modo il percorso importante.
Uno strumento per la raccolta di dati sul campo: il personale registra informazioni durante la giornata in luoghi con scarsa connettività. Il prodotto richiede un comportamento specifico del dispositivo, dati locali e una sincronizzazione successiva. Valutate un’app nativa e una PWA rispetto a quei requisiti precisi. Un piccolo esperimento sulle capacità, fatto sui dispositivi reali, può risolvere la scelta più utilmente di un confronto generico tra funzionalità.
Sono flussi ipotetici, non affermazioni su risultati ottenuti per clienti di AL+. Il primo privilegia l’accesso semplice da più dispositivi; il secondo mette al centro il comportamento del dispositivo e della connessione. Nessuno dei due determina l’architettura di tutti i prodotti della sua categoria.
Descrivete cosa succede prima, durante e dopo la perdita della connessione:
Una schermata in cache e una transazione aziendale offline sono requisiti diversi. Per esempio, mostrare un appuntamento caricato in precedenza non dimostra che una nuova prenotazione possa essere confermata senza raggiungere il sistema che gestisce la disponibilità.
Sia le implementazioni native sia quelle web richiedono decisioni su dati, conflitti e ripristino. Consultate la documentazione della piattaforma interessata e verificate il comportamento critico, invece di darlo per scontato solo per il nome di una tecnologia.
Un’app installata può comunque dipendere da account, record condivisi, pagamenti, notifiche e strumenti di amministrazione che girano altrove. Anche un’applicazione web può avere bisogno degli stessi servizi.
Per entrambi gli approcci, individuate quale backend esiste già, chi lo controlla, quali interfacce sono disponibili e cosa va costruito. Portare l’interfaccia sul telefono non risolve un’integrazione inaffidabile né una proprietà dei dati poco chiara.
Includete il flusso amministrativo. Se qualcuno deve correggere un record o assistere un cliente, decidete come lo farà. L’esperienza mobile del cliente e un’interfaccia web di amministrazione possono essere canali diversi dello stesso prodotto, ma entrambe rientrano nell’ambito di lavoro.
Chiedete a ogni proposta di separare il lavoro di prodotto condiviso dal lavoro specifico della piattaforma:
Non esiste una percentuale universale e affidabile per cui un approccio costi meno dell’altro. Un backend esistente, una funzione del dispositivo indispensabile o una seconda interfaccia possono cambiare il confronto. Confrontate lo stesso rilascio utile, non due conteggi di schermate o tariffe orarie.
La nostra guida al costo di un’app mobile (in inglese) spiega il lavoro contenuto in una stima per un’app nativa iOS. È una checklist dell’ambito di lavoro, non la promessa di un prezzo standard per il progetto.
Scrivete queste sei righe prima di chiedere a uno sviluppatore di scegliere uno stack:
Se una funzione potrebbe cambiare la decisione, chiedete una verifica tecnica mirata prima di una realizzazione completa. Se l’incertezza riguarda come le persone usano l’interfaccia, un prototipo può essere il primo passo giusto.
AL+ sviluppa applicazioni web su misura e app native per iPhone e iPad, con la responsabilità dei servizi collegati e della manutenzione dopo il lancio. Possiamo parlare della prima piattaforma partendo dal compito, dai dispositivi di destinazione e dal sistema esistente.
Scrivete ad AL+ del vostro progetto web o iOS. Inviate il brief di sei righe, così la conversazione parte dai requisiti che determinano il lavoro.
]]>