Att köpa och driva mjukvaruprojekt
Mjukvaruguiden, del 1

Att köpa och driva mjukvaruprojekt

Att beställa och äga ett mjukvaruprojekt är enklare än vad man kan tro, med rätt arbetssätt och team. Hur ser processen ut när ett bolag utan egen mjukvaru­kompetens går in i en process för att utveckla en digital produkt med oss?

Allt fler bolag som traditionellt inte arbetat med digitala produkter ger sig nu in i att utveckla och äga just sådana – vi har själva hjälpt flera bolag i industrisektorn (exempelvis Lövånger bygg, som du kan läsa om här) att lansera sina första digitala produkter. Därför har vi också sett hur många frågetecken som kan uppstå inför arbetet och hur osäkert det kan kännas. Det är ju en helt ny värld att ge sig in i med begrepp, processer och frågeställningar.

För dig som funderar över vad som skulle krävas av din organisation för att ni också skulle kunna ta klivet till att bli ett mjukvarubolag, går vi därför här igenom vilka roller som är inblandade och hur processen ser ut ur ert perspektiv som beställare.

Oftast använder vi en s.k. agil utvecklingsprocess (till skillnad från en mer traditionell vattenfallsprocess). Den agila processen har många tydligt definierade moment, men de flesta berör endast oss som teknikleverantör. Här kommer vi endast att dyka ned i de tre moment där ni som kund är delaktiga:

  • Scope workshop
  • Sprintplanering
  • Sprintutvärdering

Vilka roller är inblandade i ett teknikprojekt?

Innan vi tittar på de tre centrala momenten, ska vi sortera ut vilka roller som krävs för att få processen att flyta så bra som möjligt. Centralt här är att ni faktiskt inte behöver lära er ett uns om att bygga digitala produkter för att kunna äga en i världsklass. Ni står för ämneskunskapen och tar besluten – resten sköter vi. I våra utvecklingsprojekt strävar vi alltid efter att så tydligt som möjligt etablera vem som har vilken roll, så att ni vet vad alla inblandade från vår sida gör och vad ni förväntas stå för.

Roller hos er:

Produktägaren. En person (inte flera!) hos er som har mandat att fatta beslut som rör produkten och som avgör bästa vägen framåt. Den personen kan givetvis ta in åsikter från många håll, men den måste ha beslutsmandat och därmed en övergripande förståelse för er affär, visionen med produkten och processen. Produktägaren är också den som prioriterar tid och resurser, givetvis med all stöttning som efterfrågas från vår Design Lead.

Intressenter. Flera personer från er sida kan vara inblandade som “intressenter”. Det kan vara ledare med stor insikt i slutkundens behov, ämnesexperter, marknadschefen, kundtjänstchefen, ekonomiskt ansvariga etc. Input från flera håll är välkommet – så länge det är tydligt vem som är produktägare med sista ordet.

Roller hos oss:

Design Lead. Personen från vår sida med övergripande ansvar och den som faciliterar möten och kommunikation mellan oss och er. Hen designar produkten och gör också användartester. Om ni inte vet vem ni ska gå till med en fråga, kan ni alltid gå till Design Lead.

Tech Lead. Personen med det tekniska ansvaret hos oss. Ytterst ansvarig för att systemet som driver den digitala produkten dag ut och dag in fungerar. Hen kommunicerar också med och leder våra utvecklare och planerar det tekniska utvecklingsarbetet.

Utvecklare. Utvecklarna är de som faktiskt sitter och skriver koden som formar produkten. Oftast har varje utvecklare en specialisering inom någon del av hela det tekniska pusslet, såsom 3D-grafik, front-end (ansvarig för funktionaliteten som användarna interagerar med) eller back-end (ansvarig för grundläggande programmering som gör att allt fungerar i bakgrunden).

Account. Inte inblandad i utvecklingen av själva mjukvaran men däremot ansvarig för alla affärsmässiga frågor i relationen såsom offerter, avtal och förhandlingar.

Agil utveckling – att loopa sig framåt

Den agila utvecklingsprocessen ger lättgreppade utvecklingsprojekt, där ni bara behöver hantera den mängd planering som är aktuell för stunden. En digital produkt byggs upp del för del och ni som kund har mycket input längs vägen och stora möjligheter att styra riktningen allt eftersom ni ser produkten ta form. Detta tack vare att arbetet sker enligt en loopande process som genomförs igen och igen – potentiellt så länge som ni erbjuder den digitala produkten till era kunder.

Vi utvecklar och förfinar ständigt vår process; i nuläget ser den i sin helhet ut så här:

Den huvudsakliga pusselbiten i den agila loopen är sprinten. En sprint är en avgränsad period i utvecklingscykeln – på omkring 2 till 3 veckor – då teamet utför det som bestämts i en sprintplanering. Det är i sprinten nya funktioner tas fram och byggs in i den digitala produkten. Hur mycket nytt som byggs in i varje sprint beror lite på var i projektet man är och produktens natur.

