In occasione del nostro sesto anniversario e come una sorta di complemento al mio articolo 15 lezioni da 15.000 ore di imprenditorialità FinTech, Voglio pubblicare alcuni dei miei più grandi errori in modo che altri imprenditori possano evitarli. 

Nota del redattore: 3 * 2 = 6 e 3 ** 2 = 9, quindi il titolo è ancora collegato al nostro sesto compleanno. Ecco perché è importante imparare a programmare!

 

Innanzitutto, prima dell'elenco, se vuoi essere un techpreneur, devi imparare a programmare. Forse è ovvio, forse non lo è.  Imparare a programmare mi ha permesso costruire la prima versione e, su base giornaliera, mi permette di capire perché gli sviluppatori fanno quello che fanno. Per un periodo di tempo, mi è piaciuto molto programmare e sporcarmi le mani con le API, ecc. Un corso di machine learning mi ha permesso di interagire in modo ancora più sicuro non solo con i nostri data scientist ma anche con i CTO di clienti e partner.

Ho commesso degli errori e le persone più esperte mi hanno insegnato perché erano errori. Molti fondatori possono sviluppare complessi di superiorità, ma conoscere i propri errori ti mantiene riconoscibile con i tuoi dipendenti e lucido.

Ora passiamo alla lista.

 

1. MVP è una stronza

Hai bisogno di soldi per costruire il business, ma ogni investitore vuole vedere un Minimum Viable Product (MVP). Senza uno, la tua è solo un'idea o un sogno, dal punto di vista dell'investitore. I sogni sono grandi, diranno, ma non sono degni di investimento. 

Quindi provi a costruire un MVP il più velocemente possibile. È minimo, dopo tutto.

Metti insieme le cose; stai imparando mentre procedi e ogni giorno ti sembra di aver realizzato così tanto. Poi ti rendi conto di aver scritto una riga di codice e creato due nuovi bug. Prendi scorciatoie e, poiché ne hai solo bisogno per funzionare per pochi utenti nella fase MVP, salti la scalabilità. Sono computer, possono fare le cose velocemente. Quanto può peggiorare passando da 50 a 5.000 utenti?

Per me, non conoscevo tutte le migliori pratiche, come test, documentazione e preparazione per la scalabilità. L'obiettivo era avere un prodotto di base per raccogliere fondi, non costruire l'edizione aziendale. Ho scritto il backend utilizzando il framework Ruby on Rails ma il frontend in JavaScript e jQuery. All'inizio sembra ragionevole e, all'epoca, i framework di frontend non erano così popolari. Ma non utilizzare un framework sul frontend probabilmente ci è costato un anno di refactoring e ripensamento, perché la scalabilità e la flessibilità erano inesistenti e questo si è tradotto in un'esperienza utente con lunghi tempi di caricamento. L'inefficienza significava anche alti costi di elaborazione e hosting cloud. Per non parlare della spiegazione (e della riscoperta) del mio codice agli sviluppatori, perché la mia documentazione era minima e i concetti di fintech possono essere piuttosto complessi per i programmatori non esperti di finanza.

Probabilmente avrai bisogno di 3-6 mesi per arrivare all'MVP da zero e molti altri mesi per ottenere trazione. Allo stesso tempo, devi raccogliere fondi, ma gli investitori vogliono solo vedere trazione e entrate. Per generare entrate e trazione onnipotenti, molti nuovi fondatori cercheranno di passare da un MVP direttamente a una qualità aziendale. Ma poi le proposte di vendita cadranno piatte perché non sarà di qualità aziendale ma comunque solo minimamente praticabile. 

Quando crei il tuo MVP, pianifica almeno la scalabilità e l'efficienza. Nessuno può essere a prova di futuro fin dall'inizio, perché non sai nemmeno se funzionerà. Ma tieni sempre a mente le sfide tecnologiche future e mitigale nel miglior modo possibile fin dall'inizio.  

Dopo aver raccolto fondi e assunto sviluppatori, potresti voler eseguire il refactoring del codice e rivalutare l'architettura prima di concentrarti su più funzionalità, utenti e entrate. Questo investimento iniziale di tempo potrebbe prevenire diversi problemi importanti lungo la strada. Hai costruito un minimamente prodotto fattibile, dopo tutto, non un prodotto ottimale finale.

