I morgen er vi alle udviklere

I en nylig rapport har Gartner kigget i spåkuglen og påstår, at 25% af alle nye forretningsapplikationer vil blive bygget af “citizen developers”, dvs. brugere som er udenfor it-afdelingens kontrol. Rebeller, om man vil, og lur mig om det ikke er samme skare, som allerede nu har deres egne devices med på arbejde - som f.eks. journalisten Jesper Sandal, der i sit indlæg om BYOD i sidste uge beskrev sig selv som “it-chefens værste mareridt”.

Godt nok er det tilsyneladende blevet så trendy at kode, at selv New Yorks borgmester Bloomberg svor at lære det i 2012 (jeg håber i øvrigt, at han lægger resultatet frem til review ved nytår), men der er næppe horder af mennesker, som vil blive ramt af en akut trang til at klaske SAP-moduler sammen i nær fremtid, så hvor skal alle de applikationer så komme fra?

For det første er det naturligvis et definitionsspørgsmål hvor meget, der skal til for at udgøre en “applikation”. Hvis jeg bygger nogle smarte formler ind i et regneark, har jeg så lavet en applikation? Hvad hvis jeg sætter IFTTT til at sende mig en SMS, når min arbejdsplads bliver nævnt på Twitter? Eller hvis jeg bygger et virtuelt mødelokale i Minecraft?

Måske er det i virkeligheden den store opgave for it-afdelingerne fremover at stille værktøjer til rådighed, der ikke kun sætter it-ingeniørerne men også gerne “almindelige mennesker” i stand til at kombinere eller i det mindste personalisere funktionalitet. (Her bedes den kvikke læser se bort fra, at Kristeligt Dagblad tidligere har sat spørgsmålstegn ved om det ikke er tarveligt overfor de såkaldt ualmindelige mennesker at betegne andre som almindelige mennesker. It-ingeniører er per definition ualmindelige, beklager. Vi må overtage verden en anden gang.)

Det er ikke umuligt - når 8-årige børn kan lave seje applikationer i Scratch, så må der også være håb for de videnmedarbejdere, der kom til at vælge et humanistisk eller samfundsfagligt studium efter gymnasiet. Og hvis ikke it-afdelingen i tilstrækkelig grad sætter dem i stand til at kunne effektivisere deres egne arbejdsopgaver, så er de enten videre til en virksomhed, der i højere grad formår at understøtte deres arbejde, eller også finder de en måde at gøre det på UDEN for it-afdelingens kontrol.

Så skal vi bare have lært generation Y, at selvom arbejdslivets BYOA (Build Your Own Applications) måske ikke helt kan erstatte studietidens BYOA (Bring Your Own Alcohol), er det nok klogest at lade være med at blande de to.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Johan Bruun

Eller SQL der skulle afskaffe behovet for Business Intelligence programmører, hvorefter alle chefer var istand til selv at lave alle de statistikker de drømte hedt om ..... eller COBOL der nærmest er et menneskesprog, som enhver bankmand, sådan til husbehov, hurtigt kunne skrive en lille tælleapplikation i ....

Jeg tror de "rebeller" (citizen developers) Gartner skriver om, er programmører der er blevet sat uden for indflydelse :-)

Casper Kvan Clausen

Citizen development kan langt hen ad vejen ses som bruger-drevet, distribueret prototyping. Spørgsmålet er, som med alle andre prototyper, hvornår noget driver så meget bundlinje, at det udgør en uacceptabel risiko hvis der ikke er 24/7 support, failover, velfungerende backup osv. Så er det sådan set ligegyldigt om der er tale om et Excel-ark, en PHP-applikation eller for den sags skyld et Dropbox-baseret workflow.

Jeg ville påstå at IT-afdelingens ansvar består i at følge med i hvad citizen developers laver, at støtte dem i deres arbejde, og i at have en plan for hvordan man robustgør eller genudvikler de løsninger, der ender med at blive for vigtige til at man kan leve med risikoen.

Peter Makholm Blogger

Hvad skal få os til at tro at verden nu er klar?

Jeg skal måske lige uddybe at min kommentar ikke så skal læses som "tried that and failed, will never work" men som "tried that and failed, did we learn anything useful for next time?"

Et svar kunne netop være der skal være en større opmærksomhed på at dette ikke på magisk vis fjerner behovet for fagfolk, men kræver folk med kompetance til at lave den risikovurdering som Casper skriver om.

Et andet svar kan simpelthen være at vi er blevet bedre til at lave brugergrænseflader som gør det lettere at designe den ønskede slags produkter.

Gert Madsen

IT-afdelingens ansvar består i at følge med i hvad citizen developers laver

Jeg tror at det vil være en fejl at fjerne det ansvar fra den relevante liniechef.

Hvordan skulle IT-afdelingen kunne vurdere hvornår feks. et regneark er så vigtigt at det kræver handling ?

Man skal huske på at det kendetegnende for den slags applikationer er at enhver bekrivelse, vejledning og dokumentation er fraværende.

Casper Kvan Clausen

Jeg mener ikke at IT bør føre minutiøse protokoller, men at de skal være opmærksomme på hvad der foregår, og tage fat hvor det er relevant. Ikke mindst fordi løsningerne reflekterer forretningskrav, der næppe tilflyder udviklingsafdelingen på anden vis (de er jo opfyldt af den hjemmestrikkede løsning).

Linjelederne bør ultimativt have ansvaret for risikoen i deres processer, men hvis IT-afdelingen spiller med kan risikovurderingen blive bedre, og udfordringer adresseret tidligere, til gavn for alle. Det er min erfaring at mange linjeledere (i hvert fald på teamlederniveau) er gode til at vurdere konsekvensen ved tabet af en løsning, men undervurderer den tekniske risiko.

Der er også et simpelt ressourcemæssigt hensyn: hvis ikke IT-afdelingen selv har fingeren på pulsen, bliver den først opmærksom på evt. problemer sent. Det kan give prioriteringsproblemer og medføre større risiko i længere tid end nødvendigt.

Casper Kvan Clausen

Mht. værktøjer mener jeg at den vigtigste lektie er denne: folk bruger hvad de kender (og du kan ikke forudsige hvad de kender). Jeg tror langt hen ad vejen det er spild af tid og penge at stille specielle værktøjer til rådighed til citizen development. Dermed ikke sagt at man ikke skal opfylde konkrete behov, men det skal være drevet den vej rundt.

Henrik Schmidt

Jeg har svært ved at se for mig, hvordan en IT-afdeling skal holde styr på den slags projekter. Projekterne er jo startet fordi der ikke har været resourcer til at lave dem i IT afdelingen til at begynde med.

Hvis det er kodet på hobby-niveau, så er der jo en reel risiko for, at når det holder op med at virke, så holder det for alvor op med at virke. Måske afhænger det af en bestemt version af Access. Måske kan det kun køre på Windows XP. Det kan skalere dårligt, eller der er risiko for data-inkonsistens, såfremt to brugere gør det samme på samme tid, fordi det var et enkeltbrugersystem fra starten af.

Den slags opdager du først, når det er gået galt, og der er en vis sandsynlighed for, at det vil kræve en komplet omskrivning for at få koden op på et kvalitets- og vedligeholdsesniveau som en IT-afdeling kan leve med.

Log ind eller Opret konto for at kommentere