![\"Swing-programvare](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
bildekilde: perfectdigital.com<\/em><\/p>\n Jeg synes det viser veldig godt at det kan oppst\u00e5 store avvik og mangel p\u00e5 visjoner i programvareutvikling<\/a> prosjekter mellom alle deltakere og involverte personer.<\/strong> Problemene oppst\u00e5r ofte helt fra begynnelsen, n\u00e5r kunden kommer med en (teoretisk sett) endelig produkt<\/a> visjon og presenterer den for team<\/a>. S\u00e5 kommer ytterligere misforst\u00e5elser, feiltolkninger og til slutt prosjekt<\/a> raskt inn p\u00e5 feil utviklingsvei.<\/p>\n Mens jeg analyserer grafen ovenfor, vil jeg trinnvis presentere alle mulige trusler og foresl\u00e5 hvordan du kan bekjempe dem. La oss komme rett til saken!<\/p>\n Det vil v\u00e6re avvik i produktvisjon<\/a> helt fra begynnelsen. Hvorfor det? Grunnen er veldig enkel - alle tolker virkeligheten p\u00e5 sin egen m\u00e5te, har en id\u00e9 om noe i hodet og presenterer kanskje ikke denne visjonen n\u00f8yaktig for den andre parten. Hvis du beskriver med ord et produkt du \u00f8nsker \u00e5 bygge, er det stor sannsynlighet for at den andre parten utviklingsteam<\/a> vil forst\u00e5 visjonen din p\u00e5 en annen m\u00e5te enn du hadde tenkt.<\/p>\n Det er selvf\u00f8lgelig mulig \u00e5 unng\u00e5 dette. Du b\u00f8r begynne \u00e5 visualisere s\u00e5 snart som mulig og diskutere de enkelte elementene i produktfunksjonaliteten basert p\u00e5 skisser. Interessant nok har de f\u00f8rste skissene vanligvis ingenting til felles med det endelige produktet. P\u00e5 dette stadiet er det imidlertid viktigst \u00e5 f\u00e5 visjonen til \u00e5 henge sammen.<\/p>\n Lurer du p\u00e5 hvorfor det f\u00f8rste og det andre bildet er s\u00e5 forskjellige? Prosjektlederen vil alltid ta en n\u00e6rmere titt p\u00e5 produktvisjonen. Men det er ikke det samme, er det viktig at en slik person, som i bunn og grunn er ansvarlig for hele<\/strong> programvare utviklingsprosess<\/a><\/strong>, forst\u00e5r problemet og behovene knyttet til produktet fullt ut<\/strong>. Prosjektlederen m\u00e5 ha et klart \"st\u00f8rre bilde\". Som du ser, er det ingen funksjonell forskjell p\u00e5 de to bildene. De ser bare forskjellige ut. For \u00e5 forst\u00e5 dette poenget bedre, la oss g\u00e5 tilbake til bilde nummer \u00e9n. I begynnelsen av prosjektet var det ingen skisser, og det f\u00f8rte allerede til en misforst\u00e5else. Produktets funksjonalitet er riktig, men designet er helt annerledes.<\/p>\n Noen ganger kjenner ikke analytikere og utviklere brukernes behov eller etablerte forretningsm\u00e5l. De ser bare den lille delen av hele prosjektet som har deres hovedfokus. De er ikke i stand til \u00e5 se prosjektet i et bredere perspektiv, og dette gjelder spesielt for store prosjekter der mange utviklere jobber samtidig.<\/p>\n Vi kan ogs\u00e5 bruke et annet eksempel. Det kan skje at problemet som skal l\u00f8ses, er feil beskrevet, for eksempel av produkteieren. Dette inneb\u00e6rer at det gis ufullstendig informasjon som utvikler<\/a> eller designeren skaper sine egne tolkninger, og produktet avviker mer og mer fra den tiltenkte utviklingsbanen.<\/p>\n Hvordan kan man endre p\u00e5 det? Jeg tror at en god l\u00f8sning er \u00e5 s\u00f8rge for at de som er sentrale i prosjektet, har detaljkunnskap om det - det s\u00e5kalte \"st\u00f8rre bildet\". Hvis det oppst\u00e5r misforst\u00e5elser, vil det v\u00e6re lettere for dem \u00e5 bringe programvareutviklingsprosessen<\/em> tilbake p\u00e5 rett spor. Husk derfor - hvis alle bare ser sitt lille fragment av den utviklede funksjonaliteten, blir misforst\u00e5elser i visjonen en sannsynlig trussel.<\/p>\n Her er saken enkel. Produktet m\u00e5 selge. Du m\u00e5 skille deg ut p\u00e5 en eller annen m\u00e5te, slik at for eksempel en enkel huske til hagen din f\u00e5r ekstraordin\u00e6re elementer. Ideen er \u00e5 overbevise en potensiell kj\u00f8per. Markedsf\u00f8rings- og salgsavdelingen vil helt sikkert gj\u00f8re alt for \u00e5 vise at produktet er unikt.<\/p>\n Manglende dokumentasjon er et sv\u00e6rt vanlig problem. Noen ganger kan det \u00e5 lage dokumentasjon under produktutvikling<\/a> virker som un\u00f8dvendig sl\u00f8sing med tid. Dette er en feil. Jeg sier ofte at endringer gj\u00f8res raskere p\u00e5 papiret enn i virkeligheten. kode<\/a>og det er noe i det. I tillegg er det lettere \u00e5 henvise til dokumentasjonen for \u00e5 spore eventuelle endringer. Tro meg, et prosjekt uten dokumentasjon har en sv\u00e6rt h\u00f8y risiko for \u00e5 g\u00e5 glipp av visjonen.<\/p>\n Denne fasen handler om \u00e5 plassere milj\u00f8et p\u00e5 serveren. Som i punktet om programmerere og analytikere, uten full data<\/a> og med kommunikasjonshull, kan det vise seg at bare en del av det n\u00f8dvendige milj\u00f8et er skapt.<\/p>\n Det er et resultat av d\u00e5rlig kommunikasjon, mangel p\u00e5 UX<\/a> og s\u00e5 videre. N\u00e5r det oppst\u00e5r feil, \u00f8ker utviklingstiden. Og tid er penger, ikke sant? Mitt tips er \u00e5 kj\u00f8re prosjektet i samsvar med Agile<\/a><\/strong>, oppretthold de h\u00f8yeste kommunikasjonsstandardene og hold klare budsjettretningslinjer. Jeg er ikke i tvil om at dere p\u00e5 denne m\u00e5ten vil unng\u00e5 slike problemer.<\/p>\n Kunder fokuserer ofte bare p\u00e5 \u00e5 bygge et produkt og bli ferdige med det. Vi lever imidlertid i en tid med mange endringer og teknologiske nyvinninger, og derfor er det n\u00f8dvendig \u00e5 opprettholde konstant teknisk st\u00f8tte. Tanken er \u00e5 unng\u00e5 en situasjon der noe plutselig slutter \u00e5 fungere fordi det blir utdatert og produktet mister sin verdi. Dette aspektet b\u00f8r heller ikke glemmes.<\/p>\n Vi har n\u00e5dd det siste punktet. Se p\u00e5 avviket mellom den f\u00f8rste og den siste grafen. Begge er tross alt relatert til kundens perspektiv. Hvorfor skjer dette? Alle lyver s\u00e5 enkelt som det \ud83d\ude42 Unders\u00f8kelsesresultater avviker alltid fra respondentenes faktiske behov. N\u00e5r de svarer p\u00e5 forskerens sp\u00f8rsm\u00e5l, \u00f8nsker brukerne \u00e5 vise seg fra sin beste side. Det er grunnen til det, DE OFTE IKKE SVARER SANNFERDIG<\/strong>men heller p\u00e5 en m\u00e5te de mener de b\u00f8r svare. I utgangspunktet \u00f8nsker de ikke \u00e5 bli utsatt for andres negative vurdering. Her er et lite hint til deg - nevn i instruksjonene at det verken finnes gode eller d\u00e5rlige svar.<\/p>\n Hvor ellers kommer forskjellene til syne? Folk vet ofte ikke hva de egentlig vil ha. Ofte sier brukerne i utgangspunktet at de trenger 10 funksjoner i produktet, mens de senere bare bruker for eksempel 3.<\/p>\n S\u00e5 hvordan l\u00f8ser du dette problemet? I tillegg til \u00e5 sp\u00f8rre brukerne om hva de \u00f8nsker og trenger, la dem teste produktet, helst p\u00e5 autentiske gjenstander for \u00e5 opprettholde troverdigheten. Jo flere tester under utviklingen av produkter, desto st\u00f8rre er sjansen for at resultatet blir n\u00f8yaktig.<\/p>\n Hvis du noen gang blir medlem av en programvareutvikling<\/a> prosjektet, husk eksemplene mine og trekk konklusjoner for ikke \u00e5 kopiere feilene ovenfor. Og husk at disse konseptene er veldig viktige for \u00e5 bygge et produkt (applikasjon) fra bunnen av:<\/p>\n - god UX og tester, slik at du kan l\u00e6re hva brukerne dine virkelig trenger,<\/p>\n - kommunikasjon i prosjektet, slik at n\u00f8kkelpersoner i prosjektet f\u00e5r en dyp forst\u00e5else av problemet og behovene,<\/p>\n - utvikle produktet i samsvar med Smidig<\/a>,<\/p>\n - ikke glem teknisk st\u00f8tte.<\/p>\n Les mer om dette:<\/strong><\/p>\n - Hvordan lede eksterne utviklere p\u00e5 en effektiv m\u00e5te? En guide for CTO-er<\/a><\/p>\n - Python vs. Ruby? Hvilken teknologi b\u00f8r du bruke til produktutvikling?<\/a><\/p>\nDu kjenner dette bildet, ikke sant?<\/h2>\n
1. Hvordan forklarte kunden ideen?<\/strong><\/h2>\n
2. Hvordan forsto prosjektlederen det?<\/strong><\/h2>\n
3. Hvordan utformet analytikeren den? og<\/em><\/strong> 4. Hvordan skrev programmereren det?<\/strong><\/h2>\n
5. Hvordan beskrev bedriftskonsulenten det?<\/strong><\/h2>\n
6. Hvordan ble prosjektet dokumentert?<\/strong><\/h2>\n
7. Hvilke operasjoner ble installert?<\/strong><\/h2>\n
8. Hvordan ble kunden fakturert?<\/strong><\/h2>\n
9. Hvordan ble den st\u00f8ttet?<\/strong><\/h2>\n
10. Hva trengte kunden egentlig?<\/strong><\/h2>\n
Sammendrag<\/strong><\/h2>\n