Mød softwareingeniøren bag MobilePay

De fleste danskere kender i dag MobilePay – betalingsløsningen der gør det let at dele regninger og overføre penge via mobilen. Til gengæld er de færreste formentlig klar over, at den ene halvdel af duoen, som igangsatte udviklingen af den populære løsning, er ingeniør.

Rasmus Korsgaard hedder han. 33-årig softwareingeniør fra Aalborg Universitet i 2007 og i dag projektleder for et MobilePay-team på sammenlagt 30 mennesker.

Udviklingen af app’en begyndte i slutningen af september 2012 med et kort slideshow fra bankens forretning – i øvrigt med inspiration fra lignende løsninger hos blandt andre PayPal og britiske Barclays.

Kerneteamet bag den første version bestod af 10-15 mennesker – ingeniører, dataloger og bankfolk – men undervejs var flere end 100 ansatte alene fra Danske Banks IT-enhed involveret. Dertil kom de eksterne udviklere og designere af app’en. Og da den første version blev sendt på gaden 6. maj 2013, overraskede succesen alle:

»Da vi oprindeligt så det første designoplæg, troede vi på, at vi havde fat i noget stort. Mit eget bud var, at vi i løbet af det første år kunne få 300-400.000 brugere. I stedet har vi nu rundet 1,4 millioner,« fortæller Rasmus Korsgaard.

Vil ikke risikere at ende som Nokia

Den største udfordring undervejs har været hastighed:

»Vi har hele tiden vidst, at vi skal udvikle utrolig hurtigt for ikke at blive overhalet. Der har det, særligt i begyndelsen, været en fordel, at vi var et lille og meget dedikeret team, som kunne rykke hurtigt. Samtidig har vi rent juridisk skulle få løsningen til at passe til en lovgivning, som ofte er udviklet, før iPhone blev opfundet.«

Nu sætter Danske Bank sin lid til first-mover-effekten:

»MobilePay er helt klart en gamechanger, når det handler om betalings-infrastrukturen i Danmark. Og havde vi ikke selv udviklet løsningen, ville vi om få år risikere at stå som Nokia, da iPhone kom på markedet. De helt store konkurrenter som Google og PayPal har jo allerede udviklet lignende produkter, de satser bare ikke for alvor på Danmark endnu,« vurderer han og uddyber:

»Google+ er aldrig blevet nogen stor succes i Danmark, fordi alle i forvejen var på Facebook. På samme måde håber vi på, at kunderne vil holde fast i MobilePay, når PayPal for alvor når til det danske marked.«

Ingeniører skal også tænke forretning

Du lyder nærmest mere som forretningsmand end som ingeniør?

»I mine øjne er det utrolig vigtigt, at vi som ingeniører griber muligheden for at tænke forretningsmæssigt fra starten, fordi det giver os en mere central placering i projekterne.«

Og tanken om at være med hele vejen har præget Rasmus Korsgaard tilbage fra før studietiden:

»På universitetet valgte jeg softwareingeniør frem for datalog, fordi det var mit indtryk, at softwareingeniøren i højere grad bliver benyttet til at udvikle færdige produkter end datalogen, der typisk koncentrerer sig om specifikke dele som en smart algoritme og andre tunge matematiske opgaver. Derfor kom tankegangen i Danske Bank heller ikke som nogen overraskelse for mig.«

Kunden skal komme før koden

En anden lære af arbejdet med MobilePay har været, hvor meget pote det giver at have brugernes behov som en rettesnor fra begyndelsen:

»Ved at tage udgangspunkt i et brugerscenarie, og først derefter overveje om der skal kodes på mainframe, eller om løsningen skal involvere Java, øger du sandsynligheden for, at kunderne tager den færdige løsning til sig, fordi den er udviklet med dem for øje. Det er netop simpliciteten, som er den store forbedring med MobilePay,« mener han.

Denne artikel er den anden i serien ‘Der står en ingeniør bag’.

Læs også: Danske ingeniører spotter mælke-snyd

Du kan også være med til at ‘engineer the future’. Læs mere og tag del i debatten på ing.dk/etf.

Posted in computer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>