Den grimme sandhed om softwareudviklingsprocessen

Billedkilde: perfectdigital.com

Du kender dette billede, ikke?

Jeg synes, det viser meget godt, at der kan opstå store uoverensstemmelser og mangel på visioner i softwareudviklingsprojekter mellem alle deltagere og involverede personer. Problemerne opstår ofte helt fra begyndelsen, når kunden kommer med en (teoretisk) endelig produkt vision og præsenterer den for hold. Så kommer der flere misforståelser, fejlfortolkninger og til sidst... projekt går hurtigt ned ad den forkerte udviklingsvej.

Mens jeg analyserer grafen ovenfor, vil jeg trin for trin præsentere alle mulige trusler og foreslå, hvordan man kan bekæmpe dem. Lad os komme i gang med det samme!

1. Hvordan forklarede kunden sin idé?

Der vil være uoverensstemmelser i produktvisionen lige fra begyndelsen. Hvorfor er det sådan? Årsagen er meget enkel - alle fortolker virkeligheden på deres egen måde, har en idé om noget i tankerne og præsenterer måske ikke denne vision nøjagtigt for den anden part. Hvis du med ord beskriver et produkt, som du gerne vil bygge, er der stor sandsynlighed for, at udviklingsteamet vil forstå din vision på en anden måde, end du havde tænkt dig.

Det er selvfølgelig muligt at undgå dette. Du bør begynde at visualisere så hurtigt som muligt og diskutere de enkelte elementer i produktets funktioner ud fra skitser. Interessant nok har de første skitser normalt intet til fælles med det endelige produkt. På dette stadie er det vigtigste dog at gøre visionen sammenhængende.

2. Hvordan forstod projektlederen det?

Undrer du dig over, hvorfor det første og det andet billede er så forskellige? Projektlederen vil altid se nærmere på produktvisionen. Men det er ikke tilfældet, er det vigtigt, at en sådan person, der i bund og grund er ansvarlig for hele softwareudvikling proces, forstår fuldt ud problemet og de behov, der er relateret til produktet. Projektlederen skal have et klart "større billede". Som du kan se, adskiller de to billeder sig ikke med hensyn til funktionalitet. De ser bare forskellige ud. For bedre at forstå dette punkt, lad os vende tilbage til billede nummer et. I begyndelsen af projektet var der ingen skitser, og det førte allerede til en misforståelse. Produktets funktionalitet er korrekt, men designet er helt anderledes.

3. Hvordan designede analytikeren det? og 4. Hvordan har programmøren skrevet det?

Nogle gange kender analytikere og udviklere ikke brugernes behov eller de etablerede forretningsmål. De ser kun den lille del af hele projektet, som indfanger deres hovedfokus. De er ikke i stand til at se det fra et bredere perspektiv, og det er især tilfældet i store projekter, hvor mange udviklere arbejder på samme tid.

Vi kan også bruge et andet eksempel. Det kan ske, at det problem, der skal løses, er beskrevet forkert, f.eks. af produktejeren. Det indebærer, at der gives ufuldstændige oplysninger, som udvikleren eller designeren bruger til at skabe deres egne fortolkninger, og produktet afviger mere og mere fra den planlagte udviklingsvej.

Hvordan ændrer man på det? Jeg tror, at en god løsning er at sørge for, at de mennesker, der er centrale for projektet, har detaljeret viden om det - det såkaldte "større billede". I tilfælde af misforståelser vil det være lettere for dem at bringe softwareudviklingsproces tilbage på rette spor. Husk derfor - hvis alle kun ser deres lillebitte fragment af den udviklede funktionalitet, bliver misforståelserne i visionen en sandsynlig trussel.

5. Hvordan beskrev virksomhedskonsulenten det?

Her er sagen enkel. Produktet skal sælge. Du skal skille dig ud på en eller anden måde, så f.eks. en simpel gynge til din have får ekstraordinære elementer. Ideen er at overbevise en potentiel køber. Marketing- og salgsafdelingen vil helt sikkert gøre alt for at vise, at produktet er unikt.

