Användbarhetstester och Taylorism

När jag var liten (60-tal) fanns inom verkstadsindustrierna en av industriarbetarna ofta illa ansedd yrkesgrupp benämnd tidsstudiemän. Deras attribut var ofta den grå lagerrocken med Pocket protector, skrivplatta med stoppur och deras lära var Taylorism. En av tidsstudiemän vanligt använd metod var MTM (Methods-Time Measurement) vars mål var att optimera repetitiva arbetsprocesser inom industrin. Man bröt ner processerna i korta men mätbara moment och mätte tid för dessa. Momenten kunde vara; hämta skruv från låda A, passa in skruv i hål B på arbetsstycke C o.s.v. Under tiden kontrollerades om det fanns några onödiga rörelser som t.ex. kunde elimineras genom att t.ex. ändra placeringen av låda A. Att tidsstudiemännen ofta var illa sedda var förmodligen kopplat till att de störde yrkesstoltheten hos de "studerade" och att dessa blev lättare utbytbara när processerna blev nedtecknade.

Nog om historia nu. Jag kom att tänka på detta i samband med användbarhetstester av IT-system. Ofta sker användbarhetstester mot enstaka IT-system för att validera systemets specifikationer, sällan kopplat till de arbetsprocesser som systemen kan vara en del av. Min idé (som kanske finns förverkligad som metod men som jag i så fall är okunnig om) är att tänka lite MTM vid krav och tester av IT-system som är del i arbetsprocesser bland flera andra IT-system och alla icke-IT delar i arbetsprocessen. Det enskilda IT-systemet kanske inte uppvisar några hinder för att användaren skall kunna göra ett bra arbete men i den totala arbetssituationen kan systemet upplevas som mycket ovänligt. T.ex. upprepade in och utloggningar i olika system, möjligheter att klippa/klistra mellan systemen, olika GUI och kortkommandon m.m. påverkar arbetssituationen påtagligt.
Idéerna med MTM och Taylorismen skulle här inte användas för att ifrågasätta användarna utan för att kunna ställa rätt krav vid upphandling och utveckling av IT-system som ingår i större arbetsprocesser och för validering/användbarhetstester av hela processer.

Användbarhetstester bör utgå från användarens arbetsdag och arbetssituation, inte det enskilda IT-systemet "användbarhet"

Kvalitet i projekt

Den här texten berör i princip allt man förädlar för att sedan lämna i från sig men jag har valt att lägga fokus på projektperspektiv och för projektledarrollen.

Som projektledare har man ansvaret för att leverera ett resultat som motsvarar specifikationerna inom överenskommen tidsplan och med de resurser man tilldelats. D.v.s. allt mätbart man kommit överens om med uppdragsgivaren. Men allt är inte mätbart. Mycket av den kvalitet man upplever är subjektiv.

En kvalitetsaspekt är en produkts användbarhet. Användbarhet är svårt att definiera och även finna vad som ger en god användarupplevelse. Men varje person som kommer att använda den kommer snabbt till klarhet i om den är användbar och bra.

Mycket av den icke mätbara kvaliteten kommer från yrkeskunnande, erfarenhet och engagemang hos den eller de som tar fram produkten. Att de som utvecklar produkten dessutom måste förstå hur den skall användas och i vilken kontext är en förutsättning för att nå förväntad kvalitet d.v.s. utöver det som är mätbart.

De som har yrkeskunnande och erfarenhet vet när de tvingas lämna i från sig något som riskerar att ha dålig kvalitet, brister som kanske upptäcks långt senare när leveransen är gjord och projektet upplöst.

Men...

Har beställaren allt för stort fokus på specificerade mål och det samtidigt uppstår problem i projektet kan projektledaren pressas att bara tillgodose specifikationen och bortse från de subjektiva kvalitetsönskemålen och därmed det yrkeskunnande och den erfarenhet som finns i projektet..

Jag tror att ovanstående är orsak till många av de dåliga och svåranvända produkter vi har i vår omgivning, att kvalitéer som inte är mätbara utelämnas, med- eller omedvetet, i leveranser.

Hotet mot kvalitet är management i allt för rigida former, har inte beställaren förståelse för subjektiv kvalitet och reserverar resurser för detta kommer leveransen också sakna kvalitéer. En ödmjuk (men kompetent) beställare kan nå mycket längre. Förtroende för yrkeskunnande och yrkesstolthet är en förutsättning. Egenskaper som inte kan ersättas med metoder.

Big Data - Hur BIG kan det bli?

“Big Data” är hype men hur stor kan det bli? Vilka kommer att tjäna pengar på detta?

