{"id":26393,"date":"2020-06-19T12:46:27","date_gmt":"2020-06-19T12:46:27","guid":{"rendered":"https:\/\/cityfalcon.com\/blog\/?p=26393"},"modified":"2020-06-25T07:10:56","modified_gmt":"2020-06-25T07:10:56","slug":"9-product-and-technology-sins-of-a-founder-who-learnt-to-code","status":"publish","type":"post","link":"https:\/\/www.cityfalcon.ai\/blog\/it\/the-startup-journey\/9-product-and-technology-sins-of-a-founder-who-learnt-to-code\/","title":{"rendered":"9 Peccati di prodotto e tecnologia di un fondatore che ha imparato a programmare"},"content":{"rendered":"

In occasione del nostro sesto anniversario e come una sorta di complemento al mio articolo <\/span>15 lezioni da 15.000 ore di imprenditorialit\u00e0 FinTech<\/span><\/a>, Voglio pubblicare alcuni dei miei pi\u00f9 grandi errori in modo che altri imprenditori possano evitarli.\u00a0<\/span><\/p>\n

Nota del redattore: 3 * 2 = 6 e 3 ** 2 = 9, quindi il titolo \u00e8 ancora collegato al nostro sesto compleanno. Ecco perch\u00e9 \u00e8 importante imparare a programmare!<\/em><\/p>\n

 <\/p>\n

Innanzitutto, prima dell'elenco, se vuoi essere un techpreneur, devi imparare a programmare. Forse \u00e8 ovvio, forse non lo \u00e8.<\/span> \u00a0Imparare a programmare mi ha permesso<\/span> costruire la prima versione e, su base giornaliera, mi permette di capire perch\u00e9 gli sviluppatori fanno quello che fanno. Per un periodo di tempo, mi \u00e8 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\u00f9 sicuro non solo con i nostri data scientist ma anche con i CTO di clienti e partner.<\/span><\/p>\n

Ho commesso degli errori e le persone pi\u00f9 esperte mi hanno insegnato perch\u00e9 erano errori. Molti fondatori possono sviluppare complessi di superiorit\u00e0, ma conoscere i propri errori ti mantiene riconoscibile con i tuoi dipendenti e lucido.<\/span><\/p>\n

Ora passiamo alla lista.<\/span><\/p>\n

 <\/p>\n

1. MVP \u00e8 una stronza<\/b><\/h2>\n

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

Quindi provi a costruire un MVP il pi\u00f9 velocemente possibile. \u00c8 minimo, dopo tutto.<\/span><\/p>\n

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

Per me, non conoscevo tutte le migliori pratiche, come test, documentazione e preparazione per la scalabilit\u00e0. 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\u00ec popolari. Ma non utilizzare un framework sul frontend probabilmente ci \u00e8 costato un anno di refactoring e ripensamento, perch\u00e9 la scalabilit\u00e0 e la flessibilit\u00e0 erano inesistenti e questo si \u00e8 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\u00e9 la mia documentazione era minima e i concetti di fintech possono essere piuttosto complessi per i programmatori non esperti di finanza.<\/span><\/p>\n

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\u00e0 aziendale. Ma poi le proposte di vendita cadranno piatte perch\u00e9 non sar\u00e0 di qualit\u00e0 aziendale ma comunque solo minimamente praticabile.\u00a0<\/span><\/p>\n

Quando crei il tuo MVP, pianifica almeno la scalabilit\u00e0 e l'efficienza. Nessuno pu\u00f2 essere a prova di futuro fin dall'inizio, perch\u00e9 non sai nemmeno se funzioner\u00e0. Ma tieni sempre a mente le sfide tecnologiche future e mitigale nel miglior modo possibile fin dall'inizio.\u00a0\u00a0<\/span><\/p>\n

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

Un modo per evitare fin dall'inizio la fase MVP e la costruzione del prodotto richiesta \u00e8 raccogliere milioni interamente per un'idea, una pratica molto comune nella Silicon Valley. Certo, \u00e8 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, <\/span>alcuni <\/span><\/i>sar\u00e0 necessario un tipo di MVP prima di vedere i dollari o gli interessi degli investitori.<\/span><\/p>\n

 <\/p>\n

2. Accesso con ogni Tom, Dick e Harry: intendo Facebook, Twitter, Linkedin, Google e ora Apple<\/b><\/h2>\n

Potresti essere nello spirito inclusivo. Forse un utente ti ha inviato un'e-mail chiedendoti quando pu\u00f2 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 \u00e8 poi cos\u00ec male. Ma quando hai un sito Web, app Android e iOS e sistemi vocali come Alexa e Google Home, devi aggiungere la funzionalit\u00e0 di accesso per tutti loro.<\/span><\/p>\n

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

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.<\/span><\/p>\n

A volte, anche gli utenti si confondono su come si sono registrati: \u00e8 stato tramite Facebook o Twitter? Se \u00e8 fonte di confusione per l'utente, immagina com'\u00e8 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\u00e9 ha effettuato l'accesso con un metodo diverso.\u00a0<\/span><\/p>\n

\"\"<\/a>

Le integrazioni di accesso invitano sempre pi\u00f9 integrazioni di accesso<\/p><\/div>\n

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\u00f9 metodi di autenticazione.\u00a0<\/span><\/p>\n

 <\/p>\n

3. La tentazione di ricodificare inutilmente le funzionalit\u00e0\u00a0<\/b><\/h2>\n

Proprio come pi\u00f9 metodi di autenticazione sono "solo poche righe di codice", sentirai gli sviluppatori dire "il codice \u00e8 troppo complesso. Lasciamelo ricostruire e sar\u00e0 molto pi\u00f9 efficiente\u201d. Premi il pulsante antipanico!<\/span><\/p>\n

Gli sviluppatori hanno la spinta a rendere il loro codice efficiente e pulito e, man mano che vengono aggiunte pi\u00f9 funzionalit\u00e0, il codice diventa complesso. Ma la codifica \u00e8 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.<\/span><\/p>\n

Inoltre, una corretta gestione del prodotto non \u00e8 solo codifica. Una volta che il codice \u00e8 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.\u00a0<\/span><\/p>\n

Non aggiustare qualcosa che non \u00e8 rotto. Lo abbiamo fatto e abbiamo pagato un caro prezzo in termini di lancio, stabilit\u00e0 e qualit\u00e0.\u00a0<\/span><\/p>\n

 <\/p>\n

4. Non capire come gestire e motivare gli sviluppatori<\/b><\/h2>\n

Nella tecnologia, gli sviluppatori letteralmente creano (e distruggono) il tuo prodotto. Il tipo di persone attratte dallo sviluppo del software \u00e8 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.\u00a0<\/span><\/p>\n

Non capire le loro motivazioni e come operano \u00e8 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\u00e0 revisioni quotidiane, scadenze rigide e straordinari. Prendi sul serio queste considerazioni.<\/span><\/p>\n

Ora pi\u00f9 che mai, il lavoro a distanza \u00e8 una possibilit\u00e0 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\u00e0 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.\u00a0<\/span><\/p>\n

Puoi leggere <\/span>il mio intero articolo su come lavorare con gli sviluppatori<\/span><\/a>.<\/span><\/p>\n

 <\/p>\n

5. Non automatizzare i test dall'inizio<\/b><\/h2>\n

Come la sicurezza, il test del codice \u00e8 spesso considerato facoltativo e una perdita di tempo. Ma man mano che il team e il prodotto crescono, la complessit\u00e0 costringer\u00e0 a testare. Non \u00e8 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.<\/span><\/p>\n

Abbiamo sempre eseguito test unitari, ovvero testando ogni singolo componente in s\u00e9, 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\u00e9 la parte aggiornata funzionava, pensavamo che l'intero sistema avrebbe funzionato.\u00a0<\/span><\/p>\n

L'automazione dei test, in particolare per l'integrazione, rende molto pi\u00f9 semplice testare e ripetere il test di ogni parte del sito per ogni integrazione. Poich\u00e9 di solito non \u00e8 noto cosa cambier\u00e0 nell'intero sistema a causa del nuovo modulo, i test di integrazione devono coprire l'intero sito. Non automatizzato, questo \u00e8 molto noioso e i QA trascorrono molto tempo in attivit\u00e0 banali. Ma una volta automatizzati, vengono liberati.<\/span><\/p>\n

Ci\u00f2 porta a un'integrazione continua, in cui il nuovo codice viene aggiunto costantemente, piuttosto che in grandi aggiornamenti. Se il tuo test non \u00e8 automatizzato, attendi finch\u00e9 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, \u00e8 possibile adottare l'integrazione continua senza sprecare risorse di QA in test ripetitivi.<\/span><\/p>\n

 <\/p>\n

6. Sottostima del tempo di rilascio: codifica (1x), QA (2-3x), stabilizzazione (2-3x)<\/b><\/h2>\n

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 \u00e8 fatto, giusto? Certo, se non ne hai bisogno per funzionare.<\/span><\/p>\n

Dedicherai 1 settimana al tempo di sviluppo. Quindi i QA testano tutto (che non pu\u00f2 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\u00e0 complesse, devi dedicare 2-3 volte il tempo di sviluppo originale per garantire stabilit\u00e0 e prestazioni di qualit\u00e0.\u00a0<\/span><\/p>\n

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\u00e0 promettere troppo ai clienti e spingere troppo il tuo team quando la scadenza non viene rispettata.\u00a0<\/span><\/p>\n

Questo presuppone che tu abbia avuto la documentazione adeguata per il codice in primo luogo e che gli sviluppatori capiscano gi\u00e0 di cosa hanno bisogno UX, UI e gestione del prodotto.<\/span><\/p>\n

Costruire un prodotto tecnologico di qualit\u00e0 richiede pi\u00f9 tempo di quanto la maggior parte delle persone immagini.<\/span><\/p>\n

 <\/p>\n

7. Trascurare la differenza di produttivit\u00e0 tra programmatori buoni e cattivi<\/b><\/h2>\n

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

Ci\u00f2 richiede entrambe le qualit\u00e0: esperienza <\/span>e <\/span><\/i>capacit\u00e0. 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\u00e0 di codifica. Dovrai assicurarti che entrambe le qualit\u00e0 siano presenti. Avendo imparato da questo, ora dedichiamo molto pi\u00f9 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.<\/span><\/p>\n

Con la quantit\u00e0 di lavoro aggiuntivo richiesto per il debug, la ricodifica, il QAing e la riprogettazione a causa di un codice errato, la differenza di produttivit\u00e0 tra uno sviluppatore bravo e uno inesperto o inesperto potrebbe essere di 1000 volte.<\/span><\/p>\n

 <\/p>\n

8. La tentazione di costruire tutte le "esperienze" internamente<\/b><\/h2>\n

Ogni azienda desidera fornire un'esperienza di qualit\u00e0 ai propri utenti. Quando intraprendi il viaggio per costruire quell'esperienza, potresti avere il back-end gi\u00e0 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?<\/span><\/p>\n

Servire i dati, certo, \u00e8 facile. Realmente costruendo il frontend? Questa \u00e8 una storia diversa. Il frontend \u00e8 ingombrante. Prima c'\u00e8 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\u00e0 essere ridimensionata per essere visualizzata correttamente su diverse risoluzioni dello schermo e browser. E chi non vuole un'app mobile? Ci\u00f2 comporta una serie di problemi, come i tipi di accesso forzato (vedi 2 sopra), pi\u00f9 sistemi operativi e hardware variabile.<\/span><\/p>\n

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\u00e0 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\u00e9 a volte la versione premium risolver\u00e0 esattamente le tue esigenze senza ulteriore tempo di sviluppo.\u00a0<\/span><\/p>\n

 <\/p>\n

9. Non capire le differenze di ruolo in un contesto tecnologico<\/b><\/h2>\n

Un altro malinteso di coloro che non hanno un background tecnologico \u00e8 che tutti i ruoli tecnologici siano pi\u00f9 o meno gli stessi. Certo, gli sviluppatori sono backend\/frontend, l'interfaccia utente \u00e8 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\u00f2 essere un errore costoso in termini di tempo e qualit\u00e0.\u00a0<\/span><\/p>\n

Primo esempio: il design. Ci sono designer per l'interfaccia utente (UI) e ci sono designer per l'esperienza utente (UX). L'interfaccia utente \u00e8 fortemente creativa, rendendo tutto elegante e piacevole da guardare. L'esperienza utente riguarda pi\u00f9 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 \u00e8 appena arrivato o crea solo confusione?<\/span><\/p>\n

Non conoscere la differenza tra UX e UI pu\u00f2 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.<\/span><\/p>\n

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\u00f2 che i sistemi possono fare, quindi la stabilit\u00e0 e l'accessibilit\u00e0 diventano la massima priorit\u00e0. Ovviamente, nel mondo di oggi, il tempo di attivit\u00e0 100% \u00e8 dato per scontato e il mancato rispetto di questo \u00e8 immediatamente evidente. Disponiamo gi\u00e0 di 1,5 DevOps e potrebbe essere necessario assumerne un altro per poter aggiungere altri servizi di intelligenza artificiale.<\/span><\/p>\n

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.<\/span><\/p>\n

 <\/p>\n

9a. Peccati di un altro<\/strong><\/h2>\n

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):<\/span><\/p>\n