6. Hvordan blev projektet dokumenteret?

Manglende dokumentation er et meget almindeligt problem. Nogle gange skaber man dokumentation under produktudvikling virker som et unødvendigt spild af tid. Det er en fejltagelse. Jeg siger ofte, at ændringer sker hurtigere på papir end i praksis. Kodeog der er noget om snakken. Derudover er det lettere at henvise til dokumentationen for at spore eventuelle ændringer. Tro mig, et projekt uden dokumentation har en meget stor risiko for at gå glip af visionen.

7. Hvilke operationer blev installeret?

Denne fase handler om at placere miljøet på serveren. Som i punktet om programmører og analytikere kan det uden fuldstændige data og med kommunikationshuller vise sig, at kun en del af det nødvendige miljø er blevet oprettet.

8. Hvordan blev kunden faktureret?

Det er resultatet af dårlig kommunikation, manglende UX og så videre. Når der opstår fejl, øges udviklingstiden. Og tid er penge, ikke sandt? Mit tip er at køre projektet i overensstemmelse med AgileOprethold de højeste kommunikationsstandarder og hold klare budgetretningslinjer. Jeg er ikke i tvivl om, at du på den måde vil undgå sådanne problemer.

9. Hvordan blev det støttet?

Kunderne fokuserer ofte kun på at bygge et produkt og blive færdige med det. Men vi lever i en tid med mange forandringer og teknologiske nyskabelser, og derfor er det nødvendigt at opretholde en konstant teknisk support. Ideen er at undgå en situation, hvor noget pludselig holder op med at virke, fordi det bliver forældet, og produktet mister sin værdi. Dette aspekt bør heller ikke glemmes.

10. Hvad havde kunden virkelig brug for?

Vi er nået til det sidste punkt. Se på forskellen mellem den første og den sidste graf. Begge relaterer trods alt til kundens perspektiv. Hvorfor sker dette? Alle siger, at det er så enkelt som det er 🙂 Undersøgelsesresultater adskiller sig altid fra respondenternes faktiske behov. Når brugerne besvarer forskerens spørgsmål, vil de gerne vise sig fra deres bedste side. Det er derfor, DE SVARER OFTE IKKE ÆRLIGTmen snarere på en måde, som de mener, de bør svare på. Dybest set ønsker de ikke at blive udsat for andres negative vurdering. Her er et lille hint til dig - nævn i instruktionerne, at der hverken er gode eller dårlige svar.

Hvor dukker forskellene ellers op? Folk ved ofte ikke, hvad de egentlig vil have. Ofte siger brugerne først, at de har brug for 10 funktioner i produktet, og senere bruger de faktisk kun f.eks. 3.

Så hvordan løser man dette problem? Ud over at spørge brugerne, hvad de vil have og har brug for, skal du lade dem teste produktet, helst på autentiske genstande for at bevare troværdigheden. Jo flere tests under skabelsen af produkter, jo større er chancen for, at resultatet bliver præcist.

Sammenfatning

Hvis du nogensinde bliver medlem af en softwareudvikling projekt, husk mine eksempler og drag konklusioner for ikke at kopiere ovenstående fejl. Og husk, at disse koncepter er meget vigtige, når man skal bygge et produkt (en applikation) fra bunden:

- god UX og tests, så du kan lære, hvad dine brugere virkelig har brug for,

- kommunikation inden for projektet, så en dyb forståelse af problemet og behovene er tilgængelig for nøglepersoner i projektet,

- udvikle produktet i overensstemmelse med Agil,

- Glem ikke den tekniske support.

Læs mere om det:

– Hvordan håndterer man effektivt eksterne udviklere? En guide til CTO'er

– Python vs. Ruby? Hvilken teknologi skal du bruge til produktudvikling?

– En hurtig guide til at opbygge og udvikle din egen markedsplads. Hvad er værd at vide?