Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje

Transkript

1 Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje 30. Maj 2003 Informatik Gruppe E4-101: Aalborg Universitet Eva Lund Andersen Jens Møller Lauridsen Joan Marianne Nielsen Lasse Bech Eiler Louise Dalum Hvid

2 Institut for Datalogi Aalborg Universitet TITEL: Tidsregistreringssystem til Løgstør Kommunale Hjemmepleje TEMA: Design og vurdering af et edb-system i samarbejde med brugere PROJEKT PERIODE: INF2, 3. feburar maj 2003 PROJEKT GRUPPE: E4-101 GRUPPE MEDLEMMER: Eva Lund Andersen Jens Møller Lauridsen Joan Marianne Nielsen Lasse Bech Eiler Louise Dalum Hvid VEJLEDER: Otto Veie OPLAG: 8 ANTAL SIDER: 163 SYNOPSIS: Denne rapport omhandler udviklingen af et tidsregistreringssystem til hjemmeplejen i Løgstør Kommune. Fokus på semestret er at designe og vurdere et edb-system i samarbejde med brugere. Vi har derfor planlagt og analyseret udviklingsforløbet med henblik på at fremhæve erfaringerne med brugersamarbejdet. Vores erfaringer er, at prototyping fungerer godt, når man som udvikler ikke har nogen baggrundsviden om problemområdet. Derudover har forventningsafstemning over for brugerne stor nytteværdi. I dette projekt har brugersamarbejdet fungeret godt og været lærerigt. Dette skyldes blandt andet, at vi har haft brugere med stor velvilje til at medvirke, og at vores eksperimenter har givet os forskellige vinkler på brugersamarbejdet. Derudover er vores samarbejdspartnere tilfredse med det udviklede system Vi kan konkludere, at udviklingsmodellen og samarbejdsteknikkerne i dette projekt har været velvalgte.

3 Forord Dette projekt er udarbejdet af gruppe E4-101 på fjerde semester informatik ved Aalborg Universitet. Ifølge projektrammerne for dette semester er det overordnede tema Design og vurdering af et edb-system i samarbejde med brugere. Projektet omhandler tanker og erfaringer i forbindelse med brugersamarbejdet ved udviklingen af et tidsregistreringssystem til hjemmeplejen i Løgstør Kommune. I den forbindelse vil vi gerne takke vores samarbejdspartnere fra hjemmeplejen for et givende og inspirerende samarbejde. Vi vil også gerne rette en tak til vores vejleder for hans gode idéer og et godt samarbejde. 1

4 2

5 Indhold 1 Indledning 7 2 Foranalyse Softwareudvikling Baggrund for projektet Indledende forløb Problemformulering Afgrænsning Udviklingsstrategi Indledende overvejelser omkring brugersamarbejdet Tilgange til systemudvikling Udviklingsmodel Den modificerede udviklingsmodel Udviklingsforløb Første iteration Anden iteration Tredje iteration Fjerde iteration Erfaringer Forventningsafstemning Mødestrukturen Rollefordeling i projektperioden

6 Indhold 5.4 Tests af systemet Udviklingsmodellen Perspektivering Anderledes prioritering Etiske aspekter Vores interne organiserings indvirkning på brugersamarbejdet Konklusion 77 A Første iteration 79 A.1 Mål for første iteration A.2 Overvejelser og forventninger A.3 Erfaringsopsamling B Anden iteration 83 B.1 Mål for anden iteration B.2 Overvejelser og forventninger B.3 Erfaringsopsamling C Tredje iteration 89 C.1 Mål for tredje iteration C.2 Overvejelser og forventninger C.3 Erfaringsopsamling D Fjerde iteration 95 D.1 Mål for fjerde iteration D.2 Overvejelser og forventninger D.3 Erfaringsopsamling E Brugerhistorier 103 E.1 Første iteration E.2 Endelig version

7 Indhold F Manual 111 F.1 Installation og opsætning F.2 Brug af tidsregistreringssystem F.3 Skærmbilleder G Testrapporter 127 G.1 Papirprototype G.2 Implementeret prototype G.3 Endeligt program H Interviews 149 H.1 Interview med hjælper H.2 Interview med områdelederen på Bøgely Plejehjem I Skemaer 153 J s 155 J.1 Møder med samarbejdspartnere J.2 Installation af systemet J.3 Yderligere s

8 6 Indhold

9 1 Indledning Det overordnede tema for INF2-projektet er design og vurdering af et edb-system i samarbejde med brugere. Denne projektrapport handler om udviklingen af et tidsregistreringssystem til hjemmeplejen i Løgstør Kommune. Der er mange aspekter at tage hensyn til, når man under udvikling af IT-systemer samarbejder med fremtidige brugere, og nogle af disse vil blive trukket frem i denne rapport. Det vil blive beskrevet, hvordan vi har grebet samarbejdet med hjemmeplejen i Løgstør Kommune an, samt hvilke resultater samarbejdet har medført. Forbindelsen til Løgstør Kommunes Hjemmepleje blev formidlet af vores vejleder, som via en kontakt i hjemmeplejen vidste, at de havde behov for et system, der skulle bruges til registrering af hjælpernes tidsforbrug over en to-ugers periode. Vi blev præsenteret for områdelederen for plejehjemmet Bøgely og en administrativ medarbejder fra samme sted. De har fungeret som vores primære samarbejdspartnere gennem dette udviklingsprojekt og har bidraget med information, som gjorde det muligt for os at udvikle et IT-system til deres organisation. I rapporten vil vi komme nærmere ind på hjemmeplejens behov for et tidsregistreringssystem, og det vil blive beskrevet, hvordan vi greb samarbejdet an. Desuden beskrives og vurderes resultaterne fra det udviklingsforløb, vi har gennemgået. Det følgende er en kort introduktion til rapportens opbygning samt en ordforklaring til brug under læsningen. Selve rapporten dækker over foranalyse, udviklingsstrategi, en beskrivelse af forløbet, opsamling af erfaringerne fra forløbet, samt en perspektivering og en konklusion. Derudover findes der i bilagene det væsentligste kildemateriale, som un- 7

10 1. Indledning dervejs i forløbet enten er blevet produceret eller benyttet i udviklingen. I bilag A findes dokumentation for forventninger og erfaringer med første iteration, herefter følger i bilag B, C og D dokumentation for de følgende tre iterationer. Bilag E indeholder brugerhistorierne i forskellige versioner, efterfølgende findes i bilag F manualen til systemet, som også er en beskrivelse af systemet. Herefter er i bilag G de testrapporter, der er udviklet undervejs i forløbet. I bilag H forefindes de interviews, der blev foretaget i forbindelse med det femte møde. I bilag I findes de skemaer, der bruges til dataindsamling, og slutteligt er vores korrespondance med samarbejdspartnerne at finde i bilag J. En CD-rom svarende til den samarbejdspartnerne har fået udleveret er at finde bagerst i rapporten. Et overblik over brugergrænsefladen og systemets funktionalitet kan fås ved at læse manualen (bilag F). Nedenstående forklarer ord, der er tillagt en bestemt mening i dette projekt. De er forklaret, da deres generelle betydninger ellers ville kunne forvirre ved gennemlæsningen. Samarbejdspartner(e) henviser til den ene eller begge af de to personer i hjemmeplejen, der har været vores primære kontaktpersoner. Det er de personer, som vi har samarbejdet med under udviklingen af systemet. Hjemmeplejen betegner den organisation, vi udvikler systemet til. Det er den overordnede betegnelse for hele virksomheden. Hjælpere er de ansatte i hjemmeplejen, der har den daglige kontakt til borgerne i hjemmeplejen. Tidligere hed de hjemmehjælpere. Brugere betegner i dette projekt de personer, der vil komme til at bruge systemet. Borger betegner en person, som hjemmeplejen servicerer. Testdeltagere dækker over de personer fra hjemmeplejen, enten vores samarbejdspartnere eller andre, der har været med til at teste systemet. 8

11 2 Foranalyse I dette afsnit beskrives grundlaget for projektet. Herunder nogle generelle overvejelser angående brugersamarbejde i softwareudvikling, beskrivelse af problemområdet samt af den indledende dataindsamling, hvilket slutteligt fører til projektets problemformulering. 2.1 Softwareudvikling 1 Et af områderne indenfor softwareudvikling er at udvikle skræddersyede IT-systemer til virksomheder. Disse virksomheder har et ønske om forbedring inden for forskellige områder ved hjælp af disse systemer. Et IT-system kan løse et specifikt problem, f.eks. kan det effektivisere infrastrukturen ved hjælp af bedre kommunikation, men indførelsen af et IT-system kan også medføre uforudsete ændringer i virksomhedens struktur. Derfor er en af de væsentligste problemstillinger at forstå problemområdet korrekt. Hvis man ikke har en korrekt forståelse, kan det betyde, at systemet ikke lever op til brugerens forventninger om afhjælpning af problemer. Tværtimod er det muligt, at det som nævnt resulterer i nye. Derfor er det vigtigt, at man er opmærksom på de problemer, der kan være med hensyn til at forstå virksomhedens organisation og behovene til det ønskede system. Udfordringen i at udvikle systemer er, for udviklere, at få brugere til at formidle viden om problemområdet samt at forstå den formidlede viden. Med denne viden menes de erfaringer og den baggrund, som kun kan opnås ved at være en del af problemområdet. Grundlæggende er det vanskeligt at gøre viden formel, det vil sige at formidle den udtrykt ved generelle termer, og der vil let kunne gå information tabt i denne formaliseringsproces. Det kan skyldes flere ting. Mentale mo- 1 Dette afsnit tager udgangspunkt i Dahlbom & Mathiassen, 1993 [8] 9

12 2. Foranalyse deller kan have en kompleksitet, der er svær at omforme til formelle beskrivelser. Den krævede detaljeringsgrad af disse beskrivelser kan være umulig at fastsætte. Hvornår er beskrivelsen så dækkende, at udvikleren har den samme grundlæggende forståelse af problemområdet som brugeren? Herudover er mennesker forskellige. Én persons opfattelse af en sammenhæng bygger på denne persons viden og baggrund. Opfattelsen kan derfor være forskellig fra andre personers - det sete afhænger af øjnene, der ser. En tredje problematik er fortolkning. De formelle beskrivelser skal fortolkes for at finde problemstillingen, men en udviklers fortolkning bygger på udviklererfaringer og -baggrund og kan derfor være afvigende fra brugerens forståelse. Brugere og udviklere har forskellige udgangspunkter og viden om hvert deres fagområde, men det er udviklerens rolle at formulere opfattelsen af systemets opgave på en måde, som brugeren kan forstå og genkende. Som beskrevet ovenfor kan det være svært for brugeren at formulere eller formalisere sin viden om problemområdet, men det kan være lige så vanskeligt for udviklerne at gøre deres idéer klart forståelige over for brugeren. Formaliseringen af viden kan være et problem begge veje. Det som er essentielt, samt den største udfordring, for en udvikler, er, at få brugeren til at omsætte sin viden til nyttig information og samtidig forstå den formidlede information, så den kan danne grundlag for udviklingsarbejdet og dermed det kommende system. 2.2 Baggrund for projektet Dette afsnit beskriver problemområdet og den kontekst, som problemet skal ses udfra. Hjemmeplejen har af kommunen, på grund af loven om fritvalgsordningen 2, fået pålagt at prisfastsætte hjemmeplejens ydelser. For at få et præcist bud på ressourcefordelingen er de nødt til at lave en undersøgelse af, hvad tiden bliver brugt til, herunder hvor stor en del af tidsforbuget ATA-tiden (Ansigt Til Ansigt) udgør. ATA-tiden er den tid, en hjælper tilbringer hos borgeren, derudover bliver hjælperens arbejdstid brugt til f.eks. møder og transport. Tidsundersøgelsen skal afsløre, hvordan hjælpernes arbejdstid fordeler sig på de forskellige tidstyper. I hjemmeplejen er de ikke særligt begejstrede for at skulle gennemføre undersøgelsen, da de i forvejen har meget travlt. De føler, at endnu en opgave er blevet lagt på deres skuldre. Det er dog væsentligt for kommunen at have en præcis idé om, hvor stor en del af ressourcerne, der bliver brugt på ATA-tiden, da det gør det 2 IMM, 2002 [7] 10

13 2.3 Indledende forløb muligt at fastsætte priser og sammenligne dem med andre kommuner og private hjemmeplejeudbydere. Hjemmeplejen i Løgstør Kommune har ikke megen erfaring med tidsundersøgelser. Der er kun én gang tidligere - i blevet udført en sådan undersøgelse i hjemmeplejen i Løgstør Kommune. De resultater, man kunne uddrage af de indsamlede data fra undersøgelsen i 1997, var meget uhåndterlige, da det var besværligt for hjemmeplejen at lave statistikker og sammenligninger. Undersøgelsen dengang var lavet under en anden ledelse end den nuværende. De personer, der nu står for at tilrettelægge en ny tidsundersøgelse henter inspiration fra undersøgelsen i 1997 samt fra materiale fra en tidsundersøgelse, som hjemmeplejen i Hals Kommune lavede for to år siden. Hjemmeplejen har tænkt sig at foretage den indeværende tidsundersøgelse på følgende måde. Hjælpernes tidsforbrug bliver registreret på henholdsvis brugerskemaer og medarbejderskemaer (Se bilag I). Brugerskemaerne ligger hos borgerne, hvor hjælperne skriver, hvor lang tid de er der. Medarbejderskemaet er hjælperens personlige skema, hvor alle andre tidstyper end ATA-tiden registreres. Når undersøgelsen er overstået, indsamles alle skemaer, og tiderne på skemaerne lægges sammen ved hjælp af en lommeregner. Tallene fra beregningerne registreres efterfølgende i MS Excel, hvorfra der genereres statistikvisninger. Hjemmeplejen i Løgstør Kommune ønsker et system, der kan erstatte deres nuværende løsning på, hvordan tidsundersøgelsen skal udføres. Systemet skal først og fremmest bruges til at registrere data og lave beregninger elektronisk, så statistikberegninger omkring fordelingen af tidsforbruget ikke skal foretages manuelt. Derudover skal systemets funktionalitet lette det administrative arbejde, der er forbundet med beregning og visning af statistikker. 2.3 Indledende forløb Vores vejleder gav os en overordnet introduktion til problemet. Derefter satte vi os ind i, hvordan hjemmeplejen i Løgstør Kommune er organiseret, ved bla. at læse deres virksomhedsplan 3. Derforuden orienterede vi os om, hvordan Hals Kommune gennemførte en tidsundersøgelse for to år siden, og vi læste en pjece fra Kommunernes Landsforening om beregning af forskellige tidskategorier 4. Således skulle hjemmeplejen ikke bruge tid på at informere os om deres infrastruktur på det første møde, og vi ville have kendskab til, hvad tidsundersøgelsen skulle gå ud på. Det gav os forudsætninger for at kunne diskutere konkrete arbejds- og 3 Virksomhedsplan [3] 4 Tal på tid - Tale om tid, 2001 [4] 11

14 2. Foranalyse organisationsmæssige aspekter i hjemmeplejen, som kunne gavne vores forståelse af den. Det blev besluttet, at mødeformen skulle være åben og brainstormpræget, da det kan give mange input (se også afsnit 5.2.1). Vi ville stille nogle overordnede spørgsmål og bruge mødeformen til at give os et bredt billede af hjemmeplejen som organisation. Samtidig forventede vi, at mødeformen ville fremme mængden af idéer til systemet. Den gav også mulighed for løbende at spørge dem om praktiske ting i hjemmeplejen, som ikke fremgik af det materiale, vi fik udleveret af dem. Vi blev på mødet præsenteret for det problem, de gerne ville have vores hjælp til at løse. Det var et meget åbent formuleret problem, så der var plads til at nye ting kunne komme til hen ad vejen. Dette skyldtes dels, at vores samarbejdspartnere ikke selv var helt klar over, hvad det var, de ønskede af det kommende system, dels at de ikke havde formuleret krav til et system før, og derfor ikke kunne vide, hvordan de skulle gøre det. Kontaktpersonerne deltog aktivt i mødet ved at komme med forslag til, hvad systemet skulle anvendes til. Det kunne dog til tider være svært at danne sig et overblik over diskussionerne, og det kunne være svært at vide, om vi havde fået afdækket de områder, vi ikke kendte så meget til i hjemmeplejen. 2.4 Problemformulering Herunder opstilles problemformuleringen, der skal tage højde for de to aspekter, som projektet lægger op til. For det første skal vi lære noget i forbindelse med brugersamarbejde, og for det andet skal vi udvikle et system til hjemmeplejen. Problemformulering: Hvordan kan man opnå et godt samarbejde med de kommende brugere ved udviklingen af et computerbaseret tidsregistreringssystem til hjemmeplejen i Løgstør Kommune? Herunder undersøges: Hvilket udviklingsparadigme vil egne sig, så det tilgodeser begge formål med projektet? Hvordan kan udviklingsprocessen tilrettelægges, så vi kan få erfaringer med brugersamarbejdet? Hvordan fastholder vi erfaringer med brugersamarbejdet? 12

15 2.5 Afgrænsning Hvordan kan man inddrage brugerne i udviklingsarbejdet, så man får udnyttet deres viden og erfaring med problemområdet? Hvilke metoder vil egne sig i samarbejdet med brugerne, så de inddrages og får indflydelse, når systemet skal designes og hvordan kan vi efterfølgende vurdere systemet sammen med brugerne? 2.5 Afgrænsning Vi har afgrænset projektet til at have fokus på udvikling af den del af systemet, der skal bruges i den administrative del af hjemmeplejen. Vi fravalgte undervejs i processen at arbejde særligt med udvikling af de to papirskemaer (Se bilag I) som hjemmeplejen anvender til at registrere henholdsvis ATA-tid (Ansigt Til Ansigttid), som er den tid en plejer bruger ved en given borger, samt den indirekte brugertid som er den tid der anvendes til andre gøremål i forbindelse med arbejdet. Grunden til at vi fravalgte at arbejde med disse skemaer var, at hjemmeplejen på det tidspunkt i vores projektforløb stod lige over for at skulle i gang med en registrering af hjælpernes tidsforbrug. En dybtgående undersøgelse af skemaernes udformning og eventuelt samarbejde med hjælperne om deres brug af skemaerne, kunne forstyrre denne indsamling af data om tidsforbruget. De skemaer de havde tænkt sig at anvende til den indeværende undersøgelse, kom fra en undersøgelse i Hals Kommune, og vores samarbejdspartnere vurderede at disse skemaer ville kunne anvendes i Løgstør Kommunes hjemmepleje. Derfor vurderede vi i samarbejde med dem at det var vigtigere at vi koncentrerede os om udviklingen af den administrative del af systemet, og derfor valgte vi at benytte os af deres erfaringer med brugen og udformningen af skemaerne. 13

16 14 2. Foranalyse

17 3 Udviklingsstrategi I dette kapitel beskrives og overvejes problemstillinger og muligheder omkring valg af udviklingsstrategi. 3.1 Indledende overvejelser omkring brugersamarbejdet Dette afsnit relaterer de generelle udfordringer i softwareudvikling (se afsnit 2.1) til dette projekt. Tilrettelæggelsen af samarbejdet med hjemmeplejen i Løgstør Kommune må inkludere overvejelser om, hvordan vi kan få viden omkring miljøet og arbejdsgangene i hjemmeplejen, og hvor meget det kan forventes, at hjemmeplejen vil engagere sig i projektet. De har travlt, og derfor kan det ikke forventes, at de vil afsætte megen tid til dette projekt. Dermed skal samarbejdet tilrettelægges, så der ud fra den tid, som hjemmeplejen står til rådighed, kan indsamles mest mulig information. Det kan heller ikke forventes, at hjemmeplejen vil rejse til Aalborg for at mødes med os, så derfor må samarbejdet finde sted i hjemmeplejens lokaler. Der må vælges en udviklingsstrategi, hvor der kan tilrettelægges et samarbejde med brugerne, som tager højde for, at hjemmeplejen er et ukendt miljø for os. Det derfor vil være vigtigt, at få viden omkring det og hjemmeplejens arbejdsopgaver for at kunne udvikle et system, som kan integreres og bruges i deres sædvanlige arbejde. Det vil desuden være vigtigt med et udviklingsparadigme, der kan hjælpe med at fastholde erfaringer med brugersamarbejdet, da fokus for dette projekt netop er at få erfaringer med brug af forskellige teknikker i forbindelse med brugersamarbejdet. 15

18 3. Udviklingsstrategi 3.2 Tilgange til systemudvikling Generelt set kan udviklingsprocessen have karakter af enten konstruktion, evolution eller intervention. Forskellige situationer og problemer fordrer forskellige tilgange til udviklingen 1. Konstruktion bruges typisk, når der fra starten foreligger utvetydige krav til systemet. Konstruktion er kendetegnet ved, at der laves en grundig foranalyse, hvor det aftales med kunden, hvilken funktionalitet systemet skal tilbyde, og derefter udvikles systemet uden at inddrage brugerne. Først når systemet enten er næsten færdigt og skal testes, eller det skal præsenteres eller implementeres, vil kunden og brugerne se det. Ved brug af en evolutionær udviklingsmodel anses problemet som værende levende og dynamisk, og der bruges derfor ikke megen tid på at analysere og skabe forståelse for problemet. I stedet arbejdes med en eller flere alternative løsningsmodeller, som danner grundlag for kommunikation med brugerne, når de skal specificere krav til systemet. Løsningsmodellerne præsenteres løbende overfor brugerne, således at de kan evaluere dem. Disse evalueringer tages der højde for under det videre udviklingsarbejde. Således udvikler systemet sig løbende i takt med brugernes ønsker til systemet. Intervention ser, som konstruktion og evolution gør, ikke et system, som den eneste løsning på et problem. For at et system kan blive en succes, skal der arbejdes med holdninger til systemet. Hvis udviklingsparadigmet er intervention, så fokuseres der på opfattelser og holdninger blandt de mennesker, som berøres af systemet. Der arbejdes på at forstå de forskellige indstillinger til situationen og systemet. Intervention anvender ikke mange metoder og teknikker. Man tilsigter at ændre eksisterende forhold, som ikke fungerer godt, til noget bedre. Dette gøres ved, at man samtidig med udviklingen af systemet også arbejder på at skabe positiv interesse for systemet - eventuelt omstruktureres noget af organisationen. Problemet i hjemmeplejen i Løgstør Kommune er ikke klart defineret - der er ikke præcise krav til systemet, og derfor vil en konstruktionsorienteret udviklingsmodel ikke være velegnet. Brug af konstruktion vil indføre en større risiko for at lave et system, der ikke stemmer overens med hjemmeplejens forventninger. Det kan være svært at indsamle information om hjemmeplejen, og derefter på baggrund af den indsamlede information udvikle systemet, da hjemmeplejen er et ukendt miljø for os. Det kan være svært at vurdere, hvilken viden, der er vigtig at have, når systemet skal udvikles (se også afsnit 2.1). Systemet kan derfor udvikle sig i en uhensigtsmæssig retning, da hjemmeplejen ikke følger med i udviklingsprocessen - de krav, hjemmeplejen stiller i starten af udviklingsperioden, er muligvis 1 Dette og de følgende tre afsnit er baseret på Dahlbom & Mathiassen, 1993 [8] 16

19 3.2 Tilgange til systemudvikling ikke de samme, som dem de faktisk ønsker eller dem de troede, de stillede, når de får det færdige system præsenteret. Det vil desuden være svært at foretage eksperimenter og drage erfaringer med brugersamarbejdet, hvis der kun samarbejdes under foranalysen. Intervention vil heller ikke være velegnet som udviklingsmodel for dette projekt. Det er ikke oplagt, at der i hjemmeplejen skal ændres i holdninger, arbejdsgange eller organisering. Systemet skal være en hjælp til at behandle data - en elektronisk registrering vil lette statistikberegningen. Det primære problem er ikke holdninger til tidsregistreringen blandt medarbejdere. Det er desuden ikke realistisk, at vi kan opnå en så stor forståelse for miljøet og forskellige holdninger og opfattelser i hjemmeplejen, at vi kan udvikle et system, der skal indarbejdes sammen med andre ændringer af hjemmeplejens struktur (se også afsnit 2.1). Det er også urealistisk, at hjemmeplejen vil være åbne for sådan et projekt og afsætte ressourcer til det. Evolution er bedre egnet til dette projekt, hvor der er vage krav til systemets funktionalitet. Hjemmeplejen er ikke helt sikre på, hvad systemet skal kunne, og de har måske svært ved at forestille sig, hvilke muligheder der er (se også afsnit 2.1). Et system, der udvikler sig løbende i samarbejde med brugerne, giver dem større mulighed for at danne sig en idé om systemets muligheder, da de vil have noget konkret at forholde sig til. Den vigtigste funktionalitet udvikles typisk først, hvorefter funtionalitet med lavere prioritet implementeres, hvis tiden tillader det. Dermed kan hjemmeplejen give udtryk for, hvilke funktioner det er vigtigst, at systemet kan varetage, og derudfra få en idé om, hvad der ellers er muligt og gavnligt at implementere. En anden fordel ved evolution er, at brugerne inddrages tidligt i udviklingsprocessen, og de involveres i udviklingsarbejdet, hvilket er gunstigt set i forhold til, at målet med projektet er at få erfaringer med brugersamarbejde. Det kan også skabe en større interesse for projektet, at hjemmeplejen følger systemet fra dets fødsel og i højere grad har mulighed for at få indflydelse på det, end hvis de ikke fulgte systemets udvikling og først så det, når det skulle implementeres. Evolution egner sig bedst til en mindre udviklergruppe, da det kan være svært for en stor gruppe at sørge for, at alle er orienteret om resultater fra møder med brugere og anden fremgang i udviklingsarbejdet. Det er lettere for en mindre gruppe at arbejde sammen og sørge for, at alle er informerede om det hele. En evolutionsmodel giver desuden plads til mindre forsøg med tilrettelæggelsen af brugersamarbejdet på grund af den eksperimenterende tilgang til afdækkelsen af krav til systemet. Desuden vil det være muligt at rette op på et fejltrin, da der er flere mindre iterationer, og hele systemet ikke udvikles i et sammenhængede forløb, hvor brugerne ikke inddrages. 17

20 3. Udviklingsstrategi Svagheden ved et evolutionært udviklingsparadigme kan være, at det system som udvikles, kan få en rodet arkitektur, da kravene til systemet kan skifte. Dette kan betyde, at systemet bliver ustabilt og sværere at vedligeholde 2. Øvrige svagheder kan være, at projektet bliver svært at styre, dels indenfor udviklergruppen og dels overfor kunden med hensyn til systemkrav. Det er dog problemer, der normalt kun optræder ved større projekter end dette 3. Brugerne kan desuden inddrages i for høj grad, så de kommer til at tage kontrol over udviklingsprocessen 4, hvilket ikke er hensigtsmæssigt, eftersom den reflekterende tankegang omkring udviklingsprocessen undermineres. 3.3 Udviklingsmodel Med henvisning til ovenstående afsnit vil en evolutionær udviklingsmodel være bedst egnet til dette projekt. De evolutionsmodeller, der er kendt for os, er: Extreme Programming (XP) og prototyping. XP er ikke egnet til dette projekt af flere årsager. Den indlysende praktiske årsag er, at det ikke er muligt at have en person fra hjemmeplejen til stede i grupperummet under udviklingen af systemet. Derforuden er XP bedre egnet til en udviklergruppe med erfaring indenfor systemudvikling, og XP er mere koncentreret omkring produktet end samarbejdet med brugerne, som er vigtigt i dette projekt 5. Evolutionær prototyping er en fleksibel udviklingsmodel, hvor hver iteration tilpasses efter overvejelser omkring, hvad der på det givne tidspunkt er vigtigt at fokusere på. Overvejelserne omkring anvendelse af tid og arbejdskraft ansporer en reflekterende tankegang, som er vigtig i en lærende proces. Derforuden er overvejelserne omkring processen og målet med processen vigtige, når overvejelser og erfaringer med brugersamarbejdet skal fastholdes og dokumenteres. Traditionel prototyping er karakteriseret ved at gennemløbe et antal iterationer, som hver indeholder faserne: Analyse, design, implementering og test. Sidste iteration indeholder desuden vedligeholdelse. Som figur 3.1 illustrerer, gennemløbes faserne i venstre side et antal gange, indtil det vurderes, at systemet er færdigt, og faserne i højre side, som er orienteret mod at færdiggøre produktet, gennemgåes. Målet med dette projekt er ikke blot at udvikle produktet - systemet til hjemmeplejen. Målet er i høj grad også at erhverve nogle erfaringer med brugersamarbejdet. På grund af den indgangsvinkel vil det være vigtigt at kunne fastholde og dokumentere erfaringer i forbindelse med brugersamarbejdet. Nedenstående 2 Vliet, 1993 [11] 3 Sommerville, 2001 [10] 4 Dahlbom & Mathiassen, 1993 [8] 5 Beck, 2002 [1] 18

