En langtidsholdbar løsning til LokalBolig

Et partnerskab

På det allerførste møde blev LokalBolig overraskede over den manglende pitch og PowerPoints. Mest af alt oplevede LokalBolig en masse spørgsmål. Ikke spørgsmål til hvad der skulle udvikles, men spørgsmål om LokalBoligs forretning, ansatte, kunder, procedurer, økonomi, drømme, idéer mv. 

"Jeg faldt næsten ned af stolen, da I fortalte, at I først skulle se, om vi ville passe som kunde til jer!"

Christian Møller Andersen, direktør i LokalBolig.  

Den tilgang skabte genklang, da den svarer til den LokalBolig selv har, når de skal vurdere nye mæglere som ønsker at starte butik op i LokalBolig-kæden. De søger noget dybere end floskler og umiddelbare salgsevner og siger derfor selv nej til flere, end de siger ja til.

Ledelsen i LokalBolig ledte efter et strategisk partnerskab, ikke en leverandør, og det var den tilgang, de fandt hos Reload. Der kom ingen lovning på leverance af et specificeret produkt, men til gengæld en lovning på et stjerne-team som 100% dedikeret ville arbejde for at realisere flest mulige af LokalBoligs ønsker og drømme. 

Det betød, at LokalBolig skulle indgå i et tæt samarbejde, kun baseret på tillid, fra dag ét. Det faldt heldigvis ikke LokalBolig svært, da de er vant til at give konsulenter mandat. Der var plads til at udforske og tage fejl. De gode argumenter talte, og ingenting blev dikteret af projektplaner eller højere lag i organisationen. LokalBolig er værdidrevne, sætter integritet over alt andet og har en stærk vision. Hurtigt faldt vi for LokalBoligs værdier som passede så godt til vores egne. 
Men med meget tillid kommer et stort ansvar.   

Visionen 

Den primære opgave var at få LokalBoligs webløsninger konsolideret og fremtidssikret. Det som allerede virkede godt, skulle flyttes over på en ny stabil og fleksibel kvalitetsplatform, som kan udvikles og tilpasses til en foranderlig verden i årene frem.

Derefter skulle vi finde ud af, hvordan LokalBoligs forretning kunne understøttes endnu bedre. Ejendomsmæglere sælger boliger, men det at få solgt boligerne er faktisk ikke så svært i øjeblikket, så den primære opgave er at få endnu flere boliger til salg. 

Gøres det i virkeligheden bedst ved at vise, hvor dygtig man er til at sælge boliger? Skulle vi fokusere på markedsføring til boligsælgere som manglede at opdage LokalBoligs services? Eller skulle vi hellere bruge vores tid og energi på at opsamle interessant data og derved klæde ejendomsmæglerne endnu bedre på til yde den bedste service ved det personlige møde? Eller kunne det tænkes, at det bedste var at sikre, at de rigtige henvendelser blev besvaret af de rigtige medarbejdere lynhurtigt?  

Discovery og Delivery 

Vi gik ind i udviklingsarbejdet med rigtig mange åbne spørgsmål og sideløbende med, at prioriterede idéer blev realiseret, var der mange spørgsmål, der fortsat skulle undersøges og besvares.

Idéer er altså blevet dræbt i processen, ligesom nye er kommet til. Fokus har hele tiden været på formålet, og hvilken værdi de forskellige tiltag kunne forventes at skabe for LokalBolig i sidste ende. Derfor arbejdede vi ud fra en række input og beregninger på, hvad de forskellige konverteringer egentligt var værd for LokalBolig. 

Hvis x % af alle henvendelser om salgsvurderinger ender med et personligt møde, og x % af alle møder ender med et boligsalg, og et boligsalg i snit genererer x kr. i værdi - så har vi et bud på, hvad en henvendelse er værd. Hvis vi også har et bud på, hvor mange flere henvendelser vi tror, vi kan generere ved at udvikle en ny feature, så har vi et ret velfunderet input til et bæredygtigt udviklingsbudget.

Lokale landing pages blev dræbt

Vi havde på et tidspunkt en idé om at lave landingpages med indhold om lokalområder for at markedsføre det lokale kendskab bedre og for at øge SEO værdien, da den slags indhold kan leve længere, end en bolig til salg typisk kan. Vores største tvivl var, om der kunne autogenereres nok relevant indhold til ikke at være afhængige af eksterne indholdsleverandører.

I mellemtiden lancerede en konkurrent deres “Mit Nabolag” hvilket i sig selv gjorde det mindre værd for LokalBolig at satse på samme type feature. Samtidig blev vi bekræftet i vores tvivl om, hvorvidt vi ville have et tilstrækkeligt datagrundlag for relevant autogenereret indhold. Vi var bange for, at det ville give bagslag, og at LokalBolig nærmest kunne se ud til at mangle lokalkendskab med udmeldinger á la “Folk der bor i Kastrup er 46 år i gennemsnit og glade for at fotografere”, og ideen blev derfor dræbt for nu.

Unikke selling points 

En helt oplagt ting at udnytte var til gengæld det meget tætte og stærke samarbejde med en anden af LokalBoligs tætte partnere Esoft som bl.a. leverer tekster, film og billeder i forbindelse med boligsalg. Esoft kender LokalBoligs forretning rigtig godt og kunne være aktivt med i udviklingsteamet hele vejen igennem. 

