Case: udvikling af nye funktioner til en medarbejderplatform i vækst (Ziik)

Denne case handler om udvikling af nye funktioner til Ziik, en medarbejderplatform i vækst med aktive kunder. Kort fortalt: [PLACEHOLDER: én sætning om hvad du byggede, og hvad det betød for Ziik og deres kunder]. Casen viser hvordan jeg arbejder når jeg træder ind i et produkt der allerede er i drift, og hvad du kan bruge hvis din egen platform står samme sted.

[PLACEHOLDER: bekræft at Ziik skriftligt har godkendt navn, omfang, tal og citat før udgivelse.]

Den korte version

Casen er skrevet fra min side af bordet. Den handler om at bygge i et eksisterende produkt, til dets kunder og i en kodebase, der fandtes før mig.

Udgangspunktet: en platform i drift der skal kunne mere

Ifølge Ziiks egen hjemmeside er platformen bygget til virksomheder inden for blandt andet detailhandel, hotel og restauration, transport og franchise. Det er en anden verden end et klassisk intranet på et kontor. Brugerne står i en butik, i et køkken eller på et lager med telefonen i hånden og få minutter mellem opgaverne. Kunderne er ofte kæder med mange lokationer, så hovedkontoret, den lokale leder og medarbejderen skal se forskellige ting.

For en udvikler betyder det tre ting:

• Roller og rettigheder er en del af næsten hver eneste funktion.
• Mobilen er hovedskærmen og skal fungere på en lille skærm med svingende forbindelse.
• En fejl rammer potentielt alle kunders medarbejdere på én gang.

Hertil kommer persondata. En medarbejderplatform indeholder navne, roller og beskeder om rigtige mennesker, og det er personoplysninger efter Datatilsynets definition. Hver ny funktion skal derfor også tage højde for hvem der må se hvad, og hvor længe data gemmes.

[PLACEHOLDER: Ziiks konkrete situation da du kom ind: hvorfor de havde brug for ekstra udviklerkraft, hvad der stod på roadmappen, og hvor stort teamet var.]

Opgaven: de funktioner jeg byggede

[PLACEHOLDER: 2-4 funktioner. For hver: hvad den gør for brugeren, hvem den er til (hovedkontor, leder eller medarbejder), og hvad der gjorde den svær at bygge eller udrulle.]

Før jeg skriver kode til en ny funktion i en platform som denne, vil jeg have svar på fire spørgsmål:

1. Hvem skal se og bruge funktionen, og hvem må ikke?
2. Hvad sker der med eksisterende data og kunder når den slås til?
3. Hvordan virker den på en lille telefonskærm med dårlig forbindelse?
4. Hvordan ved vi efter udrulning om den bliver brugt?

Spørgsmålene lyder banale, men de bliver let glemt når roadmappen er lang og tiden kort. Et uafklaret svar på spørgsmål 1 bliver typisk til en fejl hvor en medarbejder kan se noget kun lederen burde se.

[PLACEHOLDER: et konkret eksempel hvor et af spørgsmålene ændrede en funktion undervejs hos Ziik.]

Sådan arbejdede jeg i et produkt med aktive kunder

Når jeg træder ind i en eksisterende platform, bruger jeg de første dage på at læse kode, køre systemet lokalt og forstå domænet før jeg ændrer noget. I et Laravel-projekt bruger jeg fx Tinkerwell og Ray til at undersøge data og kode, og resten af værktøjskassen står i listen over mine udviklerværktøjer.

Derefter følger jeg typisk denne rækkefølge:

1. Afklaring. Hvad betyder "færdig"? Det aftaler jeg med den produktansvarlige før første linje kode.
2. Små leverancer. En funktion deles op så hver del kan gå i drift for sig, gerne bag et feature flag (en kontakt der slår funktionen til for udvalgte kunder først).
3. Test af det dyre. Automatiske tests dækker først det der koster mest hvis det går galt: rettigheder, notifikationer og adskillelse af data mellem kunder.
4. Teamets proces, ikke min. Code review (kodegennemgang), udrulning og dokumentation følger den måde teamet allerede arbejder på.
5. Opfølgning. Efter udrulning tjekker jeg fejllogs og brug så vi ved om funktionen virker i praksis.

[PLACEHOLDER: hvordan det konkret foregik hos Ziik: møderytme, værktøjer (fx GitHub, Jira, Slack), code review, hvem du refererede til, og hvad der fungerede eller ikke fungerede.]