Un modo per evitare fin dall'inizio la fase MVP e la costruzione del prodotto richiesta è raccogliere milioni interamente per un'idea, una pratica molto comune nella Silicon Valley. Certo, è un privilegio solo per pochi: imprenditori seriali con un buon curriculum, amici di un VC o di un importante investitore angelico o un professionista senior del settore con molti contatti. Per il resto di noi, alcuni sarà necessario un tipo di MVP prima di vedere i dollari o gli interessi degli investitori.

 

2. Accesso con ogni Tom, Dick e Harry: intendo Facebook, Twitter, Linkedin, Google e ora Apple

Potresti essere nello spirito inclusivo. Forse un utente ti ha inviato un'e-mail chiedendoti quando può accedere tramite Facebook. Quindi guardi i documenti e, fantastico, sono solo poche righe di codice. Ma hai aperto il vaso di Pandora. Una volta che le "poche righe di codice" si espandono a molte e finalmente il processo di autenticazione funziona con i tuoi sistemi, devi integrarlo in tutti i tuoi canali di consegna. Se hai una singola app su iOS, forse non è poi così male. Ma quando hai un sito Web, app Android e iOS e sistemi vocali come Alexa e Google Home, devi aggiungere la funzionalità di accesso per tutti loro.

Quindi, potresti essere costretto ad aggiungerne altri, come l'accesso Apple per gli utenti iPhone (vedi Clausola 4.8 dei loro T&C) se desideri continuare a fornire i tuoi servizi attraverso la loro piattaforma. 

Ora che hai 6 diversi pezzi di codice, uno per ogni canale di consegna, sei pronto. Fino a quando una delle API non cambia e devi correggere il tuo codice su tutti i canali. Google e Apple non sono preoccupati per le loro modifiche che rompono la tua piccola app, ma se lo farai ti ritroverai in acqua calda.

A volte, anche gli utenti si confondono su come si sono registrati: è stato tramite Facebook o Twitter? Se è fonte di confusione per l'utente, immagina com'è costruire tutti quei metodi di accesso e poi gestirli tutti - e la confusione del cliente quando il suo account non riflette l'ultima modifica che ha apportato perché ha effettuato l'accesso con un metodo diverso. 

Le integrazioni di accesso invitano sempre più integrazioni di accesso

A meno che tu non abbia bisogno di dati oltre l'autenticazione (come immagini da Facebook o informazioni utente da Google), sii esclusivo: utilizza solo un nome utente o un indirizzo email ed escludi i vari altri metodi di accesso. Quando sei positivo al flusso di cassa e puoi permetterti uno sviluppatore esclusivamente per l'autenticazione, puoi pensare di aggiungere più metodi di autenticazione. 

 

3. La tentazione di ricodificare inutilmente le funzionalità 

Proprio come più metodi di autenticazione sono "solo poche righe di codice", sentirai gli sviluppatori dire "il codice è troppo complesso. Lasciamelo ricostruire e sarà molto più efficiente”. Premi il pulsante antipanico!

Gli sviluppatori hanno la spinta a rendere il loro codice efficiente e pulito e, man mano che vengono aggiunte più funzionalità, il codice diventa complesso. Ma la codifica è solo una parte e in sistemi complessi, come il corpo umano e il clima, piccoli cambiamenti in un punto del codice possono avere effetti a catena drastici in seguito o altrove.

Inoltre, una corretta gestione del prodotto non è solo codifica. Una volta che il codice è pronto, il team Quality Assurance (QA) deve testarlo. Questo processo si traduce invariabilmente in lunghi andirivieni (vedi Sin 6 di seguito). Quindi deve essere stabilizzato. Se qualcosa di importante cambia, potrebbe essere necessario modificare la messaggistica e il design. Si verificano effetti imprevisti e all'improvviso arrivano i reclami dei clienti. 

Non aggiustare qualcosa che non è rotto. Lo abbiamo fatto e abbiamo pagato un caro prezzo in termini di lancio, stabilità e qualità. 

 

4. Non capire come gestire e motivare gli sviluppatori

