It-professionelle er hurtige til at se dårligdommene hos de andre aktører i et it-projekt: Utilstrækkelig ledelse hos kunden, stive EU udbudsregler, copy-past udbuds-konsulenter, utrænede projektledere, umodne projektdeltagere, trælse jurister, ja andre faggrupper i almindelighed og DJØF’ere i særdeleshed.
Men hvad med os selv? Hvad med selve kilden til vores faglige stolthed, det som gør netop danske udviklere til særligt empatiske og lyttende, og netop vores løsninger til særligt værdiskabende? Jeg taler om participatory design eller den skandinaviske udviklingsmetode, som den også kaldes.
Alle it-brugere er unikke. Der skal tages udgangspunkt i deres egen arbejdssituation og organisationskultur når deres ganske særlige arbejdsgange it-understøttes. It skal understøtte mennesker i stedet for at mennesker skal underkastes it. Det lyder rigtigt, ikke? Det var også hvad jeg blev undervist i på datalog-studiet for en del år siden.
It-skandalerne i det offentlige (og ikke så få i det private) har mange forskellige årsager. Fællesnævneren er dog ofte et udgangspunkt, hvor myndigheder og virksomheder skal have noget helt specielt fordi de hver især er ganske særlige. Hvis kravspecifikationen peger mod at anskaffe noget, som aldrig er set før, gives ekstra point for forretningsforståelse og respekten for indarbejdede kulturelle forskelligheder.
Den seneste sag er jo Polsag. Polsag var et standard-system der lige skulle igennem nogle tilpasninger som betød, siger rygterne, at 80% af løsningen endte med at blive specialudviklet.
At hævde at den skandinaviske udviklingstradition tager hensyn til hvad markedet kan tilbyde af standardsystemer eller hvad tilsvarende kunder har købt og haft succes med, svarer vel til at hævde, at vandfaldsmodellen er udmærket til agil udvikling: Ikke synderlig troværdigt og i sjældent set udlevet i praksis.
Den yderste konsekvens af den skandinaviske udviklingstradition er, at vi gang på gang specialudvikler en variant af den dybe tallerken. Og der er klar evidens for at vi ofte ender med for meget og for risikabel skræddersyning.
I de senere år har staten sat hælene i. Princip nr. 1 for it-projekter i staten er:
Staten skal være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver ved at foretage en sådan satsning.
Princippet er fornuftig og vil, hvis princippet ellers bliver fulgt i praksis, sandsynligvis kunne spare os for mange omkostninger.
Samtidigt ser systemudvikling ud til i stigende grad at blive nødt til at anerkende potentialet i Cloud computing. Cloud computing, specielt Software-as-a-Service, udfordrer allerede i dag grundantagelserne i udviklingstraditionen i ekstrem grad hvor ingen skræddersyning er mulige ud over de konfigurationsmuligheder, der er i forvejen er bygget ind i produktet. Til gengæld er prisen stærkt faldende, udviklingshastigheden høj og brugerbasen bred.
Hvordan sikrer vi, at vores metoder til kravspecifikation ikke unødigt skaber behov for specialudvikling og umodne tekniske løsninger? Og hvordan sikrer vi os at vi ikke unødigt afskærer os fra at vælge cloud-løsninger? Er den skandinaviske udviklingstradition, som den praktiseres i dag, blevet utidssvarende?
Edit: For læsere ubelastede af historiekendskab har jeg indsat en kobling mellem participatory design og den skandinaviske udviklingsmetode ovenfor
Jeg tror bestemt at de fleste it professionelle kan se problemer hos en selv også. Især hvis vi snakker i det firma man er i.
Jeg tror tilgengæld ikke den lidt danske ide med at specialudvikle alting er specielt meget drevet af IT folk, jeg tror mere det er drevet af en ledelse der ikke forstår den kompleksitet det tilføjer at skulle have specielle komponeneter til det hele, istedet for at tilpasse forretningsgangene til en standardløsning.
Hvor får du fra, at der skulle være en særlig skandinavisk udviklingstradition? IT-skandaler a la Polsag kendes, så vidt jeg ved, i hele den civiliserede verden.
Jeg forstår dit indlæg primært som en opfordring til at vælge standardsystemer. Hvis man er villig til at indrette sin forretning efter standardsystemer, så er det en no-brainer. Fx er der vist ikke mange, der specialudvikler bogføringssystemer - man indrette sin bogføring efter det valgte standardsystem (som i høj grad er dikteret af lovgivning m.v.).
Polsag er netop et eksempel på, at forretningen ikke var villig til at indrette sig efter et standardsystem, men ledelsen insisterede på et standardsystem - måske efter en rådgivning nogenlunde som den, du kommer med her. Skulle det danske politi have valgt et standardsystem og indrettet sig efter det? Det kender jeg ikke nok til politiet til at have en holdning til. Men den valgte model var under alle omstændigheder det værste af to verdener.
Så svaret er ikke: Køb standardsystemer.
Svaret er enten: Køb standardsystemer og indret forretningen efter dem. Eller: Lav specialudvikling (godt - hvilket fint kan lade sig gøre).
Så skal vi også lige en tur omkring "cloud computing". Jeg tror ikke SaaS får den store betydning i det offentlige it-forbrug, hvorimod PaaS (og IaaS) kan få ganske stor betydning og gøre op med de håblåse - og dyre - driftmodeller, der anvendes i dag.
Hvor får du fra, at der skulle være en særlig skandinavisk udviklingstradition?
Participatory design har i høj grad et skandinavisk ophav og kaldes også for den skandinaviske udviklingstradition. Søg fx på Finn Kensing, Keld Bødker, Jesper Simonsen, Susanne Bødker, Erik Frøkjær, Jan Pries-Heje, Søren Lauesen eller Morten Kyng.
Se også http://www.ebst.dk/brugerdreveninnovation.dk/participatory_design for at udvide horisonten med historien bag.
Blot fordi jeg kritiserer den tradition, jeg er uddannet i, betyder det ikke at jeg anbefaler at købe et vilkårligt standard-system. Det skulle gerne fremgå klart af mit indlæg. Jeg efterlyser svar, gerne fra forskere inden for området, på hvordan participatory design skal udvikle sig for at kunne spille sammen med den stigende modenheden i standard-systemer.
Jeg efterlyser svar, gerne fra forskere inden for området, på hvordan participatory design skal udvikle sig for at kunne spille sammen med den stigende modenheden i standard-systemer.
Jeg kan ikke se hvorfor PD skal udvikle sig for at kunne blive integreret med køb af standard systemer. En PD process kan da lige så godt bruges i forbindelse med udvælgelsen af en produkt (og så tailor det til ens behov) som udvikling af et helt ny produkt.
Participatory design har i høj grad et skandinavisk ophav og kaldes også for den skandinaviske udviklingstradition.
Det kan godt være. Men prøv engang at Google "skandinaviske udviklingstradition". Der refereres kun tilbage til dette blogindlæg. Så det er måske ikke helt at være "ubelastet af historisk viden" ikke at koble "den skandinaviske udviklingstradition" til en akademisk disciplin.
Nuvel. Jeg tror nu ikke at forskningen omkring "particatory design" har haft nogen væsentlig indflydelse på den måde, det offentlige i DK indkøber IT på. I givet fald skal det være meget indirekte. Generelt er det min oplevelse, at det der sker i de akademiske cirkler i DK (inden for IT) har meget lidt påvirkning på det, der foregår "ude i virkeligheden".
Og så må jeg undskylde, at jeg ikke fangede den akademiske vinkel i din oprindelige artikel. Det gør jeg stadig ikke (udover den konkrete reference).
Mit praksisbelastede svar på, hvordan det offentlige bliver bedre it-indkøbere er (i de fleste tilfælde) at droppe ideen om en kravspecifikation, fokusere på business casen og køre agile forløb. Hvis det bliver gjort godt, så virker det. Men det er pokkers svært.
Jeg har aldrig set et stort offentligt IT-projekt der anvendte det jeg ville kalde en "ren" PD-tilgang med ægte og ærlig brugerinddragelse.
Hvis der er sådan et, og det slog fejl, så går jeg lidt ned af gangen og vækker de ældre forskere - hvis der bare er en hel masse projektledertyper i det offentlige, der synes at "Skandinavisk model!" lyder lidt som "Ny Nordisk mad", og derfor har bestemt sig for at bruge mockups og scenarier for at virke lidt innovativ, så er det måske dér problemet ligger :)
edit: og jeg ville også være meget ked af at blande "Participatory Design" som term sammen med Skandinavisk udviklingsmetode etc - det er nemlig ahistorisk (det blev ikke kaldt PD i f.eks. DEMOS og UTOPIA projekterne), så lad os få en tight PD-definition på banen først + et eksempel på et projekt der anvender en sådan.
Jeg kan kun være enig med Nicolai Hansen. Peter, dit argument er tilsyneladende følgende: - Der findes en skandinavisk udviklingstradition, der tager udgangspunkt i brugeren frem for systemet. - Glemmer man at forholde sig til eksisterende standardsystemer risikerer man at bruge unødigt mange ressourcer. - Fordi der er mange fejlslagne it-projekter i Danmark må den skandinaviske udviklingstradition, eller PD være utidssvarende
Hvor er belægget for, at Polsag blev drevet efter en Participatory Design proces (Polsag er det eneste fejlslagne it-projekt, du nævner)? Hvis ikke du kan lukke det hul i argumentet er der en overhængende fare for, at der går en Erasmus Montanus i diskussionen.
Jeg synes det er et spændende spørgsmål Peter stiller. Rent forskningsmæssigt kan man finde er et jo faktisk også svært at finde belæg for at PD giver væsentlig bedre systemer, men det er måske også mere en tilgang man anvender fordi man politisk eller ideologisk mener at folk bør have indflydelse på deres arbejde. Jeg har svært ved at følge Peter kobling mellem anvendelse af PD (i større eller mindre grad) og den megen tilpasning af standardsystemer. Jeg mener ikke at PD nødvendigvis fører til mere tilpasning det har noget at gøre med hvordan man anvender PD og hvilke forretningsmæssige retningslinjer man sætter op. Jeg er meget enig i Peters efterlysning: "Jeg efterlyser svar, gerne fra forskere inden for området, på hvordan participatory design skal udvikle sig for at kunne spille sammen med den stigende modenheden i standard-systemer." Jeg er selv skolet indenfor PD og har forsket i det. (Jeg vil nu mene at man godt kan kalde PD for en skandinavisk metode - men den diskussion synes jeg er uinteressant i denne sammenhæng) I min PhD giver jeg netop et bud på hvordan PD kan udvikle sig ved at spille en rolle i den organisatoriske implementering og i evalueringen af it anvendelsen. Jeg har eksperimenteret med hvordan man kan involvere brugere/medarbejder i den organisatoriske implementering , hvilket når der er tale om standardsystemer, handler meget om design af arbejdsprocesser og arbejdssystemer. Læs evt. mere på min blog: http://granlien.dk/ehealth/
Nu hvor du efterspørger en forskerkommentar, så har du her et hurtigt indlæg. For lige at få en sten af vejen, så er din sammenblanding af participatory design (PD) og den skandinaviske udviklingstradition upræcis. Selvom PD feltet har skandinaviske rødder, betyder det ikke nødvendigvis, at PD og den skandinaviske tilgang til systemudvikling er den samme. Mennesker og aber har sandsynligvis samme ophav, men de er dog forskellige. Anyways, videre til substansen. Som forsker og underviser inden for feltet finder jeg det indlysende, at man må undersøge ikke blot de potentielle brugeres nuværende situation, ønsker og behov, men selvfølgelig også de teknologiske muligheder. Og i mange sammenhænge er det oplagt at undersøge, hvilke standardsystemer og cloud services, der kan indgå som en del af løsningen af de problemer, man angriber som designer/udvikler. Derfor synes jeg, at du får opstillet et kunstigt modsætningsforhold mellem PD og denne type systemer og services. Du kan sagtens arbejde med en PD tilgang uden absolut at det hver gang skal resultere i skræddersyede systemer, der udelukkende baserer sig på brugernes nuværende praksis. Hvis du spørger mig (jeg vil ikke gøre mig til repræsentant for alle forskere inden for feltet - fx. kan jeg allerede se et par andre give ders besyv med her i kommentarerne) så vil det faktisk være en ret misforstået tilgang til PD. I visse sammenhænge kan ønsket om at skræddersy jo også hænge sammen med, at det giver kroner i kassen hos udviklerne. Når du spørger om den skandinaviske udviklingstradition, som den praktiseres i dag, er blevet utidssvarende, må svaret vel være, at det afhænger af, hvad du taler om. Hvis du taler om en udviklingstilgang, der er så forstenet, som du skitserer, så ja. Heldigvis tror jeg ikke, at der er ret mange, hvis overhovedet nogen, der arbejder på den måde. Forskningen inden for PD udvikler sig løbende. Når man følger feltet, er det meget iøjnefaldende, at en meget stor del af forskingen lige præcis beskæftiger sig med, hvordan PD kan ændres og tilpasses udviklingen i samfund, organisationer, kommunikation og teknologi. I den sammenhæng kunne man vende spørgsmålet om og spørge, om udviklere i praksis er up to date med denne udvikling? Hvis ikke er vi måske som forskere for dårlige til at sprede vores viden om denne udvikling og/eller folk i branchen er for dårlige til at opdatere deres viden - pilen peger sandsynligvis begge veje. Jeg kender ikke selv det store til Polsag, udover hvad jeg har kunnet læse mig til i medierne. I dette indlæg fremfører du, at den skandinaviske systemudviklingstilgang (eller PD, jeg er stadig lidt i tvivl om hvad du mener) er årsag til Polsag fiaskoen. For halvanden måned siden skrev du, i et indlæg med titlen 'Læren fra Polsag' (http://www.version2.dk/blog/laeren-fra-polsag-43322), at det var EU's udbudsform, der var skurken. Derfor er billedet nok lidt mere nuanceret, end hvad der kan stå i et enkelt indlæg eller to.
Der er flere problemer når vi udvikler kravspecifikationer i dag. Et af dem er at vi laver for detaljerede krav og går i designmode på for svagt et grundlag i stedet for at beskrive de bagvedliggende forretningsbehov. Det skyldes efter min overbevisning to faktorer:
a) at kunden eller brugerne har svært ved at undgå at blive konkrete i deres vision for / krav til hvordan deres arbejde skal it-understøttes. Det er altså svært at lave en kravspecifikation uden at udpege en implicit teknisk løsning. Når ikke-teknikere specificerer en teknisk løsning, går det meget ofte galt.
b) at vi udvikler kravspecifikationen som om at arkitektur, teknik, udvikling, driftsmodning og standardsystemer "bare" er noget vi får til at understøtte kravene efterfølgende. Det er en illusion, som koster dyrt
Når vi udvikler kravspecifikationer i dag, med udgangspunkt i brugernes ønsker og forestillinger, hvilket vi har en stærk tradition for herhjemme, har vi brug for en styrket metode. Om vi så kalder metoden for en skandinavisk metode, -tradition, PD, PD-light eller "som vi plejer" er mindre centralt. Behovet er det samme: Vi har brug for at få styrket det grundlag, brugerne går i design-mode på. Formålet er at kunne udforme og realitetstjekke kravene så projektet får en lavere risiko for forsinkelser, fordyrelser og for noget så gammeldags som at systemet bliver for langsomt.
Marens arbejde med at involvere brugere inden for rammerne af et eksisterende, og forhåbentligt kapabelt, system lyder som noget af det, jeg efterlyser.
Peter Dalsgaard, det er super at du kommer på banen (det gælder også Maren Granlien). En fiasko som Polsag har ikke mange frivillige fædre, men skyldes på den anden side også flere faktorer på samme tid, så hverken udbudsform, politik hos kunden eller kravspecifikation er uden skyld.
Jeg er ganske sikker på at praksis ikke er ajour i forhold til den seneste forskning. Så hvordan kan vi bruge den seneste forskning inden for PD til at få mere vellykket it (eller organisationsudvikling med it), specielt inden for den offentlige sektor med dens EU-udbud?
Med den lille viden jeg har om kravsspecifikationer, men den store erfaring jeg har med at sidde som lejlighedsvis bruger af indtil flere it-systemer i det offentlige (en skønsom blanding af customized, off the shelf og speciallavede) systemer, så vil mit bud være at: - problemet ikke så meget skyldes PD eller ikke-PD. Fordi der er ganske få af de systemer, jeg møder i min hverdag, der rent faktisk er lavet i samarbejde med den type person (dvs fx mig), som rent faktisk i sidste ende sidder og skal anvende dem. Hvis det således er lavet den mindste smule participatory, så er det typisk med fx økonomiafdelingen, som har behov for, at 'almindelige medarbejdere' kan lave noget økonomiarbejde selv. Det er så bare ikke en 'almindelige medarbejder', som er med til at udarbejde kravsspec. - (en undtagelse er muligvis EPJ, men det ved jeg kun overfladisk noget om. Men her har man rent faktisk fat i lægerne og sygeplejerskerne, ikke kun i det sekretærielle personale.) - problemet er nok faktisk snarere, at det ikke er PD nok. At det ikke, som du også antyder her i din kommentar, er de faktiske brugere, som er med til at bestemme, hvad der ville fungere for dem. Derimod er det, som jeg beskrev ovenfor, typisk nogle andre personer, som sidder et andet sted i organisationen. Det problem var centralt for UTOPIA (som er en generation gammelt nu), men det tyder faktisk ikke rigtig på, at det er noget, som nogen uden for universitetsverdenen har lært noget af. På trods af, at du i dit indlæg og en efterfølgende kommentar påstår det med henvisning til Bødker, Ehn, Kensing et al.
Helt konkret: jeg arbejder som videnskabelig medarbejder på et universitet (som jo er offentligt), som bl.a. benytter et system, der er rekvireret af et centralt universitets-fællesskabs-bureau. Jeg talte for nylig med det firma, som har udviklet systemet (herunder jo fx såvel database som interface), og de har ALDRIG talt med en faktisk bruger. De undersøgte sagen og fandt ud af, at INGEN undervejs fra første beslutning til endelig aflevering har lavet nogen form for brugerindragelse, hvis man med bruger forstår den person, som i sidste ende rent faktisk skal anvende systemet. Systemet giver nul mening for en person som mig, for det forstår ikke min arbejdssistuation. Det er her min tese, at hvis man bare en enkelt gang havde anvendt bare lidt PD, så havde det set helt anderledes ud, og det havde fungeret helt anderledes i organisationen.
Så problemet med dit indlæg er, så vidt jeg lige kan vurdere, at du blander noget, der ikke kan sammenblandes. Din pointe med, at kravsspec er for specifikke (at design-mode er indtrådt på et forkert tidspunkt) er god, men det her ikke noget med PD at gøre. Måske ville noget 'rigtig' PD faktisk have reddet mangt et system.
