![\"efficacia](\"\/app\/uploads\/2024\/05\/1tR8fGHRhmgTIZqb1ad_X-Q.jpeg\" "\\"efficacia")
<\/p>\n
Tutti vogliamo essere snelli e agile<\/a> affinch\u00e9 il risultato delle nostre attivit\u00e0, misurato in numeri, sia il pi\u00f9 alto possibile. Anche se concentriamo la maggior parte delle nostre energie sulla riduzione delle perdite, alla fine teniamo conto del profitto che \u00e8 aumentato grazie ai risparmi generati.<\/p>\n Questi risparmi finiscono nella stessa tasca dei restanti fattori e rimangono a disposizione solo dei pi\u00f9 curiosi. In questo modo, perdiamo la concentrazione e omettiamo involontariamente molte cose preziose. dati<\/a> e infine l'intelligenza.<\/p>\n Imparare dai propri errori \u00e8 un'abilit\u00e0 particolarmente utile (anche se costosa), ma la cultura organizzativa<\/a> e la diplomazia insita in questa capacit\u00e0 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<\/a> dicendo \"dovremmo essere pi\u00f9 efficaci\" e tutti cerchiamo di default nuove soluzioni e miglioramenti: invece di guardare al passato, cerchiamo costantemente modi per andare avanti.<\/p>\n 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.<\/p>\n Esempio:<\/em><\/strong>\u00a0<\/p>\n Un piccolo team di esperti JS<\/a> Gli sviluppatori non forniscono la funzionalit\u00e0 nei tempi previsti. L'investitore, volendo accelerare lo sviluppo, ordina di assumere un nuovo programmatore. L'introduzione di una nuova persona nel progetto distrarr\u00e0 il team, rallentando ulteriormente l'avanzamento del progetto.<\/p>\n 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.<\/p>\n Purtroppo, ora deve pagare un altro sviluppatore che lavorer\u00e0 sulla stessa apparecchiatura e la sua efficienza sar\u00e0 anch'essa di 60-70%.<\/p>\n Soluzione A:<\/strong><\/p>\n \nDa oggi il progetto costa $20.200 \/ mese<\/p>\n Spesa totale in 12 mesi: 12 * 20.200 + 10.000 = $252.400<\/p>\n Soluzione B:<\/strong><\/p>\n \nDa ora in poi i costi del progetto: $30.000 \/ mese<\/p>\n Spesa totale in 12 mesi: 12 * 30.000 = $360.000<\/p>\n Due sviluppatori che lavorano a 100% fanno pi\u00f9 o meno la stessa cosa di tre sviluppatori che lavorano a 60-70%. L'investitore pagher\u00e0 oltre $ 100.000 in pi\u00f9 all'anno per la stessa capacit\u00e0 di elaborazione a causa di una decisione progettuale errata!<\/p>\n Agilit\u00e0 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 \u00e8 necessario portarle allo stato ideale in un processo veramente agile, in quanto non apportano alcun beneficio reale al progetto. mercato<\/a> valore.<\/p>\n Lo sviluppo di soluzioni tecniche perfette richiede un grande impegno da parte del team e una comunicazione molto pi\u00f9 estesa. Di conseguenza, le patch lavorano pi\u00f9 lentamente e il progetto si appesantisce a causa dell'eccessivo sviluppo.<\/p>\n Sviluppo agile<\/a> \u00e8 quello di fornire un sistema di lavoro codice<\/a> con il minimo sforzo. La verifica del codice \u00e8 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\u00e0 tecnica ottimale delle soluzioni si colloca a met\u00e0 strada tra il minimo determinato dal team di sviluppo<\/a> e il massimo che \u00e8 limitato dal budget.<\/p>\n In definitiva, la perfezione non porta da nessuna parte. \u00c8 interessante notare che anche la questione della sicurezza \u00e8 soggetta a questa regola: in teoria, qualsiasi sistema pu\u00f2 essere violato. Tuttavia, il minimo di sviluppo di cui sopra deve essere corrispondentemente pi\u00f9 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 \u00e8 sempre gravato da un alto rischio di errore e di introduzione di vulnerabilit\u00e0 di sicurezza, \u00e8 meglio utilizzare, ad esempio, il pulsante \"Accedi con Google\", la cui corretta implementazione \u00e8 relativamente veloce e sicura.<\/p>\n Finch\u00e9 l'obiettivo \u00e8 un breve time-to-market, ipotesi troppo ambiziose si rivelano controproducenti. In un processo apparentemente perfetto, l'eccesso di entusiasmo pu\u00f2 essere uno spreco di risorse.<\/a>.<\/p>\n Il design incentrato sull'utente \u00e8 bello. La cooperazione incentrata sull'uomo \u00e8 pi\u00f9 importante. Quando il team comunica sulla stessa lunghezza d'onda, pu\u00f2 ridurre spontaneamente ulteriori perdite potenziali.<\/p>\n A UX<\/a> Il progettista che \u00e8 aggiornato sulle tecnologie di frontend non proporr\u00e0 una soluzione alla MVP<\/a> che consumer\u00e0 un tempo irragionevole nella fase di implementazione.<\/p>\n Uno sviluppatore frontend che conosce l'euristica dell'usabilit\u00e0 sar\u00e0 in grado di adattare l'interfaccia a una determinata risoluzione dello schermo senza coinvolgere l'UX designer: correzione rapida, anteprima, accettazione.<\/p>\n Lavorare su un'applicazione richiede la sincronizzazione delle attivit\u00e0 di persone con profili di competenza completamente diversi. \u00c8 necessario conoscere la distribuzione delle competenze nel team per fornire efficacemente valore ai clienti.<\/p>\n Un team impegnato e sincronizzato \u00e8 un generatore di risparmio fondamentale. Questo tipo di agilit\u00e0 richiede uno sviluppo ottimale del prodotto<\/a>.<\/p>\n Una buona performance di squadra intesa in questo modo \u00e8 estremamente difficile da raggiungere, soprattutto nell'era del lavoro a distanza<\/a>. 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.<\/p>\n Nel contesto delle crescenti esigenze di comunicazione, strumenti come Whimsical, Miro, Mural, Figma e Balsamiq registrano un impressionante aumento di popolarit\u00e0.<\/p>\n Sicuramente il blocco e la necessit\u00e0 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:<\/p>\n La popolarit\u00e0 di questi strumenti determina naturalmente l'aumento della popolarit\u00e0 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.<\/p>\n Dovete sempre dotarvi di strumenti che snelliscano il flusso di informazioni nel progetto. L'apertura a nuovi strumenti e metodi \u00e8 anche uno dei fondamenti di un'efficace sviluppo del prodotto<\/a>.<\/p>\n Progettisti esperti sia dell'interfaccia che del architettura del software<\/a> di solito notano diverse soluzioni potenziali che dovrebbero essere verificate all'inizio della collaborazione e cercano efficacemente ispirazioni appropriate o addirittura soluzioni gi\u00e0 pronte sul mercato. Un buon esempio \u00e8 il framework Material UI, che di solito \u00e8 una scommessa sicura in fase di prototipo.<\/a>.<\/p>\n A volte \u00e8 sufficiente esaminare alcune implementazioni su Behance o Dribble e utilizzare l'ispirazione per sviluppare un mood board da passare poi allo sviluppatore. Quest'ultimo la user\u00e0 per mettere insieme un'immagine cliccabile. prototipo<\/a> che pu\u00f2 essere presentato agli early adopters per raccogliere feedback. Questa ricerca organica di un processo efficace da parte di persone impegnate nel design \u00e8 naturale.<\/p>\n Se volete fornire prodotti digitali in modo efficiente, dovete lasciare che le persone facciano il loro lavoro. Sapete qual \u00e8 il valore\/servizio che volete fornire ai vostri clienti: questo \u00e8 sufficiente. Un team di progetto competente e ben gestito sapr\u00e0 come fornire questo valore\/servizio nel pi\u00f9 breve tempo possibile e con il necessario rapporto costo-efficacia.<\/p>\n Mostratevi fiduciosi, condividete le responsabilit\u00e0 e apritevi a una vera e propria comunicazione a due vie, in modo che la vostra prodotto<\/a> sar\u00e0 migliore e il fardello di dover fare tutto da soli sar\u00e0 tolto dalle vostre spalle, cosa che spesso si rivela una corsa stancante per i fondatori e gli imprenditori! A The Codest<\/a>Traduciamo questo principio non solo nei progetti, ma anche nei processi interni: probabilmente \u00e8 per questo che godiamo di alti tassi di fidelizzazione sia dei clienti che dei dipendenti (storia vera, entrambi> 90%).<\/p>\n Concedetevi un po' di pigrizia, trasferite coraggiosamente le responsabilit\u00e0 e lasciate andare il lavoro superfluo che non \u00e8 necessario per andare avanti: le funzionalit\u00e0 che sarebbero \"belle da avere\" possono sempre aspettare.<\/p>\n Il processo di creazione di un prodotto digitale \u00e8 una costante collisione di prospettive, esperienze e fonti di informazione diverse, ognuna delle quali comporta il rischio di prendere una decisione di progettazione sbagliata.<\/p>\n Una buona comunicazione interna riduce questo rischio, ma \u00e8 solo una faccia della medaglia. La domanda su come rimanere in contatto con il mercato non ha ancora trovato risposta.<\/p>\n Business Intelligence, Assistenza clienti, dipartimenti di ricerca UX e molti altri, proprio come la team di sviluppo<\/a>Dovrebbero cercare di ottenere il minimo necessario per fornire risposte specifiche alle domande poste dal proprietario del prodotto o dal team UX.<\/p>\n 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 \u00e8 importante.<\/p>\n \u00c8 certo che essere in costante contatto con il mercato permette di definire le giuste traiettorie del progetto per farlo volare. Meno scontato \u00e8 il fatto che la necessit\u00e0 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.<\/p>\n Considerando tutte le questioni sopra citate, possiamo osservare diversi problemi che compaiono regolarmente nel processo di progettazione:<\/p>\n - essere eccessivamente orientati al profitto ed evitare di guardare agli insuccessi,<\/p>\n - imprecisione e non radiografare i propri errori,<\/p>\n - inseguire un prodotto perfetto che avete in testa, ma che non \u00e8 quello di cui il mercato ha bisogno,<\/p>\n - l'implementazione troppo zelante dei processi dei libri di testo - l'eccessivo sviluppo e l'eccessiva progettazione,<\/p>\n - inflessibilit\u00e0 del lavoro di squadra e costringere i dipendenti a rimanere solo nelle loro aree di specializzazione,<\/p>\n - comunicazione inefficace,<\/p>\n - tendenza a reinventare la ruota.<\/p>\n L'ottimizzazione dei processi su scala macro comprende la somma dei risparmi. Per affrontare adeguatamente le sfide sopra citate, \u00e8 necessario coinvolgere i colleghi in modo che presentino apertamente le idee per migliorare il processo.<\/p>\n A volte basta parlare meno e ascoltare pi\u00f9 attentamente i subordinati, i clienti, i partner - in base al ruolo e alla responsabilit\u00e0 di ciascuno - per raggiungere il successo.<\/p>\n Quando non si \u00e8 abbastanza, \u00e8 molto probabile che si stia investendo troppo.<\/a>. Avete troppi soldi?<\/p>\n Per saperne di pi\u00f9:<\/strong><\/p>\n CTO sfide - scalabilit\u00e0 e crescita dei prodotti software<\/a><\/p>\nLezioni apprese dai fallimenti<\/h2>\n
\n
\n
Costruire un prodotto perfetto \u00e8 come rincorrere il coniglio<\/h2>\n
\u00c8 bene sapere tutto di qualcosa e qualcosa di tutto.<\/h2>\n
Attrezzatura potente prima di partire<\/h2>\n
![\"Miro\"](\"\/app\/uploads\/2024\/05\/miro.png\" "\\"Miro\\"")
<\/p>\nSi pu\u00f2 (e si deve) essere pigri<\/h2>\n
Concentrarsi sulla ricerca delle risposte corrette<\/h2>\n
Conclusioni<\/h2>\n
![\"Zitto](\"\/app\/uploads\/2024\/05\/meme.png\" "\\"Zitto")
<\/p>\nZitto e prendi i tuoi soldi! Oh, e inoltre:<\/h2>\n
\n