Nella tecnologia, gli sviluppatori letteralmente creano (e distruggono) il tuo prodotto. Il tipo di persone attratte dallo sviluppo del software è una razza speciale e devi capire come operano. Potresti avere 20 anni nel settore e gestire centinaia di persone non tecnologiche, ma tutta quella conoscenza ed esperienza potrebbe non aiutare a lavorare con gli sviluppatori. 

Non capire le loro motivazioni e come operano è un grosso errore. Porta a incomprensioni, ritardi e mal di testa. Nel processo di assunzione incontrerai molti sviluppatori che desiderano una retribuzione elevata, un'elevata autonomia e orari flessibili. La maggior parte non vorrà revisioni quotidiane, scadenze rigide e straordinari. Prendi sul serio queste considerazioni.

Ora più che mai, il lavoro a distanza è una possibilità reale per gli sviluppatori e il mondo intero sta assumendo. I migliori lavoreranno dove vengono trattati meglio. E non vuoi un prodotto di scarsa qualità sfornato da dipendenti scontenti, soprattutto quando hai bisogno di quella soluzione dell'ultimo minuto prima di presentarlo agli investitori. Gli sviluppatori felici faranno un'eccezione straordinaria per te; quelli infelici potrebbero semplicemente svanire. 

Puoi leggere il mio intero articolo su come lavorare con gli sviluppatori.

 

5. Non automatizzare i test dall'inizio

Come la sicurezza, il test del codice è spesso considerato facoltativo e una perdita di tempo. Ma man mano che il team e il prodotto crescono, la complessità costringerà a testare. Non è possibile integrare un componente in un sistema complesso senza alcun test, per non essere pronti ad affrontare le ricadute del cliente quando la produzione si blocca e inizia a sputare codici di errore agli utenti.

Abbiamo sempre eseguito test unitari, ovvero testando ogni singolo componente in sé, prima di collegarlo al sistema completo. Tuttavia, abbiamo avviato i test olistici di integrazione automatizzata solo dal 2019. Uno dei motivi principali era la mancanza di risorse per ripetere il test dell'intero sistema per ogni aggiornamento. Finché la parte aggiornata funzionava, pensavamo che l'intero sistema avrebbe funzionato. 

L'automazione dei test, in particolare per l'integrazione, rende molto più semplice testare e ripetere il test di ogni parte del sito per ogni integrazione. Poiché di solito non è noto cosa cambierà nell'intero sistema a causa del nuovo modulo, i test di integrazione devono coprire l'intero sito. Non automatizzato, questo è molto noioso e i QA trascorrono molto tempo in attività banali. Ma una volta automatizzati, vengono liberati.

Ciò porta a un'integrazione continua, in cui il nuovo codice viene aggiunto costantemente, piuttosto che in grandi aggiornamenti. Se il tuo test non è automatizzato, attendi finché non sono pronte molte piccole modifiche, quindi rilasciale tutte insieme, quindi testerai l'intero sistema una volta. Ma una volta automatizzati i test banali a livello di prodotto, è possibile adottare l'integrazione continua senza sprecare risorse di QA in test ripetitivi.

 

6. Sottostima del tempo di rilascio: codifica (1x), QA (2-3x), stabilizzazione (2-3x)

Quando si ha a che fare con la tecnologia, soprattutto se si proviene dall'esterno del mondo della tecnologia, la codifica sembra in primo piano. Vuoi creare un prodotto tecnologico, lo codifichi e il gioco è fatto, giusto? Certo, se non ne hai bisogno per funzionare.

Dedicherai 1 settimana al tempo di sviluppo. Quindi i QA testano tutto (che non può essere automatizzato), i ticket vengono scritti e il codice ritorna agli sviluppatori per la correzione dei bug. Quindi i QA ottengono il codice modificato e il processo ricomincia, generalmente impiegando 2-3 volte il tempo di sviluppo originale. Una volta che sei pronto per inviare il nuovo codice alla produzione, in caso di big data e funzionalità complesse, devi dedicare 2-3 volte il tempo di sviluppo originale per garantire stabilità e prestazioni di qualità. 