21 3.4 Den modificerede udviklingsmodel Analyse Design Design Implementering Implementering Test Test Vedligeholdelse Figur 3.1: Prototyping, kilde: Vliet, 1993 [11] afsnit beskriver, hvilke initiativer vi vil tage, for at udviklingsmodellen tilskynder dokumentationen af disse erfaringer. 3.4 Den modificerede udviklingsmodel Den traditionelle prototypingmodel er ikke så dokumenttung som f.eks. konstruktion, og den koncentrerer sig ikke om at dokumentere erfaringer i forbindelse med brugersamarbejdet. Derfor har vi modificeret modellen, så der i begyndelsen af hver iteration, skal udarbejdes dokumentation, der beskriver mål for og forventninger til den givne iteration. Således anspores til at gøre overvejelser omkring målet med iterationen samt hvordan målet nås. Disse overvejelser vil eksplicit eller implicit afføde nogle forventninger til, hvordan forløbet af iterationen former sig. Tilrettelæggelsen af iterationen bygger på forventninger til og overvejelser omkring, hvilke aktiviteter der skal gennemføres, og overordnet skal forventninger til vores eget udviklingsarbejde og mere vigtigt forventninger til brugersamarbejdet inkluderes. Når vi er bevidste omkring forventningerne, vil det være nemmere at gøre os bevidste omkring erfaringerne. Den væsentligste forskel på tradionel prototyping og vores modificerede model er, at vi har brug for dokumentation i forbindelse med brugersamarbejdet, og derfor bygges det ind i modellen som en aktivitet. Faren ved den modificerede model er, at den kan blive for dokumenttung. Da det er vigtigt at dokumentere forventninger og erfaringer, kan vi risikere at komme til at fokusere for meget på dokumentationen og glemme at iterere og på den måde komme videre i udviklingsprocessen. Vi er dog bevidste om denne mulige ulempe, og vil derfor forsøge at undgå den. 19

22 3. Udviklingsstrategi Der findes også andre ulemper ved prototyping, men de optræder normalt kun ved væsentlig større projekter og systemer end dette 6. Aktiviteter, der gennemløbes i den modificerede model af prototyping, resulterer alle i enten dokumentation eller system. Den modificerede model kan ses på figur 3.2. I det efterfølgende afsnit bliver modellens aktiviteter og dokumenter beskrevet detaljeret. De dokumenter, som er en del af udviklingsmodellen, kan ses i bilag E (brugerhistorier), samt A, B, C og D (iterationsdokumentation). Forventninger fra brugeren Tekniske krav Forventninger og mål Design og implementering Bruger indragelse Erfarings opsamling Brugerhistorier System specifikation Dokumentation af mål og forventninger Prototype Dokumentation af bruger indragelse Dokumentation af erfaringer Figur 3.2: Modificeret udviklingsmodel Forventninger fra brugerne Denne aktivitet indebærer at gøre overvejelser om brugernes forventninger til systemet. Hvilken funktionalitet vil de gerne have, at systemet tilbyder? Vi skal prøve at sætte os ind i og forstå deres ønsker til systemet. Klarlæggelsen af brugernes ønsker til systemet vil ske på baggrund af kontakt med brugerne Brugerhistorier Formålet med dette dokument er at fastholde brugernes ønsker til systemets funktionalitet. Dokumentet er dynamisk, det vil sige, at det bliver revideret i hver iteration. Dokumentet udarbejdes indledningsvis på grundlag af den viden, foranalysen gav os. I hver iteration herefter skal det præsenteres for samarbejdspartnerne. Det er meningen, at vores samarbejdspartnere skal vurdere om brugerhistorierne dækker, hvad de havde forestillet sig, systemet skal kunne. Efter mødet skal vi revidere brugerhistorierne og tilføje eventuelle nye oplysninger eller ændringer. 6 Sommerville, 2001 [10] og Vliet, 1993 [11] 20

23 3.4 Den modificerede udviklingsmodel Tekniske krav Udfra overvejelser angående udformningen af brugerhistorierne, opstilles mere detaljerede og tekniske krav til systemet Systemspecifikation Systemspecifikationen skal bruges internt i gruppen for at beskrive systemet på en mere detaljeret og teknisk måde end brugerhistorierne. Formålet med dokumentet er, at alle i gruppen har det at referere til. Det skal ligesom brugerhistorierne opdateres efter hver iteration, hvis der er sket ændringer. Grunden til, at vi både vil bruge brugerhistorier og systemspecifikation, er, at brugerhistorierne primært skal bruges i brugersamarbejdet, og vi mener, at det ville være uinteressant og måske forvirrende for vores samarbejdspartnere at se de tekniske detaljer, der skal bruges i udviklingen Forventninger og mål Efter brugerhistorierne og systemspecifikationen er udformet, opstilles mål og forventninger for den igangværende iteration. Mål henviser til, hvor meget systemet skal udbygges, og hvordan systemet efterfølgende skal valideres ved inddragelse af brugere. Forventninger indeholder vores forventninger til brugerinddragelsen og resultaterne heraf. Disse overvejelser omkring forventninger og mål er vigtige, for at vi kan være bevidste omkring vores handlinger og bagvedliggende årsager til disse handlinger Dokumentation af forventninger og mål Alle mål, overvejelser og forventninger dokumenteres så detaljeret som muligt, så de kan bruges under erfaringsopsamling. Herunder beskrives, hvordan hele iterationen skal forløbe, og hvorfor iterationen tilrettelægges, som den gør. Hvilken del af systemet er det vigtigt at fokusere på og hvorfor? Hvordan skal valideringen foregå? Hvis vi vil foretage eksperimenter med brugerinddragelsen, skal hensigt og forventet resultat beskrives i dokumentationen af mål og forventninger. 21

24 3. Udviklingsstrategi Design og implementering Design og implementering er den aktivitet, hvor vi udvikler systemet. Hele udviklergruppen skal deltage i design- og implementeringsarbejdet. Implementeringen skal, efter inspiration fra XP, så vidt muligt foregå som parprogrammering i grupperummet, så ingen sidder alene med det. Brugergrænsefladen skal designes først, og derefter tilføjes funktionalitet, fordi vi på den måde hurtigt har noget visuelt at præsentere for vores samarbejdspartnere Prototype Design og implementering resulterer i en prototype og eventuelle dokumenter, der er nødvendige under udviklingen af systemet Brugerinddragelse Under brugerinddragelsen skal brugerne vurdere, om de præsenterede prototyper og brugerhistorier opfylder den ønskede funktionalitet samt ikke-funktionelle krav som f.eks. forståelighed og effektivitet. De prototyper, vi præsenterer, kan gøre det lettere for brugerne at forholde sig til de muligheder, der er. Udfra prototyperne kan der opstå nye eller ændrede krav til systemet. Teknikkerne, der bliver beskrevet under forventninger og mål, anvendes ved brugerinddragelsen Dokumentation af brugerinddragelse Dokumentation af brugerinddragelse kan være mødereferater, testrapporter eller andet. Dokumentationen fremstilles med henblik på at fastholde de resultater og informationer, samarbejdet har resulteret i Erfaringsopsamling Under erfaringsopsamlingen vurderes og reflekteres over resultaterne fra brugerinddragelsen i forhold til vores egne forventninger til den. Endvidere vurderes anvendte teknikker i forhold til resultater og eventuelt tidligere anvendte teknikker. 22

25 3.4 Den modificerede udviklingsmodel Dokumentation af erfaringer Dokumentation af erfaringer indeholder beskrivelser af, hvordan brugersamarbejdet forløb. Herunder om det gik som forventet, eller om der var overraskelser. Desuden beskrives eventuelle ændringer i brugerhistorierne og systemspecifikationen. 23

26 24 3. Udviklingsstrategi

27 4 Udviklingsforløb Dette kapitel giver et overblik over det samlede udviklingsforløb. Vi valgte at gennemføre fire iterationer gennem udviklingen af systemet til hjemmeplejen. Det skyldtes dels, at det overordnede udviklingsparadigme foreskrev flere iterationer (se afsnit 3.4), og dels at vi hermed kunne afprøve forskellige tilgange til brugersamarbejdet. Derudover passede fire iterationer i forhold til de prototyper, vi vurderede var hensigtsmæssige at lave - brugerhistorier, papirprototype, implementeret prototype og endelig prototype. At det blev disse fire prototyper skyldtes delvist, at en arbejdstid på to til tre uger i de enkelte iterationer ville være en passende tidsperiode for os. Derforuden vurderede vi, at netop de fire prototypers udvikling fra iteration til iteration ville være passende med hensyn til brugernes evaluering og efterfølgende implementering af ændringer. Herefter beskrives hver af de fire iterationer, som systemet har gennemløbet. Under hver iteration beskrives mål med iterationen, hvorledes målet forsøges opnået, samt erfaringer erhvervet i iterationer. På figur 4.1 ses det overordnede udviklingsforløb. Øverst er angivet resultatet af de fire iterationer, og i venstre side er møder med samarbejdspartnerne i hjemmeplejen angivet. Hensigten med figuren er at give et overblik over udviklingsforløbet ved læsning af dette kapitel. 4.1 Første iteration Mål og forventninger I første iteration udarbejdede vi et forslag til brugerhistorier (se bilag E.1) på baggrund af mødet under foranalysen samt viden om hjemmeplejens infrastruktur. Intentionen med brugerhistorier var, at de skulle fungere som en form for aftale med 25