Hvordan et forløb ser ud når jeg selv har ansvaret fra første møde til lancering, har jeg beskrevet i sådan foregår et projekt med mig. [PLACEHOLDER: én sætning om hvordan din rolle hos Ziik adskilte sig fra det, fx at teamet ejede prioriteringen og du leverede ind i den.]

Resultatet

[PLACEHOLDER: hvad funktionerne betød, med tal som Ziik har godkendt. Fx hvor mange kunder der fik funktionen, hvor meget den bliver brugt, færre supporthenvendelser eller tid sparet hos kunderne. Ingen tal uden godkendelse.]

[PLACEHOLDER: citat fra en navngiven person hos Ziik, godkendt ordret, med navn og titel.]

[PLACEHOLDER: hvad der gik mindre godt eller tog længere tid end ventet, og hvad du ville gøre anderledes i dag.]

Det kan du bruge hvis din platform vokser

En platform i vækst har næsten altid flere idéer end udviklere. Det fristende svar er at hente flere udviklere ind, men ekstra hænder hjælper kun hvis rammerne er på plads. Går det langsomt med en ny udvikler, er det værd at kigge på rammerne før du kigger på personen.

Det handler især om tre ting. Én person skal eje prioriteringen, ellers ender den eksterne udvikler med at gætte. Hver ny funktion skal også testes, supporteres og opdateres i årene efter, og at glemme den regning er en af 10 faldgruber ved SaaS-udvikling. Og en ny udvikler skal have adgange, testmiljø og dokumentation klar fra dag 1. Den del har jeg samlet i hvad du skal have klar når en freelanceudvikler starter.

Hvornår en freelancer ikke er det rigtige valg

Ekstra udviklerkraft udefra passer godt når der er en klar opgave og et team der kan tage imod. Det passer dårligt i disse situationer:

• Du har brug for en udvikler på fuld tid i mange år. Så er en fastansat typisk billigere og bedre forankret i virksomheden.
• Ingen internt ejer produktet. En freelancer kan foreslå prioriteringer, men kan ikke erstatte en produktansvarlig.
• Du har brug for vagt døgnet rundt. Én person kan ikke dække det, og en seriøs freelancer lover det heller ikke.
• Platformen er bygget i en stack jeg ikke arbejder i. Jeg arbejder i Laravel, PHP og moderne JavaScript som React og Next.js. Er din platform bygget i fx .NET eller Ruby on Rails, er en specialist i den stack et bedre valg.

Næste skridt

Står din medarbejderplatform eller SaaS et sted hvor kunderne efterspørger mere end teamet kan bygge, så start med at skrive de næste 2-3 funktioner ned. Notér hvem de er til, og hvad der sker hvis de ikke kommer. Det er nok til en første snak.

Hvordan jeg hjælper med at bygge videre på eksisterende produkter, kan du se under udvikling af webapps og platforme. Til større forløb starter jeg med et betalt forprojekt til fast pris så vi begge ved hvad der skal bygges før det store arbejde går i gang. Koden er jeres fra første dag.

Ofte stillede spørgsmål

Kan en freelanceudvikler arbejde sammen med vores eget udviklingsteam?+

Ja, og det er ofte den bedste model for en platform i vækst. Freelanceren arbejder i jeres kodearkiv, følger jeres code review og bruger jeres værktøjer til opgaver og kommunikation. Det virker bedst når freelanceren deltager i teamets planlægning og ikke kun får opgaver smidt over hegnet.

Hvor hurtigt kan en ny udvikler levere i en eksisterende kodebase?+

Det afhænger mest af kodebasen og dokumentationen. Min tommelfingerregel er at en erfaren udvikler bør kunne sætte en lille ændring i drift inden for de første par uger hvis adgange og testmiljø er klar. Er kodebasen udokumenteret eller uden tests, tager det længere tid, og så er det bedre at starte med en kort gennemgang af koden.

Hvem ejer koden når en freelancer bygger funktioner i vores produkt?+

Det bør I, og det skal stå i kontrakten. Hos mig ejer kunden koden fra første dag, og arbejdet foregår i kundens eget kodearkiv. Sørg også for at adgange til hosting, databaser og tredjepartstjenester ligger på jeres konti så I ikke er afhængige af en bestemt udvikler.

Skal vi have en databehandleraftale med en udvikler der arbejder i vores platform?+

Ofte ja. Får udvikleren adgang til produktionsdata med personoplysninger om jeres brugere, behandler udvikleren typisk data på jeres vegne, og så kræver GDPR en databehandleraftale. Arbejder udvikleren kun med anonymiserede testdata, er behovet mindre. Spørg en rådgiver hvis du er i tvivl om jeres konkrete situation.