Sommati, siete passati da un tempo di rilascio di 1 settimana (stima originale per i nuovi imprenditori tecnologici) a 5-7 settimane. Essere impreparati a questo tipo di tempismo ti farà promettere troppo ai clienti e spingere troppo il tuo team quando la scadenza non viene rispettata. 

Questo presuppone che tu abbia avuto la documentazione adeguata per il codice in primo luogo e che gli sviluppatori capiscano già di cosa hanno bisogno UX, UI e gestione del prodotto.

Costruire un prodotto tecnologico di qualità richiede più tempo di quanto la maggior parte delle persone immagini.

 

7. Trascurare la differenza di produttività tra programmatori buoni e cattivi

C'è molta pressione nelle prime fasi per perdere meno soldi possibile. Ciò porta ad assumere sviluppatori junior per progetti che non dovrebbero essere affidati a sviluppatori junior. È fantastico assumere sviluppatori junior in seguito per assistere con compiti più piccoli, ma il fulcro della tua attività è la tua tecnologia: è necessario uno sviluppatore bravo ed esperto. Altrimenti, passerai molto tempo a rielaborare il vecchio codice per scalabilità, stabilità ed efficienza. Vale la pena pagare un extra per un buon sviluppatore con sufficiente esperienza lungo la strada.

Ciò richiede entrambe le qualità: esperienza e capacità. Alcuni sviluppatori junior sono programmatori fantastici, trascurano semplicemente i problemi futuri che i programmatori esperti non fanno. Al contrario, 10 anni di esperienza non si traducono necessariamente in una buona capacità di codifica. Dovrai assicurarti che entrambe le qualità siano presenti. Avendo imparato da questo, ora dedichiamo molto più tempo durante il processo di assunzione per assicurarci di coinvolgere il candidato giusto. Quindi, durante il periodo di prova, valutiamo a fondo il loro lavoro e qualsiasi segnale di allarme viene affrontato immediatamente.

Con la quantità di lavoro aggiuntivo richiesto per il debug, la ricodifica, il QAing e la riprogettazione a causa di un codice errato, la differenza di produttività tra uno sviluppatore bravo e uno inesperto o inesperto potrebbe essere di 1000 volte.

 

8. La tentazione di costruire tutte le "esperienze" internamente

Ogni azienda desidera fornire un'esperienza di qualità ai propri utenti. Quando intraprendi il viaggio per costruire quell'esperienza, potresti avere il back-end già costruito. Forse hai anche un paio di clienti che usano la tua API. Dovrebbe essere molto facile fornire quei dati a un frontend del consumatore, giusto?

Servire i dati, certo, è facile. Realmente costruendo il frontend? Questa è una storia diversa. Il frontend è ingombrante. Prima c'è la grafica: avrai bisogno di un designer per realizzare quella grafica. Le API sono solo endpoint, tutto testo e codice. Oh, e la grafica dovrà essere ridimensionata per essere visualizzata correttamente su diverse risoluzioni dello schermo e browser. E chi non vuole un'app mobile? Ciò comporta una serie di problemi, come i tipi di accesso forzato (vedi 2 sopra), più sistemi operativi e hardware variabile.

Il mio consiglio: dovrai creare molto frontend, ma se puoi acquistare componenti premade da terze parti che ti permetteranno di coprire la maggior parte degli scenari (sistema operativo, hardware, dimensioni dello schermo, ecc.), Acquista i componenti premade. Il tuo prodotto si differenzia per il codice di backend e il design del frontend, non per il codice di base del frontend. Se puoi acquistarlo, salta i mal di testa del test di controllo qualità su 15 diversi browser, tablet e telefoni. Non devi costruire tutto internamente; potrebbe esserci una soluzione per l'acquisto a un prezzo ragionevole. O anche open source, se sei fortunato. Ma non lasciarti risucchiare dalla convinzione che l'open source valga sempre i risparmi, perché a volte la versione premium risolverà esattamente le tue esigenze senza ulteriore tempo di sviluppo. 

 

9. Non capire le differenze di ruolo in un contesto tecnologico