28 ? > > D D > > > > > > > > L ( 2! ( $ = ' %! "! ( - = 4. Udviklingsforløb Indledende møde med Løgstør hjemmepleje et møde med Løgstør hjemmepleje (e ) dje møde med Løgstør hjemmepleje (e < A CB. $ % - % + se 3 $ !#",! & / ( -<;! )!#"$ "! & "$ ( &!#"$ % & 6! & ( - / & $ ( ( " - "$5 &9 &: %! & $ ",!.) "87 6 )!#"$ % * ) + ) $ ( on 2! & &!#"$ % "0/ 1 " + on 3! & 2 ) $ (! & &!#"$ % "!.) ( on 4 ED GF øde med Løgstør hjemme- IH CE < F FJ C A e) FJ møde med Løgstør hjemme- K> IH CE <C A e) ts > il Figur 4.1: Udviklingsforløb vores samarbejdspartnere med hensyn til, hvilken funktionalitet systemet skulle indeholde. Brugerhistorierne beskrev eksempler på arbejdsopgaver, som skulle kunne udføres på systemet. Vi forventede, at samarbejdspartnerne i hjemmeplejen lettere ville kunne forstå brugerhistorierne end mere formelle beskrivelser af arbejdssituationer. Brugerhistorierne indeholdt forskellige forslag til konkrete arbejdsopgaver i hjemmeplejen såsom oprettelse af undersøgelser, tidsregistrering samt udtræk af statistikker. Efter udarbejdelsen af brugerhistorierne afholdt vi et møde med samarbejdspartnerne - lederen af tidsundersøgelsen og den administrative medarbejder, der ville blive den primære bruger af systemet. Da de havde en dybere indsigt i problemområdet, ville de have en bedre forståelse for, hvilke opgaver systemet skulle understøtte. De havde endvidere indblik i hjælpernes arbejde, og derfor var der ikke brug for hjælpere til at svare på spørgsmål under mødet. Hensigten med mødet var at finde frem til, hvilke opgaver de ønskede understøttet af systemet. Vi ville diskutere dette på baggrund af forslagene til brugerhistorierne, og vi opfordrede dem derfor til at bidrage med rettelser eller nye brugerhistorier. På mødet ønskede vi også at diskutere udkast til systemets brugergrænseflade samt udkast til de to skemaer (se bilag I). Udkastet til brugergrænsefladen var håndtegnet, da dette ville signalere, at det kun var skitser, der var lette at rette til. Eksempler på skitserne kan ses på figurerne 4.2, 4.3, 4.4 og 4.5. Vi forventede, at samarbejdspartnerne ville foreslå flere ændringer til disse håndtegnede udkast, 26

29 4.1 Første iteration end de ville ved computergenererede udkast, da disse let kunne virke færdige i forhold til håndtegnede skitser. Skemaerne lavede vi forskellige udkast til, da vi havde idéer til forbedring af de skemaer, hjemmeplejen havde fået fra en tidsundersøgelse i Hals Kommune. Det drejede sig kun om mindre ændringer. Figur 4.2: Visning af grupper i systemet Udover brugerhistorier og skitser til brugergrænsefladen, udarbejdede vi en systemspecifikation, som var en mere formel beskrivelse af systemets virkemåde end brugerhistorierne. Den skulle anvendes til at fastholde specifikke detaljer, som skulle holdes for øje gennem udviklingen af systemet. Idéen med denne formalisering var at give os et overblik over systemet og samtidigt lette arbejdet ved fremtidige rettelser i systemet. Det var vigtigt at skabe en dialog med vores samarbejdspartnere og sørge for at indrage dem i diskussionerne. Det var desuden væsentligt, at de forstod, hvad vi gav udtryk for på mødet, da vi ikke forventede, at de havde erfaring med systemudvikling. Det var derfor vigtigt at anvende termer og udtryk, som de ville forstå. Herudover ville vi sørge for at opmuntre dem til at foreslå rettelser og at give kritik. De skulle opfordres til at være kreative og tænke ud over de forslag, vi havde med på mødet Eksperimenter Vi forestillede os, at de møder der afholdtes med samarbejdspartnerne uundgåeligt ville skabe nogle forventninger til os som udviklere og omvendt. I et forsøg på at kontrollere disse forventninger, sendte vi en plan for det kommende udviklingsforløb og de møder, vi ønskede med dem. Planen ønskede vi at diskutere på mødet 27

30 4. Udviklingsforløb Figur 4.3: Opret grupper - forslag 1 Figur 4.4: Opret grupper - forslag 2 28

31 4.1 Første iteration Figur 4.5: Indtastning af data 29

32 4. Udviklingsforløb for at blive enige om, hvordan det kommende samarbejde skulle forløbe. Herudover sendte vi en dagsorden for mødet samt brugerhistorierne og en forklaring af deres formål. Ved at tilsende brugerhistorierne, kunne de læse dem forinden mødet, og der ville være grundlag for en diskussion af dem Mødeforløb Under mødet syntes samarbejdspartnerne i hjemmeplejen at forstå vores forslag til brugerhistorier, men der var usikkerhed om, hvorfor der var flere forslag til hver type funktionalitet. Vi havde flere forskellige forslag for at forhindre, at de ville blive fastlåste til ét forslag. I stedet håbede vi, at de ville blive inspireret til at foreslå ændringer. De forstod ikke, hvorfor der var flere brugerhistorier til at beskrive de samme arbejdsopgaver. De troede, de skulle vælge ét forslag i stedet for at lade sig inspirere af de forskellige forslag. Vi opfatter det som manglende introduktion til brugerhistorierne fra vores side. Det var dog ikke et større problem, da vi efter en kort forklaring fik en diskussion i gang. Den mundede ud i, at nogle af forslagene blev godkendt - nogle med rettelser Erfaringer Udkastene til systemets brugergrænseflade fungerede efter hensigten, da samarbejdspartnerne var i stand til at udpege, hvilke udkast de foretrak, samt hvilke rettelser der skulle foretages. Under diskussionen af udkastene til skemaer viste det sig, at de ikke ønskede at ændre brugerskemaet i forhold til det, de havde fra Hals Kommune. Det skyldtes dels, at de var tilfredse med det skema, de havde, samt at de ændringer, vi foreslog, var ubetydelige. De var derimod tilfredse med et udkast til brugerskemaet, da de vurderede at det kunne lette tidsregistreringen for hjælperne. De ønskede dog ikke at anvende skemaet i den kommende undersøgelse, da de allerede havde introduceret hjælperne til skemaet fra Hals Kommune. De frygtede, at det ville skabe forvirring at introducere hjælperne til et nyt skema. 4.2 Anden iteration Mål og forventninger Formålet med anden iteration var, på baggrund af brugerhistorier og udkast til systemets brugergrænseflade, at udvikle og evaluere en papirprototype. Denne havde til formål at illustrere systemets funktionalitet og brugergrænseflade. Vi ønskede 30

33 4.2 Anden iteration at teste prototypen for at undersøge, om vi havde forstået de krav og forventninger til systemet, der var fremkommet under første iteration, herunder om vi havde implementeret brugerhistorierne korrekt. Derudover ønskede vi at finde eventuelle fejl og mangler samt at undersøge brugervenligheden af papirprototypen. Parpirprototypen var et udkast til systemets funktionalitet og brugergrænseflade. Vi udarbejdede dette udkast, da det ellers kunne være svært for samarbejdspartnerne at komme med forslag uden at have noget konkret at tage udgangspunkt i. Udkastets formål var at danne grundlag for en diskussion med samarbejdspartnerne, og de blev i den forbindelse opfordret til at foreslå ændringer til papirprototypen. Prototypen skulle bestå af udprintede skærmbilleder, da den herved, i modsætning til et håndtegnet udkast, kunne give vores samarbejdspartnere et realistisk billede af, hvordan systemet kunne komme til at se ud. Dele af prototypen kan ses på figurerne 4.6, 4.7 og 4.8. Figur 4.6: Administration af distrikter og medarbejdere En anden årsag, til anvendelsen af en papirprototype frem for en implementeret prototype, var, at det var vores første samlede udkast til systemet. Samarbejdspartnernes forventninger til systemet ville muligvis være meget forskellige fra vores forslag, og derfor blev det en papirprototype for at undgå at skulle foretage omfattende ændringer i systemkoden. Vi vurderede desuden, at en prototype udarbejdet på papir ville fremme samarbejdspartnernes idéer og ændringsforslag til den. Vi forventede, at de lettere ville kunne give udtryk for deres mening om papirproto- 31

34 4. Udviklingsforløb Figur 4.7: Indtastning af medarbejderskema 32

35 4.2 Anden iteration Figur 4.8: Generering af statistik typen, da denne var let at rette på mødet - man kunne tilføje rettelser og nye idéer direkte på prototypen. Vi ville understrege, at prototypen var en skitse, og at vi let kunne lave ændringer i den. Testmetoden var en tænke-højt test 1 modificeret, således at to testdeltagere arbejdede sammen og udførte én test. Derforuden ønskede vi, at testmetoden skulle lægge op til en efterfølgende diskussion. Testmetoden blev ændret, da vi gerne ville have en dialog mellem de to testdeltagere og os, da vi på den måde kunne få mange input til eventuelle ændringer. Vi forventede, at testdeltagerne ville have nemmere ved at tænke højt, når de sad sammen. Resultaterne fra testen ville blive anvendt ved implementering af systemet Eksperimenter Den modificerede tænke-højt test indgik i et eksperiment, hvor vi ønskede at undersøge, hvilke forskelle der kunne være ved en tænke-højt test, hvor testdeltagerne arbejder sammen og en tilsvarende test, hvor testdeltagerne sidder hver for sig. Testen af papirprototypen ville være mere oplagt til en test, hvor testdeltagerne sad sammen end en test af en implementeret prototype, da de ved papirprototy- 1 Molich, 2000 [6] 33

36 4. Udviklingsforløb pen kunne pege for at navigere. Derved kunne begge testdeltagere aktivt deltage i navigeringen, og hvis de ville navigere forskelligt kunne dette diskuteres, før næste billede blev vist. Ved test af den implementerede prototype ville det derimod være hensigtsmæssigt med to individuelle tests. Hvis de testede den implementerede prototype sammen, ville den testdeltager, der sidder med musen, nemt kunne tage styringen, hvilket ikke ville være hensigtsmæssigt. Vi valgte til dette møde, at vi ville teste systemet med to testdeltagere samtidigt, og derefter sammenholde de erfaringer dette gav med de erfaringer, vi ville få med to individuelle tests på det efterfølgende møde. Dette var derfor et forsøg, der forløb over to iterationer. Et andet forsøg drejede sig om, hvordan samarbejdspartnerne ville reagere på et - i forhold til det foregående - mere formelt møde. En del af forsøget bestod i at gøre brugerhistorierne mere formelle. Denne formalisering havde til hensigt at lette forståelsen af brugerhistorierne, men også at lette arbejdet ved eventuelle rettelser. Det ville være interessant at se, om de formelle brugerhistorier gav samme indtryk af funktionaliteten som de mindre formelle, og hvordan samarbejdspartnerne ville reagere. En anden del af forsøget med et mere formelt møde var at tildele hinanden ansvarsroller. Rollerne skulle hjælpe os med at fastholde mødets struktur, hvilket var en smule problematisk i forrige iteration. Ved fordeling af ansvarsroller havde vi hver ansvar for en del af mødet, og det kunne dermed være lettere at holde styr på dagsordenens punkter. Vi tilsendte samarbejdspartnerne en udførlig dagsorden for mødet samt de formelle brugsmønstre, så de kunne have tid til at læse dem forinden mødet Mødeforløb Selve mødet startede med en introduktion til dagsordenen, hvorefter vi fortalte, hvem der ville gennemgå henholdsvis brugerhistorierne og prototypen. Ved gennemgang af de formelle brugerhistorier havde vi forventet, at vores samarbejdspartnere ville have reageret på formaliseringen, men dette var ikke tilfældet. Først da vi spurgte dem direkte, gav de udtryk for, at den formelle fremstilling var let at forstå, og at brugerhistorierne var forståelige. Vi valgte at beholde den formelle form, da de var mere overskuelige - både for os og samarbejdspartnerne Erfaringer Forsøget med at have to testdeltagere sammen forløb nogenlunde som forventet. Dog viste det sig at være mere naturligt at lade diskussionen af systemet udvikle sig undervejs og ikke efterfølgende. Vores samarbejdspartnere forholdt sig kritisk til papirprototypen. Var de i tvivl om noget, foreslog de ændringer hertil eller 34

37 4.3 Tredje iteration overvejede forslag til ny funktionalitet. Det overordnede forsøg med at afholde et struktureret møde gav ikke nogen umiddelbar reaktion fra vores samarbejdspartnere. Vi ønskede ikke at spørge direkte, hvordan de oplevede mødet, da de derved kunne opfatte mødet som et eksperiment, hvilket kunne have haft en negativ indvirkning på deres engagement på selve mødet. Vi kunne selv mærke en markant forbedring, da vi under hele mødet havde føling med, om vi havde fået afdækket vores spørgsmål. På baggrund af de gode erfaringer med det strukturerede møde, ønskede vi fortsat at anvende denne mødeform. 4.3 Tredje iteration Mål og forventninger På baggrund af testen af papirprototypen ville opgaven i denne iteration være at implementere og evaluere en kørende prototype. Under implementeringen ville vi medtage samarbejdspartnernes rettelser til papirprototypen. Prototypen skulle implementeres, så den var så identisk som muligt med den evaluerede papirprototype. Det ville gøre det nemmere for samarbejdspartnerne at genkende systemet. Som beskrevet i forrige afsnit, skulle testdeltagerne i denne iteration teste systemet hver for sig. Testdeltagerne var - ligesom i forrige iteration - vores to samarbejdspartnere. I modsætning til testen af papirprototypen ville denne test følge den traditionelle tænke-højt testmetode 2. Testen måtte derfor forventes at få en mere formel karakter, da testdeltagerne f.eks. ikke ville have mulighed for at diskutere eventuelle problemer under selve testen. Efter testen planlagde vi en opsamlende diskussion. Brugen af denne testmetode ville bevirke, at vi skulle bruge flere ressourcer på at notere problemer og reaktioner i forhold til, hvad der var nødvendigt ved forrige test, hvor disse ting blev diskuteret under selve testen. Vi skulle desuden være opmærksomme på, at testdeltagerne kunne have problemer med at tænke højt, da de ville sidde alene, og det kunne virke unaturligt at tænke højt. På baggrund af disse overvejelser ville vi give testdeltagerne en grundig introduktion til testen, så de ville være trygge ved, hvordan testen skulle forløbe. Det var vigtigt, at de ikke følte sig presset, da dette kunne have indflydelse på testresultaterne. Det var vigtigt at præsentere forslag til statistikvisninger og få diskuteret, hvordan samarbejdspartnerne ønskede dem udformet, da vi ønskede inspiration til den senere implementering af denne funktionalitet. 2 Molich, 2000 [6], Rubin 1994 [9] 35

38 4. Udviklingsforløb Eksperimenter Udover forsøget med en traditionel tænke-højt test, ville vi bytte om på de ansvarsroller, som vi havde ved mødet i forrige iteration, hvor rollerne blev fordelt efter gruppemedlemmernes kompetencer. Denne gang ville de blive fordelt, således at de gruppemedlemmer som ikke havde så stor erfaring med f.eks. at være testleder fik denne rolle Mødeforløb Mødet startede med en introduktion til dagsordenen, hvorefter brugerhistorierne blev gennemgået. Der var kun få ændringer til dem. Derefter fulgte en samlet introduktion til testene, der blev afholdt i to adskilte rum. Testdeltagerne virkede under testen mere usikre, end de var ved testen i forrige iteration. Begge testdeltagere oplevede stort set de samme problemer under testen. Da formålet med testen i denne iteration var at undersøge prototypens funktionalitet, korrekthed og brugervenlighed efter implementering, havde vi brug for testdeltagernes umiddelbare reaktioner ved brug af systemet. Hertil virkede testmetoden som forventet, da den gav en stor mængde data at arbejde videre med. De fleste af problemerne kom til udtryk ved, at testdeltagerne virkede usikre, og vi vurderede mange af dem som egentlige fejl ved prototypen. Fejl, der skulle rettes i den efterfølgende iteration. Vi præsenterede de statistikvisningsmuligheder, vi havde lavet. Derudfra diskuterede vi, hvordan de syntes statistikkerne skulle se ud, og om der var nogle mangler ved vores forslag Erfaringer Vi havde forventet, at mødet ville forløbe på samme strukturerede måde som det forrige møde gjorde, men på grund af tekniske vanskeligheder blev starten af mødet afholdt ret uformelt. Testen forløb dog som forventet, hvilket kan skyldes brugen af ansvarsroller. Vi havde forventet, at vores samarbejdspartnere havde reageret på vores nye roller, men der var ingen direkte reaktion på dette. Det var dog en lærerig og positiv oplevelse for os at prøve andre roller. Der var lidt problemer under fremlæggelsen af forslag til de statistikvisninger, som systemet skulle håndtere. De blev fremlagt på en computerskærm, hvilket medførte, at kun to af gruppemedlemmerne kunne følge med i visningerne. Derved var det også kun de to, der deltog i samtalen med de to samarbejdspartnere, hvilket ikke var helt hensigtsmæssigt. 36

39 4.4 Fjerde iteration 4.4 Fjerde iteration Mål og forventninger Målet med denne iteration var at udvikle det endelige system, teste det, rette fejl og efterfølgende installere det hos hjemmeplejen. Der manglede stadig den funktionalitet, som skulle gøre det muligt at gemme filer til statistikvisning i MS Excel. Desuden skulle der rettes forståelsesmæssige fejl samt mindre funktionelle fejl, som viste sig under testen i tredje iteration. På figurerne 4.9, 4.10 og 4.11 kan ses eksempler på det endelige system. Figur 4.9: Hovedvindue - valg af undersøgelse Systemet skulle denne gang evalueres af én af samarbejdspartnerne samt en administrativ medarbejder, der ikke før havde deltaget i udviklingsprocessen. Vi ønskede at evaluere systemet med en person, der ikke før havde set det, for at teste og observere den umiddelbare reaktion på brugen af systemet. Testene ville blive afholdt som to individuelle tests - som på det forrige møde. Det skyldtes dels, at vi havde succes med denne testmetode, da den gav mange resultater på sidste møde, og dels at den ene testdeltager ikke havde erfaring med systemet, og derfor ikke skulle påvirkes af en anden testdeltagers forståelse af systemet. Udover denne test havde vi fået en aftale med en hjælper, som vi ville interviewe med henblik på at undersøge, hvordan vedkommende havde oplevet at udfylde tidsskemaer i forbindelse med den netop afsluttede dataindsamling i hjemmeplejen. Det ville være interessant at undersøge hjemmeplejens praktiske erfaringer med tidsskemaerne. Grunden til, at vi ikke havde undersøgt dette område før, var, at det passede tids- 37

40 4. Udviklingsforløb Figur 4.10: Indtastning af brugerskema 38

41 4.4 Fjerde iteration Figur 4.11: Generering af statistik mæssigt dårligt for hjemmeplejen, da de i starten af udviklingsforløbet allerede var ved at forberede den kommende tidsundersøgelse. Som i de to forrige iterationer ønskede vi at beholde den formelle struktur for mødet, da det virkede godt første gang. Mødet gik ikke som forventet i den tredje iteration, og vi forventede til denne fjerde iteration, at vi kunne omgå forrige mødes lidt tilfældige udvikling ved at være bevidste om de årsager, der gjorde mødet mindre formelt. Derudover havde vi igen uddelt ansvarsroller; denne gang i forhold til personlige kompetencer. Rollerne på dette møde blev derfor meget lig de roller, som vi startede med ubevidst at have. Vi forventede, at dette ville være hensigtsmæssigt, da vores samarbejdspartnere ville være vænnet til dem fra starten af udviklingsprocessen. Vi forventede, at planlægningen af mødet samt rollefordelingen ville resultere i et roligere møde end det i tredje iteration Eksperimenter I forhold til forrige tests opgaver var opbygningen af opgaverne ændret, således at de i højere grad lignede små historier. Vi forventede, at testdeltagerne ville have lettere ved at forholde sig til opgaverne, når de kunne se en sammenhæng til dagligdagen. Vi forventede desuden, at de nye opgaver kunne forebygge testdel- 39

42 4. Udviklingsforløb tagerens følelse af at befinde sig i en kunstig situation. På dette tidspunkt i forløbet vurderede vi, det var vigtigt at afstemme vores forventninger i forhold til samarbejdspartnernes forventninger. Vi havde efter forrige møde indtryk af, at de havde høje forventninger til os og systemet. Derfor ville vi på mødet tale om dette og gøre klart, hvor stor en del systemet vi kunne nå at udvikle, og hvornår de kunne forvente at få det installeret Mødeforløb Mødet startede med tests af systemet. Vi var denne gang alle klar til tiden. Vi gennemførte de to tests i adskilte rum med henblik på at undgå, at testdeltagerne skulle påvirke hinanden. Testene forløb godt og mere formelt, end de gjorde i tredje iteration. En af årsagerne hertil var, at vi denne gang havde forsøgt at undgå de problemer, der opstod forrige gang. Efter testene interviewede vi hver for sig den samarbejdspartner, der havde fulgt hele udviklingsforløbet og en hjælper (se bilag H). Vi stillede omtrent de samme spørgsmål til dem begge. Hjælperen fortalte, hvordan skemaerne havde påvirket hendes dagligdag. Hun gav bl.a. udtryk for, at det ikke var meget slemt at udfylde skemaerne, men hun ville dog meget nødigt skulle gøre det over en længere periode. Den ene samarbejdspartner, som også var leder af tidsundersøgelsen, sagde, at hjælpernes holdning til tidsundersøgelsen var blevet mindre negativ i forhold til undersøgelsen i 97. Overordnet gav begge interviews stort set det samme indtryk af dataindsamlingen, der var dog enkelte uoverensstemmelser, hvilket man muligvis kunne forvente, da de interviewede kommer fra forskellige dele af hjemmeplejen. Efter interviewene talte vi om, hvornår og hvordan systemet skulle installeres Erfaringer I denne iteration opstod nogle vanskeligheder angående installationen af programmet. Kontakten til teknikeren i hjemmeplejen gav nogle uforudsete problemer på grund af misforståelser (se også afsnit 5.1.3). Testen med den administrative medarbejder, som ikke havde set systemet før forløb godt i forhold til forventningerne. Hun oplevede få problemer ved programmet, hvoraf de fleste var af mindre betydning. Hun foreslog ændringer, som efter hendes mening ville gøre systemet bedre og mere brugervenligt. Til hverdag er hun superbruger af Windows office applikationer, og hun er vant til at bruge en computer. Det kan muligvis have en betydning, at hun er vant til at sætte sig ind i de programmer, hun skal anvende. Dette kunne give hende en fordel i forhold til den anden testdeltagere. 40

43 4.4 Fjerde iteration Det virkede som om, at testopgaverne var lettere at forstå og forholde sig til end de forrige, hvor der manglede kontekst. Den ene testdeltager virkede en smule forvirret ved forrige test, mens hun denne gang var mere rolig, hvilket kan skyldes mere rolige omstændigheder og det faktum, at hun før havde set systemet. Den anden testdeltagers ro kan være forårsaget af, at hun er vant til at arbejde med computere og nye programmer. Ved denne test var der i det hele taget langt færre misforståelser omkring betydningen af opgaverne og løsningen heraf. Vi mener, dette kan skyldes, at opgaverne var sat i kontekst. Denne iteration forløb nogenlunde som forventet. Dog blev vi overrasket over misforståelserne i kommunikationen med teknikeren. Efter denne iteration ville vi rette de fejl, der fremkom på mødet. Vi blev efter mødet informeret om, hvordan systemet skulle installeres. Herefter ville vi sende to fra gruppen ud til hjemmeplejen for at installere programmet på en stationær computer. 41

44 42 4. Udviklingsforløb

45 5 Erfaringer Dette kapitel omhandler de erfaringer, vi har fået gennem udviklingen af systemet til Løgstør Kommunes Hjemmepleje. Herunder beskriver vi de måder, vi har håndteret henholdsvis forventningsafstemning med vores samarbejdspartnere, de teknikker vi har anvendt til at planlægge mødestrukturen, eksperimenter med ansvarsroller på møder med samarbejdspartnerne, test af systemet med indragelse af samarbejdspartnerne og erfaringer med udviklingsmodellen. 5.1 Forventningsafstemning Dette afsnit vil behandle forskellige aspekter af vores forventninger som udviklergruppe i forhold til samarbejdspartnernes forventninger til systemet. Vi kommer fra to meget forskellige miljøer - universitet og hjemmeplejen - og har derfor muligvis haft forskellige forventninger til udviklingsprocessen og resultaterne deraf. Alle møder med samarbejdspartnerne i hjemmeplejen har foregået i Løgstør på Bøgely Plejehjem. Samarbejdspartnerne har kun vores ord for, hvad det vil sige at studere informatik, hvordan vi arbejder, og hvad vi kan. Det må forventes, at de har et billede af os, som udspringer af en kombination af deres egne erfaringer, historier de har hørt, og de erfaringer de undervejs har fået med os. Det er derfor muligt, at deres forventninger til udviklingsprocessen og resultatet er meget forskellige fra vores. Ingen af os er bekendte med miljøet i hjemmeplejen, og vi kan derfor have lige så svært ved at forholde os til deres dagligdag, som de kan have svært ved at forholde sig til vores. Dette afsnit beskriver de tiltag, vi har gjort for at mindske misforståelser med hensyn til forskellige forventninger - forventningsafstemning. Efterfølgende beskrives, hvordan forventningsaftemningen er grebet an. Herunder 43

46 5. Erfaringer hvordan møderne er blevet forberedt med henblik på at afstemme vores forventninger med samarbejdspartnernes forventninger. Derefter beskrives erfaringer, der er erhvervet i forbindelse med de dokumenter, der skulle fastholde krav til systemet - brugerhistorier og systemspecifikation. Afslutningsvis beskrives samarbejdet med teknikeren i hjemmeplejen Forberedelse og introduktion til møder Til hvert møde, der afholdtes med samarbejdspartnerne i hjemmeplejen, forberedte vi en dagsorden for mødet ud fra de forventninger og mål, vi havde opstillet til iterationen. Udfra dagsordenen og forventninger og mål udarbejdede vi en introduktion til samarbejdspartnerne om, hvad de kunne forvente, der skulle ske på det kommende møde. Det indledende møde med samarbejdspartnerne er ikke beskrevet her, da der ikke blev foretaget nogen egentlig forventningsafstemning fra vores side (det første møde er beskrevet i afsnit 2.3 under foranalysen). Generelt kommunikerede vi mellem møderne per (i de følgende afsnit bruges oplysninger fra bilag J). Det andet møde - Brugerhistorier Formålet med det andet møde var hovedsageligt at få evalueret udkastene til brugerhistorierne. Vi vurderede, at det ville være vigtigt for samarbejdspartnernes forståelse af historierne, at vi gav en introduktion til deres formål. Dermed ville de være bedre udrustede til at vurdere dem, og de ville muligvis give mere feedback. På den dagsordenen, der blev tilsendt samarbejdspartnerne, blev det forklaret nærmere, hvad brugerhistorier er, og hvad de kan tilføre udviklingen af systemet. Samarbejdspartnerne blev også informeret om, hvordan det gik med udviklingen, og hvornår de kunne forvente at se de forskellige prototyper. Det tredje møde - Papirprototype På det tredje møde var formålet at teste papirprototypen og gennemgå de ændrede, mere formelle brugerhistorier. Samarbejdspartnerne fik tilsendt en dagsorden for mødet, vedhæftet de formelle brugerhistorier. Desuden blev det forklaret, at brugerhistorierne havde ændret karakter i fohold til dem, der blev præsenteret på foregående møde. For ikke at forvirre samarbejdspartnerne unødvendigt, forklarede vi, at brugerhistorierne indeholdt stort set de samme informationer, som de foregående. Vi beskrev desuden, hvordan tænke-højt testen af papirprototypen skulle foregå, da det ikke kunne forventes, at de havde prøvet det før. 44

47 5.1 Forventningsafstemning Det fjerde møde - Implementeret prototype På det fjerde møde skulle den implementerede prototype testes. Vi sendte igen en dagsorden, hvor der var en introduktion til, hvordan tænke-højt testen skulle foregå. Vi anså det for vigtigt at forklare, at vi ville foretage to indivielle tests; modsat testen på forrige møde hvor de to samarbejdspartnere sad sammen. Det blev desuden beskrevet, hvor fremskreden udviklingen af programmet var, og hvilke dele af systemet, der skulle testes. Hele programmet var på dette tidspunkt ikke implementeret, hvilket samarbejdspartnerne blev informeret om, så de ikke skulle have en forventning, vi ikke kunne leve op til. Det femte møde - Endelig prototype Det femte møde omhandlede test af hele systemet samt interview med hjælper og den ene samarbejdspartner, der er leder af tidsundersøgelsen. Den tilsendte dagsorden indeholdt en beskrivelse til lederen af, hvad hun skulle forberede sig på med henblik på interviewet. Derudover vedhæftede vi et dokument, som lederen kunne give til hjælperen. Dokumentet indeholdt en kort beskrivelse af projektet og en introduktion til interviewet. Vi gav grundige introduktioner til interviewene og håbede derved at personerne, der skulle interviewes ville tænke over relevante aspekter forinden, så vi kunne få så omfattende svar som muligt. Konklusion på forberedelse og introduktion til møder Foruden det tilsendte materiale har selve møderne haft en forventningsafstemmende funktion. Det har vi udnyttet således, at mødernes form og indhold gradvist er blevet mere formelt. Vi startede med at tilsende brugerhistorier skrevet i naturligt sprog, og i efterfølgende iteration sendte vi nogle mere formelt opstillede historier, som ikke indeholdt beskrivelse af kontekst. Ligeledes tilrettelagdes testene sådan, at de gradvist blev mere formelle. Først testede samarbejdspartnerne sammen, og derefter hver for sig. Vi har løbende taget små skridt, for at samarbejdspartnerne ikke skulle blive overrasket i en negativ retning. Det har fungeret godt, at vi gradvist ved hjælp af møderne har forberedt dem på efterfølgende møder. Det lader ikke til, at samarbejdspartnerne har været utilpasse eller utilfredse med nogle af de ting, vi har været igennem på møderne, og de har kunnet se formålet med mødernes indhold. Erfaringerne med mødeforberedelserne viser desuden, at det var en god idé at informere samarbejdspartnerne om mødernes indhold forinden, da alle dermed vidste, hvad der skulle foregå, og der var enighed om, hvornår mødet var overstået. 45

48 5. Erfaringer Det medførte sandsynligvis også, at samarbejdspartnerne ikke fik andre forventninger til mødet, end vi havde. Yderligere betød det, at vi satte dagsordenen og derfor kunne kontrollere forløbet Brugerhistorier og systemspecifikation Dette afsnit beskriver, hvordan brugerhistorierne og systemspecifikationen er blevet brugt, og hvad vi fik ud af det. Brugerhistorier Efter det første møde med hjemmeplejen lavede vi brugerhistorier ud fra de oplysninger, vi havde fået på mødet. Hensigten med dem var at skabe kommunikation mellem dem og os om, hvilke funktioner systemet skulle have. Vi mente, at det ville være en god ide, at brugerhistorierne ikke var for tekniske men i stedet indeholdt kontekst om funktionaliteten. Således mente vi, at det ville være nemmere for samarbejdspartnerne at sætte sig ind i dem. De blev via mail forberedt på brugerhistoriernes formål. De havde ikke problemer med at forstå dem, og historierne fungerede godt som udgangspunkt for samtalen ved det andet møde - brugerhistorier. Ved det tredje møde - papirprototype - eksperimenterede vi med formen på brugerhistorierne og lavede dem mere tekniske og formelle med henblik på at afdække, om det betød noget for vores samarbejdspartnere, hvordan historierne blev udformet. De blev forberedt på ændringen, så vi ikke forvirrede dem. Det viste sig, at de satte pris på den mere formelle form, idet de syntes, den var lidt nemmere at læse. Det lader altså ikke til, at det er noget problem at bruge formelle og eventuelt tekniske beskrivelser overfor samarbejdspartnerne. I dette tilfælde var det endda en fordel, da de ligesom os mente, det blev mere overskueligt at have brugerhistorierne i en fast opbygning, selvom det betød, at konteksten i hver brugerhistorie forsvandt. Det er dog muligt, at deres erfaring med de uformelle brugerhistorier har gjort det nemmere at forstå de mere formelle brugerhistorier. Det var hensigten, at brugerhistorierne skulle fungere som en aftale mellem samarbejdspartnerne og os og være dynamiske dokumenter, der beskrev, de krav systemet skulle opfylde. Det, der rent faktisk skete, var, at brugerhistorierne blev brugt ved de to første møder som samtalegrundlag, da der på disse to møder var flere uklarheder om den ønskede funktionalitet. På tredje møde - papirprototype - blev brugerhistorierne præsenteret inklusiv de rettelser, der var blevet indført sidst, og her var der ikke yderligere tilføjelser. Dette betød, at fokus for de sidste møder blev flyttet over på prototyperne. De tjente som et holdepunkt i forhold til møderne med samarbejdspartnerne, da det var med dem, der skete størst ændringer. 46

49 5.1 Forventningsafstemning Det viste sig at være på dette område, det var lettest for samarbejdspartnerne at komme med ændringsforslag, måske på grund af den mere visuelle præsentation af funktionaliteten. Brugerhistorierne var velegnede i starten af forløbet, men da de efterhånden blev implementeret i prototyperne, og der ikke opstod rettelser til dem, var der ikke længere behov for at diskutere dem. De rettelser, der fremkom til prototyperne håndterede vi ved hjælp af testrapporter, referater og samtaler. Desuden var rettelserne primært relateret til brugergrænsefladen med hensyn til, hvordan funktionaliteten bedst kunne præsenteres, og denne detaljeringsgrad egnede sig ikke i brugerhistorierne. Derfor ville de kun blive aktuelle igen, hvis der opstod nye opgaver, som skulle håndteres af systemet, eller hvis der opstod ændringer til de allerede definerede opgaver. Systemspecifikation Efter andet møde - brugerhistorier - lavede vi en systemspecifikation, der skulle fungere som en hjælp under implementeringen. Som beskrevet i den modificerede udviklingsmodel (se afsnit 3.4) var det et dokument, vi kun selv skulle anvende, og det havde ikke nogen tilknytning til samarbejdspartnerne, udover at det skulle indeholde information om de systemkrav, som var givet fra dem. Systemspecifikationen blev dog aldrig rigtig brugt som planlagt og foreskrevet af vores udviklingsmodel. Dokumentet var ikke tilstrækkelig detaljeret og var derfor ikke særlig brugbart som dokumentation og checkliste ved programmeringen. Ligeledes var det meningen, at systemspecifikationen skulle have været et dynamisk dokument, der skulle have ændret sig igennem forløbet, når der dukkede nye detaljer eller ændringer op - præcis ligesom brugerhistorierne. Systemspecifikationen blev ikke brugt på denne måde, hvilket for det første skyldtes, at der ikke skete store ændringer i de overordnede systemkrav undervejs i udviklingen, og for det andet at dokumentets detaljeringsgrad ikke var høj nok til, at små ændringer hørte hjemme i det. Resultatet blev, at dokumentet kom til at stå stille i mangel på rettelser og tilføjelser. Det gled dermed i baggrunden, som noget vi ikke benyttede os af. Vi burde måske have holdt fast i bestemmelsen om at have en dynamisk systemspecifikation, da vores modificerede udviklingsmodel foreskriver en sådan. Men på grund af de nævnte omstændigheder blev den funktion, vi havde tiltænkt dokumentet, erstattet af andre dokumenter og prototyperne. Især vores tests af prototyperne overtog en stor del af systemspecifikationens opgave, da grundlaget, for hvad der skulle laves i hver iteration, nærmest direkte var affødt af testresultaterne. Derforuden anvendte vi en top-down tilgang, hvor vi udviklede brugergrænsefladen først og derefter implemeterede funktionalitet i prioriteret rækkefølge. Vi har derfor ikke haft brug for designdokumenter til at fastholde programmets arkitektur 47

50 5. Erfaringer og klassediagram. Spørgsmålet er, om vi har mistet noget undervejs ved ikke at bruge systemspecifikationen som tiltænkt. I dette projekt var forløbet så uproblematisk og tilføjelserne og ændringerne i prototyperne så små, at vi ikke ser det som et problem, at vi ikke brugte systemspecifikationen. Havde det været et turbulent samarbejde, hvor der undervejs var dukket store ændringer til systemet op, så havde det været en fordel med en opdateret systemspecifikation. Konklusion på brugerhistorier og systemspecifikation Brugen af brugerhistorierne og systemspecifikationen fungerede ikke helt som planlagt. Ganske vist fungerede brugerhistorierne godt med vores samarbejdspartnere, men lidt af den dynamik, vi havde forudset de ville have, manglede. Dette skyldtes, at der ikke kom ændringer af større karakter undervejs. Hvad systemspecifikationen angår, så blev den ikke brugt, som det var tiltænkt - i dette projekt var den overflødig og gennemgik ingen forandring undervejs. Den har ikke vist sig at være nødvendig for udviklingen. Dette er måske kun tilfældet, da den første prototype og de næste, der fulgte, indfriede de forventninger, samarbejdspartnerne havde. Havde der været problemer, havde det måske været godt og ligefrem nødvendigt at fastholde disse i et dokument som systemspecifikationen Forventninger vedrørende samarbejde med tekniker Midt i udviklingsforløbet ønskede vi at tage kontakt til teknikerne, som stod for driften af de computere og servere, der var tilknyttet hjemmeplejen. Vi talte først med vores samarbejdspartnere om, hvordan vi skulle kontakte teknikerne. De fortalte os, hvilken tekniker vi skulle tage kontakt til, samt at de ville fortælle ham, at han kunne forvente, at vi kontaktede ham per (al kontakt med teknikeren foregik via , se bilag J). Vi sendte derefter en til teknikeren, som vi ikke fik svar på. Efter to dage fik vi en fra vores vejleder, som ad andre veje havde hørt, at teknikeren var tilbageholdende med hensyn til installationen af vores program. Der var sket en misforståelse imellem os og samarbejdspartnerne, der medførte, at teknikeren og vi misforstod hinanden. Han var ikke så velinformeret om vores program, som vi havde forventet, og derfor var han blevet overrasket over at se en fra os, hvori vi bad om at få et, for ham, ukendt system installeret på hjemmeplejens server. Efter at have erfaret at der var nogle problemer, skrev vi en ny til teknikeren, der mere dybtgående forklarede, hvad det hele handlede om. Vi forklarede, hvad vi lavede, og hvad systemkravene var. Mailen indeholdt en beskrivelse af tekniske krav og systemets formål. Vi spurgte, om han 48

51 5.2 Mødestrukturen eventuelt havde tid til at mødes med os den dag, vi skulle til det femte møde - endelig prototype. Derefter modtog vi en fra teknikeren, hvori han forklarede bevæggrundene for hans reaktion samt hvilke muligheder, der var, og hvorfor han ikke var tilbøjelig til at ville installere systemet. Han havde desværre ikke tid til at mødes med os. Vi besvarede denne med en længere forklaring af, hvem der havde ansvar for systemet, og hvem der skulle udøve support på det. Denne svarede han ikke tilbage på, så på det sidste møde med hjemmeplejen diskuterede vi med vores samarbejdspartnere, hvilke muligheder der var for det videre forløb i denne situation. Det endte med, at den ene samarbejdspartner tog kontakt til teknikeren for at vejre situationen, og der blev enighed om en løsning. Programmet skulle installeres lokalt på en pc uden om kommunens netværk. I forbindelse med kontakten til teknikeren i hjemmeplejen har vi erfaret, at det er vigtigt at tage kontakt tidligt i forløbet. Der opstod nogle problemer, vi kunne have taget i opløbet. I dette tilfælde havde han ikke tid til at tale med os på det tidspunkt, vi kontaktede ham, og han var overrasket over at høre fra os. Det kunne have være undgået ved at tage kontakt på et tidligere tidspunkt. 5.2 Mødestrukturen Som beskrevet i kapitlet om udviklingsforløbet (se kapitel 4) afholdt vi i starten uformelle møder - møder uden nogen fastlåst fordeling af ansvarsroller og struktureret planlægning. Gennem forløbet formaliserede vi møderne, så vi vidste præcis, hvem der havde hvilke roller, og hvem der tog sig af hvilke spørgsmål. Men hvilke forventninger havde vi til de forandringer, vi indførte på møderne? Efter vores opfattelse havde begge former for møder sine fordele og ulemper. Ud fra den situation, vi var i på det pågældende tidspunkt i udviklingsforløbet, foretog vi de valg, vi fandt mest hensigtsmæssige Forventninger til en uformel mødestruktur Vi forventede, at et uformelt møde - i højere grad end et formelt - ville fremme deltagernes kreativitet. Selve mødesituationen var mere åben, da ansvaret for emnerne og de spørgsmål, som ønskedes besvaret, ikke var placeret på enkeltpersoner. Gruppen havde blot diskuteret emnerne igennem inden mødet og ikke fordelt ansvaret for emnerne. Dette kunne være medvirkende til, at flere mødedeltagere kom med input til det emne, der blev diskuteret, og kreativiteten ville sandsynligvis også blive større, da der kunne komme flere vinkler på den samme diskussion. Derimod kunne det uformelle mødes løsere struktur betyde, at samarbejdspartnerne blev usikre på, hvem de skulle tale til, da flere forskellige ville stille spørgs- 49

52 5. Erfaringer mål. Måske ville de simpelthen vælge en bestemt person at henvende sig til under mødet, og denne person ville i det tilfælde komme til at optræde som en egentlig mødeleder. Hvis det skulle ske, at et gruppemedlem ubevidst fik tildelt rollen som mødeleder, kunne det medføre, at denne person fik overladt ansvaret for mødet. Dette skal gruppen være opmærksom på, så man får stillet de spørgsmål, der undervejs dukker op hos hvert enkelt gruppemedlem. Et andet problem ved at holde et uformelt møde kunne være en mangelfuld fastholdelse af resultaterne. Det kan være svært at tage referat af et møde, som ikke har nogle faste rammer. En måde at få et fyldestgørende referat på kunne være at lave en transskription af mødet, som så bagefter skal gennemgås for at uddrage resultaterne af mødet. Dette vil i teorien være muligt, men i praksis vil det betyde en temmelig stor arbejdsbyrde, og trods dette kan der stadig være resultater, som overses. Derudover kan det være svært at holde fast i, at alle i gruppen skal være lige aktive med at stille spørgsmål, hvis én person skal være referent. Referenten kan enten blive passiv i diskussionen eller modsat glemme at tage referat for at komme med indlæg i diskussionen. Et muligt alternativ til dette ville være at optage hele mødet på video eller bånd, da man på denne måde kunne få en bedre dækning af situationen. Dette kan betyde en stor arbejdsbyrde med at gennemgå materialet, men en videooptagelse kan være en stor hjælp efterfølgende, fordi man får mange flere nuancer med end ved et mødereferat. Det kan dog have betydning for resultatet, at man laver sådanne optagelser, da det kan påvirke mødedeltagerne, bevidst eller ubevidst, at alt, hvad de siger og gør, bliver optaget Forventninger til en formel mødestruktur Et formelt møde vil være karakteriseret ved, at man inden mødet har fordelt rollerne i gruppen, og der dermed, ideelt set, ikke er tvivl om, hvem der har ansvar for hvad. Det formelle mødes største force er, at det har en klar struktur. Hvis mødet er godt forberedt, burde der ikke kunne opstå misforståelser undervejs, og værdien af den spontanitet, som blev udnyttet ved det uformelle møde, ville forhåbentligt blive erstattet af en grundigt forberedt dagsorden. Denne forberedelse medfører, at spørgsmålene ideelt set burde afdække det samme som på et uformelt møde. Denne antagelse bygger på, at man, gennem en grundig forberedelse og ved at følge en dagsorden, er sikker på at få afdækket det, man havde sat sig for. Det er muligt, at kreativiteten ikke ville være til stede i samme grad, som hvis mødets struktur var løsere. På selve mødet kan det dog formentlig virke mere afslappende for samarbejdspartnerne, at det er én person ad gangen, der fører ordet. Man skal dog være opmærksom på ikke at give udtryk for, at de personer, 50

53 5.2 Mødestrukturen som ikke fører ordet, kunne være blevet hjemme - at de bliver for passive. En anden fordel ved det formelle møde er, at referenten koncentrerer sig om at tage referat. Referatet har desuden en fast struktur fra starten, og dermed mindskes risikoen for, at der mangler noget i fastholdelsen af resultaterne. Samarbejdspartnerne vil måske også føle sig mere trygge ved situationen på grund af den fastere opdeling af mødet Erfaringer fra møderne Erfaringerne med afholdelse af møder svarede ikke helt til vores forventninger, som er beskrevet i forrige afsnit. Erfaringerne var dog overvejende positive. Det skyldes sandsynligvis, at vi i projektperioden har gjort os overvejelser om, hvordan møderne skulle afholdes, i forhold til den situation vi var i på det pågældende tidspunkt. Vores første møder var uformelle, da vi ønskede at fremme kreativitet i forslagene til systemet. Vi udnævnte to referenter for at få fastholdt resultaterne, uden at der var én person, som blev holdt tilbage af referentrollen. Når den ene var aktiv i diskussionen, skulle den anden være særlig påpasselig med at tage notater. Dette fungerede udmærket. Det lykkedes både at få taget fyldestgørende notater og deltage i diskussionen for begge referenter. Det er svært at sige, om kreativiten ville være højere på et af de første møder end ved et mere struktureret møde. Det er ikke umiddelbart nemt at drage sammenligninger mellem disse to mødeformer, da tests optog meget af tiden på de senere møder. Kreativitet er ikke nem at måle og veje, men der var ikke mangel på input, og den uformelle mødeform fungerede godt til de møder, hvor den blev brugt. Det var sværere end forventet at holde styr på, hvor langt vi var kommet i den række spørgsmål, vi gerne ville have besvaret. Alle i gruppen sad med disse spørgsmål, og de blev derfor ikke nødvendigvis stillet i den rækkefølge, de var skrevet i. I slutningen af mødet var det derfor svært at overskue, om et spørgsmål var blevet stillet eller besvaret indirekte gennem et andet spørgsmål. De efterfølgende møder blev afholdt mere formelt. Vi havde inden mødet fordelt, hvem der tog sig af hvilke emner, og vi havde en struktureret dagsorden. Dette betød en klar forbedring i forhold de uformelle møder med hensyn til at vide, hvornår man var færdig med et emne. Selvom det kun var en person ad gangen, der stod for spørgsmålene, tillod vi dog andre at komme med supplerende spørgsmål undervejs. Vi oplevede ikke, det var forvirrende, og vi havde heller ikke opfattelsen af, at vores samarbejdspartnere fandt det underligt. Der var generelt ikke nogle problemer med at samarbejdspartnerne ikke kunne håndtere vores måde at holde møder på - formelle som uformelle. Vi oplevede 51

54 5. Erfaringer ikke, at der var forvirring eller undren over, at vi undervejs skiftede struktur på møderne. Begge mødeformer fungerede godt på de aktuelle tidspunkter i udviklingsforløbet. 5.3 Rollefordeling i projektperioden En oversigt over forløbet Vores første møder var uformelle, og derfor var der ikke nogen fordeling af ansvarsroller i forbindelse med brugersamarbejdet i den første del af forløbet, til og med anden iteration (se figur 4.1). De to første møder - indledende møde og brugerhistorier - forløb mindre struktureret end de senere møder, og fordelingen af roller på disse møder, skete i realiteten først på selve møderne, ved at folk påtog sig de forskellige opgaver efter interesse og tilbøjelighed. Ved de senere møder blev rollerne fordelt forinden. Ved det tredje møde - papirprototypen - blev rollerne fordelt inden mødet. De blev fordelt efter ønske, og i forbindelse med testen blev der også taget hensyn til, at de personer, der normalt var mere tilbageholdende, fik mere fremtrædende roller. Grunden hertil var, at vi mente, det ville være en fordel for alle gruppemedlemmer at have prøvet forskellige roller, også nogen man ikke umiddelbart selv ville finde naturlige. Ved det fjerde møde - implementeret prototype - var rollerne fordelt, således at de personer i gruppen, som normalt er de mest passive i en mødesituation, fik mere aktive roller, og de normalt mest aktive personer fik mere tilbageholdende roller. Grunden til rollefordelingen var, ligesom på sidste møde hvor alle skulle prøve forskellige roller, at vi ville se, hvordan vores samarbejdspartnere reagerede på en ændret rollefordeling. Erfaringerne fra dette var blandede. Dels var det for nogle i gruppen svært at påtage sig en rolle, som ikke umiddelbart passede til deres natur, og dels blev vi, uden at ville det, fastholdt i rollerne fra de første møder. Dette skyldes sandsynligvis, at samarbejdspartnerne allerede var blevet vant til at tale til nogle bestemte personer på møderne - nemlig dem, de på de første møder, havde snakket mest med. Dette viser, at man ikke bare lige kan vende rollerne på hovedet, hvis samarbejdspartneren først er blevet introduceret til én rollefordeling. På femte møde - endelig prototype - vendte vi tilbage til den gamle rollefordeling. Denne gang mere bevidste om, hvad vi gjorde. Mødet fungerede umiddelbart bedre end de to foregående, men foregik dog også først og fremmest som tests og to separate interviews. Det kan derfor ikke fuldstændig sammenlignes med tredje og fjerde møde, hvor hele gruppen var repræsenteret ved en samlet test, og den efterfølgende samtale med de to kontaktpersoner. 52

55 5.3 Rollefordeling i projektperioden Rollerne De forskellige rolletyper, som vi benyttede os af i løbet af de fem møder med Løgstør Kommunes Hjemmepleje, var: Diskussionsleder ved møde (person der præsenterer et emne og styrer diskussionen om dette - kan være flere personer ved et møde med flere emner) Referent ved møde Interviewer Referent ved interview Testleder ved tænke-højt test Referent ved tænke-højt test Der er ikke noget nyskabende i disse rolletyper, hvilket skyldtes, at vi fandt det mere relevant at eksperimentere med, hvordan rollerne blev fordelt, end at skulle opfinde alternativer til disse gængse roller. Som det fremgår af beskrivelserne i sidste afsnit, havde vi flere gange uddelt mere end én referentrolle. Ved evaluering af papirprototypen fik de forskellige referenter dog forskellige fokusområder. F.eks. fik én test-referent til opgave at holde øje med testdeltagernes gestik og ansigtsudtryk, mens de andre to referenter skulle tage almindeligt referat. Desuden brugte vi også at uddele forskellige emner til forskellige personer, og derfor kunne rollen som diskussionsleder godt veksle mellem flere personer på det samme møde Rollefordeling internt i gruppen Gruppen er opbygget som en matrixorganisation. Hermed menes, at alle kommunikerer med alle, og at der ikke er nogen egentlig leder. I gruppen har vi valgt at lade to interne roller cirkulere mellem os, for at alle prøve at være f.eks. mødeleder, og man ikke forbliver i samme rolle for længe. De to cirkulerende roller er mødeleder og referent. Rollerne skifter hver 14. dag - ganske simpelt efter et rotationsprincip. Fordelene ved at køre det interne samarbejde på denne måde er, at det mindsker risikoen for at gruppemedlemmer bliver fastlåst i en rolle gennem hele projektperioden (det er f.eks. ikke særlig spændende at være referent i tre måneder). Derforuden kan rotation af ansvarsroller i høj grad øge gruppemedlemmernes engagement i og ansvar for projektet 1. Hvis der kun er én gruppeleder 1 Kilde: Otto Veie om et projekt, hvor de som forsøg havde roteret de interne roller. 53

56 5. Erfaringer gennem hele projektperioden, kan det blive for let for de andre gruppemedlemmer at lægge alt ansvar for projektet over på vedkommende. Endelig skal vi som studerende også udnytte mulighederne for at afprøve forskellige roller, også de roller man ikke umiddelbart selv ville vælge. Man kunne jo vise sig at være bedre til noget, end man troede. Hvis man ser rollefordelingen i et mindre positivt lys, så kan beslutningen om cirkulationen af roller måske tolkes, som at vi ikke tør overlade ansvaret for projektet til en enkeltperson gennem hele forløbet. Eller at vi ikke kan håndtere kendsgerningen at en fast projektleder reelt er en form for leder af gruppen. For selvom det bare er en rollefordeling ud fra en fælles beslutning,kan det måske ubevidst virke som om, nogen fra gruppen er bedre eller mere værd end andre. For at sikre os mod at komme ud i problemer, hvis rotationen af roller ikke fungerede, valgte vi at holde samarbejdsmøder gennem forløbet, så vi havde mulighed for at opfange problemerne på et tidligt tidspunkt. Det viste sig at være unødvendigt, da det fungerede godt, og i dette projekt har vi ikke haft problemer med den form, vi har kørt samarbejdet på. Det har fungeret godt for vores gruppe med de skiftende roller, så hvorfor skulle man egentlig gøre det anderledes? Måske netop for at få de universitetsprojekter man deltager i til at ligne, hvad man som oftest kommer ud til i erhvervslivet: At der til hvert projekt er tilknyttet en projektleder, og at man derigennem har nogle faste formelle rammer. Det er under alle omstændigheder en fordel at have overvejet rollefordelingen i gruppen meget bevidst ved projektstart, samt undervejs i forløbet at evaluere samarbejdet Rollefordeling i eksterne mødesituationer Den måde vi har valgt at forholde os til roller på internt i projektarbejdet samt den kendsgerning, at vi er tilfredse med, hvordan det har fungeret, kan have betydet, at vi ikke har forholdt os særlig aktivt til rollefordeling eksternt - specielt i starten af forløbet. Det var først efterhånden, at vi blev mere bevidste omkring de forskellige roller, og vi dermed startede formaliseringen af møderne. I forhold til vores samarbejdspartnere betød det, at de kunne have anbragt os i nogle roller, som ikke var planlagt. De roller, der på det første møde blev tildelt efter kompetencer og tilbøjeligheder, har fungeret udmærket i det efterfølgende samarbejde på det andet og femte møde - brugerhistorier og endelig prototype Forsøg med ombyttede roller Vi udførte et bevidst forsøg med rollefordelingen undervejs i forløbet. På det tredje og fjerde møde - papirprototype og implementeret prototype - forsøgte vi at tildele andre roller end de sædvanlige, hvilket betød, at de normalt mest passive af 54

57 5.4 Tests af systemet os fik aktive roller og omvendt. Formålet med forsøget var at forhindre, at det altid var de samme i gruppen, som styrede diskussionen på møderne. Derudover ville vi dels se, om de af natur mere tilageholdende i gruppen kunne presses til at bidrage med mere, og dels hvordan samarbejdspartnerne reagerede på den omvendte rollefordeling. Erfaringerne fra dette forsøg var overvejende positive, da de personer, som fik aktive roller, generelt påtog sig rollen uden store problemer. Det var måske sværere for de personer, som plejede at sige en masse, at de skulle lægge bånd på sig selv. Dette blev også forstærket af samarbejdspartnernes reaktion på forsøget. De henvendte sig nemlig til de personer, de var vant til at tale med ved de tidligere møder. Vi havde ikke forventet, at det ville ske i den grad. Men da forsøget var skjult for samarbejdspartnerne - de havde ikke specifikt fået noget at vide om det inden møderne - så var det selvfølgelig mest naturligt for dem at tale til de samme personer. Et eksempel på dette var en test, hvor testdeltageren henvendte sig til referenten i stedet for testlederen. 5.4 Tests af systemet Dette afsnit beskriver, hvordan vi har testet programmet, og hvilke erfaringer vi har fået med at bruge tests i brugersamarbejdet. Vi lavede tre tests. Den første test var en gennemgang af en række opgaver med begge samarbejdspartnere på en gang. Disse opgaver skulle danne baggrund for en efterfølgende uformel diskussion om systemet. Den næste test var en mere traditionel tænke-højt test med de samme personer, men hvor de testede systemet hver for sig. Den sidste test var også en tænke-højt test hvor en af samarbejdspartnerne igen medvirkede, men hvor der derudover var en person med fra hjemmeplejens administration, som ikke kendte noget til systemet på forhånd. Vi valgte tænkehøjt testmetoden til alle tre tests, fordi man med den metode kan få megen viden og indsigt i, hvordan brugerne forholder sig til et computersystem, i forhold til hvor mange testdeltagere man benytter. Det betyder, at man ved test med kun få testdeltagere kan få fyldestgørende resultater 2. De ting, vi ønskede at undersøge med testene, var overordnet, om brugergrænsefladen var forståelig for brugere, der kender hjemmeplejens begreber, om systemet er let at anvende, selv for nogen som ikke har prøvet det før, samt om den tilbudte funktionalitet var tilstrækkelig. Desuden håbede vi, at testene kunne fange eventuelle fejl og upraktiske ting, f.eks. ved indtastning af data. 2 Lauesen, 2002 [5]; Molich, 2000 [6] 55

58 5. Erfaringer Vores testdeltagere var som nævnt vores samarbejdspartnere hos Løgstør Hjemmepleje, samt en person, der arbejder i administrationen i hjemmeplejen og er superbruger af Windows og MS Office. Denne person kender hjemmeplejen indefra men var ellers ikke bekendt med systemet Beskrivelser af testene Det følgende afsnit beskriver kort testene. Testrapporterne kan ses i bilag G. Beskrivelser af møderne som helhed kan ses i kapitel 4. Den første test - Papirprototypen Formålet med testen var at sikre, at samarbejdet indtil videre havde fungeret tilfredsstillende, og at vi dermed havde forstået, hvilke funktioner systemet skulle have, samt at disse funktioner blev præsenteret på en forståelig og brugervenlig måde i programmet. Testen blev modificeret i forhold til en traditionel tænke-højt test, som beskrevet af f.eks. Molich 3, da vi ønskede, at de to testdeltagere skulle arbejde sammen og at testen skulle lægge op til en efterfølgende diskussion. Desuden blev brugergrænsefladen, der var blevet tegnet på en computer, præsenteret på papir. Dette kan være medvirkende til at opmuntre til ændringsforslag, da mange mennesker finder det lettere at foreslå ændringer til papir end til ting på en computerskærm 4. Da vi ønskede, at alle fem gruppemedlemmer skulle deltage aktivt i testen, uddelte vi, udover rollerne som testleder og "computer", tre referent-roller. To til at referere samtaler, og en til at referere gestik og ansigtsudtryk. Vi forventede, at det ville være nyttigt, at have flere typer referater, men det viste sig, at der ikke var særlig meget at referere med hensyn til gestik og ansigtsudtryk, og at et almindeligt samtalereferat var fuldt tilstrækkeligt til vores behov efter denne test. Bordopstilling Vi forberedte bordopstillingen på forhånd med henblik på, at referenterne skulle have tilstrækkeligt udsyn og testlederen god mulighed for at tale med testdeltagerne. Opstillingen kan ses på figur 5.1. Det viste sig, at testdeltagerne foretrak at henvende sig henover bordet til de to referenter og den person, der agerede computer. Testlederen havde derfor svært ved at deltage i samtalen. Det var ikke så 3 Molich, 2000 [6] 4 Lauesen, 2002 [5] 56

59 5.4 Tests af systemet Referent "Computer" Referent 2 Referent 1 Testdeltager 1 Testdeltager 2 Testleder Figur 5.1: Bordopstilling til første test heldigt, da det forstyrrede referenterne og forvirrede computeren lidt, men det er meget naturligt, at man henvender sig til de personer, man ser på. Derudover var de personer, der sad over for testdeltagerne, også på det tidligere møde mere aktive i samtalen. Testdeltagernes forventning til, hvem de skulle tale med, havde muligvis bund i, at de på de tidligere møder havde vænnet sig til at henvende sig til dem, der var mest aktive (se afsnit 5.3). I og med at testdeltagerne henvendte sig til andre end testlederen, udviklede testen sig til en diskussion imellem testdeltagerne og gruppemedlemmerne. Det havde været hensigten, at diskussionen skulle foregå efter testen, men det viste sig at fungere udmærket med diskussion ind imellem opgaverne. Da vi ikke ønskede, at testdeltagerne skulle blive nervøse eller anspændte ved situationen, lod vi diskussionen udvikle sig i stedet for at afbryde testdeltagerne for at gå videre i testen. Samarbejdspartnerne viste sig at være gode til at forholde sig kritisk og konstruktivt til brugergrænsefladen. De kom med forslag og kommentarer i løbet af testen og gav ikke indtryk af, at de holdt sig tilbage eller var bange for at sige noget. De deltog begge lige aktivt, og vore forventninger om at testmetoden ville aktivere testdeltagerne blev opfyldt. Vi fik også gode ændringsforslag og rettelser til programmet, så allerede på dette tidlige stadie af programudviklingen havde vi nogle helt konkrete udsagn at arbejde videre med. Den anden test - Implementeret prototype Formålet med denne test var at få samarbejdspartnerne til at afprøve programmet på computer, og dermed blandt andet finde ud af om brugergrænsefladen var brugervenlig og forståelig, efter at den var blevet implementeret. Dette møde skulle foregå mere formelt, og vi mente, at en traditionel tænke-højt test ville passe godt. Som en del af eksperimenterne ved mødet, havde vi valgt at bytte de sædvanlige roller om, så de, der normalt talte mere ved møderne, var referenter og de andre testledere. Denne gang skulle testen foregå formelt. Det vil sige, at der ikke måtte opmuntres 57

60 5. Erfaringer til diskussion under testen, og testlederen måtte ikke hjælpe mere end absolut nødvendigt. Testdeltagerne var de samme som ved den foregående test, men denne gang udførtes to separate tests. Systemet blev testet på bærbare computere med en almindelig, ekstern mus, men intet numerisk tastatur. Da der var flere opgaver med talindtastning, kan det have påvirket testpersonerne, at de skulle bruge et tastatur, hvor det er mere besværligt at indtaste tal. Testen foregik på Bøgely Plejehjem i det mødelokale, som vi tidligere havde brugt til møder. Test med bruger 1 Test med bruger 2 Referent 1 Testleder Testdeltager Referent 2 Testleder Testdeltager Referent Figur 5.2: Bordopstilling til anden test Da vi denne gang skulle lave to tests, delte vi gruppen op i to; én mødeleder til hver test og henholdsvis en og to referenter. Det var tilfældigt hvilke af testene, der havde en eller to referenter. Referenterne skulle koncentrere sig om, hvad testdeltageren sagde og gjorde i forbindelse med opgaveløsningen, men i øvrigt skulle de helst være "usynlige"ved testen. Derfor forsøgte vi denne gang at placere referenterne, så det ikke virkede oplagt for testdeltagerne at tale til dem. For testopstillingen med de to referenter (test med bruger 2 på figur 5.2) betød det, at referenterne fik et dårligt udsyn til skærmen. Det blev ikke bedre af, at det var en fladskærm, hvor indholdet var svært at se fra siden. Bordopstillingen ændrede dog ikke så meget på, hvem testdeltagerne henvendte sig til. De henvendte sig stadig også til referenterne i nogle situationer. Referenterne oplevede, at det var svært ikke at reagere, da det ville have virket mærkeligt og unaturligt ikke at svare, når de blev tiltalt. De to tests forløb lidt forskelligt. På grund af tekniske vanskeligheder med computerne kom vi lidt for sent af sted til mødet, og vi måtte bruge det første kvarter på at gøre den ene computer klar til testen. Den ene testdeltager var klar til tiden og måtte således vente på os. Efter at testen var kommet i gang, forløb den uden større problemer. Den anden testdeltager var forsinket og kom lige fra et andet møde. Hun var stresset og følte sig uforberedt til mødet med os. Hun havde en del problemer med første opgave og kom i det hele taget lidt skævt ind på testen. Hun var også mere tilbageholdende i forhold til at prøve programmet af end ved den foregående test. Efter begge tests mødtes vi alle til en opsamling og diskussion af 58

61 5.4 Tests af systemet nogle af de ting, der var dukket op under testen. Vi havde forventet kun at støde på mindre problemer, ligesom til forrige test, men en funktion i statistikdelen viste sig at blive opfattet en del anderledes end aftalt ved det foregående møde. Testdeltagerne mente selv, at funktionen ikke skulle laves om, men at det var noget, der måtte læres ved brug af programmet. Hvis testdeltagerne havde siddet sammmen ved testen, er det muligt, at de ved at diskutere problemet havde fundet ud af at bruge funktionaliteten korrekt. Det var derfor værdifuldt, at de testede hver for sig, da det afslørede problemet. Det viste sig, at referaterne fra testene ikke var velegnede til at få formidlet data om testen fra den ene del af gruppen til den anden. Det er åbenbart svært for en eller to personer at nå at skrive tilstrækkeligt ned om alt, hvad der sker. Vores måde at komme uden om dette problem på var at diskutere, hvad der var sket og skrive det ned, der skulle rettes i programmet. Vi havde ikke på forhånd overvejet at filme eller lydoptage testene, da gruppemedlemmernes tidligere erfaringer med tænke-højt tests ikke har vist nødvendigheden af dette. Grunden til, at det ikke tidligere har været et problem, kan være, at alle i gruppen har været til stede ved alle tests, og derfor kan huske det, som måske ikke eksplicit står i referatet. Denne gang var det nødvendigt at alt stod i referatet, og det viste sig som nævnt at være yderst vanskeligt. En anden grund til, at vi ikke brugte videofilmning, var, at det kan virke som en ekstra forstyrrende faktor på en testdeltager og dermed påvirke resultaterne. Den tredje test - Endelige prototype Formålet med denne test var at undersøge, om systemet var brugervenligt, efter at forrige iterations rettelser var implementeret, samt om en person, der var ubekendt med systemet, og altså ikke havde deltaget under udviklingen, kunne finde ud af at bruge det. Ligesom de to forrige gange skulle dette møde forløbe formelt, og vi anvendte tænke-højt testmetoden på samme måde som forrige gang. Denne gang var vi meget opmærksomme på at være ekstra godt forberedte hvad angik computerne, så vi kunne undgå en dårlig start. Testdeltagerne var denne gang den ene af vores samarbejdspartnere og en administrativ medarbejder, der kendte hjemmeplejen men ikke tidsundersøgelsen eller systemet. Testforløbet var denne gang mere ligetil. Vi var forberedte og kom til tiden, ligesom vores testdeltagere. Testene forløb uden store problemer, selvom det dog stadig var svært at undgå, at testdeltagerne talte til referenterne. Resultatet af testen viste, at brugergrænsefladen fungerede efter hensigten, også for den testdeltager der ikke kendte den i forvejen. Der var dog stadig et problem i statistikdelen, som 59

62 5. Erfaringer Test med bruger 1 Referent 1 Test med bruger 2 Testleder Referent 2 Testleder Testdeltager Referent Testdeltager Figur 5.3: Bordopstilling til tredje test vi i samarbejde med hjemmeplejen har fundet frem til, at vi ikke vil gøre noget for at udbedre. Dette skyldtes, at som programmet er bygget op, vil det kræve en indskrænkning i valgmulighederne, hvis problemet skal udbedres, og det ønsker man ikke Vurdering Valg af testmetoder Der var flere grunde til, at vi valgte tænke-højt testmetoden. For det første har vi brugt den ved flere tidligere projekter og er dermed godt bekendt med den. Det er vores erfaring med testmetoden, at man får mange brugbare oplysninger om, hvordan et program fungerer, og hvordan brugerne forstår det. Det skyldes, at man iagttager brugernes adfærd i en situation, som er så realistisk som muligt, og man samtidig også får indblik i, hvad testdeltagerne overvejer, når de bruger programmet 5. Hvis man f.eks. nøjedes med at observere brugere, ville man ikke få indblik i, hvorfor de gør, som de gør. Hvis man valgte i stedet at bruge rene interviewteknikker som f.eks. fokusgrupper eller spørgeskemaer, får man kun indblik i, hvad brugerne mener om systemet, og hvordan de selv tror, de vil anvende det - ikke hvad de rent faktisk gør, og det kan der være stor forskel på 6. Endelig kan man gå helt uden om brugerne og vurdere brugergrænsefladen med en heuristisk inpektion 7. Dette er den nemmeste og hurtigste metode, men i forhold til tænkehøjt metoden finder den færre problemer, og man kan ikke være helt sikker på, at problemerne også vil opstå for en bruger 8. Men også en tænke-højt test har problemer. For eksempel kan den for nogle testdeltagere virke som en slags eksamen af dem selv fremfor systemet, selvom man forsøger at afhjælpe det. Det kan på- 5 Molich, 2000 [6] 6 Lauesen, 2002 [5] 7 Molich, 2000 [6] 8 Karat et al., 1992 [2] 60

63 5.4 Tests af systemet virke deres adfærd ved, at de f.eks. bliver mere tilbageholdende, end de ellers ville have været, eller også skynder de sig gennem opgaverne for at virke effektive og dygtige. Vores testdeltagere gav generelt ikke indtryk af at være plaget af disse problemer. Ved den anden test var der dog forskellige mindre problemer, men det kan også skyldes, at vi fik startet på en stresset og forjaget måde. Det har i hvert fald ikke hjulpet med til at berolige testdeltagerne. Rollernes indflydelse Det tidligere nævnte problem, med at testdeltagerne undervejs spurgte referenterne i stedet for testlederen (se afsnit 5.3), kan måske også have haft en effekt på resultaterne fra testen. Det er i hvert fald et brud på den situation, vi som tilrettelæggere af testen forsøgte at lave: En realistisk række opgaver, som udførtes af testdeltageren med så lidt intervention fra omverdenen som muligt. Når denne situation bliver brudt, så kan det betyde, at vi som udviklere ubevidst kan komme til at give hints til systemets brug, og dermed kan der gå nogle resultater tabt. Udover at en mindre diskussion midt i en test kan virke som en hjælp til testdeltageren, så kan forstyrrelsen også betyde, at det bliver sværere for testlederen at klare opgaven tilfredsstillende. Vedkommende skal jo optræde så neutralt som muligt for netop ikke at give hints til systemets brug. Men hvis der først er opstået en lille diskussion mellem referenter og testdeltagere, så kan det være vanskeligt at få testen tilbage på sporet, uden at man bryder ud af den neutrale rolle. Udbytte Der var ingen større forskelle mellem udbyttet af de enkelte tests. Både den uformelle og de formelle tests gav feedback på, hvordan programmet fungerede, og om vi havde korrekt forståelse af det ønskede system. Som tidligere nævnt (se afsnit 5.4.1) var der dog et problem med at fastholde alle resultaterne fra vores dobbelttests, da vi udelukkende brugte skrevne referater. Vores indbyrdes samarbejde var betydeligt lettere efter den første test, som vi alle deltog i, da det gav mindre arbejde med for hinanden at formidle, hvad der var sket under testen. Det betød også, at vi kunne nøjes med referaterne og ikke havde brug for en detaljeret testrapport. Denne erfaring vil vi helt sikkert inddrage i fremtidige projekter og overveje, om vi som et supplement til referaterne skal optage hele testen på video eller lignende, så vi altid har muligheden for at få afgjort uklarheder i de skrevne referater. 61

64 5. Erfaringer Hvordan samarbejdspartnerne forholdt sig til testene Det har været interessant at opleve, hvor ukompliceret testdeltagerne forholdt sig til at medvirke i vores tænke-højt tests, i forhold til de erfaringer gruppens medlemmer har haft fra tests i tidligere projekter, samt fået gennem undervisningsmateriale. Der har ikke være nogen nervøsitet at spore, måske nærmere det modsatte: At testdeltagerne ikke opfattede testen som en formel test, men godt kunne finde på at afbryde med generelle spørgsmål til systemet ind imellem. 5.5 Udviklingsmodellen Dette afsnit beskriver de erfaringer, vi har fået ved at anvende vores modificerede model af prototyping som udviklingsparadigme. Modellen har direkte været en hjælp til at minde os om at få nedskrevet de forventninger og mål, vi havde til hver iteration, og undervejs i iterationerne, at få nedfældet de erfaringer vi gjorde os. Disse dokumenter var netop det, vi ønskede at få ud af at tilrette den traditionelle prototypingmodel. Specielt dokumenterne med forventninger til, og erfaringer med, brugersamarbejdet har været centrale i hver iteration 9. Efter hvert møde med hjemmeplejen vurderede vi, i forhold til de mål og forventninger vi havde nedfældet inden mødet, om der var noget, der overraskede os, eller om mødet forløb som forventet. Disse erfaringer blev så dokumenteret - præcis som modellen foreskrev. Idéen med at have et klart struktureret og grundigt udformet forventningsdokument var, at det så var nemmere at udlede erfaringer med brugersamarbejdet, da det ellers efter mødet med samarbejdspartnerne kunne være svært at huske, hvilke mere eller mindre eksplicitte forventninger man havde. Dette blev også bekræftet i forløbet. Det var nødvendigt, at forventningsdokumentet blev udformet i starten af hver iteration, da det ellers var problematisk at få skrevet erfaringerne i iterationen ned. Ved udarbejdelsen af forventningsdokumentet var der dog en tendens til, at det var svært at nedfælde præcise forventninger. De forventninger, man har, kan være udtalt i forskellig grad, og det kan være besværligt at præcisere dem. Vi havde ikke nogen decideret model eller skabelon for dokumentet, da vi mente, at det kunne variere fra iteration til iteration, hvad der ville være interessant at have med. Selvom en skabelon kan hjælpe med at huske, hvad der skal med, så kan den også virke hæmmende, da den gør det unødvendigt at overveje, hvad der er interessant i den enkelte situation. Som nævnt i afsnit var vores erfaringer ikke helt tilsvarende, hvad den modi- 9 Se bilag A, B, C, og D 62

65 5.5 Udviklingsmodellen ficerede udviklingsmodel foreskriver (se afsnit 3.2). Det viste sig i vores tilfælde, at være unødvendigt at have både brugerhistorier og systemspecifikation til at dokumentere kravene til systemet. Systemspecifikationen blev stort set ikke brugt eller ændret, efter den blev skrevet i første iteration. Årsagen hertil er nok, at brugerhistorierne i kombination med prototypen var tilstrækkelige til at fastholde kravene. Desuden er dette ikke et meget stort projekt, og vi har alle deltaget i møderne med samarbejdspartnerne og i udviklingen af systemet, og vi har derfor alle haft overblik over kravene til systemet og selve systemet. Brugerhistorierne var vigtige og nyttige for kommunikationen med samarbejdspartnerne - specielt i starten af udviklingsforløbet. Efter at den første prototype var blevet præsenteret, overtog den i høj grad brugerhistoriernes plads. En væsentlig grund til at dette skete er nok, at der ikke forekom særlig mange eller særlig store ændringer, med hensyn til de funktioner systemet skulle have. Det er muligt, at flere ændringer havde betydet, at vi skulle bruge brugerhistorierne længere hen i forløbet. Design og implementering foregik stort set som ønsket. Det var ikke hele tiden muligt at lave parprogrammering, bl.a. fordi vi er fem i gruppen, og fordi vi har forskellige niveauer af kunnen med hensyn til programmering. Der var en tendens til, at de dygtigste brugte noget tid på at hjælpe de mindre gode, og ind i mellem var der også nogle, der sad alene og programmerede. Vi lavede dog alt programmeringsarbejdet i grupperummet, dels fordi vi så kunne hjælpe hinanden, og dels fordi det ellers var svært at holde styr på, hvem der sad med hvad. Det fungerede godt at arbejde sammen om programmeringen på denne måde. Det har givet alle gruppemedlemmer et godt indblik i hvordan systemet er opbygget, og hvad der er muligt at lave - det har også været en fordel i samtalerne med vores samarbejdspartnere. Vi startede med at tegne brugergrænsefladen på computer og brugte denne første udgave til en evaluering af en papirprototype. På den måde kom vi hurtigt i gang med systemet og havde et grundlag at starte programmering af funktionerne på. De blev så tilføjet og udvidet i løbet af de næste iterationer. Vi havde lidt vanskeligheder med beregningerne i statistikdelen, som derfor blev implementeret sidst. Derfor fungerede det godt, at resten af systemet ellers var i orden, og vi dermed havde mulighed for at evaluere og teste det med vores samarbejdspartnere. Konklusionen på brugen af vores egen modificerede prototypemodel må være, at det ikke har været en hæmsko for os at skulle skrive forventnings- og erfaringsdokumenterne, og de har været meget brugbare under rapportskrivningen, da det ville være svært at huske, hvad der forventedes og erfaredes under hver iteration. 63

66 64 5. Erfaringer

67 6 Perspektivering Dette afsnit vil forsøge at sætte henholdsvis udviklingsarbejdet og resultatet af det ind i en større kontekst. Først diskuteres mulige fordele og ulemper ved at have valgt andre tilgange til dele af udviklingsprocessen. Dernæst gennemgåes overvejelser i forbindelse med etikken omkring det at udvikle et tidsregistreringssystem. Tilsidst reflekteres over, hvilke konskekvenser størrelsen og organiseringen af vores gruppe har haft på brugersamarbejdet. 6.1 Anderledes prioritering Her præsenteres overvejelser omkring valg, der er taget i løbet af udviklingsprocessen. Det overvejes, hvilke fordele og ulemper det kunne have medført, hvis der var foretaget en analyse af lignende systemer med henblik på at lære af dem. Derefter diskuteres mulige konsekvenser af samarbejdet med en lille kundegruppe, der bestod af to personer. Det overvejes, hvilken betydning det kunne have haft, hvis vi havde udviklet et standardtidsregistreringssystem, hvor gruppen af mulige brugere ville være meget større. Desuden overvejes, hvilke udfald det kunne have givet, hvis fokus i projektet havde været anderledes, og vi havde samarbejdet med en større del af organisationen med henblik på at videreudvikle dataindsamlingsmetoden. Herunder inddrages to interviews med henholdsvis en hjælper og lederen af tidsundersøgelsen Forbilleder Ved det indledende møde med hjemmeplejen i Løgstør Kommune gav de udtryk for, at der ikke allerede fandtes IT-systemer til tidsregistrering i hjemmeplejer. 65

68 6. Perspektivering Vi undersøgte ikke selv, om der forefindes lignende systemer, der kunne bruges som inspiration i vores udviklingsarbejde, da vi var mere fokuserede på at skulle udvikle et system fra bunden. Hvis der var foretaget en forbilledanalyse af andre systemer, der omhandler registrering af tid, kunne der muligvis have været draget nytte af de systemers gode og dårlige sider. Vi kunne f.eks. have analyseret et system, hvor timelønnede stempler ind og ud, når de går til og fra arbejde, så de kan lønnes for præcis den tid, de har været på arbejde. I det tilfælde at vi havde foretaget en forbilledanalyse, kunne det dog muligvis have hæmmet os i designet af vores system, og det havde krævet meget tid at sætte sig så godt ind i lignende systemer, at man kunne lære af deres fejl og fortrin. Desuden lægger det overordnede udviklingsparadigme ikke op til den omfattende foranalyse, som ville være nødvendig ved en forbilledanalyse Samarbejdspartnere I dette projekt kan antallet af samarbejdspartnere opfattes relativt, da det afhænger af, hvordan man opfatter udviklingsarbejdet og målet med det. Vi har haft kontakt med fem personer i hjemmeplejen, men det er kun to af dem, der har fulgt processen og har haft indflydelse på systemets udvikling. Som projektet udviklede sig blev fokus rettet mod at udvikle den del af systemet, som skal bruges i det administrative arbejde. Det medførte, at systemets anvendelsesområde blev indsnævret meget. Hvis vi havde samarbejdet med en større gruppe brugere, f.eks. ti eller derover, kunne der være opstået konflikter mellem forskellige personers ønsker til systemet. Vi overvejede, hvorvidt det ville være muligt at lave et standardsystem til hjemmeplejen i Løgstør, der også kunne anvendes af hjemmeplejer i andre kommuner. Hvis man skulle udvikle et standardsystem, ville det kræve stor indsigt i, hvordan et repræsentativt udsnit af hjemmeplejer er organiseret, og hvordan de fungerer i praksis. Man kunne forestille sig, at der ville være forskellige behov til et tidsregistreringssystem, og det ville kræve, at vi havde flere samarbejdspartnere. Vores system er bygget op omkring plejegrupper kaldet distrikter, men sådan er hjemmeplejer i andre kommuner ikke nødvendigvis organiseret. Hjemmeplejen i Løgstør Kommune er lille og forholdsvis nem at overskue, mens store kommuner måske kræver en helt anden tilgang til tidsregistreringssystemet. Det kunne f.eks. være en nødvendighed, at flere skulle kunne bruge systemet sideløbende. Store kommuners dataindsamling ville muligvis også foregå anderledes, end den gør i Løgstør Kommune, hvilket også vil have indflydelse på programmets udforming. En analyse af behov og organisering i andre kommuners hjemmeplejer ville af omfangsmæssige årsager ikke være mulig at foretage i dette projekt. At lave et system til brug i alle hjemmeplejer ville også introducere et problem med 66

69 6.1 Anderledes prioritering hensyn til analyse af brugergruppen og systemets brugervenlighed. Der vil være større usikkerhed omkring, hvem der skal bruge systemet, og det ville kræve, at vi samarbejdede med flere mulige brugere for at afdække usikkerhederne. I vores tilfælde arbejdede vi sammen med den person, der primært kommer til at bruge systemet, hvilket kan have gjort det nemmere at udvikle brugergrænsefladen. I dette projekt har to personer fulgt hele processen og fået deres ønsker til systemet opfyldt, da der ikke har været andre at tage hensyn til. Havde antallet af samarbejdspartnere været større, kunne det muligvis have medført konflikter i samarbejdet med os. Der kunne opstå fraktioner, som vi blev tvunget til at tage parti for, eller vi kunne af en eller anden årsag tage parti for én gruppe af kunderne frem for en anden. Der har ikke været nogle umiddelbare ulemper ved kun at samarbejde med to personer fra hjemmeplejen. Vi mener,dette skyldes,at lederen af undersøgelsen samt den primære bruger af systemet har været med under hele udviklingsforløbet. Det har været nemmere at forklare ting og nå frem til enighed med en gruppe på to frem for en større gruppe. Det er blevet overvejet, hvem der,udover personer i hjemmeplejen,kunne have en holdning til tidsregistreringssystemet. Det er muligt, at de kommunale politikere ville have en holdning til systemet - specielt statistikberegningsmetoderne. De kunne muligvis se en fordel i at få fremstillet dataene på en måde, som var mere hensigtsmæssig for dem end for selve hjemmeplejen. I dette tilfælde er det blevet overladt til Løgstør hjemmepleje selv at stå for undersøgelsen. Desuden er der heller ikke givet nogen entydige retningslinier, hverken kommunalt eller på landsplan, for hvordan sådan en undersøgelse skal udføres (kilde: Områdelederen i Løgstør Kommunale Hjemmepleje). Derfor er det begrænset, hvor meget indflydelse kommunalpolitikerne har haft på undersøgelsen, og det er hovedsageligt hjemmeplejen i Løgstør, der har kunnet sætte dagsordenen. Vi har derfor undgået at skulle tage stilling til en mulig konflikt mellem politikerne og hjemmeplejen, og det kan have gjort samarbejdet lettere, fordi vi har kunnet koncentrere os om deres ønsker Alternativt fokus på systemet Som nævnt i afgrænsningen (se afsnit 2.5) er projektet koncentreret om udvikling af et program til hjemmeplejen. Det er blevet fravalgt at bruge ressourcer på at videreudvikle dataindsamlingsmetoden eller komme med et andet forslag dertil. I dette afsnit diskuteres, hvilken betydning det kunne have haft, hvis dataindsamlingen også havde været en del af projektets fokus. Indsamlingen af data vedrørende hjælpernes tidsforbrug er tidligere foretaget ved, at hjælperne udfylder papirskemaer, og samarbejdspartnerne synes at foretrække at beholde denne mo- 67

70 6. Perspektivering del. Vi har med små rettelser direkte inkluderet de skemaer, som hjemmeplejen selv har udviklet, i systemet. Hvis der var fokuseret mere på dette område, kunne det måske have afdækket konflikter mellem ledelsen, hjælperne og borgerne. For at undersøge hvordan hjælperne havde reageret på registreringen af tidsforbruget afholdte vi henholdsvis et interview med en hjælper og lederen af undersøgelsen, som også har været vores samarbejdspartner gennem hele forløbet (se bilag H for interviews). Vi er opmærksomme på, at de to interviews ikke vil give et dækkende billede af hjælpernes indstilling til og erfaringer med tidsregistreringen. Denne ene hjælpers holdning vil ikke afspejle alle andre hjælperes holdning. Yderligere vil lederen af undersøgelsen muligvis være farvet af at se tidsregistreringen i et andet perspektiv end hjælpernes. Nedenunder gennemgåes interviewene grundigt, da der er flere interessante forhold med hensyn til forståelsen, af de holdninger og bevæggrunde der kommer til udtryk i disse. Interview med hjælper Formålet med interview af hjælperen er at afdække hendes holdning til tidsundersøgelsen, samt hvordan hun oplevede at skulle registrere sit tidsforbrug. Den interviewede hjælper arbejder 30 timer om ugen og har været ansat hos hjemmeplejen i Løgstør i ca. fem år. På undersøgelsens første dag brugte hun 20 minutter på at udfylde skemaet, de efterfølgende dage brugte hun 10 minutter. Betegnelserne for de forskellige tidstyper var ikke nogle, de normalt anvendte, men hun mente ikke, at det var problematisk at skelne imellem dem. Hun havde en lille notesbog, hvor hun noterede forbrugte minutter, og så regnede hun tallene sammen og udfyldte sit skema sidst på dagen. På den måde kunne hun også selv se, om tallene stemte. Det var efter hjælperens mening fint, at der var så mange forskellige tidstyper på skemaerne, for så kunne de - det vil sige lederne og politikerne - se hvad hjælperne brugte tiden til - underforstået at de ikke dovner. F.eks. skal der være tid til at cykle fra den ene borger hen til den næste. De uger, som undersøgelsen stod på, cyklede hun lidt langsommere end normalt. Dog syntes hun ikke, at hun var påvirket af tidsundersøgelsen; hun skyndte sig ikke mere end normalt. Hun tænkte ikke over, at andre gennemgik hendes tider, når de skulle registreres i systemet. Hun udtalte dog, at det ville være skrækkeligt, hvis undersøgelsen varede et par måneder. Adspurgt, om hun ville foretrække selv at registere tiderne i systemet, gav hun udtryk for, at det ville være smart, hvis hver hjælper selv tastede sine tider ind, så ville der ikke være så meget arbejde for den administrative medarbejder. Med hensyn til brugerskemaerne hos borgerne, hvor der i hjemmeplejens nuværende skema skal skrives minuttal, og vores forslag skal skrives start- og sluttids- 68

71 6.1 Anderledes prioritering punkt, foretrak hun ikke det ene frem for det andet. Det gjorde ikke nogen forskel, hvilke måde tidsforbruget skulle registreres, da hun altid har styr på, hvor lang tid hun har været hos en borger. Hun er alligevel altid opmærksom på at blive færdig inden for den normerede tid. Borgerne kunne mærke, at der var en undersøgelse i gang, og nogle af dem, hun besøgte, gav udtryk for bekymring. De troede, at det var en overvågning af hjælperne og var bange for, at der skulle blive skåret ned i den tid, de har ret til hjemmehjælp. Borgerne var ikke blevet informeret om undersøgelsen, og det var derfor op til hjælperne at berolige de bekymrede borgere. Overordnet forventede hjælperen, at undersøgelsen ville give et reelt billede af, hvordan tiden bruges generelt, og hun glædede sig til at se resultatet af undersøgelsen. Interview med leder af tidsundersøgelsen Formålet med interviewet af lederen af tidsundersøgelsen var at finde ud, hvilket indtryk hun havde af hjælpernes oplevelse af undersøgelsen. Desuden kunne det være interessant at finde ud af, hvordan hun havde forholdt sig overfor hjælperne undervejs, og hvordan hun havde forberedt dem på undersøgelsen. Lederen havde forventet en vis negativitet og dårlig stemning omkring undersøgelsen, for det viste erfaringerne fra undersøgelsen i Dengang følte hjælperne sig kontrollerede og styrede, og de følte, at de blev påbudt at udføre nye arbejdsopgaver. Den reaktion kan skyldes, at der dengang var begyndt at ske ændringer med hensyn til det administrative arbejde. Nogle administrationsopgaver blev lagt over på hjælperne, så papirarbejdet for hjælperne generelt blev øget. Erfaringerne med den nuværende undersøgelse var, at hjælperne fokuserede mindre på kontrol og overvågning end ved undersøgelsen i De var i stedet modvillige, fordi det ville blive besværligt, og de havde ikke lyst til at bruge tid på papirarbejde. Hun mener, at den mindre modvilje skyldtes, at hjælperne er blevet mere vant til papirarbejde, og derfor følte de det ikke så meget som overvågning. Det viste sig dog, at der var en tendens til, at der generelt var lidt mindre modstand mod undersøgelsen fra de yngre i forhold til de ældre. Lederen havde informeret alle grupperne hver for sig én gang inden undersøgelsen. Det kan, ifølge hende, have indvirket på deres indstilling til undersøgelsen, at de vidste, hvad den drejede sig om. Desuden mener hun, at det viser respekt og forståelse fra ledelsens side, at der er et felt på medarbejderskemaet, der hedder: Udfyldning skema. Der var dog problemer ved undersøgelsen. Nogle af skemaerne blev ikke udfyldt korrekt på grund af manglende forståelse. Nogen af hjælperne havde svært ved 69

72 6. Perspektivering at administrere tal og lave beregninger. Der var en tendens til, fravær ikke blev skrevet på skemaet. Lederen tror enten, at det skyldes, at hjælperne ikke ved, at de skal skrive fridage på, eller at de ikke kan lide at skrive fravær på. I fremtiden vil lederen sørge for at informere grupperne mere inden undersøgelsen går igang. Hun vil følge grupperne på tættere hold og håber på den måde at opfange eventuelle problemer tidligt i forløbet. Desuden vil hun lægge mere ansvar over på gruppelederne, hvilket også kræver bedre instruktion. Hun mener ikke, at det vil være en god idé, at hjælperne selv indtaster skemaerne, da det ikke er alle, der er lige fortrolige med at bruge computere, og det derfor kan give meget instruktionsarbejde. Samlet indtryk af holdning til tidsundersøgelsen Ved sammenligning af de to interviews ses der ikke store uoverensstemmelser mellem hjælperen og områdelederens opfattelse af, hvordan undersøgelsen er forløbet. I det hele taget var hjælperne lidt trætte af undersøgelsen, og enkelte følte sig overvåget. Den generelle stemning var, at undersøgelsen mest var til besvær for hjælperne, men at det var en fordel, at dem, der bestemmer er klar over, hvad tiden bliver brugt til - det mente både leder og hjælper. Stemningen var altså ikke direkte negativ, men den var heller ikke specielt positiv. Dette ville lederen forsøge at afhjælpe ved næste undersøgelse ved at være mere opmærksom og stå mere til rådighed for spørgsmål. Andet fokus med inddragelse af hjælperne Hvis fokus også havde ligget på udvikling af skemaerne - brugerskema og medarbejderskema (se bilag I) - skulle hjælperne have været inddraget i udviklingsprocessen. Det kunne have været en fordel, at hjælperne havde været involveret i processen, da det kunne gøre dem mere engagerede i undersøgelsen, og få dem til at føle sig mere ansvarlige overfor f.eks. at udfylde skemaerne korrekt. Det ville desuden give os føling med, hvor godt skemaerne fungerede, og om de kunne udformes bedre, så de var lettere for hjælperne at udfylde, og følelsen af overvågning var mindre. På den anden side kunne vores undersøgelse have forstyrret hjælpernes arbejde eller fået konflikter frem, som ledelsen ikke brød sig om. Eftersom vi kun har samarbejdet med to personer fra hjemmeplejen, kender vi ikke miljøet tilstrækkelig godt til at kunne sige, om det er en mulighed. Samarbejdspartnerne lagde dog ikke op til, at systemudviklingen skulle dække mere end udviklingen af et computerprogram. Fravalget af at have inddraget hjælperne betyder, at vi ikke har fundet ud af, om skemaerne har fået den bedst mulige form. Det betyder desuden, at hvis hjemmeplejen skulle ønske at ændre i skemaerne, så vil de ikke 70

73 6.1 Anderledes prioritering længere kunne anvende vores program, da det er opbygget ud fra skemaerne. Ved inddragelse af hjælpere i udviklingsprocessen kunne det få karakter af involvering af medarbejdere med henblik på at skabe en mere positiv holdning til tidsregistreringssystemet. I og med at udviklingsmetoden ikke direkte lægger op til, at man skal intervenere i den organisation, man samarbejder med, er dette ikke et område, vi har undersøgt nærmere. Det er heller ikke en tilgangsmåde, man som udvikler bare kan anvende, uden at det er ønsket af brugerorganisationen, da det kan medføre omfattende forandringer. Da holdningen til undersøgelsen ikke er udpræget positiv, og hjælperne ikke er meget engagerede, kunne en undersøgelse, der også går ind og arbejder med holdninger, organisation og arbejdsvaner, ændre nogle af disse ting. Det er muligt, at det på længere sigt vil være med til at ændre hjælpernes opfattelse af, at f.eks. undersøgelsen er blevet pålagt dem og bruges til at kontrollere deres arbejde. Det vil dog blive et helt andet projekt, hvis interventionsmetoden blev anvendt (se også afsnit 3.2). Det vil kræve stor fordybning i og forståelse for miljøet og arbejdsgangene i hjemmeplejen, men i forlængelse af de holdninger, der har været i forhold til undersøgelsen, kunne det være en interessant alternativ indgangsvinkel for udvikling af et tidsregistringssystem, forudsat at ledelsen i hjemmeplejen er interesseret Undersøgelsens indvirkning på resultaterne I dette afsnit fremsættes overvejelser omkring de mulige virkninger, selve tidsundersøgelsen kan have på resultaterne af samme undersøgelse. Hermed menes den indvirkning, som dataindsamlingsmetoden har på dataene. Hjælperne skal registrere deres tidsforbrug fordelt på 18 forskellige tidstyper, samtidig med at de skal arbejde som normalt og ikke lade deres egen holdning til tidsundersøgelsen få indflydelse på dataene. Det vil være urealistisk, at hjælperne ikke på nogen måde er påvirket af undersøgelsen eller har en holdning til den. Spørgsmålet er, hvor meget holdningen vil skinne igennem og påvirke registreringen af data. I interviewet med hjælperen (se afsnit 6.1.3) fortalte hun, at hun cyklede lidt langsommere i den tid, undersøgelsen stod på. Det tolker vi, som et forsøg på at øge køretiden en smule; at hun vil give sig selv en lille fordel, hvis undersøgelsen også bliver brugt til at optimere normeringerne. Hun vil forhindre at normeringerne ændres i en, for hende, uhensigtsmæssig retning. Det er muligt, at der også på andre punkter lempes en smule med tiderne. For andre hjælpere kan det muligvis være andre forhold, de opfatter som relevante, hvis de vil lempe med dataene. Det kunne være interessant at vide, hvor stor indflydelse fejlregistrering har på statistikkerne. Det kan både være som følge af forsøg på at lempe på data eller 71

74 6. Perspektivering som følge af forkert udfyldelse af skemaer. Lederen i hjemmeplejen mener ikke, at ubevidst fejlagtigt udfyldelse af skemaer vil have den store indflydelse på statistikkerne (kilde: Områdelederen i Løgstør Kommunes Hjemmepleje). Hjælperne vil sandsynligvis registrere tiderne under de rigtige tidskategorier, og derfor vil det ikke have den store indvirkning på statistikkerne. Så er spørgsmålet, i hvor høj grad hjælperne lemper på dataene. Den usikkerhed vil dog altid være tilstede, så den kan være svær at tage højde for. 6.2 Etiske aspekter Dette afsnit vil beskrive etiske overvejelser, der kan være relevante ved udviklingen af et tidsregistreringssystem. Med etiske overvejelser mener vi overvejelser omkring, hvad der er rigtigt og forkert at gøre i forbindelse med udviklingen af systemet. Er der nogle valg, vi har truffet i løbet af udviklingsprocessen, som ikke er etisk forsvarlige? Kan vi f.eks. forsvare rigtigheden i at udvikle et system til en organisation uden at overveje, om de eksisterende arbejdsgange kunne ændres til noget bedre? En del af den gruppe, som systemet kommer til at berøre, ignoreres og fastholdes i en praksis, uden at der stilles spørgsmålstegn ved den Tidsundersøgelsens mulige virkninger Tidsregistreringssystemet til hjemmeplejen kan have mange mulige brugere afhængig af, hvordan problemområdet opfattes og afgrænses. Ser man på hele tidsregistreringssystemet - ikke bare programmet - så berører det mange mennesker. Hjælperne skal udfylde skemaerne, og brugerne registrerer, at der er en eller anden undersøgelse igang. Derudover er der nogen, der skal varetage det administrative arbejde, der er før og efter undersøgelsen. Ingen af de grupper, der lige er nævnt - hjælpere, brugere, ledelse og administration - er begejstrerede for undersøgelsen (kilde: hjælper og samarbejdspartner). Hjemmeplejen har ikke selv taget initiativ til undersøgelsen, men skal lave den, fordi de er blevet pålagt af kommunen at prissætte hjemmehjælpen på grund af loven om fritvalgsordningen 1. Hjælperne, brugerne, ledelse og administration påvirkes forskelligt af undersøgelsen på grund af deres forskellige roller. Ledelsen skal bruge tid på at tilrettelægge og informere om undersøgelsen. Administrationen får ekstra arbejde med behandlingen af de data, der kommer ud af undersøgelsen. Hjælperne skal udfylde skemaer, så det i minutter kan ses, hvad de har brugt arbejdstiden til. Brugerne blev ikke informeret omkring undersøgelsen (se 6.1.3), og nogle blev bekymrede for, at

75 6.2 Etiske aspekter der ville blive skåret ned i den tid, de har ret til hjemmehjælp. Tidsundersøgelsen berører som sagt mange mennesker, men det er nok hjælperne, der påvirkes mest, da det er deres arbejde, der med hensyn til tidsforbrugets fordeling over alternative tidstyper, skal klargøres i detaljer. Lederen af undersøgelsen gav udtryk for, at hun fornemmede, at nogle følte sig kontrollerede og overvågede, når de skulle gøre rede for hvert minut, de er på arbejde. Hjælperen følte det ikke som en overvågning men syntes, at det var irriterende at skulle udfylde skemaerne. Der er forskel på, hvordan mennesker reagerer og opfatter sådan en undersøgelse. Det må dog have en indvirkning, at tiden pludselig gives ekstra meget opmærksomhed. Hjælperen sagde, at hun altid ved, hvor lang tid hun har været ved brugerne, fordi hun skal overholde normeringen. Den tid, hun er ved brugerne, er dog kun én ud af 18 forskellige tidstyper, der skal registreres. En sådan yderligere fokusering på tid må have nogle konsekvenser for hjælpernes opfattelse af arbejdsdagen. Spørgsmålet er, om det var korrekt af os som udviklergruppe at ignorere en mulig videreudvikling af dataindsamlingsteknikken. Hvis vi kunne have gjort noget for at mindske den mulige følelse af overvågning hos hjælperne, kunne det have mindsket den nok lidt dårlige stemning, der hersker omkring undersøgelsen. Det kunne muligvis have gjort følelsen af kontrol og undertrykkelse hos nogle af hjælperne mindre og dermed gjort deres arbejdsdage bedre. Problemet er bare, at skal såden en tidsundersøgelse gennemføres, så skal hjælpernes tid registreres, og hjælperne ved, at de bliver registreret. Hvordan kan man så gøre det på en bedre måde? Man kunne tage noget af ansvaret fra hjælperne, så deres forbrug af tid på en eller anden måde blev registreret, uden at de selv behøvede at gøre rede for minutterne. Man kunne forestille sig en elektronisk registrering, hvor hjælperne hver især har en PDA-lignende registreringsapparat, hvorpå hver tidstype har et nummer, og der er begynd- og slutknapper. Så kan hjælperne trykke et tidstypenummer og begynd, når de begynder på en aktivitet, og når de er færdige trykkes slut. På den måde vil de ikke selv vide noget om, hvor mange minutter de bruger på de forskellige tidstyper, medmindre de holder øje med uret. Spørgsmålet er så, om det vil være bedre, at hjælperne har mindre føling med resultatet af undersøgelsen. Der er risiko for, at det vil forstørre hjælpernes følelse af overvågning og kontrol, når noget af ansvaret fjernes fra dem, og de ikke selv ved, hvordan tiderne fordeler sig. Hvis undersøgelsen skal foretages vil det bedste nok være, at der forinden informeres grundigt omkring den, så der ikke opstår nogle misforståelser internt. Derudover vil det nok være bedst, at hjælperne har føling med undersøgelsen, ved at de selv registrerer deres tidsforbrug. 73

76 6. Perspektivering 6.3 Vores interne organiserings indvirkning på brugersamarbejdet I dette afsnit vil det blive overvejet, hvorvidt vores måde at arbejde sammen i gruppen direkte eller indirekte kan have haft en indvirkning på, hvordan brugersamarbejdet har forløbet. Vi har været fem personer i gruppen på dette projekt. Generelt har dette antal gruppemedlemmer været meget passende, og vi er ikke stødt ind i store problemer med samarbejdet undervejs. Det er dog en interessant overvejelse, om vores gnidningsfrie interne forløb kan have påvirket måden, hvorpå vi arbejdede sammen med samarbejdspartnerne i hjemmeplejen. Det kan overvejes, om noget så simpelt som gruppestørrelsen kan have haft en betydning for, hvilke valg vi foretog. Der er flere situationer i forløbet, hvor vi sandsynligvis ville have handlet anderledes, hvis vi havde været færre eller flere i gruppen. På samtlige møder med samarbejdspartnerne deltog alle fra gruppen, uden at vi overvejede det nærmere. Fem personer kunne lige være i én bil, og så passede det jo fint. Hvis ikke alle havde kunnet være i samme bil, ville det sandsynligvis have betydet, at vi skiftedes til at deltage i møderne, så nogle blev hjemme fra møderne. Dette kunne betyde, at samarbejdspartnerne ville føle, at de ikke havde et så nært samarbejde med os, da vi ikke ville være repræsenteret med de samme mødedeltagere hver gang. Et positivt aspekt, ved at være flere personer i gruppen, kan være, at udvælgelsen af de personer, som skal med til møderne, bliver mere bevidst. Når alle ikke kan være med, så bliver det måske i højere grad overvejet, hvilke personer der er brug for - hvem der har styrker inden for de relevante områder, og hvem der kan undværes på det pågældende møde. På den måde kunne en større gruppe fremtvinge grundigere overvejelser forinden møderne. Det kan dog have en negativ indvirkning på det interne samarbejde i gruppen, hvis nogen føler sig tilsidesat. Hvis man modsat tænker sig, at gruppen havde været mindre, så kunne det sandsynligvis også have betydning for mødernes forløb. F.eks. kunne man, ved planlægningen af en test, blive i tvivl om, hvorvidt man kunne få tilstrækkeligt med resultater på grund af et begrænset antal referenter. I det tilfælde ville man måske overveje at optage hele seancen på video. I vores forløb blev det overvejet, men ikke gennemført, at videooptage testene; efterfølgende viste det sig dog, at det kunne have været en god idé. Vores uproblematiske interne samarbejde havde nok ikke direkte nogen indvirkning på vores måde at tage forbindelse til og samarbejde med samarbejdspart- 74

77 6.3 Vores interne organiserings indvirkning på brugersamarbejdet nerne. Indirekte kan det dog have haft en betydning, da man som velfungerende gruppe har en række uskrevne regler og indforståede måder at kommunikere på. Disse ting er noget, man ikke tænker nærmere over i det daglige og derfor skal være særligt opmærksom på i andre samarbejdssituationer. Vi gjorde ikke brug af vores interne samarbejdsaftale undervejs i forløbet, da det ikke var nødvendigt at holde den i hævd. Dette betød måske også, at vi ikke overvejet at lave en skriftlig aftale med hjemmeplejen i Løgstør Kommune angående samarbejdet, da vi antog at mundtlige aftaler var lige så bindende - præcis som i det interne samarbejde. Det var heldigvis ikke af større betydning, da samarbejdspartnerne og vi selv for det meste havde en overensstemmende forståelse af samarbejdsaftalerne. I enkelte tilfælde blev de mundtlige aftaler dog fortolket forskelligt fra henholdsvis vores og deres side. For eksempel talte vi med samarbejdspartnerne om, hvem vi skulle kontakte angående den tekniske del af systeminstallationen, og de lovede, efter vores mening, at forberede teknikeren på, at vi ville tage kontakt til ham. Dette var dog ikke blevet gjort, og teknikeren blev derfor noget forvirret over vores henvendelse (se afsnit 5.1.3). Dette lille eksempel viser bare, at det ikke kræver meget, før et samarbejde kører skævt. 75

78 76 6. Perspektivering

79 7 Konklusion Formålet med dette projekt var at undersøge, hvordan man kan opnå et godt samarbejde med de kommende brugere i udviklingen af et computerbaseret tidsregistreringssystem til hjemmeplejen i Løgstør Kommune. Vi anvendte prototyping som udviklingsmodel og gennemgik fire iterationer udover foranalysen. Efter den fjerde iteration havde vi et system, der var færdigt til at aflevere til hjemmeplejen. Igennem forløbet med iterationerne lavede vi forsøg, med hensyn til forskellige måder at håndtere brugersamarbejdet på, for at se, om der var teknikker, der virkede bedre end andre eller var uhensigtsmæssige. Forsøgene indebar variationer af rollefordelinger, mødestrukturer, brugerhistorier og tests af systemet. Prototyping har understøttet vores brug af forsøg, som igen har understøttet aspekter ved brugersamarbejdet. Ligeledes har valget af prototyping som udviklingsparadigme betydet, at vi igennem de fire iterationer har udviklet et system, som kan anvendes af hjemmeplejen. Vi foretog en modificering af prototyping for at underbygge begge aspekter af projektet, henholdsvis brugersamarbejde og systemudvikling. Modificeringen betød, at der var mere dokumentation i vores model end normalt ved prototyping, men der blev ikke ændret på de egenskaber, som fremmer brugerinddragelse. Den større mængde dokumentation har underbygget den læringsproces, vi har været igennem i dette forløb, og prototyping som udviklingsparadigme har understøttet udviklingen af systemet. Ydermere har prototyping været med til at skabe et aktivt samarbejde med brugerne på grund af iterationsstrukturen. Vi inddrog brugerne under hver iteration for at indsamle information til udvikling af prototypen samt at gøre os erfaringer med brugersamarbejdet. Det har medført, at brugerne blev mere engagerede i samarbejdet, end hvis vi havde benyttet f.eks. konstruktion, da de i dette tilfælde ikke ville have haft samme grad af indflydelse undervejs. Forventnings- og erfaringsdokumenterne fungerede rigtig godt til at sammenholde 77

80 7. Konklusion de erfaringer, vi erhvervede med brugersamarbejdet gennem iterationerne. En bevidst rollefordeling og en formel mødeform egnede sig godt i brugersamarbejdet. Der var hele tiden styr på, hvilken information man havde fået, og hvad der stadig manglede at blive besvaret. Brugerhistorierne har fungeret som en aftale mellem os og vores samarbejdspartnere om, hvilke krav systemet skulle udfylde. Undervejs i forløbet blev prototyperne et supplement til brugerhistorierne, og de gav samarbejdspartnerne en visualisering af den ønskede funktionalitet. For at fastholde kravene til systemet over for os selv, ville vi anvende en systemspecifikation. Denne blev kun brugt i starten af udviklingsforløbet, hvilket skyldtes, at vi ikke havde problemer med fastholdelsen af af krav internt i gruppen, og den blev derfor ikke revideret. Dette havde ingen betydning for det endelige system. Til at vurdere systemet i samarbejde med brugerne anvendte vi tænke-højt testmetoden. Denne gav resultater, der var meget anvendelige ved systemudviklingen. Den interne kommunikation omkring testresultater fra dobbelttests fungerede dog ikke optimalt. Testreferaterne var ikke fyldestgørende nok til at formidle fuldstændigt, hvad der var sket under testen for dem, som ikke havde været til stede. En anden gang vil det være oplagt at bruge flere dataindsamlingsteknikker under testen - f.eks. videooptagelse. Igennem samarbejdet med brugerne er vi kommet frem til et brugbart system, som de er tilfredse med. Ligeledes har vi lært meget om inddragelse af brugere i systemudvikling, og har fået udbytte af at anvende forskellige metoder og sammenligne dem. Vi kan konkludere, at udviklingsmetoden og samarbejdsmetoderne har været velvalgte. 78

81 A Første iteration A.1 Mål for første iteration Målet med denne iteration er at udlede specifikke krav til systemet. Dette vil blive i form af brugerhistorier og en systemspecifikation, som skal fungere som dynamiske dokumenter i udviklingsprocessen. De overordnede krav, der fremkom under første møde med hjemmeplejen i Løgstør Kommune, skal uddybes med henblik på at få en klarere forståelse af, hvad systemet skal kunne, og hvordan systemet skal bygges. Uddybelsen af kravene til systemet skal foregå i samarbejde med vore samarbejdspartnere. Omdrejningspunktet i denne iteration bliver dermed dialogen med hjemmeplejen, da de bedst selv ved, hvad de ønsker af systemet. Vi skal derfor forberede os på et møde, hvor vi skal forsøge at få så meget relevant information som muligt ud af det. Iterationen vil munde ud i en revideret udgave af brugerhistorierne og systemspecifikationen. Herudover vil vi drøfte det kommende brugersamarbejde, herunder fremtidige møder. A.2 Overvejelser og forventninger Dette afsnit beskriver henholdsvis overvejelser omkring tilrettelæggelsen af, samt forventninger til iterationen. A.2.1 Overvejelser omkring brugersamarbejdet Da det er nødvendigt at få mere detaljeret information om krav til systemet, bl.a. omkring den ønskede funktionalitet i systemet, så afholdes et møde med områ- 79

82 A. Første iteration delederen og en administrativ medarbejder. De ved bedre end os, hvilke opgaver systemet skal understøtte, da de selv skal anvende systemet, og de har indblik i hjemmehjælpernes arbejde. Formålet med mødet er, at finde frem til hvilke opgaver hjemmeplejen ønsker understøttet af systemet. Dette vil vi diskutere på baggrund af vores idéer til systemets funktionalitet ved hjælp af brugerhistorier samt forskellige udkast til systemets brugergrænseflade. Herudover vil vi diskutere de to tidsskemaer for henholdsvis ATA-tid og indirekte brugertid. Diskussionen vil ligeledes tage udgangspunkt i forskellige udkast til disse skemaer. Disse udkast har til formål at fungere som et redskab til at fremme kommunikationen og mere præcist finde ud af, hvad hjemmeplejen ønsker, og hvad de har brug for. Vi skal så vidt muligt have en dialog med de to samarbejdsparter, der deltager på mødet, og vi må sørge for, at de inddrages i diskussionen, og at de forstår, hvad det er, vi forklarer. De skal opmuntres til at foreslå rettelser og give kritik. Vi vil opfordre dem til at være kreative, og tænke ud over de forslag vi har medbragt, da de, som før nævnt, ved mere om problemområdet, end vi gør, og derfor ikke bør begrænses af vores idéer. Mødet vil være åbent, og vi forventer derved, at vi vil få den information, som muliggør udviklingen af første prototype. Brugerhisorierne skrives i et naturligt sprog, og forslag til brugergrænseflade vises som håndtegnede papirprototyper. Det vil signalere, at de forskellige udkast er skitser, og at det derfor er nemt at indføre rettelser. Vi har en idé om, at vores samarbejdspartnere derved vil komme med flere forslag og rettelser til systemet, end de vil gøre ved brugen af et computergenereret udkast til systemets brugergrænseflade. Vi skal være så åbne som muligt overfor krav til systemet, men samtidig skal vi have noget at tage udgangspunkt i, og derfor viser vi forskellige forslag. Det kan desuden give samarbejdspartnerne en idé om, hvorvidt vores forståelse af problemområdet er korrekt. A.2.2 Forventninger til mødet Udover ønsket om en mere detaljeret forståelse, for hvilke funktioner systemet skal tilbyde, så er der under udarbejdelsen af forslag til brugerhistorier og papirprototyper opstået andre mere specifikke spørgsmål, som vi ønske besvaret. Det gælder generelt selve hjemmeplejens virkemåde og infrastruktur. A.2.3 Forventningsafstemning I dette brugersamarbejde har hjemmeplejen forventninger til os vedrørende det endelige produkt, men også til de forskellige møder vi afholder i løbet af udvik- 80

83 A.3 Erfaringsopsamling lingsfasen. Vi har ligeledes forventninger til dem, og da vi styrer udviklingsforløbet, ser vi det som vores opgave at skabe en forventningsafstemning for at nå til en enighed om vores fælles forventninger. Hertil sender vi til vores samarbejdspartnere et udkast til en samarbejdsplan, indeholdende de kommende møder vi ønsker at afholde med dem. Derudover sender vi en dagsorden for det kommende møde, for at informere om hvad selve mødet går ud på, og den vil vi tage op til diskussion. Derudover ses brugerhistorierne som et værktøj til at afstemme fælles forventninger med i forhold til systemet, da de beskriver de forskellige arbejdsopgaver, der skal kunne udføres ved hjælp af systemet. Vi vil forinden mødet sende disse brugerhistorier til samarbejdspartnerne, med en beskrivelse af hvad begrebet brugerhistorier dækker over, hvad de skal bruges til, og hvordan vores samarbejdspartnere skal forholde sig til dem. A.3 Erfaringsopsamling Vore samarbejdspartnere synes at forstå de forskellige brugerhistorier som dannede grundlag for en diskussion og specificering af, hvilken funktionalitet systemet skulle indeholde. Der var dog lidt usikkerhed omkring, hvorfor der var flere forslag til brugerhistorier, og vi ser denne usikkerhed som en mangel på forklaring fra vores side i den information vi sendte inden mødet. Det var dog ikke noget større problem, men det krævede lidt forklaring på selve mødet. Papirsprototyperne virkede, som vi havde forventet, og samarbejdspartnerne var i stand til at udpege, hvilket udkast de brød sig mest om samt hvilke rettelser, der skulle foretages. 81

84 82 A. Første iteration

85 B Anden iteration B.1 Mål for anden iteration Målet med denne iteration er at udarbejde en fuldstændig papirprototype af systemet til hjemmeplejen og efterfølgende få den vurderet af de kommende brugere. Det skal undersøges, om de krav og forventninger til systemet, der er fremkommet under det hidtidige samarbejde med brugerne, er tolket korrekt af os. Dermed skal papirprototypen, i en eller anden form for test, vurderes af brugerne. I forhold til mødet i forbindelse med første iteration, hvor vi havde mange spørgsmål, skal dette møde i stedet tjene som en undersøgelse af, om vi er på rette spor - om det er det rette system, vi er ved at udvikle. B.2 Overvejelser og forventninger Dette afsnit beskriver overvejelser i forbindelse med tilrettelæggelsen af, og forventninger til, denne iteration. Herunder overvejelser omkring udformning af papirprototype, testtype og udførelse af brugertest, tilrettelæggelse af møde med brugerne samt overvejelser omkring små eksperimenter i brugersamarbejdet. Derforuden beskriver vi, hvad vi ønsker at få ud af mødet. B.2.1 Papirprototypen I forhold til udbygningen af systemet resulterer denne iteration i en papirprototype, som har til formål at illustrere systemets funktionalitet og brugergrænseflade. Ved test af papirprototypen håber vi på at kunne fange de evt. mangler og 83

86 B. Anden iteration ændringer, der måtte være inden systemet implementeres. Ved større ændringer vil denne prototype spare tid, da det er lettere at ændre en papirprototype end at ændre systemkode. Desuden kan det muligvis være lettere for brugerne at foreslå ændringer til en papirprototype, da den ikke virker så færdig. Med hensyn til overvejelser omkring udseendet og udformningen af papirprototypen er der flere muligheder. Vi kan lave en håndtegnet papirprototype eller tegne og udprinte skærmbilleder, der ligner rigtige skærmbilleder. En håndtegnet papirprototype kan signalere, at udformingen af brugergrænsefladen endnu er på et meget tidligt stadie, mens udprintede skærmbilleder måske vil indikere, at designet af systemet er mere overvejet og længere fremskreden i processen. Det kan derfor muligvis være sværere for brugerne at kritisere designet af udprintede skærmbilleder, fordi de virker mere færdige. Ved at sætte brugerne ind i at det er skitser til systemet, og at det er nemt at ændre systemet efter deres ønsker, håber vi på at kunne forebygge den tilbageholdenhed, som de måtte have med hensyn til at komme med forslag til ændringer. Set fra det synspunkt at vi anvender prototyping som overordnet udviklingsmodel, fungerer prototyperne som et redskab til kommunikation med brugerne i hver iteration. Der bruges ikke meget tid på at fastlægge krav til systemet, før designet af systemet påbegyndes. Med baggrund i disse overvejelser vil vi vise udprintede skærmbilleder ved mødet. De udprintede skærmbilleder vil, i forhold til håndtegninger, desuden give samarbejdspartnerne et bedre billede af, hvordan systemet i sidste ende kommer til at se ud. Det aspekt vil vi komme yderligere ind på i afsnittet Forventningsafstemning. B.2.2 Samarbejdspartnernes vurdering af prototypen Mødet skal resultere i en vurdering af papirprototypen, hvor det ønskes, at så mange sider af systemet som muligt bedømmes. For at opnå denne detaljerede vurdering vil vi tilrettelægge en form for tænke-højt test, hvor testpersonerne skal løse nogle opgaver, som vi stiller. Det er ikke meningen, at det skal være en formel test, hvor testbrugeren ikke får nogen hjælp fra testlederen, da vi gerne vil have, at de spørger os, hvis der er noget, de er i tvivl om. Systemet er under udvikling, og vi kan have overset noget, hvilket testen har til formål at afsløre. Derfor vil vi gerne have en dialog med dem, hvis de har problemer med at løse en opgave. Ved mødet vil områdelederen og en administrativ medarbejder være til stede. Det er blevet overvejet, om de skal teste systemet sammen eller hver for sig. Hvis vi lader dem teste systemet hver for sig, så kan det vise et mere realistisk billede af en brugersituation, da det vil anskueliggøre de individuelle oplevelser med brugen af systemet. Det vil muligvis frembringe flere resultater, end hvis vi lader dem 84

87 B.2 Overvejelser og forventninger foretage testen sammen, hvor den enes oplevelse af systemet måske overskygges af den andens oplevelse af systemet. Ved at lade dem teste systemet sammen kan der fremkomme en dialog mellem de to testdeltagere om systemet, som vi kan uddrage nyttige oplysninger udfra. Det vil være nemmere for dem at tænke højt, da det falder mere naturligt, når de taler sammen. Samtidig vil det kræve, at vi skal være opmærksomme på, om de begge er aktive, så alle usikkerheder så vidt muligt opdages. Vi kunne godt tænke os at se, hvilke forskelle der vil være på en tænke højt-test, hvor brugerne sidder sammen, og en tilsvarende tænke højt-test hvor de to brugere sidder hver for sig. På dette møde vil vi teste en papirprototype, og på næste møde vil vi teste en implementeret del af systemet. Der er forskel på at sidde foran en skærm og at kigge på en papirprototype. Når de sidder foran en skærm, kan den person, som har musen i hånden, komme til at tage beslutninger, eksemplevis ved at klikke sig videre, som så muligvis ikke diskuteres, fordi man er kommet videre i programmet og står overfor en ny situation. Det kan fremme dialogen om systemet, hvis testdeltagerne sidder med en papirprototype, hvor de begge kan bruge deres pegefingre, og i højere grad er nødt til at blive enige om, hvad de skal gøre. Derfor synes vi, at det vil give størst udbytte at foretage en tænke højt-test, hvor de sidder sammen nu, i forhold til at vente. Desuden kan det opleves som mere trygt for testdeltagerne først at have prøvet at sidde sammen og foretage en tænke højt-test, før de skal gøre det hver for sig. B.2.3 Tilrettelæggelse af mødet Formålet med mødet er at få vurderet brugerhistorierne og papirsprototypen. Det forrige møde havde en meget åben struktur og lagde op til en samtale om systemet, og hvilke krav de havde til det. Det bundede blandt andet i, at vi havde så mange spørgsmål, vi skulle have besvaret. Vi vil tilrettelægge dette møde mere struktureret end det i forbindelse med 1. iteration, for at se om det gør en forskel set i forhold til det forrige møde. B.2.4 Eksperimenter i brugersamarbejdet Vi vil tilsende hjemmeplejen brugerhistorier, der er mere formelle og detaljerede end dem, vi gennemgik med dem på det forrige møde, og se hvordan de reagerer på dem. Med denne formalisering vil brugerhistorierne være mere overskuelige end de foregående. Vi ved ikke, om de over for vore samarbejdspartnere stadig repræsenterer det kommende systems opgaver, så vi vil tage dette op til fornyet diskussion på det kommende møde. 85

88 B. Anden iteration Derudover vil vi, som en del af det mere formelle møde, tildele hinanden ansvar gennem roller. Disse roller vil fungere som et værktøj til at fastholde mødets struktur, fordi vi hver især står for en del af mødet. Vi tror, at kvaliteten af mødet bliver forbedret, da hvert gruppemedlem kun behøver at koncentrere sig om sin egen rolle i stedet for hele mødeforløbet. Efterfølgende kan vi vurdere, hvad det betyder for vores egen aktivitet og fremtræden overfor hjemmeplejen. Derudover er tænke højt-testen en del af et eksperiment, der fuldføres ved næste iteration. B.2.5 Forventninger til brugersamarbejdet Det forventes, at denne iteration resulterer i en vurdering af brugergræsefladen og den dermed tilbudte funktionalitet. Derudover forventer vi, at eksperimentet med formelle brugerhistorier og det strukturerede møde giver nogle reaktioner fra vores samarbejdspartneres side. B.2.6 Forventningsafstemning Vi skal være opmærksomme på, at de ting vi fremviste, og det vi sagde på det forrige møde, gav hjemmeplejen nogle forventninger, som vi skal være opmærksomme på. På samme måde vil det kommende møde give dem nogle forventninger, som vi skal tage højde for i næste iteration. Det vil sige, at den prototype vi viser dem, vil give dem nogle forventninger om, hvordan det færdige system kommer til at se ud. For ikke at komme til at skuffe dem, vil det være en god idé at denne prototype og den implementerede prototype, hjemmeplejen kommer til at se til næste møde, ligner hinanden. Bland andet derfor er det valgt at vise papirprototypen som udprintede skærmbilleder. Vi vil ikke forberede hjemmeplejen på, at dette møde vil blive mere struktureret end sidste møde, da det muligvis vil få mødet til at fremtræde som et eksperiment. Vi tilsender dem i stedet en dagsorden, så de ved præcis, hvad der skal ske på mødet. Desuden tilsendes de mere formelle brugsmønstre, så de har tid til at læse dem inden mødet. B.3 Erfaringsopsamling Dette afsnit beskriver erfaringer fra mødet i forhold til de forventninger, vi havde. Først gennemgås, hvordan mødet foregik. Dernæst beskrives og vurderes specifikke aspekter af mødet og erfaringer i forbindelse hermed. 86

89 B.3 Erfaringsopsamling B.3.1 Faktiske forløb af mødet Der var to overordnede punkter på dagsordenen for mødet. Vi ønskede at få vurderet de mere formelt opstillede brugerhistorier samt at få testet papirprototypen. Vi havde forinden mødet sendt en mail til vore samarbejdspartnere for at forberede dem på, hvad der skulle ske på mødet. Vi begyndte med en introduktion, der uddybede dagsordenen en smule. Derforuden fortalte vi hvem af os, der ville gennemgå henholdsvis brugerhistorier og prototype. Vi startede med at gennemgå brugerhistorier, derefter testede vi prototypen, og så var det meningen, at vi efter testen ville forsøge at uddybe usikkerheder eller spørgsmål i forbindelse med testen af prototypen. Ved mødet vurderede vi dog, at det ville være mere hensigtsmæssigt at foretage denne uddybning under selve testen, når usikkerheden eller spørgsmålet opstod. Efter testen havde vi nogle få opklarende spørgsmål omkring systemet, og vore samarbejdspartnere havde nogle spørgsmål og forslag til systemet. Til sidst spurgte vi, hvordan de havde oplevet mødet. B.3.2 Formelle brugerhistorier Brugerhistorierne blev til dette møde præsenteret med de rettelser, der fremkom under sidste møde, og denne gang blev de fremstillet på en mere formel måde med beskrivelse af aktør, handling og resultat. Vi havde forventet, at de ville reagere på, at vi havde fremstillet brugerhistorierne meget formelt, men de reagerede ikke umiddelbart anderledes, end da de så de mindre formelle brugerhistorier. Først da vi spurgte dem, sagde de, at det var en meget overskuelig måde at opstille brugerhistorierne på, og den mere formelle fremstillingsmåde var nem at forstå. Derfor besluttede vi os for at beholde brugerhistorierne på denne form. B.3.3 Vurdering af brugergrænsefladen Det, der ovenfor er kaldt testen af prototypen, er en uformel undersøgelse af, hvorvidt designet af brugergrænsefladen lever op til samarbejdspartnernes forventninger, herunder om den tilbyder den rette funktionalitet, og om de kan finde ud af at bruge prototypen. Undersøgelsen forløb således, at de to testdeltagere blev stillet nogle opgaver, som de skulle løse ud fra papirprtotypen. De opfordredes til at sige alt, hvad der faldt dem ind under løsningen af opgaverne. Det blev understreget, at hvis de syntes, at noget ville fungere bedre, hvis det blev lavet anderledes, så skulle de endelig sige det, for det ville være nemt for os at lave det om. Mens de løste opgaverne, talte de sammen og spurgte os om det, de ikke umiddelbart forstod. Testen var uformel, og begge samarbejdspartnere var gode til at forholde sig kritisk til prototypen. De gav udtryk for tvivl, foreslog ændringer og kom med 87

90 B. Anden iteration nye overvejelser omkring funktionalitet. Bortset fra nogle småting var de meget tilfredse med designet af brugergrænsefladen. B.3.4 Det mere strukturerede møde Dette møde havde et klart mål for, hvad vi ville have ud af det. Vi havde tildelt hinanden roller inden mødet, planlagt hvordan vi skulle sidde i forhold til samarbejdspartnerne og havde en mere detaljeret dagsorden end på de foregående møder. Disse tiltag skulle lægge op til et mere stuktureret møde. Vi spurgte om, hvordan de havde opfattet mødet, men de gav ikke indtryk af, at de var påvirket i hverken positiv eller negativ retning i forhold til det sidste mindre strukturerede møde. Vi uddybede ikke diskussionen, da det kunne give mødet en forsøgspræget karakter, som vi ikke ønskede, at de skulle bemærke. Vi kunne dog selv mærke en forskel ved, at mødet blev afholdt på en struktureret måde. Vi havde bedre føling med, hvorvidt vi fik afdækket de aspekter, vi manglede for at kunne udvikle systemet. En anden grund til at strukturen på dette møde virkede bedre er, at vi havde mange opklarende spørgsmål på forrige møde, og der opstod samtidig nye spørgsmål, hvilket gav det forrige møde en mere ustruktureret karakter. På baggrund af disse aspekter vil vi fastholde den strukturerede mødeform på næste møde. Det betyder også vi vil beholde rollebegrebet, som vi havde på dette møde, og det vil være nødvendigt på det kommende møde, da vi skal afholde tænke-højt test med hver af de to samarbejdspartnere. 88

91 C Tredje iteration C.1 Mål for tredje iteration Målet med tredje iteration er at udvikle en kørende prototype. Denne skal udvikles ud fra den papirprototype, vi viste vore samarbejdspartnere på det sidste besøg. Den kørende prototype vil blive vurderet på et møde med dem, for at undersøge om systemet svarer til deres forventninger. Dette vil komme til at foregå igennem en test af systemet, som samarbejdspartnerne foretager. C.2 Overvejelser og forventninger Dette afsnit beskriver de overvejelser, vi har haft i henhold til denne iteration og de forventninger, der er kommet ud af disse overvejelser. Herunder beskrives forventningerne til den kørende prototype og overvejelser om, hvordan testen af denne skal foregå. Der vil også blive beskrevet, hvordan mødet angående den kørende prototype vil komme til at forløbe, og hvad vi ønsker at få ud af dette. C.2.1 Den tredje prototype På baggrund af papirprototypen fra sidste iteration vil vi bygge systemet op med hensyntagen til de rettelser, der fremkom på mødet, hvor den blev præsenteret. Dette vil resultere i en kørende prototype, som samarbejdspartnerne vil kunne prøve på en computer. Den vil i udseende komme til at være så identisk med papirprototypen som muligt. Dette vil medføre, at de kan genkende systemets virkemåde og ikke skal til at lære noget nyt at kende. 89

92 C. Tredje iteration C.2.2 Samarbejdspartnernes vurdering af prototypen Prototypen skal vurderes på et møde med vore samarbejdspartnere. Der vil blive lagt vægt på funktioner, korrekthed og brugervenlighed. Testen vil blive tilrettelagt som en tænke-højt test udfra nogle opgaver. Samarbejdspartnerne vil blive testet hver for sig, og de to testdeltagere vil være vores samarbejdspartnere. I forhold til sidste prototypetest vil denne tage en mere formel indgangsvinkel, og meningen er, at vi vil køre testen og tage eventuelle spørgsmål og diskussion bagefter som en opsamling. Dette vil stå i modsætning til den måde, vi greb det an på sidste iteration. Testen vil foregå ved, at testdeltagerne bliver placeret i hver sit rum med en computer, hvorpå systemet kører. De vil blive bedt om at udføre nogle relevante opgaver og om at tænke højt, mens de udfører dem. Da testen således vil blive mere formel, skal vi være klar over, at vi skal bruge flere resourcer på at få registreret og dokumenteret vanskeligheder, som testdeltageren kan have undervejs. Vi skal også være forberedte på, at testdeltageren måske ikke er så villig til at tænke højt alene som i sidste iteration, hvor testen udførtes som et samarbejde mellem to personer. C.2.3 Tilrettelæggelse af mødet Ved dette møde starter vi med at tale om brugerhistorierne, da der er kommet flere til i takt med, at systemet implementeres. Derefter foretages testen af systemet, hvorefter vi samler op på erfaringer i forbindelse med testen. Til sidst fremlægges et forslag til, hvordan statistik kan vises i MSexcel. Da målet med dette møde primært er at få testet vores kørende prototype, vil det foregå meget formelt. Vi vil sætte samarbejdspartnerne ind i, hvordan testen kommer til at foregå, og forklare dem hvad formålet er med den. Efter testen vil der blive mulighed for begge testdeltagere til at komme med deres syn på, hvordan de oplevede testen, både med hensyn til systemet og selve oplevelsen at afprøve systemet på den måde. Vi vil dog arrangere, at der ikke kommer diskussion ind under testen af systemet, som det var tilfældet sidste gang. C.2.4 Eksperimenter i brugersamarbejdet De eksperimenter der kommer til at indå i denne iterations brugersamarbejde, er at gøre testen mere formel, at bytte de roller om som blev givet til sidste møde og test af hver testdeltager for sig. En del af det er også at se, hvordan de forholder sig 90

93 C.3 Erfaringsopsamling til systemet på en skærm, fremfor papir som sidste gang. Sidste gang blev rollerne fordelt, så vi udnyttede det gruppens medlemmer var gode til hver især. Denne gang vil vi forsøge at gøre rollerne til en udfordring ved at bytte helt om på dem, og se hvad vi får ud af det. C.2.5 Forventninger til brugersamarbejdet Forventningerne til dette møde bunder i ønsket om at få et færdigt system klar til den fjerde iteration. Vi forventer at få respons på den kørende prototype, og vi forventer, at den mere formelle måde at teste systemet på giver os nogle reaktioner fra vore samarbejdspartnere, som vi kan se på i forhold til sidste prototypetest. C.2.6 Forventningsafstemning Sidste iteration gav samarbejdspartnerne nogle forventninger om, hvordan systemet kommer til at se ud, og hvilke funktioner det skal have. Vi har valgt at lave den tredje prototype så identisk med papirprototypen som muligt, og på den måde indfrier vi en af de forventninger, de har til systemet. Med denne iteration vil vi komme til at give dem forventninger om et færdigt system, og det skal vi være klar over for at kunne holde deres og vores forventninger i den samme højde. Til denne iteration vil vi sende en dagsorden og en kort beskrivelse af testforløbet til vore samarbejdspartnere. C.3 Erfaringsopsamling Dette afsnit beskriver de erfaringer, der er erhvervet i forbindelse med mødet med vore samarbejdspartnere i tredje iteration. Mødet havde til formål at teste den del af systemet, som var implementeret - det vil sige hele programmet bortset fra den del, hvor statistikkerne vises. Først beskrives, hvordan mødet faktisk forløb, derefter behandles specifikke aspekter af mødet, og resultaterne fra testene fremstilles. Slutteligt beskrives, hvilke forventninger, vi tror, samarbejdspartnerne har til det næste møde. Mødets forløb Mødet startede ca. en halv time senere, end det var aftalt. Dels på grund af forsinkelse fra vores side, og dels på grund af at den ene af de to samarbejdspartnere 91

94 C. Tredje iteration var forsinket. Desuden var vi nødt til at bruge tid på at få styr på tekniske problemer, da alle endelig var til stede. Det gjorde, at mødet blev rodet og ustruktureret i begyndelsen. Vi startede med at fortælle, hvad der skulle foregå på mødet. Først spurgte vi, om der var nogle kommentarer til de nye brugerhistorier, som de havde fået tilsendt i forvejen. De gjorde opmærksom på, at vi havde brugt nogle forkerte betegnelser, men havde ikke flere indvendinger. Derefter gav vi en samlet introduktion til testen, hvor vi forklarede, hvad formålet var, hvad de skulle gøre og så videre. Dernæst delte vi os i to grupper, da testen skulle foretages i to forskellige rum. Testene havde karakter af en tænke-højt test, hvor testdeltagerne fik tildelt nogle opgaver, som de skulle løse, mens der blev tænkt højt. Til hver test var der en testleder og henholdsvis en og to referenter. Resultaterne af testen beskrives nedenfor. Efter testene samledes vi igen i det ene rum, og vi fremlagde - på en computerskærm - forslag til statistikvisninger, hvilket satte en samtale igang om, hvilke udregninger, der er interessante for vore samarbejdspartnere. Overvejelser omkring mødets forløb Dette afsnit indeholder overvejelser omkring specifikke aspekter af mødet, som kan være interessante i forbindelse med brugersamarbejdet, f.eks. vores egen tolkning af mødet og overvejelser omkring den fremtidige planlægning af næste møde. Konsekvenser af forsinkelsen Vi var forsinket til mødet. Vi måtte ringe og fortælle vores samarbejdspartner, at vi kom et kvarter for sent. Det var i orden med dem, da den ene af dem sad i et andet møde og derved også var forsinket. Ved ankomsten måtte vi skynde os at få den ene af de computere, der skulle testes på, gjort klar da vi havde haft nogle tekniske vanskeligheder. Det tog yderligere 20 minutter så vi blev 35 minutter forsinket med testen ialt. Vores ene samarbejdspartner ventede de 35 minutter med os inde i lokalet og havde fået at vide, at vi havde nogle tekniske problemer, vi skulle have løst, før vi kunne teste. Den anden samarbejdspartner ventede 5-10 minutter på os, og så gik vi igang. Den ene testdeltager virkede meget forvirret og stresset i starten af testen. Det kunne have noget at gøre med, at både hun og vi var forsinket og at stemningen blev lidt stresset på grund af tiden. Den første testdeltager gav sig ikke så god tid til at læse og tænke over opgaverne, det virkede som om, de bare skulle overståes så hurtigt som muligt. Dette kan skyldes, at vi var blevet så forsinkede. Det kan fremkalde et ønske hos testdeltagerne om at blive hurtigt færdige for at indhente 92

95 C.3 Erfaringsopsamling noget af den tid, der gik tabt, og derfor skynder de sig gennem opgaverne uden at tænke over, hvad de bliver bedt om. Det kan også være tiden slet ikke har noget med det at gøre, men at det bare var en unarturlig situation, de befandt sig i, og helst ville være fri for så hurtigt som muligt. Den anden testdeltager tog det hele lidt mere roligt, men gav sig ikke så god tid til at tænke over opgaverne, der blev stillet. Det kan være stressende at blive sat foran en computer, man ikke er vant til, og skulle bruge den i forbindelse med en test hvor man bliver overvåget og ens fejl skrives ned. Det giver et pres, som de umuligt kan opfylde, og det hjælper ikke på deres stressniveau, at de kan opfatte situationen som en eksamen af deres evner med en computer, som den ene testdeltager gav udtryk for. Ligeledes kan de være bange for, at vi vil sammenligne deres resultater i forhold til hinanden og bedømme den ene til at være dårligere end den anden til at bruge både en computer og vores specifikke system. I tolkningen af resultaterne er vi nødt til at tage hensyn til, at testpersonerne skyndte sig igennem opgaverne, at den ene virkede stresset og at de kunne have opfattet testen som en eksamen af dem selv og deres brug af en computer. Test hver for sig kontra samlet test I forhold til testen sidste gang, hvor vi testede samlet, var der mere usikkerhed og stress denne gang. Da vi testede samlet virkede de mere sikre og mindre pressede. De oplysninger, vi fik fra testen, var nogenlunde det samme for begge testpersoner, det var de samme problemer, de løb ind i. Nogle af problemerne var måske ikke opstået, hvis de havde snakket om dem ved en samlet test. Her kan man trække tilfældet sammentælling af valgte frem. Ved denne knap havde de sandsynligves snakket om, hvad de mente den gjorde og var kommet i tanker, om hvad de fandt ud af på sidste møde. Det, der skete denne gang, var, at de helt havde glemt den, og de brugte den ikke, som det var meningen, eller som det de kom frem til ved diskussion af den ved sidste mødes test. Da gruppen også blev delt i 2, var det vigtigt at få formidlet resultaterne for begge tests til hinanden. Vi gjorde det ved at fortælle hinanden på et møde om de to tests, og derefter ved at skrive fyldige referater ind som viste forløbet under hver test. Andre overvejelser Vi havde forventet at holde et formelt møde, og dermed også afholde en formel test. Mødet blev ikke så formelt, som vi havde håbet på, derimod var der en del forvirring i starten, og vi lagde rodet ud. Testen forløb dog meget formelt, og en 93

96 C. Tredje iteration af grundene til dette kunne være, at vi hver især havde en rolle, som vi havde forberedt i god tid hjemmefra, så her var vi forberedt. I forhold til forrige møde havde vi denne gang forsøgt at uddele roller, ikke efter gruppens individuelle styrker, men efter det at alle skulle prøve de forskellige roller. Det var derfor ikke de vante testleder- eller referent-roller, vi havde fordelt. Det havde ikke nogen stor betydning for deltagerne på mødet, de kunne hurtigt omstille sig til en ny mødeleder i forhold til det sidste møde. For os selv betød det, at vi alle fik prøvet nye ting, og det var en positiv oplevelse, da det ikke gav anledning til nogen problemer. Det gik ganske godt med at skifte rollerne om på den måde. Ved fremlæggelsen af forslag til statistikvisning var det kun to gruppemedlemmer, der kunne deltage aktivt i samtalen, da vi fremviste forslagene på en computer. Vi skulle måske istedet have vist diagrammerne på papir, så alle kunne følge med, og man kunne kigge på flere forskellige diagrammer samtidigt. Det ville give anledning til mindre forvirring, for så kunne man bladre gennem papirerne, og de administrative medarbejdere kunne selv sidde med dem. Resultater fra testen Testen forløb overordnet set fint. Der var en stresset atmosfære, men opgaverne blev løst uden de store problemer. Begge testdeltagere kom med forslag til ændringer og forbedringer, og de fandt enkelte fejl i systemet. Overraskelser Sidste gang talte vi om knappen Vis sammentælling af valgte, og der var forståelse for, hvad den gjorde. Under testen havde begge testpersoner en forkert - og forskellig - opfattelse af knappens funktion. Hvad skal vi tænke på næste gang? Til det næste møde med vore samarbejdspartnere vil de forvente et færdigt system. De forventer, at det kan installeres den dag på deres system, og at de har mulighed for at bruge det derefter. Vi skal derfor bestræbe os på at gøre det færdigt, og det skal undersøges, om vi kan få det installeret engang efter mødet. Dette er dog forudsat, der ikke dukker nogen kristiske fejl op under testen. Det er også vigtigt til næste gang, at have gennemført pilot test på begge de maskiner vi skal have med, for at undgå de tekniske problemer der opstod denne gang. 94

97 D Fjerde iteration D.1 Mål for fjerde iteration Målet med denne iteration er at rette de fejl og problemer, der blev fundet under testen og mødet i tredje iteration, samt implementere muligheden for at generere filer, der kan vises i MS Excel. Det færdige system skal vurderes ved hjælp af en tænke-højt test foretaget med to testdeltagere. I denne iteration vil vi desuden undersøge, hvordan en hjælper har oplevet at udfylde skemaerne i undersøgelsesperioden. D.2 Overvejelser og forventninger Dette afsnit beskriver de overvejelser, vi har haft i forbindelse med denne iteration og de forventninger, der er kommet ud af disse overvejelser. Herunder beskrives forventningerne til det færdige system og overvejelser om hvordan testen af dette skal foregå. Der vil også blive beskrevet, hvordan mødet angående vurderingen af systemet vil komme til at forløbe, og hvad vi ønsker at få ud af dette. D.2.1 Det endelige system Det endelige system vil i de fleste henseender ligne den først implementerede prototype. De ændringer som skal implementeres drejer sig om forståelsesmæssige fejl i systemets brugergrænseflade, samt mindre funktionelle fejl og mangler. Herudover vil statistikdelen af systemet være implementeret, hvorfra det er muligt at få vist statistikker i form af forskellige typer diagrammer gennem MS Excel. 95

98 D. Fjerde iteration D.2.2 Vore Samarbejdspartneres vurdering af prototypen Det færdige system skal vurderes på et møde med samarbejdspartnerne. Der vil blive lagt vægt på funktionalitet, korrekthed og brugervenlighed. Testen vil blive tilrettelagt som en tænke-højt test, udfra nogle opgaver som illustrerer realistiske arbejdssituationer. De to testdeltagere skal teste systemet hver for sig. Den ene kender systemet, da vedkommende har været med i hele udviklingsforløbet, og har en begrænset praktisk erfaring med systemet, hun anvendte det under testen i forrige iteration. Den anden testdeltager er ikke blevet introduceret til systemet før, men vedkommende kender systemets eksistens og formål. Formålet med testen er dels at finde ud af om systemets brugergrænseflade fungerer efter hensigten, både med kendte og ukendte testdeltagere, samt evt. at foretage en sammenligning mellem de to testdeltageres reaktioner. D.2.3 Tilrettelæggelse af mødet Ved dette møde skal vi teste det færdige system med to forskellige testdeltagere. Derudover skal vi tale med en hjælper, om hvordan vedkommende har oplevet at udfylde skemaer under undersøgelsen. Det vil vi gøre, fordi vi er interesseret i dette aspekt, men ikke har gået nærmere ind på det i starten af projektet, da det passede tidsmæssigt dårligt med det undersøgelsesforløb, som hjemmeplejen befandt sig midt i. Testen skal foretages på samme måde som sidste gang. Denne gang skal vi være grundigt forberedte og have alt på plads til testen, så vi ikke bliver forsinkede ligesom sidste gang. Det skal overvejes, om vi skal optage testen på video, da vi på grund af to tests sidste gang måtte dele gruppen op. Det har gjort det sværere at formidle testens forløb til den anden halvdel af gruppen. Det negative ved brugen af videooptagelser kan være, at det kan gøre testdeltagerne mere usikre. Det er aftalt med områdelederen, at vi kan komme til at snakke med en hjælper i ca. 30 min. Dette skal sandsynligvis foregå samtidig med testene, alt efter hvornår hjælperen har tid. Det skal helst foregå i et separat lokale, for at undgå at hjælperen bliver påvirket af at andre hører på. Sidste del af mødet vil blive en samtale om forventningerne til systemet og implementeringen af det. 96

99 D.3 Erfaringsopsamling D.2.4 Interview med hjælper Under denne iteration vil vi afholde et interview med en hjælper i hjemmeplejen. Vi forventer, at dette vil give os nogle nye måder at se på organisationen og tidsundersøgelsen på. Vi forventer, at der vil være en forskel mellem den måde hjælperen opfatter undersøgelsen på, og den måde lederen af undersøgelsen opfatter hjælpernes holdninger til den på. Det vil vi undersøge ved at stille dem de samme spørgsmål, og derefter se om der er markante forskelle. D.2.5 Eksperimenter i brugersamarbejdet Vi vil denne gang fortsat arbejde med en formel fremgangsmåde. Denne gang med den forskel, at vi er forberedt så godt som muligt, og har styr på så meget som muligt, i forhold til forrige gang. Hver person i gruppen bliver tildelt roller i forhold til deres styrker. D.2.6 Forventninger til brugersamarbejdet Forventningerne til dette møde er, at vi skal være grundigere forberedt, så vi har mest muligt styr på, hvad der skal foregå. Det vil forhåbentligt give et roligere møde end forrige møde. D.2.7 Forventningsafstemning Det er vores indtryk at hjemmeplejen har store forventninger, med hensyn til hvor godt systemet kommer til at virke, samt at det snart kan implementeres. Vi bør sandsynligvis talemed dem om til mødet, hvor meget de præcist kan forvente og hvornår. Der bliver sendt en dagsorden for mødet til vore samarbejdspartnere, samt et oplæg til de to interviews. Desuden vil vi lave et brev til den plejer, som vi skal tale med, så hun er lidt forberedt på interviewet. D.3 Erfaringsopsamling Dette afsnit beskriver de erfaringer, der er erhvervet i forbindelse med mødet i fjerde iteration. Mødets formål var at få testet systemet, så eventuelle problemer 97

100 D. Fjerde iteration kan blive rettet, inden vi overdrager systemet til hjemmeplejen og vore samarbejdspartnere. Ydermere ønskede vi at afholde to interviews: et med vores samarbejdspartner, der har stået for den indeværende undersøgelse, og et med en hjælper. Disse interviews skal afdække, hvordan hjælperne forholdt sig til undersøgelsen. Først beskrives mødets forløb, derefter behandles specifikke aspekter af mødet, og resultaterne fra testene fremstilles. D.3.1 Mødets forløb Mødet startede til tiden, og begge testdeltagere var klar, da vi kom. Den ene testdeltager gik ind i et rum med to af os for at lave testen af systemet der. De andre blev i det andet rum for at udføre testen med den anden testdeltager. Den første testdeltager gennemgik testen og da hun var færdig, skulle hun gå. Den anden testdeltager og vi satte os ned for at snakke om hvilke erfaringer, der havde været med skemaerne ude i hjemmeplejen. Samtalen forløb godt og et stykke inde i forløbet kom den hjælper, vi havde bedt om at måtte mødes med. To af os gik ud for at snakke med hende, og det blev et meget vellykket interview med en god respons fra hende om skemaerne og deres påvirkning på medarbejderne i hjemmeplejen. I forhold til det sidste møde, der blev holdt med hjemmeplejen, var dette meget mere struktureret og formelt, som vi havde ønsket os det. D.3.2 Overvejelser omkring mødets forløb Dette afsnit indeholder overvejelser omkring specifikke aspekter af mødet, som kan være interessante i forbindelse med brugersamarbejdet. Testen med en testdeltager, der ikke har været involveret i udviklingen af systemet Den første testdeltager havde ikke set systemet før og havde ikke, som den anden, været med i udviklingen af det. Hun er superbruger af windows/msoffice applikationer i hjemmeplejen, og det betyder blandt andet, hun hjælper, når der er noget andre ikke kan finde ud af med en computer. Hun havde ikke ret mange problemer i testen, og hun var god til at komme med forslag, som hun mente ville gøre systemet mere brugervenligt. Hun fangede hurtigt ideen i, hvordan det var bygget op og havde kun meget få problemer med at bruge det korrekt. Dette kan have noget at gøre med, at hun er superbruger. Hun er vant til at skulle overskue et program og sætte sig ind i det for at hjælpe andre med det. Hun har også den fordel, at hun kender meget til hjemmeplejen og kender deres opbygning. Det hjælper hende til 98

101 D.3 Erfaringsopsamling at forstå opbygningen af systemet, da denne tager udgangspunkt i hjemmeplejens opbygning. Havde det været en testdeltager med de samme kvalifikationer, bortset fra kendskabet til hjemmeplejen, kunne dette have givet et helt nyt billede af, hvordan systemet kan opfattes. Testopgaver skrevet som cases Forrige test havde nogle meget korte og enkelt beskrevne opgaver. Der var ingen baggrund for udførelsen af en opgave, og det kan have virket forvirrende på testdeltagerne. Derfor forsøgte vi denne gang at lave nogle opgaver, som var beskrevet med noget kontekst, og dermed en slags begrundelse for at udføre opgaven. Vi forventede, det ville få testdeltagerne til lettere at sætte sig ind i tankegangen og hjælpe med til, at de ikke skulle føle at situationen var alt for kunstig. Opgaverne forsøgte vi at få til at afspejle en hverdags handling, som den kunne se ud med systemet implementeret. Det gik ganske udmærket, og i forhold til sidste gang var der mindre misforståelser, med hensyn til hvad opgaven gik ud på. Det var, som om opgaverne var lettere for dem at sætte sig ind i, da der var en historie bag dem. Andre overvejelser Vi havde forventet, at mødet skulle være formelt og dermed også testen. Disse forventninger blev opfyldt i langt højere grad end på sidste møde. Testene forløb formelt, med et par enkelte små undtagelser, hvor en referent sagde noget. Mødet i sig selv blev også, som vi havde forventet, formelt, og der var styr over, hvem der stillede spørgsmålene, og hvem der tog referat af hvad. En af grundene til at det denne gang kunne forløbe så formelt, kan have noget at gøre med, at vi denne gang havde lagt en hel del mere forberedelse i mødet og dets opbygning. Vi havde uddelt roller, som vi hver især var ansvarlige for, og der var lagt mere arbejde i mødets og testenes struktur og opbygning denne gang. Denne gang var rollerne uddelt efter styrker som på mødet i anden iteration, og det kan have noget at sige, da testdeltagerne fra starten af kunne have låst os fast i de roller og derfor have vænnet sig til at snakke med de to, der snakkede meget på de første par møder. D.3.3 Resultater fra testen Der var kun små problemer i testen, og det havde mest at gøre med brugen af tab og lignende. Der var stadig problemer med forståelsen Sammentælling af valgte under statisik. Vi har ikke kunnet få forslag til forbedringer fra testdeltagerne, og vi har i samarbejde med hjemmeplejen vurderet, at det er bedst at beholde 99

102 D. Fjerde iteration opsætningen, som den er, da det giver de fleste muligheder for at vælge forskellige statistikvisninger. Problemet bliver så en ting, der må læres, når man arbejder med systemet, og vi har vurderet, at da der kun vil være få brugere af systemet, skal der ikke rettes mere ved det. Ellers viste testen i øvrigt, at systemets brugergrænseflade er brugervenlig og forståelig. Der dukkede enkelte mindre ting op, som bliver rettet inden aflevering af programmet. D.3.4 Interview med hjælper Interviewet med hjælperen gav som forventet et nyt syn på tidsundersøgelsen. Hun gav udtryk for nogen ting, vi ikke tidligere havde været klar over, og der var enkelte af hendes svar, der var overraskende. For eksempel blev vi lidt overraskede over, at hun cyklede en smule langsommere, i den periode undersøgelsen foregik, for at gøre opmærksom på at det tog tid at komme frem og tilbage mellem borgerne. En anden overraskende ting var, at borgerne havde givet udtryk for, at de var nervøse for, om undersøgelsen kunne betyde, at der blev skåret i hjemmehjælpen. D.3.5 Interview med lederen af tidsundersøgelsen Interviewet forløb fint, og der blev givet udtryk for, at hjælperne ikke synes det var helt så forfærdeligt at lave undersøgelsen denne gang, som det var i 97. Hun kom med forskellige bud på, hvorfor hun mente det var sådan, og vi fik et godt sammenligningsgrundlag ud af de to interviews. D.3.6 Overraskelser Midt i forløbet af den sidste iteration sendte vi en mail til teknikeren i kommunen for at høre efter, hvorledes vi kunne få arrangeret installationen af systemet. Vi hørte ikke noget fra ham, men pludselig fik vi en mail fra vores vejleder, som gennem andre kilder havde fået respons fra teknikeren. Han havde sine forbehold, og vi skrev en længere og forklarende mail tilbage til ham. Han svarede os og påpegede de steder, hvor han havde sine forbehold og, hvori problemerne lå i forhold til installationen. Vi var lidt overraskede over, at han tilsyneladende ikke vidste noget om, at vi havde lavet et system til hjemmeplejen og skulle have det installeret - det var det, vi havde forventet efter at have talt med områdelederen. Efter at have talt med hende om installationsmulighederne ville hun tage initiativ til at sørge for at de i samarbejde med teknikerne fandt ud af, hvad der var muligt. 100

103 D.3 Erfaringsopsamling D.3.7 Hvad skal vi tænke på nu? Før vi overdrager systemet til hjemmeplejen skal et par enkelte ting rettes til. Vore samarbejdspartnere forventer, det kan blive installeret meget snart, og inden da skal vi have snakket noget mere med teknikeren i hjemmeplejen. Kan det ikke lade sig gøre at installere på serveren, skal vi have arrangeret, at det bliver installeret på en af de stationære computere. Det endte så med, at systemet skal installeres lokalt på den administrative medarbejders computer. 101

104 102 D. Fjerde iteration

105 E Brugerhistorier E.1 Første iteration E.1.1 Registrer tid i skemaer Hjælper registrerer ATA-tid hos klienten Forslag 1 En hjælper besøger en klient og registrerer klokkeslettet for ankomst i skemaet, der ligger hos klenten. Når vedkommende går, registreres klokkeslettet på skemaet. Forslag 2 En hjælper ankommer til klientens hjem og ordner de ting, der skal ordnes, når vedkommende er færdig registreres hvor mange minutter, der er tilbragt i hjemmet. Hjælper registrerer indirekte brugertid Forslag 1 Hjælperen har skemaet med sig rundt hele dagen. Når vedkommende har udført en aktivitet, f.eks. været til møde eller holdt pause, skrives det antal minutter, som er brugt, ind i skemaet ud for den rette dag og aktivitetstype. Forslag 2 De aktiviteter der kun bliver udført en gang om dagen, f.eks. morgenmøde, udfyldes med antal minutter, når aktiviteten er overstået, eller når det passer hjælperen bedst. De aktiviteter, der udføres flere gange om dagen, f.eks. pauser, skrives ind med antal minutter før hjælperen går hjem. 103

106 E. Brugerhistorier E.1.2 Opret plejegrupper i systemet En administrativ medarbejder opretter plejegrupper i systemet Forslag 1 En administrativ medarbejder vælger at oprette personer i systemet. Vedkommende skal først indtaste navnene og initialerne på hjælperne i systemet, og når dette er gjort sammensætte plejegrupperne ved at udvælge personer fra en liste. Plejegruppen gemmes og efter indtastning af tidsregistreringerne, kan der laves statistik for plejegruppen. Forslag 2 En administrativ medarbejder vælger at oprette plejegrupper i systemet. Vedkommende indtaster navnet (til identifikation) på plejegruppen og kan herefter tilføje personer til plejegruppen. Personerne skal tilføjes med navn og initialer. Når plejegruppen er komplet gemmes den, og der kan senere hentes statistik frem for den. E.1.3 Indtastning af data i systemet Data fra undersøgelsen skal tastes ind (Klient skema) Forslag 1 En administrativ medarbejder sidder med to bunker skemaer, fordelt efter plejegrupper. Den ene bunke består af skemaer ude fra klienternes hjem, og den anden af hjælpernes individuelle skemaer. Medarbejderen vil indtaste skemaerne for klienterne først. Vedkommende vælger denne funktion i programmet, og går derefter i gang med at indtaste oplysninger for den første plejegruppe i bunken. Forslag 2 En administrativ medarbejder vælger at indtaste klientskemaer i systemet. Vedkommende tager det første skema fra bunken og har et identisk skema på skærmen, dog ikke udfyldt. Oplysningerne tastes ind i samme rækkefølge som de er skrevet på papiret, og programmet inddeler selv oplysningerne i plejegrupper. Data fra undersøgelsen skal tastes ind (Hjælpers skema) Forslag 1 En administrativ medarbejder vælger at indtaste hjælper-skemaer i systemet. På skærmen har vedkommende et skema magen til det som hjælperne har udfyldt. Skemaet på skærmen udfyldes fra en ende af og efter endt ind- 104

107 E.1 Første iteration tastning startes på det næste skema. Systemet inddeler selv indtastningerne i plejegrupper. Forslag 2 De skemaer den administrative medarbejder har, er manuelt inddelt efter plejegrupper på forhånd. Vedkommende starter med indtastningen for den plejegruppe, hvis skemaer er øverst i bunken, og afslutter med den sidste. E.1.4 Statistik ud fra indtastninger En administrativ medarbejder vil gerne se statistik udfra indtastninger: Forslag 1 Efter den administrative medarbejder har tastet oplysningerne fra skemaet ind i systemet, vil vedkommende gerne se noget statistik over det. Vedkommende er interesseret i at se den samlede ATA-tid for hele hjemmeplejen, så i systemet vælges at se statistik for alle plejegrupper og alle tider i systemet. Vedkommende beder om at få det vist i et diagram, og systemet laver et diagram over den valgte statistik. Forslag 2 Efter indtastning vil den administrative medarbejder gerne se noget statistik. Vedkommende udvælger i systemet hvilke tider og for hvilke plejegrupper, der skal laves statistik, og det udvalgte vises i et Excel-genereret diagram. Forslag 3 Efter indtastning kan den administrative medarbejder vælge mellem forskellige former for statistik som systemet tilbyder. Vedkommende kan se grafer/diagrammer for helt bestemte data. Personer indenfor hjemmeplejen vil gerne se noget statistik: Forslag 1 En hjælper (eller en med lignende rettigheder i systemet) vil gerne se noget statistik. Denne person har i systemet mulighed for at se en vis mængde foruddefineret statistik. Forslag 2 En hjælper vil gerne se statistik og kan uden begrænsninger bruge systemet, til at se den statistik vedkommende finder interessant. Forslag 3 En hjælper er interesseret i at se noget bestemt statistik, men har ikke selv rettigheder til at bruge systemet. Vedkommende skal derfor tage kontakt til en administrativ medarbejder og bede denne om det ønskede materiale. 105

108 E. Brugerhistorier Personer udenfor hjemmeplejen, f.eks. fra kommunen, vil se statistik for den nyligt gennemgåede undersøgelse. Forslag 1 En leder vil gerne se statistik for hjemmeplejen. Denne beder hjemmeplejen om nogle nøgletal og diagrammer over den undersøgelse hjemmeplejen har været igennem. Lederen skal ikke selv bruge systemet til at finde de ønskede tal, vedkommende skal bare bede om det, der er brug for. Forslag 2 En leder udenfor hjemmeplejen har adgang til en del af systemet. Denne udvælger selv de statistikker, vedkommende ønsker at se, baseret på de begrænsede muligheder systemet giver. Forslag 3 En leder udenfor hjemmeplejen har samme adgang til systemet som de administrative medarbejdere og kan frit vælge hvilke statistikker, denne vil se. E.1.5 Mulige statistiske udtræk fra systemet - se statistik for en bestemt plejegruppe i forhold til det samlede resultat - statistik for den samlede indtastning - udvælgelse af bestemte tider - statistik uden fravær E.2 Endelig version E.2.1 Skema for ATA-tid Registrering af brugernavn og nummer Aktør Handling Resultat Administrativ medarbejder eller distriktleder. Brugernavn og distriktnavn skrives på skemaet. Et fortløbende nummer påføres hvert skema. Brugernavn og nummer er registreret på skemaet. 106

109 E.2 Endelig version Registrering af ATA-tid Aktør Handling Resultat Hjælper. Ved ankomst til og afgang fra en bruger noteres de aktuelleklokkeslet og initialer i ATA-skemaet, som ligger hos brugeren. Tidspunktet for ankomst og afgang og aktørens initialer er noteret i skemaet. E.2.2 Skema for indirekte brugertid Registrering af navn på hjælper Aktør Handling Resultat Hjælper. Aktøren skriver sit navn på skemaet. Aktørens navn er noteret på skemaet. Registrering af aktiviteter der kun udføres en gang om dagen Aktør Handling Resultat Hjælper. Aktøren registrerer det forbrugte antal minutter for aktiviteten i det relevante felt i skemaet. Det forbrugte antal minutter er registreret. Registrering af aktiviteter der udføres flere gange om dagen Aktør Handling Resultat Hjælper. Aktøren registrerer forbrugte minutter på kladdepapir. Før aktøren afslutter sin arbejdsdag, tælles de forskellige tider sammen og indføres i skemaet. Det forbrugte antal minutter er registreret. E.2.3 Opret, rediger og slet undersøgelse i systemet Opret undersøgelse Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger Opret ny undersøgelse i systemet. Aktøren noterer navnet på undersøgelsen. Undersøgelsen gemmes. Undersøgelsen er oprettet med navn. 107

110 E. Brugerhistorier Rediger navnet på en undersøgelse Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger en undersøgelse og derefter Rediger undersøgelsens navn i systemet. Aktøren ændrer navnet på undersøgelsen. Undersøgelsen gemmes. Undersøgelsens navn er redigeret. Slet en undersøgelse Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger en undersøgelse. Herefter vælges Slet undersøgelse i systemet. Aktøren bekræfter sletningen. Undersøgelsen er slettet. E.2.4 Opret og rediger distrikt i systemet Opret distrikt Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger en undersøgelse og derefter Vælg undersøgelse. Herefter vælges Distrikter og medarbejdere og Opret distrikt i systemet. Aktøren noterer distriktnavnet, de medarbejdere, der er tilknyttet distriktet, samt antallet af brugere i distriktet, i de relevante felter. Distriktet gemmes. Distriktet er oprettet med navn, tilknyttede hjælpere og brugere. Rediger distrikt Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger det distrikt, der skal redigeres og vælger Rediger distrikt. De relevante oplysninger rettes og gemmes. Distriktet gemmes med de rettede oplysninger. 108

111 E.2 Endelig version E.2.5 Indtastning af data i systemet Indtastning af data i medarbejderskema Aktør Handling Resultat Administrativ medarbejder. Skemaerne er sorteret efter distrikt. Aktøren vælger Tidsregistrering i systemet, vælger derefter Medarbejderskema, vælger det relevante distrikt og medarbejder og taster oplysningerne ind. Skemaet gemmes. Oplysningerne fra papirskemaet er gemt i systemet. Indtastning af data i brugerskema Aktør Handling Resultat Administrativ medarbejder. Papirskemaerne er sorteret efter distrikt. Aktøren vælger Tidsregistrering i systemet, vælger derefter Brugerskema, distrikt og skemanummer og taster oplysningerne ind. Skemaet gemmes. Oplysningerne fra papirskemaet er gemt i systemet. E.2.6 Statistik Valg af tal og generering af statistik Aktør Handling Resultat Administrativ medarbejder. Aktøren vælger Statistik. De relevante tidstyper og distrikter, for hvilke man ønsker at vise statistik, vælges og statistikkombinationen gemmes som en MS Excel fil. En MS Excel fil, der indeholder en bestemt kombination af tal for tidstyper og distrikter. Visning af statistik Aktør Handling Resultat Administrativ medarbejder. Aktøren åbner gemte statistikkombinationer i MS Excel og vælger hvilken type diagram det skal vises som. MS Excel diagram. 109

112 110 E. Brugerhistorier

113 F.1 Installation og opsætning F Manual For at installere systemet overføres mappen Tidsregistreringssystem fra den medfølgende CD-rom til det sted man ønsker systemet placeret (f.eks. C:M ProgrammerM Tidsregistreringssystem ). Der skal være installeret MS Excel, MySql og oprettet en database på den computer systemet skal installeres på 1. Installationen af MySql udføres som foreskrevet i dokumentationen som følger med MySql. Efter installationen oprettes databasen ved at åbne en kommandopromt, hvorefter der navigeres til mappen bin under MySql installationen (f.eks.: C:M mysqlm binm ). Herefter skrives kommandoen: mysql Herved vil man kunne oprette en database ved at skrive: create database atalogstor; For at afslutte MySql skrives: exit Der skal nu oprettes tabeller i databasen, hvilket gøres ved at importere en skabelon for databasen. I dette eksempel antages at tidsregistreringssystemet er installeret under C:M ProgrammerM TidsregistreringssystemM. For at anvende skabelonen skrives: 1 MySql kan hentes gratis på 111

114 F. Manual mysql atalogstor < C:N ProgrammerN TidsregistreringssystemN skabelon.txt Luk herefter kommandopromten. For opsætning af systemet åbnes filen config, som er at finde i mappen hvor systemet er installeret (f.eks. C:M ProgrammerM TidsregistreringssystemM ), via programmet Notepad eller en anden teksteditor. Her skal adressen på databasen sættes op, samt brugernavn og adgangskode. Dette gøres på følgende måde: $server = <Adresse på serveren, f.eks.: localhost> $user = <Brugernavn til serveren> $password = <Adgangskode til serveren> Man kan i visse tilfælde undlade at angive brugernavn og adgangskode. Systemet er nu klar til brug. For at anvende det køres filen Tidsregisteringssystem.exe som ligger i mappen, hvor systemet er installeret (f.eks. C:M ProgrammerM TidsregistreringssystemM ). F.2 Brug af tidsregistreringssystem Denne afsnit er tænkt som et opslagsværk ved brug af tisdregistreringssystemet. Her beskrives først hver af systemets vinduer, herunder vinduets muligheder og funktionalitet. Efterfølgende er der eksempler på løsninger til forskellige opgavetyper, som ønskes udført ved hjælp af systemet. Gennem manualen refereres der til billeder af systemet, som er at finde i afsnit F.3. F.2.1 Hovedvindue - ATA-system Løgstør Kommune Hovedvinduet fremkommer ved start af systemet, og herfra er det muligt at anvende en allerede oprettet undersøgelse samt at oprette en ny undersøgelse (se figur F.1). En undersøgelse skal forstås som skallen udenom det data, der indtastes i forbindelse med en undersøgelse. Herved kan man via systemet generere statistikker for en igangværende undersøgelse eller en afsluttet undersøgelse. Systemet kan indeholde flere undersøgelser på en gang. Man kan fra hovedvinduet oprette, vælge eller slette en undersøgelse, samt redigere navnet på en undersøgelse. For at vælge, redigere eller slette en undersøgelse skal den ønskede undersøgelse markeres på listen, der indeholder oprettede undersøgelser. Hvis man vælger at gå videre i systemet med en valgt undersøgelse, fremkommer vinduet Administration af undersøgelse. 112

115 F.2 Brug af tidsregistreringssystem F.2.2 Administration af undersøgelse Dette vindue indeholder muligheder for at registrere tid for medarbejdere og brugere i distrikter (se figur F.3). Før man kan registrere tid for en medarbejder eller en bruger, skal disse være oprettet i et distrikt. Fra dette vindue kan man vælge at gå videre til Distrikter og medarbejdere, Tidsregistrering, Statistik samt Gå tilbage til hovedmenu. F.2.3 Administration af distrikter I dette vindue vises til venstre en liste af distrikter oprettet i systemet for den pågældende undersøgelse (se figur F.4). Listen i midten viser en liste af medarbejdere for det markerede distrikt. Fra dette vindue kan man oprette, redigere og slette distrikter. Oprettelse og redigering af distrikter, medarbejdere og brugere foregår i samme vindue. F.2.4 Oprettelse eller redigering af distrikter Ved valg af Opret nyt distrikt eller Rediger distrikt fremkommer et vindue, hvorfra det er muligt at imdtaste et navn på distriktet, antallet af brugere i distriktet og navne på medarbejdere i distriktet (se figur F.5). Ved valg af Rediger distrikt kan man redigere navnet på distriktet, antallet af brugere samt navne på medarbejdere ved at ændre de data, der står i de respektive felter. F.2.5 Indtastning / Tidsregistrering Ved valg af Tidsregistrering er det muligt at taste oplysninger fra skemaerne ind i systemet. Før dette kan gøres skal distrikter samt antal brugere i disse og medarbejdere være oprettet. Der er to slags skemaindtastningsmuligheder. Den ene er for medarbejderskemaer (se figur F.6), den anden er for brugerskemaer (se figur F.7). De vælges ved at klikke på fanebladene øverst i vinduet. F.2.6 Generering af statistik Ved valg af Statistik er der mulighed for at sammensætte statistikker efter behov. Dette er kun muligt, hvis der er indtastet data i den valgte undersøgelse. Statistikker kan sammensættes af forskellige tidstyper: direkte brugertid (ATA), indirekte brugertid, organiserings- og planlægningstid samt fravær (se figur F.8). 113

116 F. Manual For hver af disse tidstyper, undtagen direkte brugertid, er det muligt at generere en detaljeret visning, hvor hver tidstype inden for de tre kategorier bliver vist i den genererede statistik. Kategorierne kan også sammentælles ved markering af Sammentæl valgte, hvorved kategorien vil blive vist som en samlet postering i statistikken. Efter valget af tidstyper i statistikken skal der vælges hvilke distrikter, der skal indgå i statistikken. Her kan man vælge distrikterne hver for sig, hvorved de vil have hver sin postering i statistikken. Det er også muligt at vælge gennemsnit af, eller en sammentælling over, tiden for de forskellige distrikter. Disse kan kombineres efter ønske. For at generere statistikken skal den først gemmes, dette gøres ved at vælge Gem som..., hvorefter der fremkommer en standard Gem som eller Save as dialogboks (se figur F.9). Her vælges et filnavn efter eget ønske, hvorefter filen gemmes. Filen kan nu åbnes i MS Excel. F.2.7 Eksempler Her kan du finde eksempler på opgaveløsninger på alt fra oprettelse af en undersøgelse til generering af statistikker. Opgaveløsningerne vil kunne bruges som udgangspunkt ved daglig brug af systemet, og det fremgår desuden, hvilke input systemet godtager. Hovedvindue - ATA-system Løgstør Kommune Opgave: 1. Vil du oprette en ny undersøgelse? 2. Vil du slette en undersøgelse? 3. Vil du redigere undersøgelsens navn? 4. Vil du gå videre med den markerede undersøgelse? 5. Vil du afslutte brugen af systemet? 1. Opret ny undersøgelse Tryk Opret ny undersøgelse fra hovedvinduet. Herefter fremkommer vinduet Oprettelse af undersøgelse (se figur F.2). Indtast navnet på den undersøgelse du vil oprette - Eksempelvis ATA-Undersøgelse forår Tryk 114

117 F.2 Brug af tidsregistreringssystem på Gem for at gemme undersøgelsen eller tryk på Annuller for at gå tilbage til hovedmenuen uden at gemme. 2. Slet undersøgelse Marker den undersøgelse du vil slette og tryk på Slet undersøgelse. Svar Ja i boksen, der dukker op, hvis du virkelig vil slette undersøgelsen, tryk Nej hvis du ikke vil slette alligevel. 3. Rediger undersøgelsens navn Marker den undersøgelse, hvis navn skal redigeres, og tryk på Rediger undersøgelsens navn. Ret så navnet på undersøgelsen i boksen og tryk Gem for at gemme eller Annuller for ikke at gemme og gå tilbage til hovedmenuen. 4. Vælg undersøgelse Marker den undersøgelse du vil gå videre med og tryk på Vælg undersøgelse. Du vil blive ledt videre til vinduet Administration af undersøgelse, hvorfra du kan administrere den valgte undersøgelse. 5. Afslut Tryk på Afslut for at lukke programmet. Administration af undersøgelse Opgave: 1. Vil du administrere (oprette, redigere, slette) distrikter og medarbejdere? 2. Vil du registrere tidsskemaer i systemet? 3. Vil du vælge statistik og se visninger af dette? 4. Vil du tilbage til hovedmenuen? 1. Distrikter og medarbejdere Klik på Distrikter og medarbejdere for at komme til vinduet Administration af distrikter hvorfra du kan oprette, slette og redigere distrikter med tilhørende medarbejdere. 2. Tidsregistrering Klik Tidsregistrering for at registrere tid fra skemaer i systemet. De distrikter og medarbejdere, du vil indtaste skemaer for, skal dog være oprettet først. Du vil blive ledt videre til vinduet Indtastning. 115

118 F. Manual 3. Statistik Klik her hvis du ønsker at generere og gemme en statistik. Du vil blive ledt videre til vinduet Statistik. 4. Gå tilbage til hovedmenu Tryk Gå tilbage til hovedmenu for at gå tilbage til hovedmenuen hvorfra du kan vælge en ny undersøgelse, rette navnet, oprette en ny undersøgelse, slette en undersøgelse og afslutte systemet. Administration af distrikter Opgave: 1. Vil du oprette et nyt distrikt? 2. Vil du redigere et eksisterende distrikt? 3. Vil du slette et distrikt? 4. Vil du forlade dette vindue og gå tilbage? 1. Opret nyt distrikt For at oprette et distrikt i systemet skal du trykke på Opret nyt distrikt. Du vil blive ledt videre til vinduet Opret nyt distrikt hvor du skal udfylde det nye distriktsnavn i det øverste felt (se figur F.5). Antallet af brugere i distriktet skal tastes ind i det næste felt, og navnene på de medarbejdere, der er i distriktet, føres ind i listen under felterne. Tryk på Gem når du er færdig og vil gemme, eller tryk på Annuller for at lukke vinduet uden at gemme. 2. Rediger distrikt For at redigere et eksisterende distrikt skal du markere dette i listen af distrikter og vælge Rediger distrikt. Du bliver så ledt videre til vinduet Rediger distrikt, hvor du i det øverste felt kan rette navnet på distriktet. Du kan også ændre på antallet af brugere og på navnene på medarbejderne i distriktet. Hvis en medarbejder ønskes slettet fra listen, skal dennes navn blot rettes til et tomt felt, så er den slettet. Det betyder dog også at al tid for denne medarbejder i dette distrikt går tabt. Når distriktet ser ud som det skal og er redigeret færdigt afsluttes med "Gem"for at gemme eller "Annuller"for at for at forlade vinduet uden at gemme eventuelle ændringer. 116

119 F.2 Brug af tidsregistreringssystem 3. Slet distrikt Tryk på Slet distrikt for at slette det markerede distrikt. En dialogboks vil dukke op, og du skal svare Ja, hvis du virkelig ønsker at slette distriktet og det data, der hører til det (medarbejder og deres tidsregistrering). Tryk Nej hvis du ikke vil slette distriktet alligevel. 4. Luk vindue Hvis du vil lukke vinduet, hvor du administrerer distrikter, skal du vælge Luk vindue. Du vil blive ledt tilbage til vinduet Administration af undersøgelse. Indtastning / Tidsregistrering 1. Medarbejderskema Når medarbejderskemaet er valgt, kan du begynde indtastning af skemadata ved at vælge hvilket distrikt medarbejderen tilhører. Dette gøres ved at vælge distriktet i listen under fanebladene (se figur F.6). Når et distrikt er valgt, kan en medarbejder vælges i listen til højre for distrikt listen. Alle medarbejdere registreret i det valgte distrikt vil blive vist i listen. Når medarbejderen også er valgt, kan man begynde at føre tiden fra medarbejderens skema ind. Tiderne ned til og med Udfyldning af skema indføres i minutter, resten indføres i timer. Når en medarbejders skema i systemet er udfyldt trykkes Gem for at gemme skemaet. Trykker man på Slet skema slettes det skema, der er vist, og man skal vælge distrikt og medarbejder forfra. For at vende tilbage til Administration af undersøgelse trykkes på Afslut indtastning. Man vil man se dialogboksen Data ikke gemt, hvis der er rettelser i skemaet, som ikke er blevet gemt. For at gemme disse trykkes Nej for at vende tilbage til skemaindtastningen. Herfra trykkes på Gem skema, hvorefter det er muligt at afslutte. Hvis man ikke ønsker at gemme data fra skemaet, trykkes der Ja i dialogboksen. 2. Brugerskema Skal du indtaste tid fra brugerskemaer vælges Brugerskema i fanebladet øverst i vinduet Indtastning / Tidsregistrering. Der skal vælges et distrikt i listen, for hvilket der skal tastes skemaer ind for. Ligeledes skal et skemanummer vælges i listen til højre. Skemanumrene går fra 1 til antallet af brugere i distriktet. Det er valgfrit, om man vil indtaste navnet på brugeren, det fungerer kun som en ekstra sikkerhed for, at det er den rette brugers skema, man sidder med. Dette vil have mest relevans, hvis man vil ind og redigere en brugers skema. Når distrikt og skemanummer er valgt, kan indtastning begyndes. Starttid angives som et klokkeslæt, og man kan taste ind 117

120 F. Manual på flere forskellige måder: 12:45, 12.45, 1245 og 12,45. Når skemaet er udfyldt trykkes Gem skema for at gemme. Trykkes på Slet skema slettes alle tal fra det pågældende skema. For at afslutte indtastning af tid og gå tilbage til Administration af undersøgelse trykkes på Afslut indtastning. Hvis der er data i skemaet, som ikke er gemt, vil man se samme dialogboks som i medarbejdserskemaet. Generering af statistik Opgave: 1. Vil du generere en statistik for et distrikt med sammentælling af de respektive tidskategorier? 2. Vil du generere en statistik for et distrikt med en udspecificering af de respektive tidskategorier? 3. Vil du generere en statistik over det samlede tidsforbrug for den valgte undersøgelse? 4. Vil du generere en statistik over et distrikt mod gennemsnittet af det samlede tidsforbrug i undersøgelsen? 1. Statistik - sammentælling af tidskategorier for et distrikt Vælg Statistik fra vinduet Administration af undersøgelse. Vælg herefter Alle tidstyper i nederste venstre hjørne af vinduet Statistik. Herved vil alle tidstyperne blive valgt. For at sammentælle de forskellige tidskategorier klikkes der på Sammentæl valgte udfor hver kategori. Herefter vælges i øverste højre hjørne det distrikt, der skal vises statistik for. Tryk på Gem som... for at generere og gemme statistikken. Herefter kan den gemte fil åbnes og vises i MS Excel. Statistikken vil herved se ud som den, der er vist på figur F Statistik - udspecificering af tidskategorier Vælg Statistik fra vinduet Administration af undersøgelse. Vælg herefter Alle tidstyper i nederste venstre hjørne af vinduet Statistik. Herved vil alle tidstyperne blive valgt. Herefter vælges i øverste højre hjørne det distrikt, der skal vises statistik for. Tryk på Gem som... for at generere og gemme statistikken. Herefter kan den gemte fil åbnes og vises i MS Excel. Statistikken vil herved se ud som den, der er vist på figur F

121 F.3 Skærmbilleder 3. Statistik - samlede tidsforbrug for valgt undersøgelse Vælg Statistik fra vinduet Administration af undersøgelse. Vælg herefter Alle tidstyper i nederste venstre hjørne af vinduet Statistik. Herved vil alle tidstyperne blive valgt. For at sammentælle de forskellige tidskategorier klikkes der på Sammentæl valgte udfor hver kategori. Herefter vælges i øverste højre hjørne Sammentælling over: og alle distrikter under Sammentælling over: skal herefter markeres. Tryk på Gem som... for at generere og gemme statistikken. Herefter kan den gemte fil åbnes og vises i MS Excel. Statistikken vil herved se ud som den, der er vist på figur F Statistik - distrikt mod det samlede tidsforbrug Vælg Statistik fra vinduet Administration af undersøgelse. Vælg herefter Alle tidstyper i nederste venstre hjørne af vinduet Statistik. Herved vil alle tidstyperne blive valgt. For at sammentælle de forskellige tidskategorier klikkes der på Sammentæl valgte udfor hver kategori. Herefter vælges i øverste højre hjørne det distrikt, der skal holdes op mod det samlede tidsforbrug for undersøgelsen. Vælg herefter Sammentælling over: og alle distrikter under Sammentælling over: skal herefter vælges. Tryk på Gem som... for at generere og gemme statistikken. Herefter kan den gemte fil åbnes og vises i MS Excel. Statistikken vil herved se ud som den, der er vist på figur F.13. F.3 Skærmbilleder 119

122 F. Manual Figur F.1: Hovedvindue Figur F.2: Oprettelse af undersøgelse Figur F.3: Administration af undersøgelse 120

123 F.3 Skærmbilleder Figur F.4: Aministration af distrikter Figur F.5: Oprettelse af distrikt 121

124 F. Manual Figur F.6: Medarbejderskema 122

125 F.3 Skærmbilleder Figur F.7: Brugerskema 123

126 F. Manual Figur F.8: Oprettelse af statisitik Figur F.9: Gem statisitik 124

127 F.3 Skærmbilleder Figur F.10: Statistik 1 Figur F.11: Statistik 2 125

128 F. Manual Figur F.12: Statistik 3 Figur F.13: Statistik 4 126