“Big Data” är ett ganska nytt begrepp för att utvinna och härleda information ur stora datamängder. Tidigare har begreppet “data mining” används för att beskriva detta. Men “data mining” har oftast varit kopplad till att analysera det data man “råkar” ha, inte som man mer strategiskt samlat in för att kunna göra bättre analyser.

Om vi tar upp perspektivet leverantör-kund så kan man med “data mining” hitta mönster i vad kunder har köpt och vad potentiella kunder har frågat efter eller vilket mönster de haft när de besökt din hemsida. Du kan med detta underlag kan du anpassa ditt erbjudande.

Men...

Du har svårt att av de data du har tillgång till lära känna din kund utöver den relation ni har. Vilka konkurrerar du med om kundens gunst? Hur är kundens förhållande till dessa? Vad har kunden för andra intressen och hur kan dessa korsa dina? Detta har du svårt att veta utifrån de data kunden lämnat hos dig och din analys blir svår.

Men vilka kan göra en bättre analys om dina kunder än du själv kan? Jo de som vet mer om dina kunder än du själv vet. De som kan se relationen från båda sidor har ett klart övertag. Idag är det få aktörer som är stora på detta, främst är det  Google, Facebook, välfungerande underrättelsetjänster m.f. som sitter på mycket mer data än vad du själv kan samla in. Förmodligen kommer det snart gå att köpa analyser från flera av dessa gigantiska datalager men att köpa obearbetade data för egna analyser blir nog svårare.

Min slutsats är att Big Data bara blir BIG för de allra största.

Det kostar att ha otur när man tänker

Systemutveckling i sammanhanget utveckling av IT-system härrör sig (förhoppningsvis) från en intention i att utveckla någon form av verksamhet m.h.a. IT så att den upplevs bättre. Bättre lönsamhet, effektivitet, produktivitet, miljömässigt eller arbetsmiljömässigt eller anpassning till yttre krav. Intentionen bör vara uttalad och följa genom de projekt som startas.

Utöver projektens mål d.v.s. en formaliserad beskrivning av intentionerna sätts också ramar upp för de projekt som startas. Ramarna består ofta av en tidsplan, med eller utan delmål,  och en beskrivning vilka resurser som projektet får tilldelat.

Ett övergripande sätt att beskriva de steg ett utvecklingsprojekt för verksamheten kan vara:

Ursprunglig verksamhet                        Förändrad verksamhet

Idé--> Design--> Kodning--> Integration--> Leverans--> Förvaltning

Vad som är känt är att ju tidigare ett tankefel introduceras (som inte ifrågasätts och åtgärdas löpande) i projektet ju högre blir kostnaden för att åtgärda felet.

Konceptuella fel, designfel eller kodbuggar beror på “den mänskliga faktorn”, någon har haft otur i sitt tänkande.

För att fånga fel används tester och metoder för test utvecklas löpande. Men... avståndet i tid mellan att ett fel introduceras tills att det upptäcks med hjälp av tester kan vara ganska lång.

Etablerade testmetoder hanterar i huvudsak den kod som levereras i samband med leverans av delar eller hela systemet.

Designfel kanske inte upptäcks förrän integrations- eller leveranstester görs. Idéfel kanske upptäcks först i förvaltningsfasen. Ett designfel kan resultera i ett misslyckat och bortkastat projekt även om alla har gjort ett perfekt arbete i projektets senare skeden.

Ett “perfekt genomfört” projekt kan också betraktas som misslyckat om det inte genererar verksamhetsnytta. Har bakomliggande idé varit dåligt genomarbetad kommer projektet inte att generera förväntad nytta.

Det gäller alltså att så snabbt som möjligt fånga resultatet av de tankefel som de inblandade orsakar och övriga risker som föreligger så att bra beslut kan tas löpande i projekten. För att göra detta behövs bättre metoder för kvalitetssäkring av projektens tidiga faser.

Kvalitetssäkrar man inte alla projektsteg med korta loopar kan “otur när man tänker” bli dyrt.

Riskanalys och agil systemutveckling

• Beslut i projekt skall vara medvetna
• Beslut i projekt tas dagligen
• Beslut skall bygga på bästa möjliga underlag

Beslut tas för att nå ett mål. Vägen till målet kan vara omgiven av risker som kan störa möjligheten att uppnå förväntade mål. För att kunna göra en realistisk bedömning av hur svårt det är att nå målet används riskanalys som ett verktyg. Riskanalys bygger på att använda den kunskap man har till förfogande till att bedöma sannolikheten för störningar och ev. konsekvenser av dessa störningar.