Un altro malinteso di coloro che non hanno un background tecnologico è che tutti i ruoli tecnologici siano più o meno gli stessi. Certo, gli sviluppatori sono backend/frontend, l'interfaccia utente è diversa dall'infrastruttura. All'inizio, questo potrebbe anche essere vero. Quando sei solo tu (e forse un paio di altri), i ruoli si fondono tutti insieme. Ma man mano che l'azienda cresce, la differenziazione e la specializzazione sono necessarie e confonderle può essere un errore costoso in termini di tempo e qualità. 

Primo esempio: il design. Ci sono designer per l'interfaccia utente (UI) e ci sono designer per l'esperienza utente (UX). L'interfaccia utente è fortemente creativa, rendendo tutto elegante e piacevole da guardare. L'esperienza utente riguarda più la struttura: in che modo gli utenti fluiscono attraverso il sistema? Cosa succede se si verifica un errore qui, l'utente arriva alla schermata A o alla schermata B? Questo design ha senso nel contesto da cui l'utente è appena arrivato o crea solo confusione?

Non conoscere la differenza tra UX e UI può portare a prodotti visivamente accattivanti che frustrano e confondono gli utenti. Non vendi solo l'aspetto, vendi l'esperienza. Assicurati che valga la pena per i clienti, altrimenti andranno altrove.

Ho anche scambiato gli sviluppatori di software e il personale DevOps, portando a una maggiore pressione lavorativa sui nostri sviluppatori. I sistemi tecnologici, specialmente quelli complessi come il nostro, non sono solo codice (come menzionato in Sin 6). I Big Data spingono anche il limite di ciò che i sistemi possono fare, quindi la stabilità e l'accessibilità diventano la massima priorità. Ovviamente, nel mondo di oggi, il tempo di attività 100% è dato per scontato e il mancato rispetto di questo è immediatamente evidente. Disponiamo già di 1,5 DevOps e potrebbe essere necessario assumerne un altro per poter aggiungere altri servizi di intelligenza artificiale.

I tuoi sviluppatori, sia backend che frontend, si concentrano sul codice e sull'algoritmo. Hai bisogno di DevOps per garantire che la potenza di calcolo sia disponibile per eseguire quel codice e deve essere abbastanza stabile da soddisfare i clienti. Non confondere DevOps e sviluppo software.

 

9a. Peccati di un altro

Abbiamo ricevuto alcuni chiari avvertimenti da Jelle van Mourik, una lettrice su Facebook. Li esporremo qui in questa intestazione (abbiamo parafrasato un po' e ovviamente abbiamo aggiunto il nostro sapore):

  • Non forzare i programmatori a codificare ciò che non codificano. In altre parole, non cercare di far lavorare un programmatore back-end sul codice dell'interfaccia utente front-end e viceversa. Poiché USD e RMB sono entrambe valute che non si utilizzano in modo intercambiabile, potrebbero essere tutte righe di codice, ma gli approcci, le strutture e l'esperienza differiscono tra i vari aspetti. Errori considerevoli, ritardi e mal di testa attendono chiunque cerchi di convincere un programmatore a codificare ciò che non codifica
  • Progetta prima di programmare: non c'è niente come far funzionare l'intera base di codice e rendersi conto che il nuovo design è incompatibile o richiede una revisione significativa del codice
  • Vai al test degli utenti il prima possibile, perché gli utenti sono quelli che non puoi controllare e romperanno le cose o le rifiuteranno, e questo è un male per il business
  • Affronta il feedback negativo nell'app in modo che gli utenti scontenti esprimano tale malcontento a te, non al pubblico in generale negli app store iOS e Android
  • Mantieni un singolo ramo stabile per la distribuzione, non più rami "rilasciabili" che divergeranno, quindi confonderanno tutti e mancheranno pezzi critici che richiedono una settimana per integrare al tuo ramo rilasciato
  • Mantieni un arretrato esplicito di cose tecniche da fare e pianifica gli sprint utilizzandolo. Queste cose hanno la tendenza a sfuggire alla mente. In effetti, se te lo puoi permettere, potresti anche voler assumere una persona per gestirlo

 

E questi sono i 9 peccati (più i peccati dei lettori). Hai esperienze simili che vorresti condividere con noi? Qualche altra trappola di cui vorresti mettere in guardia i colleghi imprenditori? Si prega di commentare di seguito.