![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
fonte: perfectdigital.com<\/em><\/p>\n Penso che dimostri molto bene che grandi discrepanze e una mancanza di visione possono apparire in sviluppo software<\/a> progetti tra tutti i partecipanti e le persone coinvolte.<\/strong> I problemi sorgono spesso fin dall'inizio, quando il cliente si presenta con un progetto (teoricamente) definitivo. prodotto<\/a> visione e la presenta al squadra<\/a>. Seguono ulteriori malintesi, interpretazioni errate e, alla fine, il progetto<\/a> si avvia rapidamente sulla strada sbagliata dello sviluppo.<\/p>\n Analizzando il grafico precedente, presenter\u00f2 passo dopo passo tutte le possibili minacce e suggerir\u00f2 come combatterle. Andiamo subito al sodo!<\/p>\n Ci saranno discrepanze nella visione del prodotto<\/a> fin dall'inizio. Perch\u00e9? Il motivo \u00e8 molto semplice: ognuno interpreta la realt\u00e0 a modo suo, ha un'idea di qualcosa nella mente e pu\u00f2 non presentare con precisione questa visione all'interlocutore. Se descrivete a parole un prodotto che vorreste costruire, c'\u00e8 un'alta probabilit\u00e0 che l'interlocutore si faccia un'idea precisa della realt\u00e0. team di sviluppo<\/a> capir\u00e0 la vostra visione in un modo diverso da quello che intendete.<\/p>\n Naturalmente \u00e8 possibile evitarlo. \u00c8 necessario iniziare a visualizzare il prima possibile e discutere i singoli elementi delle funzionalit\u00e0 del prodotto sulla base di schizzi. \u00c8 interessante notare che i primi schizzi di solito non hanno nulla in comune con il prodotto finale. In questa fase, tuttavia, la cosa pi\u00f9 importante \u00e8 rendere coerente la visione.<\/p>\n Vi chiedete perch\u00e9 la prima e la seconda immagine sono cos\u00ec diverse? Il leader del progetto guarder\u00e0 sempre pi\u00f9 da vicino la visione del prodotto. Tuttavia, \u00e8 importante che tale persona, essenzialmente responsabile per l'intero<\/strong> software processo di sviluppo<\/a><\/strong>, comprende appieno il problema e le esigenze relative al prodotto<\/strong>. Il responsabile del progetto deve avere chiaro il \"quadro generale\". Come potete vedere, le due immagini non differiscono in termini di funzionalit\u00e0. Hanno solo un aspetto diverso. Per capire meglio questo punto, torniamo all'immagine numero uno. All'inizio del progetto non c'erano schizzi e questo ha gi\u00e0 portato a un malinteso. La funzionalit\u00e0 del prodotto \u00e8 corretta, ma il design \u00e8 completamente diverso.<\/p>\n A volte, analisti e sviluppatori non conoscono le esigenze degli utenti o gli obiettivi aziendali stabiliti. Vedono solo una piccola parte dell'intero progetto, che cattura la loro attenzione principale. Non sono in grado di guardare da una prospettiva pi\u00f9 ampia, e questo \u00e8 particolarmente vero per i progetti di grandi dimensioni, dove molti sviluppatori lavorano contemporaneamente.<\/p>\n Possiamo anche usare un altro esempio. Pu\u00f2 accadere che il problema da risolvere sia descritto in modo errato, ad esempio dal proprietario del prodotto. Questo comporta la fornitura di informazioni incomplete su cui il sviluppatore<\/a> o designer creano le proprie interpretazioni e il prodotto si discosta sempre pi\u00f9 dal percorso di sviluppo previsto.<\/p>\n Come cambiare questa situazione? Credo che una buona soluzione sia quella di assicurarsi che le persone chiave per il progetto abbiano una conoscenza dettagliata del progetto stesso, il cosiddetto \"quadro generale\". In caso di incomprensioni, sar\u00e0 pi\u00f9 facile per loro portare il progetto a conoscenza di tutti. processo di sviluppo del software<\/em> sulla strada giusta. Pertanto, ricordate: se ognuno vede solo il suo piccolo frammento di funzionalit\u00e0 sviluppata, le incomprensioni nella visione diventano una probabile minaccia.<\/p>\n In questo caso, la questione \u00e8 semplice. Il prodotto deve vendere. Bisogna distinguersi in qualche modo, in modo che, ad esempio, una semplice altalena per il giardino raggiunga elementi straordinari. L'idea \u00e8 quella di convincere un potenziale acquirente. Il reparto marketing e vendite far\u00e0 sicuramente di tutto per dimostrare che il prodotto \u00e8 unico.<\/p>\n La documentazione mancante \u00e8 un problema molto comune. A volte, la creazione di documentazione durante sviluppo del prodotto<\/a> sembra un'inutile perdita di tempo. Si tratta di un errore. Dico molto spesso che le modifiche si fanno pi\u00f9 velocemente sulla carta che nella realt\u00e0. codice<\/a>e c'\u00e8 qualcosa di vero. Inoltre, \u00e8 pi\u00f9 facile fare riferimento alla documentazione per tenere traccia di eventuali modifiche. Credetemi, un progetto senza documentazione corre un rischio molto elevato di perdere la visione.<\/p>\n Questa fase si riferisce al posizionamento dell'ambiente sul server. Come per il punto relativo ai programmatori e agli analisti, senza una piena dati<\/a> e con lacune nella comunicazione, pu\u00f2 risultare che sia stata creata solo una parte dell'ambiente necessario.<\/p>\n \u00c8 il risultato di una scarsa comunicazione, della mancanza di UX<\/a> e cos\u00ec via. La comparsa di errori aumenta i tempi di sviluppo. E il tempo \u00e8 denaro, giusto? Il mio suggerimento \u00e8 quello di gestire il progetto in conformit\u00e0 con Agile<\/a><\/strong>mantenere i pi\u00f9 alti standard di comunicazione e mantenere chiare le linee guida del budget. Non ho dubbi che cos\u00ec facendo eviterete questi problemi.<\/p>\n Spesso i clienti si concentrano solo sulla realizzazione di un prodotto e si fermano a quello. Tuttavia, viviamo in un'epoca di molti cambiamenti e innovazioni tecnologiche, motivo per cui \u00e8 necessario mantenere un'assistenza tecnica costante. L'idea \u00e8 quella di evitare una situazione in cui qualcosa smette improvvisamente di funzionare perch\u00e9 diventa obsoleto e il prodotto perde il suo valore. Anche questo aspetto non va dimenticato.<\/p>\n Abbiamo raggiunto l'ultimo punto. Osservate la discrepanza tra il primo e l'ultimo grafico. Entrambi si riferiscono alla prospettiva del cliente. Perch\u00e9 succede questo? Tutti lo dicono in modo semplice \ud83d\ude42 I risultati dei sondaggi differiscono sempre dalle reali esigenze degli intervistati. Nel rispondere alla domanda del ricercatore, gli utenti vogliono mostrare il loro lato migliore. Pertanto, SPESSO NON RISPONDONO IN MODO SINCERO<\/strong>ma piuttosto in un modo in cui pensano di dover rispondere. In sostanza, non vogliono essere esposti alla valutazione negativa degli altri. Ecco un piccolo suggerimento: menzionate nelle istruzioni che non ci sono n\u00e9 risposte buone n\u00e9 cattive.<\/p>\n Dove appaiono le differenze? Spesso le persone non sanno cosa vogliono veramente. Molto spesso gli utenti dichiarano inizialmente di aver bisogno di 10 funzionalit\u00e0 nel prodotto, mentre in seguito ne usano solo 3.<\/p>\n Come risolvere questo problema? Oltre a chiedere agli utenti ci\u00f2 che vogliono e di cui hanno bisogno, consentite loro di testare il prodotto, preferibilmente su articoli autentici per mantenere la credibilit\u00e0. Pi\u00f9 test vengono effettuati durante la creazione dei prodotti, maggiore \u00e8 la possibilit\u00e0 che il risultato sia accurato.<\/p>\n Se diventate membri di un'associazione sviluppo software<\/a> progetto, ricordate i miei esempi e traete le conclusioni per non copiare gli errori di cui sopra. E ricordate che questi concetti sono molto importanti nella costruzione di un prodotto (applicazione) da zero:<\/p>\n - una buona UX e dei test, in modo da poter capire quali sono le reali esigenze degli utenti,<\/p>\n - comunicazione all'interno del progetto, in modo che le persone chiave del progetto abbiano a disposizione una comprensione profonda del problema e delle esigenze,<\/p>\n - sviluppare il prodotto in conformit\u00e0 con Agile<\/a>,<\/p>\n - non dimenticate il supporto tecnico.<\/p>\n Per saperne di pi\u00f9:<\/strong><\/p>\n - Come gestire efficacemente gli sviluppatori remoti? La guida per gli CTO<\/a><\/p>\n - Python vs. Ruby? Quale tecnologia utilizzare per lo sviluppo dei prodotti?<\/a><\/p>\nConoscete questa immagine, vero?<\/h2>\n
1. Come il cliente ha spiegato l'idea?<\/strong><\/h2>\n
2. Come l'ha capito il responsabile del progetto?<\/strong><\/h2>\n
3. Come lo ha progettato l'analista? e<\/em><\/strong> 4. Come lo ha scritto il programmatore?<\/strong><\/h2>\n
5. Come lo ha descritto il consulente aziendale?<\/strong><\/h2>\n
6. Come \u00e8 stato documentato il progetto?<\/strong><\/h2>\n
7. Quali operazioni sono state installate?<\/strong><\/h2>\n
8. Come \u00e8 stato fatturato il cliente?<\/strong><\/h2>\n
9. Come \u00e8 stato supportato?<\/strong><\/h2>\n
10. Di cosa aveva realmente bisogno il cliente?<\/strong><\/h2>\n
Sintesi<\/strong><\/h2>\n