Sprinten och flera av de andra momenten innebär dock endast arbete för oss som leverantör. Som beställare finns ni med i hela processen i en kontinuerlig dialog, men rent kalendermässigt är det tre huvudsakliga moment ni behöver boka in och ha koll på – de ska vi zooma in på nu.

1. Scope Workshop – så startar vi

Det första vi gör tillsammans är en “Scope workshop”. Detta uppstartstillfälle tar bara en halvdag och ingår inte riktigt i loopen; det är ett engångs-tillfälle för att starta processen. Det är också det enda ni initialt köper; visar den workshopen att förutsättningarna för ett digitalt utvecklingsprojekt inte är bra, då kanske vi hjälper er att helt tänka om med nytt upplägg eller bara rakt av avslutar samarbetet.

Målet med workshopen, är att lägga grunden för den digitala produkten. Ni får berätta om er vision, om era kunder och vilka behov ni sett. Vi ställer en massa frågor, dokumenterar och försöker se att alla byggstenar finns på plats alternativt identifiera vilka som saknas. Konkreta resultat från dagen är:

Produktvisionen påbörjad. Visar tydligt vad ambitionen med produkten är och utgör målbild i arbetet.

“Roadmap” påbörjad. En roadmap är en utvecklingsplan som visar hur produkten skulle kunna ta form över tid. Vad händer ungefär när?

Användarberättelser. Visar vilka olika typer av användare ni vill tillmötesgå och vad deras behov är. Med hjälp av användarberättelser kan en idé för produkten specificeras med fokus på vilket resultat en viss funktion ska leverera för denna användare.

Efter den här halvdagen, har vi allt vi behöver för att börja jobba tillsammans – eller för att gå skilda vägar.

2. Sprintplanering

Nästa steg i vår process tillsammans, är att göra en första sprintplanering. Sprintplaneringarna är sedan också återkommande i processens loop.

Vad går det här mötet ut på? Se det som ett ordentligt planeringsmöte som ger den kommande sprinten bästa möjliga förutsättningar att lyckas. Konkret är det här vi bestämmer vilka nya funktioner som ska prioriteras i kommande sprint. Det viktiga för oss är att ni tack vare sprintplaneringen vet vad som ska hända den kommande sprinten och har total klarhet i vem som gör vad.

Ni som kan produkten och känner kunden bäst bidrar med den kunskapen under mötet, så ansvarar vi för att det tekniska ska gå ihop och för att omfattningen på sprinten är vettig. Planeringen går snabbare och resultatet blir bättre om en sprint inte försöker gapa över för mycket. Då är det bättre att hålla sprintar och tillhörande planering kortare och istället ha fler sprintar.

Utöver att bestämma hur lång sprinten ska vara, bokar vi på sprintplaneringen in kommande möten, workshops och avstämningar samt en utvärdering av sprinten (s.k. sprint review). Det gör att ni lämnar sprintplaneringen med koll på allt som händer härnäst.

Sprintutvärdering

Utvärderingsmötet efter varje sprint är nästa stora hållpunkt för er. Vi vill lyfta fram tre huvudsakliga syften med mötet:

  1. Fira framgångar

Vi tar en stund och bekräftar vad som är avklarat och belyser vad som blivit bra. Det är viktigt att faktiskt blicka tillbaka och konstatera vad som är gjort, så att man inte fastnar i vad som inte riktigt hunnits med eller vad som ska göras härnäst.

  1. Utvärdera arbetssätt

Under utvärderingen belyser vi också allt som inte har direkt med produkten att göra. Hur fungerar arbetet och kommunikationen i teamet? Hur vi arbetar tillsammans ska diskuteras och utvecklas för varje sprint, så att inte dåliga vanor blir rutin eller frågor från er sida lämnas hängande och växer till orosmoln. Här är vi aldrig rädda för att lyfta problem, så länge tonen är konstruktiv.

  1. Stärka relationen

Under sprintutvärderingen samlas många inblandade från vår och er sida och de brukar vara ett ypperligt tillfälle för frågor och svar om högt och lågt, gärna över en fika. Oftast finns nya funktioner att demonstrera vilket alltid blir en bra samlingspunkt – låt alla som är intresserade av produkten komma och få inblick i hur utvecklingen går. Ju fler sprintutvärderingar vi samlas för, desto starkare bli relationen.

Alla kan bli digitala produktägare

Vi vill att så många bolag som möjligt, som kanske inte traditionellt sysslat med mjukvara, ska kunna ta del av digitaliseringens möjligheter och konkurrera med användarvänliga digitala produkter. Genom den lättgreppade process med tydliga roller som vi beskrivit ovan ser vi att det är möjligt.

Lär dig mer om hur Lövånger byggs kliv till att erbjuda en digital produkt lyft dem till en ny nivå.

Har du idéer eller funderingar kring nya tekniska lösningar som du vill diskutera med oss?