TORNA INDIETRO
La caccia agli unicorni è un hobby dannatamente costoso. Ogni anno, le startup divorano miliardi per far sì che solo una, su decine o centinaia, riesca a guadagnare milioni. I fondatori e i proprietari dei prodotti raccolgono denaro dagli investitori e sacrificano la loro indipendenza per conquistare il mercato più velocemente. Alla fine, però, il più delle volte non riescono a raccogliere fondi sufficienti. Forse è stato giusto dire "stai zitto e prendi i tuoi soldi" al momento giusto?
Il denaro contante governa tutto ciò che mi circonda. Anche le organizzazioni più turchesi non possono negarlo. Lo sviluppo di progetto I metodi di gestione, la messa a punto e l'ottimizzazione dei processi o la motivazione dei dipendenti sono fondamentalmente innescati dal bisogno universale di denaro. L'agilità progettuale comporta alcuni rischi.
Tutti vogliamo essere snelli e agile affinché il risultato delle nostre attività, misurato in numeri, sia il più alto possibile. Anche se concentriamo la maggior parte delle nostre energie sulla riduzione delle perdite, alla fine teniamo conto del profitto che è aumentato grazie ai risparmi generati.
Questi risparmi cadono nella stessa tasca dei restanti fattori e rimangono a disposizione solo dei più curiosi. In questo modo, perdiamo la concentrazione e omettiamo involontariamente molti dati preziosi e, in ultima analisi, l'intelligenza.
Imparare dai propri errori è un'abilità particolarmente utile (anche se costosa), ma la cultura organizzativa e la diplomazia insita in questa capacità non sempre aiutano. Spesso nascondiamo l'impatto negativo delle finanze con parole "fumogene". Quando un investitore urla "Ho perso i miei soldi!", il manager lo comunica al squadra dicendo "dovremmo essere più efficaci" e tutti cerchiamo di default nuove soluzioni e miglioramenti: invece di guardare al passato, cerchiamo costantemente modi per andare avanti.
Nel frattempo, le perdite sono spesso la chiave per trarre le giuste conclusioni. Se ripercorriamo alcune fasi del processo senza tenerne conto, le soluzioni successive saranno probabilmente infettate dagli stessi errori.
Esempio:
Un piccolo team di sviluppatori JS senior non riesce a fornire la funzionalità nei tempi previsti. L'investitore, volendo accelerare lo sviluppo, ordina di assumere un nuovo programmatore. L'introduzione di una nuova persona nel progetto distrarrà il team, rallentando ulteriormente l'avanzamento del progetto.
Se l'investitore comprendesse meglio le ragioni dell'inefficacia del team, arriverebbe alla conclusione che esso sfrutta il suo potenziale solo in 60-70%. Attrezzature migliori e qualche giorno lavorativo dedicato all'automazione del lavoro risolverebbero il problema.
Purtroppo, ora deve pagare un altro sviluppatore che lavorerà sulla stessa apparecchiatura e la sua efficienza sarà anch'essa di 60-70%.
Soluzione A:
Da oggi il progetto costa $20.200 / mese
Spesa totale in 12 mesi: 12 * 20.200 + 10.000 = $252.400
Soluzione B:
Da ora in poi i costi del progetto: $30.000 / mese
Spesa totale in 12 mesi: 12 * 30.000 = $360.000
Due sviluppatori che lavorano a 100% fanno più o meno la stessa cosa di tre sviluppatori che lavorano a 60-70%. L'investitore pagherà oltre $ 100.000 in più all'anno per la stessa capacità di elaborazione a causa di una decisione progettuale errata!
Agilità nel processo non significa necessariamente puntare a una copertura di test 100% o a battere il record di prestazioni. Sebbene queste metriche forniscano una panoramica delle condizioni tecniche del progetto, sono talmente insignificanti dal punto di vista del cliente finale che non è necessario portarle allo stato ideale in un processo veramente agile, in quanto non apportano alcun beneficio reale al progetto. mercato valore.
Lo sviluppo di soluzioni tecniche perfette richiede un grande impegno da parte del team e una comunicazione molto più estesa. Di conseguenza, le patch lavorano più lentamente e il progetto si appesantisce a causa dell'eccessivo sviluppo.
Lo sviluppo agile consiste nel fornire un prodotto funzionante. codice con il minimo sforzo. La verifica del codice è indubbiamente una buona pratica e i test dicono molto sul funzionamento del codice, ma non dovrebbero essere fatti solo per il gusto di farli e vantarsene: la qualità tecnica ottimale delle soluzioni si colloca a metà strada tra il minimo determinato dal team di sviluppo e il massimo che è limitato dal budget.
In definitiva, la perfezione non porta da nessuna parte. È interessante notare che anche la questione della sicurezza è soggetta a questa regola: in teoria, qualsiasi sistema può essere violato. Tuttavia, il minimo di sviluppo di cui sopra deve essere corrispondentemente più alto e rilevante per il peso, la scala e il costo delle potenziali conseguenze di un errore nel codice. Spesso, invece di scrivere il modulo di login da zero, che è sempre gravato da un alto rischio di errore e di introduzione di vulnerabilità di sicurezza, è meglio utilizzare, ad esempio, il pulsante "Accedi con Google", la cui corretta implementazione è relativamente veloce e sicura.
Finché l'obiettivo è un breve time-to-market, ipotesi troppo ambiziose si rivelano controproducenti. In un processo apparentemente perfetto, l'eccesso di entusiasmo può essere uno spreco di risorse..
Il design incentrato sull'utente è bello. La cooperazione incentrata sull'uomo è più importante. Quando il team comunica sulla stessa lunghezza d'onda, può ridurre spontaneamente ulteriori perdite potenziali.
Un UX designer aggiornato sulle tecnologie di frontend non proporrà una soluzione al momento dell'acquisto. MVP che consumerà un tempo irragionevole nella fase di implementazione.
Uno sviluppatore frontend che conosce l'euristica dell'usabilità sarà in grado di adattare l'interfaccia a una determinata risoluzione dello schermo senza coinvolgere l'UX designer: correzione rapida, anteprima, accettazione.
Lavorare su un'applicazione richiede la sincronizzazione delle attività di persone con profili di competenza completamente diversi. È necessario conoscere la distribuzione delle competenze nel team per fornire efficacemente valore ai clienti.
Una buona performance di squadra intesa in questo modo è estremamente difficile da raggiungere, soprattutto nell'era del lavoro a distanza. Le aziende che sono "remote-friendly" da anni hanno un vantaggio significativo in questo campo rispetto a quelle che sono state costrette a sintonizzare l'organizzazione durante il blocco e stanno imparando solo ora a conoscere nuovi metodi e forme di comunicazione.
Nel contesto delle crescenti esigenze di comunicazione, strumenti come Whimsical, Miro, Mural, Figma e Balsamiq registrano un impressionante aumento di popolarità.
Sicuramente il blocco e la necessità di lavorare in remoto hanno fatto la loro parte in questa esplosione di utenti. Credo che la scelta dello strumento debba corrispondere alle preferenze individuali, ma diamo un'occhiata a Miro:
La popolarità di questi strumenti determina naturalmente l'aumento della popolarità delle metodologie stesse. Chi ha acquistato Miro per lavorare sulle personas ha accesso a decine di altri modelli che possono rivelarsi interessanti e influenzare positivamente il lavoro quotidiano del team.
Dovete sempre dotarvi di strumenti che snelliscano il flusso di informazioni nel progetto. L'apertura a nuovi strumenti e metodi è anche uno dei fondamenti di un'efficace sviluppo del prodotto.
I progettisti esperti sia dell'interfaccia che dell'architettura del software di solito notano diverse soluzioni potenziali che dovrebbero essere verificate all'inizio della collaborazione e cercano efficacemente ispirazioni appropriate o addirittura soluzioni già pronte sul mercato. Un buon esempio è il framework Material UI, che di solito è una scommessa sicura in fase di prototipo..
A volte è sufficiente esaminare alcune implementazioni su Behance o Dribble e utilizzare l'ispirazione per sviluppare un moodboard e poi passarlo allo sviluppatore. Quest'ultimo la userà per mettere insieme un prototipo cliccabile che potrà essere presentato agli early adopters per raccogliere feedback. Questa ricerca organica di un processo efficace da parte di persone impegnate nel design è naturale.
Se volete fornire prodotti digitali in modo efficiente, dovete lasciare che le persone facciano il loro lavoro. Sapete qual è il valore/servizio che volete fornire ai vostri clienti: questo è sufficiente. Un team di progetto competente e ben gestito saprà come fornire questo valore/servizio nel più breve tempo possibile e con il necessario rapporto costo-efficacia.
Mostratevi fiduciosi, condividete le responsabilità e apritevi a una vera e propria comunicazione a due vie, in modo che la vostra prodotto sarà migliore e il fardello di dover fare tutto da soli sarà tolto dalle vostre spalle, cosa che spesso si rivela una corsa stancante per i fondatori e gli imprenditori! A The CodestTraduciamo questo principio non solo nei progetti, ma anche nei processi interni: probabilmente è per questo che godiamo di alti tassi di fidelizzazione sia dei clienti che dei dipendenti (storia vera, entrambi> 90%).
Concedetevi un po' di pigrizia, trasferite coraggiosamente le responsabilità e lasciate andare il lavoro superfluo che non è necessario per andare avanti: le funzionalità che sarebbero "belle da avere" possono sempre aspettare.
Il processo di creazione di un prodotto digitale è una costante collisione di prospettive, esperienze e fonti di informazione diverse, ognuna delle quali comporta il rischio di prendere una decisione di progettazione sbagliata.
Una buona comunicazione interna riduce questo rischio, ma è solo una faccia della medaglia. La domanda su come rimanere in contatto con il mercato non ha ancora trovato risposta.
Business Intelligence, Assistenza clienti, dipartimenti di ricerca UX e molti altri, proprio come la team di sviluppoDovrebbero cercare di ottenere il minimo necessario per fornire risposte specifiche alle domande poste dal proprietario del prodotto o dal team UX.
Anche il branding stesso e la strategia di comunicazione del marchio sono importanti. Servono a costruire un rapporto qualitativo con i clienti, che poi si traduce in un loro impegno. Se volete porre delle domande ai clienti, dovete assicurarvi che siano disposti a rispondere. Il tono della voce è importante.
È certo che essere in costante contatto con il mercato permette di definire le giuste traiettorie del progetto per farlo volare. Meno scontato è il fatto che la necessità di questo contatto debba essere considerata fin dall'inizio del progetto, prevedendo le giuste competenze nel team (per fare le domande giuste e rispondere) e costruendo una strategia di prodotto che coinvolga i gruppi target.
Considerando tutte le questioni sopra citate, possiamo osservare diversi problemi che compaiono regolarmente nel processo di progettazione:
- essere eccessivamente orientati al profitto ed evitare di guardare agli insuccessi,
- imprecisione e non radiografare i propri errori,
- inseguire un prodotto perfetto che avete in testa, ma che non è quello di cui il mercato ha bisogno,
- l'implementazione troppo zelante dei processi dei libri di testo - l'eccessivo sviluppo e l'eccessiva progettazione,
- inflessibilità del lavoro di squadra e costringere i dipendenti a rimanere solo nelle loro aree di specializzazione,
- comunicazione inefficace,
- tendenza a reinventare la ruota.
L'ottimizzazione dei processi su scala macro comprende la somma dei risparmi. Per affrontare adeguatamente le sfide sopra citate, è necessario coinvolgere i colleghi in modo che presentino apertamente le idee per migliorare il processo.
A volte basta parlare meno e ascoltare più attentamente i subordinati, i clienti, i partner - in base al ruolo e alla responsabilità di ciascuno - per raggiungere il successo.
Quando non si è abbastanza, è molto probabile che si stia investendo troppo.. Avete troppi soldi?
Per saperne di più:
CTO sfide - scalabilità e crescita dei prodotti software
Quale DB scegliere per un tipo di dati specifico nel vostro progetto software?
Italian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Japanese 
Korean 
Polish