En flot mediebåret boligpræsentation blev derfor prioriteret. Idéen har været at hive de boligsøgende ud af den evige fotokarussel og i stedet give dem en magasinoplevelse med tekst og billeder der hænger sammen og en medieoplevelse med interaktive videoer og panorama.

Derfor har det været absolut essentielt, at alle parter har arbejdet sammen som et ligeværdigt team og sørget for, at medier og webplatforme blev visuelt alignet og udformet på en måde, så det spiller bedst muligt sammen.
   

Et GDPR kapløb

GDPR pustede os i nakken og sideløbende med, at vi udviklede Lokalboligs nye webplatform blev dele af det bagvedliggende boligssystem skiftet ud, for efter 25. maj 2018 måtte henvendelser ikke mere gemmes og behandles på den gamle webløsning og brugere måtte ikke mere logge ind på den. 

Det skulle i stedet ske i den nye Mit Lokalbolig App som det tidligere website ikke kunne kommunikere med. Det betød derfor, at mæglerne indtil lancering af det nye website manuelt måtte flytte alle henvendelser over i det nye system, indtil vi lancerede den nye løsning. Den nye løsning er bygget til at sende henvendelser videre automatisk, en feature vi aldrig havde en ærlig chance for at specificere og estimere up front, da hverken systemet eller den nødvendige dokumentation var tilgængelig dér.

Et hårdt “time to market fokus” kom derfor til, hvor udviklingsøkonomien blev mindre vigtig end kalender-tiden, så trods mere overhead time blev teamet udvidet, så vi kunne nå i mål med det nødvendige så hurtigt som muligt.

Teknologien

Fra begyndelsen var vi klar over at platformen til LokalBolig skulle opfylde tre behov:

• Fokus på brugeroplevelsen

• Fleksibilitet ift. fremtidige features og integrationer

• Få regressioner, høj oppetid og understøttelse af øget trafik i peak-perioder

Der var også et element af indholdsstyring ift. de enkelte butikker, men det stod klart, at mæglerne helst gerne så sig fri for at skulle redigere indhold direkte på websitet, hvis det kunne undgås. Derimod var det vigtigt, at grænsefladen for redaktører af sitet var let at gå til.

“Da vi stod overfor at skulle udskifte adskillige af vores mest forretningskritiske systemer samtidigt - havde vi altså ikke brug for en klassisk leverandør, men en fleksibel partner, der kunne agere på den virkelighed, vi stod i. Det samarbejde har vi opnået med Reload."

Christian Møller Andersen, direktør i LokalBolig

For at bevare et fokus på brugeroplevelsen valgte vi React som frontend framework. Pointen var at sikre muligheden for at bygge en tidssvarende og responsiv brugergrænseflade.

For at understøtte behovet for fleksibilitet faldt valget på en to-delt applikation med Drupal som backend og CMS, og React som ansvarlig for frontend. Samtidig lagde vi os fast på GraphQL som query-sprog mellem Drupal og frontend. Med Drupal havde vi et velkendt og robust fundament til at bygge integrationer og redaktørgrænseflade op omkring, og med kombinationen GraphQL + React gjorde vi det muligt at lægge en stor del af dataforståelsen (og dermed det meste af logikken omkring præsentation og fortolkning af data) ovre i frontend-laget. Det blev vores måde at sikre “Separation of Concerns”.

For at sikre en høj oppetid og god integration med vores udviklingsflow, anbefalede vi LokalBolig at hoste sitet via Platform.sh og deres Enterprise-service. Den leveres med en SLA og triple-redundant setup ovenpå Amazons cloud-infrastruktur. Her stødte vi på et af projektets større udfordringer, idet vi først sent blev gjort opmærksomme på, at vores todelte applikation ikke var understøttet af deres Enterprise-plan. Det gjorde det nødvendigt at samarbejde med Platform.sh om at bygge et deployment-værktøj der bandt vores udviklingsflow sammen med deres infrastruktur, sådan at vi kunne bevare vores arkitekt og samtidig deploye ny kode til platformen på en nem måde (via CircleCI).

Alt i alt har den valgte arkitektur taget et par drejninger undervejs, men pga. valget af platform og udviklingssetup har det været muligt at justere uden større problemer. 

En radikal agil tilgang

Det agile mindset har virkelig bevist sit værd med sin fleksibilitet og cost benefit fokus. Designprocesser skete sideløbende med udvikling med kun et overordnet oplæg på princip design. Vi har hele vejen igennem arbejdet med at skabe fulde, færdige funktionaliteter én for én frem for at tænke i færdige systemer.

Drift og udvikling flyder sammen

Lanceringen betyder ikke, at vi stopper med at udvikle, ambitionerne rækker videre, men det ville være skørt ikke at lancere det som er klart og kan generere værdi, mens vi fortsætter udviklingen. Så faktisk fortsætter vi i samme fart i nogle sprints efter lancering, fordi vi måtte skære et par hjørner meget hårdt for at nå i mål. 

Herfra kan vi så begynde at samle op på, hvordan den nye løsning fungerer og prioritere den videre udvikling ud fra reel feedback frem for gætteri.