Brukermedvirkning In 140 Forelesning

Historie Skandinaviske tradisjon Sosio-teknisk metode NJMF-prosjektet( ) –Dataavtalen LO-NAF(i dag NHO) –Arbeidsmiljøloven §12 UTOPIA prosjektet( ) Aksjonsforskning I dag: stor enighet i software industrien at brukermedvirkning er viktig

Hvorfor brukermedvirkning? Det er brukernes arbeid som skal støttes vha. IT Problemdefinering en viktig del av systemutviklingsprosessen –Brukere har ofte motstridende behov –Perfekt teknisk løsning, men for galt problem Gjensidig læring mellom bruker og utvikler –Brukere må lære om IT –Utviklere må lære om problemområdet –Flere perspektiver Eierskap til systemet Prosess like viktig som produktet

Betingelser for brukermedvirkning Relasjonen til brukerorganisasjonen –Leverandør av hyllevare –Konsulent –Intern utvikling Systemutvikleren er selv ofte brukeren Grad av usikkerhet –Rutine, problemløsning og problemdefinering

Brukermedvirkning kun ved utforming av kravspesifikasjonen er ikke nok Krav.spek er ofte ikke presis nok Detaljer krever kommunikasjon med brukerne Krav endres Vi gjøre feil Vi lærer Andre løsninger er billigere og bedre Analyse, design og implementering påvirker hverandre

Systembeskrivelser med eller for brukere Systembeskrivelse for brukere degenererer lett til reklame Systembeskrivelse med brukerne er en gjensidig læringsprosess –Krever en sosio-teknisk tilnærming –Unngå abstrakte diskusjoner Prototyping Bedriftsbesøk Demonstrasjoner Veggraf

Systembeskrivelser med brukere Gjensidig kunnskapsoppbygging Tekniske spørsmål ses konsekvent i relasjon til brukernes arbeid og organisasjon Veksle mellom generelle beskrivelser av arbeid, spesifikke beskrivelser av systemet og relasjonen mellom dem Skape konkrete forestillinger om systemet og bruken av systemet

Eksperimentell systemutvikling Analyse og design bør utføres i gjensidig samspill Prototyping –Formålet med prototypen –Hvem evaluerer prototypen? Systemutvikleren, representanter for brukerne, eller alle brukerne? –Gir brukerne reel mulighet til å påvirke systemet

Eksperimentell systemutvikling(2) Problemer og fallgruber: –Vanskelig å styre prosjektet –Vanskelig å styre forventninger til brukerne –Bruk og kast–prototype blir endelig (del)system –Tidlig prototype kan føre til blindhet i forhold til andre systemer

Bruk av ulike perspektiver Bruk av en metode innebærer et bestemt perspektiv Konfliktperspektiv eller harmoni Databaseperspektiv Kommunikasjonsperspektiv Verktøyperspektiv Fugleperspektiv eller personperspektiv

Perspektiv Noe vi anvender når vi forholder oss til et fenomen Tre vesentlige egenskaper –Ståsted –Seleksjon –Tolkning De er viktig at vi bruker ulike perspektiver i systemutviklingsprosessen (eks. database og kommunikasjonsperspektiv)

Valg av samarbeidsform Samarbeidsform bør bestemmes ved prosjektetablering (men revurderes ut i fra situasjoner som oppstår) Rutine-, problemløsning-, eller problemdefineringssituasjon? Risikovurdering

Samarbeidsformer - 1 Samtaler og intervjuer med brukere –Strukturerte eller ustrukturerte –Idemyldring –Forutsetter at brukerne vet hva de vil –Billig teknikk

Samarbeidsformer - 2 Studere kjent system –I en annen organisasjon eller en annens leverandørs system –Krav utformes ut i fra disse systemene –Forutsetter at krav til funksjonalitet er kjent

Samarbeidsformer – 3 Systematisk analyse av arbeidssituasjon og designforslag –Mulighet for nytenkning –Forutsetter gode abstraksjonsevner til brukerne og gode kommunikasjonsevner hos utviklerne –Kan være kostbar –Bygger på idealet av en rasjonell systemutviklingsprosess

Samarbeidsformer – 4 Eksperimentell systemutvikling/prototyping –Håndterer usikkerhet

Teknikk for valg av samarbeidsform Trinn 1: Definer situasjonen Trinn 2: Karakteriser situasjonen Trinn 3: Vurder usikkerhet Trinn 4: Velg PRIMÆR samarbeidsform Kvalitativ vurdering, ikke kvantitativ

Trinn 1: Definere situasjonen Hva er problemområdet for prosjektet? Hvilket system skal utvikles? Hvem er brukerne av det nye system? Hvem er systemutviklerne?

Trinn 2: Karakterisere situasjonen Problemområdet: (Svaralternativ: ja,nei kanskje) –Finnes det en brukbar beskrivelse av problemområdet? –Er problemområdet stabilt? –Finnes det fastlagte prosedyrer/rutiner? –Er dataene stabile? IT-systemet –Anvendes IT-systemet utelukkende på lavere nivå i organisasjonen? –Er systemet enkelt å forstå?

Trinn 2 forts. Brukerne: –Er brukergruppen homogen? –Har brukerne abstraksjonsevne? –Har brukerne erfaring med oppgavene i problemområdet? –Har brukerne erfaring med tilsvarende edb-systemer? –Har brukerne erfaring med systemutvikling? Systemutviklerene: –Har systemutviklerne kjennskap til oppgavene i problemområdet? –Har systemutviklerne erfaring med utvikling av tilsvarende systemer? –Har systemutviklerne analyse- og designerfaring?

Trinn 3: Vurdere usikkerhet Eksistens og stabilitet av krav til systemet Evne hos brukerne til at formulere krav Evne hos systemutviklerne til å frembringe og vurdere krav:

Trinn 4: Velg primær samarbeidsform Situasjoner: Rutine Problemløsning Problemdefinering Samarbeidsform: Uformell samtaler Analyse av kjent system Systematisk analyse Eksperimentell utvikling Lav usikkerhet Høy usikkerhet