L'agenzia consiglia linguaggi separati per iOS e Android — come incide la scelta del codice sul budget?

La gestione della stampante portatile bluetooth e la lettura dei codici a barre lavorano tramite bridge nativi nei moderni framework multipiattaforma, con zero latenza sull'hardware. Se insistono sui linguaggi separati, è molto probabile che il loro team non abbia competenze solide sul cross-platform.

Nella nostra rete di distribuzione all'ingrosso 3 anni fa abbiamo fatto lo stesso errore commissionando l'app nativa. Abbiamo speso 240.000 TL. A ogni aggiornamento di Android o cambio di policy iOS pagavamo modifiche doppie. L'anno scorso siamo passati al codice unico e la manutenzione mensile è scesa da 18.000 TL a 8.500 TL.

L'agenzia ha probabilmente sviluppatori iOS e Android interni fermi senza progetti e cerca di scaricare il loro costo ore/uomo sul vostro lavoro. Il 90% delle app aziendali di vendita ormai esce con una singola base di codice.

Punti da chiarire con l'agenzia prima di firmare: 1) Rispetto al codice unico, quali schermate operative garantiscono essere effettivamente più veloci? 2) Cosa include il canone di manutenzione per le due basi di codice? 3) A fine lavori la proprietà dei codici sorgente di entrambe le piattaforme a chi appartiene?

Prima di impegnare 340.000 TL, sottoponete le stesse specifiche ad altre due agenzie che sviluppano in multipiattaforma. Vedrete che il preventivo scenderà attorno ai 190.000 TL con tempi di consegna di circa 6 settimane.

I vostri agenti di vendita entrano in magazzini dove non prende internet? Se serve la sincronizzazione offline del database l'architettura diventa un po' più importante, ma anche questa non è una cosa che non si possa risolvere con una sola codebase.

Far sviluppare in nativo con due linguaggi diversi un'app B2B che mostra solo il catalogo e legge i codici a barre significa proprio buttare via i soldi.

Grazie mille, proverò oggi. Inizia con un piccolo test non impegnarti subito su tutto.

Lascio una nota potrebbe servire.

A me è successo l'esatto contrario, per questo scrivo. Un report settimanale scritto sull'avanzamento è molto più utile che chiedere date.

Approfondisco l'aspetto tecnico. L'offerta più economica è spesso quella meno ponderata.

Io seguirei questa strada.

il mio dubbio è stato chiarito, grazie. cioè quando perndi una decisione guarda prima quali dati hai a disposizione.

Riassumo l'argomento, perché sono state date diverse risposte. La risposta varia molto in base al settore, non esiste una regola generale.

Introdurre un processo per le richieste di modifica non rallenta il lavoro, lo accelera. Buon lavoro.

Nel nostro caso è andata così. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Se scrivete qui il risultato, sarà utile anche ad altri.

ho vissuto la stesssa cosa.

Concordo pienamente. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Nessun processo migliora senza tracciamento perché non sai cosa correggere. È tutto, scusate se mi sono dilungato.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Se lo scope cresce devono crescere o i tempi o il budget. Non c'è una terza opzione.

Spero che le sia utile.

Racconto la mia esperienza. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Inizia con un piccolo test, non impegnarti subito su tutto.

Grazie per aver scritto.