Briding the Gaps Between Developers and Users v. Grudin Indledning Faktorer som kan påvirke bruger involvering Kontrakt udvikling Produkt udvikling Intern udvikling Oplæg til debat

Indledning Niveauet for brugerinddragelse Udviklingsmodeller: vandfald  spiral Brugerinddragelse og prototyper 3 paradigmer

Indledning 3 paradigmer –Kontraktudvikling Brugerne kendes fra starten, udviklerne kendes når kontrakten er underskrevet –Produktudvikling Brugerne kendes, når produktet er på markedet, udviklerne kendes fra starten –Intern udvikling Brugerne og udviklerne kendes fra starten

Indledning Mellemmænd kan mindske afstanden fra udviklere til brugere –konsulenter –3. parts udviklere –sælgere –forretningseksperter –fleksible eller flerledede kontrakter

Faktorer som kan påvirke bruger involvering Udvikingsafdelingen /- virksomhedens størrelse (små virksomheder kan være mere fleksible) Organisationens struktur og procedurer Brugerne er meget forskellige Usikkerhed i forbindelse med at designe til et nyt marked Mellemmænd – mellem udvikler og bruger (marketing, bruger-support m.m.)

Kontraktudvikling ovh1 Beskrivelse af situationen Government contract Vandfaldsmodel – minimal mulighed for prototyper Passer godt til den rene kontraktudvikling Prototyper = "build it twice" Kontrakten bliver en væg mellem brugere og udviklere

Kontraktudvikling ovh2 Muligheder for brugerdeltagelse Veldefinerede brugere Brugerne kan være med til at definere kontrakten

Kontraktudvikling ovh3 Forhindringer for brugerdeltagelse En kontrakt for hver fase Manglende brugerinddragelse skyldes –Unfair advantage –Geografisk afstand Man udvikler præcis hvad der står i kontrakten Prototyper er til for at forberede kunden på fejl (ikke rette dem)

Kontraktudvikling ovh4 Mellemmænd Surrogat udvikler/bruger Standard kontrakter Conceps of use – beskrivelse af brugerne Nye slags kontrakter: –med menneskelige faktorer –rigtig prototype der kan ændre dialog design

Produkt-udviklings situation ovh 1 Beskrivelse af situationen –Udvikling af et produkt, som skal sælges på et marked –Køber er ikke altid slutbrugeren, men kan være ledelsen –Behøver ikke at tage hensyn til den sociale kontekst som systemet skal anvendes i (i modsætning til in-house)

Produkt-udviklings situation ovh 2 Muligheder for brugerdeltagelse Har typisk mange ressource, som kan anvendes til at sikre brugervenlighed Har typisk mange brugergrænseflade specialister ansat

Produkt-udviklings situation ovh 3 Forhindringer for brugerdeltagelse Udviklerne skal acceptere deltagelse af uerfarne, ej-tekniske brugere Det er svært at involvere brugere hvis de ikke er identificeret ! Svært at få adgang til brugerne, som kan arbejde i forskellige virksomher i forskellige lande Korte udviklingsforløb

Produkt-udviklings situation ovh 4 Mellemmænd Salg- og marketings afdelinger Bruger-service/støtte afdelinger Brugergrupper Markedsundersøgelser

Intern-udviklings situation ovh 1 Beskrivelse af situationen –Også kaldet in-house udvikling –Brugere og udviklere er i samme virksomhed –F.eks de store banker, forsikringsselskaber og ATP-huset har en stor del af egenudvikling

Intern-udviklings situation ovh 2 Muligheder for brugerdeltagelse –Gode muligheder fordi brugere og udviklere er kendt fra starten og findes i samme virksomhed –Bruger-deltagelse giver bedre mulighed for at brugerne acceptere det nye system –Kommunikation kan udføres udfra en fælles kulturel baggrund –Nemmere overgange mellem de enkelte udviklingsfaser (udviklerne er i nærheden efter iværksættelsen)

Intern-udviklings situation ovh 3 Forhindringer for brugerdeltagelse –Geografiske eller organisatoriske adskillelse –Interesse-konflikter i virksomheden –Ledelsen er dem der får det primære udbytte af et system (ledelsesinformationssystemer) – slutbrugerne får besværet ! –Svært at udvælge repræsentative brugere Mangel på tid Tekniske interesserede brugere er interesserede men ikke repræsentative –Rapid-Prototyping kan give falske forventninger (gælder også ved kontrakt- og produktudvikling)

Intern-udviklings situation ovh 4 Mellemmænd ikke mange ”mellemmænd” (kun ledelse og human resources) Friedman’s 5 muligheder for at dække ”kløften” mellem brugere og udviklere –Direkte brugerdeltagelse ved udvikling efter traditionelle metoder(vandfald ?) –Slutbruger udvikling (systemer som kan tilpasses af slutbruger) –Decentralisere IT-udviklingen (udviklerne ud til brugerne) –Ændre systemudviklingen til prototyping og iterativ design –Udviklere skal både have forretningskendskab og IT-ekspertice

Oplæg til debat Hvordan er billedet i dag – 10 år efter artiklen er skrevet ? –In-house udvikling går mere i retning af bruge færdige komponenter og købe standardsystemer –In-house udvikling er blevet mere opmærksomme på brugervenlighed –? Hvilke erfaringer erfaringer deles på tværs af de 3 udviklings kontekster