I projekt är det oftast ett krav att man gör en riskanalys innan man påbörjar arbetet. Skulle riskerna bedömmas som stora kan det resultera i att projektet stoppas eller att målformuleringen ändras. Även delprojekt eller specifika egenskaper kan bli föremål för riskanalyser. Men ...oftast sker riskanalyser enbart vid projektstart, tyvärr, för under ett projekt ökar kunskapen kontinuerligt om dess risker och hur dessa kan förebyggas. En riskanalys som görs en tid efter projektstart kan peka åt ett helt annat håll än den ursprungliga och kvaliteten på förutsägelserna är troligen högre.

Agil systemutveckling bygger på en medvetenhet om att allt i en systemutvecklingsprocess inte kan förutses och därmed inte fullt specificeras inför genomförande. Det mesta, utom de övergripande målen, kan behöva förändras i arbetet. Besluten inom projekten kommer därmed att bli större och viktigare varför det också är viktigt att man har bästa och färskaste underlag för dessa beslut, inklusive en riskanalys som stöd.

Kontentan av ovanstående är att inför en beslutspunkt skall finnans en aktuell riskanalys som underlag för ett bra beslut. Att sammakalla till en riskanalysseans inför varje beslut är förmodligen ogörligt. Finns det däremot verktyg för att för att kontinuerligt samla in och värdera risker i form av sannolikhet och konsekvens skulle kvaliteten på del löpande besluten kunna öka.

Mitt mål är alltså att hitta eller skapa en process för löpande analys av risk så att man vid varje beslutstillfälle har bästa möjliga underlag.

Testdata för vård-IT

Jag har de senaste veckorna stött på frågeställningar om hur man skapar och arbetar med testdata för IT inom vården och sammanfattar här mina spaningar.

För tester av IT-system inom vården krävs, som för all test, relevanta testdata. Det enklaste sättet att få tillgång testdata är att använda produktionsdata från likvärdig miljö men det är något som sällan låter sig göras. Så fort det rör sig om någon form av känsligt data som t.ex. personuppgifter, patientdata eller annan information som omfattas av sekretess är det oftast olämpligt och i många fall olagligt att hantera data på det sätt som tester kräver. Personuppgiftslagen (PUL) och Patientdatalagen reglerar tydligt hur uppgifter får hanteras.

Hur löser man då lämpligen behovet av testdata. För lågnivåtester som enhetstester och liknande fungerar det ganska bra med att generera testdata för varje “enhet”. Antalet variabler och ”states” är oftast begränsade.

Vid större systemtester och integrationstester blir det hela mer komplext. Större mängder testdata med stor variation behövs. Dessutom behövs också testdata från olika system vid integrationstester, data som behöver gemensamma nycklar över systemgränser, ofta personnummer. Vid sådana tester används ofta “anonymiserade” produktionsdata där personnummer, kontonummer o.d. ersatts med ett fiktiva, namn och adressuppgifter tagits bort eller ersatts av slumpmässaga uppgifter. Övrigt information lämnas sedan orörd för att kunna fungera som testdata. Fiktiva person- eller kontonummer måste ha föreskriven struktur men om möjligt inte kollidera med verkliga nummer. Specifika personnummer bör bytas ut mot samma fiktiva i de system som skall integrationstestas.

Men...
Ovanstående hantering av testdata är inte oproblematiskt, hittills har anonymiseringen oftast ansetts som ett tillräckligt skydd av persondata men det kan vi inte räkna med i framtiden. Samkörning av läckta testdata mot publik information, Facebook eller Google kan framöver förmodligen koppla väldigt stor del av den anonymiserade informationen mot fysiska personer. Nämnda aktörer har i stor utsträckning kännedom när du varit på olika platser, t.ex. ett sjukhus, hur gammal du är, kanske har du sökt på symptom som stämmer med din sjukjournal m.m.

Anonymisering av personnummer och kontonummer är inte heller oproblematiskt, använder man en metod som inte är fullt slumpmässig utan att resultatet vid bytet av ett personnummer blir det samma vid upprepning är det troligt att man med begränsade datorresurser faktiskt kan spåra ursprungligt nummer.

För ett seriöst arbete med testdata inom vården bör följande finnas med:

1. Ett kryptografiskt “säkert” sätt att anonymisera nyckeldata t.ex. personnummer från de produktionsdata som kommer att användas. Detta gör att den personal som kommer i kontakt med testdata inte enkelt kan göra sökningar på fysiska personer.
2. Säkra processer för generering, distribution och lagring av testdata som inte riskerar att läcka produktionsdata.
3. Säkring av testmiljöer både logiskt och fysiskt så att testdata inte riskerar att lämna den avgränsade testmiljön.
4. Rutiner för att förstöra testdata på ett kontrollerat sätt efter genomförda tester.