Den stygge sannheten om programvareutviklingsprosessen

bildekilde: perfectdigital.com

Du kjenner dette bildet, ikke sant?

Jeg synes det viser veldig godt at det kan oppstå store avvik og mangel på visjoner i programvareutviklingsprosjekter mellom alle deltakere og involverte personer. Problemene oppstår ofte helt fra begynnelsen, når kunden kommer med en (teoretisk sett) endelig produkt visjon og presenterer den for team. Så kommer ytterligere misforståelser, feiltolkninger og til slutt prosjekt raskt inn på feil utviklingsvei.

Mens jeg analyserer grafen ovenfor, vil jeg trinnvis presentere alle mulige trusler og foreslå hvordan du kan bekjempe dem. La oss komme rett til saken!

1. Hvordan forklarte kunden ideen?

Det vil være uoverensstemmelser i produktvisjonen helt fra begynnelsen. Hvorfor er det slik? Årsaken er veldig enkel - alle tolker virkeligheten på sin egen måte, har en idé om noe i hodet og presenterer kanskje ikke denne visjonen nøyaktig for den andre parten. Hvis du beskriver med ord et produkt du ønsker å bygge, er det stor sannsynlighet for at utviklingsteamet vil forstå visjonen din på en annen måte enn du hadde tenkt.

Det er selvfølgelig mulig å unngå dette. Du bør begynne å visualisere så snart som mulig og diskutere de enkelte elementene i produktfunksjonaliteten basert på skisser. Interessant nok har de første skissene vanligvis ingenting til felles med det endelige produktet. På dette stadiet er det imidlertid viktigst å få visjonen til å henge sammen.

2. Hvordan forsto prosjektlederen det?

Lurer du på hvorfor det første og det andre bildet er så forskjellige? Prosjektlederen vil alltid ta en nærmere titt på produktvisjonen. Men det er ikke det samme, er det viktig at en slik person, som i bunn og grunn er ansvarlig for hele programvareutvikling prosess, forstår problemet og behovene knyttet til produktet fullt ut. Prosjektlederen må ha et klart "større bilde". Som du ser, er det ingen funksjonell forskjell på de to bildene. De ser bare forskjellige ut. For å forstå dette poenget bedre, la oss gå tilbake til bilde nummer én. I begynnelsen av prosjektet var det ingen skisser, og det førte allerede til en misforståelse. Produktets funksjonalitet er riktig, men designet er helt annerledes.

3. Hvordan utformet analytikeren den? og 4. Hvordan skrev programmereren det?

Noen ganger kjenner ikke analytikere og utviklere brukernes behov eller etablerte forretningsmål. De ser bare den lille delen av hele prosjektet som har deres hovedfokus. De er ikke i stand til å se prosjektet i et bredere perspektiv, og dette gjelder spesielt for store prosjekter der mange utviklere jobber samtidig.

Vi kan også bruke et annet eksempel. Det kan skje at problemet som skal løses, er feil beskrevet, for eksempel av produkteieren. Dette innebærer at det gis ufullstendig informasjon som utvikleren eller designeren lager sine egne tolkninger av, og produktet avviker mer og mer fra den tiltenkte utviklingsveien.

Hvordan kan man endre på det? Jeg tror at en god løsning er å sørge for at de som er sentrale i prosjektet, har detaljkunnskap om det - det såkalte "større bildet". Hvis det oppstår misforståelser, vil det være lettere for dem å bringe programvareutviklingsprosessen tilbake på rett spor. Husk derfor - hvis alle bare ser sitt lille fragment av den utviklede funksjonaliteten, blir misforståelser i visjonen en sannsynlig trussel.

5. Hvordan beskrev bedriftskonsulenten det?

Her er saken enkel. Produktet må selge. Du må skille deg ut på en eller annen måte, slik at for eksempel en enkel huske til hagen din får ekstraordinære elementer. Ideen er å overbevise en potensiell kjøper. Markedsførings- og salgsavdelingen vil helt sikkert gjøre alt for å vise at produktet er unikt.

6. Hvordan ble prosjektet dokumentert?

Manglende dokumentasjon er et svært vanlig problem. Noen ganger kan det å lage dokumentasjon under produktutvikling virker som unødvendig sløsing med tid. Dette er en feil. Jeg sier ofte at endringer gjøres raskere på papiret enn i virkeligheten. kodeog det er noe i det. I tillegg er det lettere å henvise til dokumentasjonen for å spore eventuelle endringer. Tro meg, et prosjekt uten dokumentasjon har en svært høy risiko for å gå glipp av visjonen.

7. Hvilke operasjoner ble installert?

Denne fasen refererer til å plassere miljøet på serveren. Som i punktet om programmerere og analytikere, uten fullstendige data og med kommunikasjonshull, kan det vise seg at bare en del av det nødvendige miljøet er opprettet.

8. Hvordan ble kunden fakturert?

Det er et resultat av dårlig kommunikasjon, manglende UX og så videre. Når det oppstår feil, øker utviklingstiden. Og tid er penger, ikke sant? Mitt tips er å kjøre prosjektet i samsvar med Agile, oppretthold de høyeste kommunikasjonsstandardene og hold klare budsjettretningslinjer. Jeg er ikke i tvil om at dere på denne måten vil unngå slike problemer.

9. Hvordan ble den støttet?

Kunder fokuserer ofte bare på å 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ødvendig å opprettholde konstant teknisk støtte. Tanken er å unngå en situasjon der noe plutselig slutter å fungere fordi det blir utdatert og produktet mister sin verdi. Dette aspektet bør heller ikke glemmes.

10. Hva trengte kunden egentlig?

Vi har nådd det siste punktet. Se på avviket mellom den første og den siste grafen. Begge er tross alt relatert til kundens perspektiv. Hvorfor skjer dette? Alle lyver så enkelt som det 🙂 Undersøkelsesresultater avviker alltid fra respondentenes faktiske behov. Når de svarer på forskerens spørsmål, ønsker brukerne å vise seg fra sin beste side. Det er grunnen til det, DE OFTE IKKE SVARER SANNFERDIGmen heller på en måte de mener de bør svare. I utgangspunktet ønsker de ikke å bli utsatt for andres negative vurdering. Her er et lite hint til deg - nevn i instruksjonene at det verken finnes gode eller dårlige svar.

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.

Så hvordan løser du dette problemet? I tillegg til å spørre brukerne om hva de ønsker og trenger, la dem teste produktet, helst på autentiske gjenstander for å opprettholde troverdigheten. Jo flere tester under utviklingen av produkter, desto større er sjansen for at resultatet blir nøyaktig.

Sammendrag

Hvis du noen gang blir medlem av en programvareutvikling prosjektet, husk eksemplene mine og trekk konklusjoner for ikke å kopiere feilene ovenfor. Og husk at disse konseptene er veldig viktige for å bygge et produkt (applikasjon) fra bunnen av:

- god UX og tester, slik at du kan lære hva brukerne dine virkelig trenger,

- kommunikasjon i prosjektet, slik at nøkkelpersoner i prosjektet får en dyp forståelse av problemet og behovene,

- utvikle produktet i samsvar med Smidig,

- ikke glem teknisk støtte.

Les mer om dette:

– Hvordan lede eksterne utviklere på en effektiv måte? En guide for CTO-er

– Python vs. Ruby? Hvilken teknologi bør du bruke til produktutvikling?

– En rask guide til hvordan du bygger og utvikler din egen markedsplass. Hva er verdt å vite?