8 challenges for developers - Jonathan Grudin, 1994
Grudin ser på udviklingen fra tidligere mainframe og enkeltbruger systemer til design af groupware, og kommer med 8 forhold der giver særlige udfordringer I designet af løsninger.
Hvor er groupware i udviklingsuniverset: Grudin ser det som et sted mellem mainframe udvikling der har haft hele organisationer som perspektiv, og enkeltbruger systemer (fx tekstbehandling) der har haft fokus på forholdet mellem bruger og maskiner. Groupware er kommet til siden og aktørerne omkring groupware er præget af de to andre verdener.
En grundlæggende udfordring for groupware er, at organisationers ledere og systemudviklere er vant til de to andre perspektiver. Fx at det historisk har været normalt at se udviklingen af et mainframe system som noget der påvirkede hele organisationen og kunne gennemtvinge forandringer i processer og organisering.
Grudin opstiller 8 særlige udfordringer ved groupware udvikling:
1. Kløft mellem indsats og udbytte for den enkelte
2. Kritisk masse mangler for at opnå gruppedynamik
3. Angriber/nedbryder eksisterende sociale processer
4. Håndtering af afvigelser
5. Groupware funktioner bruges sjældnere hvilket stiller højere krav til nem tilgængelighed
6. Svært at evaluere succes af groupware produkt
7. Udvikleres intuition fungerer ikke for groupware
8. Sværere at implementere i arbejdspladsen
Ad 1 – kløft mellem indsats og udbytte
Mange groupware systemer giver for meget benefit til en enkelt bruger (mødeindkalder, projektleder osv) på bekostning af, at andre gruppemedlemmer skal yde en større indsats for at systemet giver udbytte – fx altid holde sin kalender opdateret, eller indtaste tidsforbrug i projektsystem..
Sammenlign med enkeltbrug: Her opstår problemet slet ikke, fordi brugeren får direkte benefit af egen indsats
Sammenlign med organisation: Et stort dyrt system vil ofte få ledelsen til at sikre ved særlig indsats, at systemet kommer til at fungere fx ved at tilpasse organisation og roller omkring systemet
Løsning: Forsøge at designet systemet 1)kræve mindre indsats af gruppemedlemer hvis muligt (svært), 2) design tillægsfunktioner der giver gruppemedlemmer fordele – fx indflydelse på dagsorden ved møde, som man skal deltage i
Ad 2 – kritisk masse mangler for at opnå gruppedynamik
Benefit opnås i sagens natur først, når alle relevante medlemmer af en gruppe bruger systemet – selv enkelte ikke-brugere kan ødelægge den samlede benefit. Risikoen er at ’early adaptors’ har forladt systemet igen, hvis der ikke tidligt nok opnås kritisk masse.
Undersøgelser viser, at hvis alle bruger systemet ud fra egoistisk betragtning (ikke yde, kun nyde) vil ingen få udbytte af systemet, og måske være stillet ringere, end hvis der var tale om enkeltbruger-systemer.
Sammenlign med enkeltbruger: Problemet eksisterer ikke
Sammenlign med organisation: ledelsen kan forcere at alle bruger systemet – fx ved at fjerne alternativer
Løsning: Forsøg at mindsk den nødvendige indsats, indbyg incitamenter til øget brug, vis mulige anvendelsesmåder der giver større benefit
Ad 3 – Angreb på eksisterende sociale, politiske og motivationsfaktorer
Risikoen er, at der designes systemer hvis anvendelse ikke passer til bestående sociale normer, hvad der anses som acceptabel adfærd. Eksempel – et fejlrapporteringssystem, der samtidig krævede at chefen fik besked, når man rapporterede en fejl, resulterede i, at ingen rapporterede fejl længere.
Et andet perspektiv herpå er, hvis brugergrupperne er meget forskellige og har forskellige normer – kunne fx være produktionsarbejdere kontra akademikere.
Sammenlign med enkeltbruger: ikke afgørende problem, udover eventuel sideeffekt af, at systemet i kan rykke på kompetence/rolle-balancen i en organisation (alle kan nu sætte en hjemmeside op), men det ser Grudin ikke som afgørende.
Sammenlign med organisation: Formål og målgrupper kendes ofte bedre her, hvilket gør det nemmere – omvendt er eventuelle konflikter værre her, da de griber dybere – groupware defineres som et ’low-conflict’ område.
Løsning: At erkende problemets eksistens og størrelse, samt at undlade den gængse opfattelse om ’rationelle’ arbejdsmiljøer er step 1. Derudover har udviklere brug for sofistikeret forståelse af brugernes arbejdsforhold. Intensiv inddragelse af repræsentative brugere understreges som meget vigtigt.
Ad 4 – håndtering af afvigelser i arbejdsgrupper
Arbejdsprocesser kan man enten se på som – hvordan det er meningen de skal være, og så hvordan de faktisk er. ’Arbejd efter reglerne’ er en effektiv metode til at få produktiviteten langt ned – design af groupware efter smalt definerede processer, kan ligeledes sætte tingene i stå.
Arbejds og procesbeskrivelser er for fattige. Mennesket har en høj evne til at håndtere fejl, afvigelser og improvisere, hvilket ikke kan beskrives.
Sammenlign med enkeltbruger: Enkeltbrugersystemer består ofte af en række ’handlings-atomer’ der gør det muligt for den enkelte at opbygge sin praksis og justere ved afvigelser via trial-error. At gøre det samme ved groupware ville være meget tidskrævende.
Sammenlign med organisation: Undersøgelser viser, at der ikke er stor sammenhæng mellem de organisatoriske strukturer og så (fag)gruppers faktiske arbejdspraksis. Empiri viste, at sygeplejerskers praksis var meget ens, på tværs af organisatoriske skel. Det er altså vigtigt, at designe systemer der de-kobler disse to forhold.
Løsning: Opnå forståelse for arbejdsprocesserne og gå efter systemer der kan skræddersys.
Ad 5 – Designe til sjældent brugte funktioner
Tendens til at ville lave groupware support for alt for mange ting – sandheden er, at de er et supplement til enkeltbruger-perspektivet.
a. Tilføj groupware funktionalitet til eksisterende enkeltbruger-funktionalitet
b. Lad groupware funktioner være ’beskedent designet’ (ikke påtrængende) – men dog skal de være kendte og tilgængelig for brugerne – en svær balance-gang.
Sammenlign med enkeltbruger: De fleste funktioner bruges ofte – udfordringen er mere at undgå en rodet overlæsset grænseflade
Sammenlign med organisation: Store mainframe/org. Systemer har oftest til sigte at understøtte funktioner der udføres ofte af målgruppen.
Løsning: hvis muligt, så tilføj groupware funktionalitet til allerede eksisterende og velkørende systemer, frem for at lancere nye store systemer isoleret til groupware. Som en ekstra krølle her er, at det kan kræve at eksisterende systemer træner brugeren trinvist i at udnytte groupware funktioner.
Ad 6 – Svært at evaluere succes af groupware produkter
Mange fejler metodemæssigt i evaluering af groupware. Hvor usability test kan sige noget og virke fint for enkeltbruger, vil det ikke afsløre den reelle brug på gruppeplan. Desværre mener Grudin også, at denne mangel går igen mange steder i groupware-branchen, hvor næsten ingen lærer af fejltagelser fra fortiden omkring løsninger, der ikke tages i brug – ofte pga nogle af de her nævnte 8 problemer om manglende benefit, sociale normer osv.
Sammenlign med single user: Nemmere at evaluere, fx ved usability test
Sammenlign med organisation: Løsninger bygget konkret til en organisation med et bestemt formål er som regel nemmere at
Løsning: Rekruttere de rette kompetencer til evaluering (fx antropolog, social psykologi), og sprede erfaringerne, så vidensniveauet indenfor feltet øges
Ad 7 – Udvikleres og beslutningstageres intuition duer ikke til groupware
Grudins erfaring er at især beslutningstagere ofte træffer intuitive beslutninger om groupware baseret på egne personlige erfaringer med enkeltbruger-systemer eller ud fra et for snævert benefit-synsvinkel: nemlig hvad leder-rollen (bredt set) får ud af det, men overser om det giver en ubalance i andre medarbejderes indsats for at løsningen bliver en succes.
På lignende måde er de ressourcer i udviklingsteamet der skal lave løsningen, i høj grad bias’ed af enkeltbrugersystemer – der er sjældent kompetencer, der ved noget om at studere gruppedynamik over tid.
Eksempel: use cases tager udgangspunkt i lederens behov – altså den der får mest benefit af at systemet bruges
Sammenlign med singleuser: intuition går bedre her
Sammenlign med organisation: mindre slemt, og der er midler til at træne og motivere (!) brugere til ønsket adfærd
Løsning: erkendelse hos beslutningstagere og udviklingsteams om problemet vil være et stort skridt til at justere måden der udvikles og besluttes på
Ad 8 – svært at implementere på arbejdspladsen
Det kritiske er graden af accept og ibrugtagning hos målgruppen. Hvor man kan acceptere kun delvis accept ved en enkeltbruger produkt, så vil hele successen i et groupware produkt være afhængig af at alle tager systemet i brug.
Grudin ser her på udvikler-teamet som frakoblet det at implementere produktet i en organisation.
Gode råd om implementering handler om at se på gruppens problemer, udvælge de rette piloter (brugere ikke beslutningstagere!), giv et klart billede af, hvordan gruppens hverdag vil se ud, når systemet kører fuldt ud for at motivere, lav træning der giv positiv effekt i arbejdsdagen, vær klar til at håndtere tidlig modstand ved at kunne adressere problemer og give support..
Sammenlign med singleuser: der er generelt ikke de samme problemer med ibrugtagning
Sammenlign med organisation: lignende issues, men udfordringen er at groupware er mindre synligt og får mindre ledelses-attention end store mainframe løsninger til en hel organisation
Grudin slutter af med at diskutere eksemplet e-mail – om hvordan man bør skifte fra et teknologi perspektiv til et arbejds perspektiv. Fx de forskellige roller der anvender email og til hvad, og hvordan det kan understøtte eller forstyrre den eksisterende organisationsstruktur.
Igen en stor understregelse af behovet for at forstå arbejdspraksis og gruppedynamik evt ved at lytte til kompetencetyper som fx antropologer.
Grudins generelle råd om groupware udvikling:
- Udvid brugen af et eksisterende singleuser system ved at tilføje relevante groupware funktioner (eksempel jeg tænker på her er hvordan sharepoint kan være en integreret funktion inde i MS Word)
- Find de nicher, hvor groupware fungerer godt ift organisationens eksisterende struktur og normer
- Fokuser på objekter frem for at modellere gruppeprocesser til en bestemt proces
- Find måder at give benefits til alle gruppemedlemmer – pas på kun at favorisere fx ledere
- Uddan ledere og udviklere om groupware forhold
- Skab basis for bedre beslutninger – intuition og trial-error er for dyrt og tager for lang tid
Opslag
Ingen kommentarer:
Send en kommentar