Stakeholder-analyse i mobilappudvikling

I mobilappudvikling er succes ikke kun et spørgsmål om innovativ teknologi eller et slankt design. Det handler i høj grad om at forstå og imødekomme behovene hos dem, der påvirker eller påvirkes af appen. Dette er kernen i stakeholder-analyse, en kritisk proces, der sikrer, at dit projekt forbliver på sporet, inden for budgettet og leverer den ønskede værdi. At ignorere stakeholders kan føre til uforudsete problemer, scope creep og i værste fald en app, ingen bruger.

Hvad er Stakeholder-Analyse?

Stakeholder-analyse er en systematisk proces til at identificere alle personer, grupper eller organisationer, der har en interesse i eller kan blive påvirket af et projekt. I konteksten af mobilappudvikling involverer dette at finde ud af, hvem der har en investering i appens succes, og hvordan deres interesser stemmer overens med projektets mål. Det handler om at forstå deres roller, indflydelse, forventninger og potentielle bidrag eller hindringer.

Hvorfor er Stakeholders Vigtige i App-udvikling?

At involvere stakeholders fra starten er et af de mest effektive skridt, udviklere kan tage. Når virksomheder springer over denne fase, risikerer de at overse grupper, hvis støtte de har brug for senere. En grundig stakeholder-identifikation er derfor en bevidst proces, der skal ske i de tidlige faser af opdagelsesfasen (discovery phase). Uden input fra stakeholders arbejder udviklere med en ufuldstændig liste af krav. Overraskende behov kan opstå under udviklingen, hvilket fører til scope creep – hvor projektet vokser ud over sine oprindelige rammer. Dette tvinger de oprindelige tids- og budgetkrav til at strække sig, og ofte må funktioner skæres væk for at overholde deadlines.

Endnu vigtigere er risikoen for manglende adoption. Selvom softwaren lever op til ledelsens forventninger, kan medarbejderne simpelthen ikke bruge den. De har måske allerede mere effektive værktøjer, finder ud af, at den nye software mangler ønskede funktioner, eller de er ikke overbeviste om dens værdi. Denne mangel på entusiasme resulterer i en spildt investering, især for mindre eller nichegrupper, hvis behov ofte bliver overset. Selvom der er plads til nye krav under udviklingen, bør disse komme som svar på løbende feedback, ikke som en plaster på et svagt discovery-forløb.

Hvem Betragtes som Stakeholders?

Selvom hvert udviklingsprojekt er unikt, er der universelle kategorier, der kan guide stakeholder-identifikationen:

1. Slutbrugere og Modtagere (End Users and Beneficiaries)

Dette er de personer, der vil blive mest direkte påvirket af appen. Deres accept er essentiel. Uanset hvor smart eller effektiv en app er, vil slutbrugerne ikke bruge den, hvis de ikke kan lide den. Slutbrugere kan opdeles i tre hovedgrupper:

• Direkte Brugere: Disse personer bruger appen direkte og er oftest mest optaget af, hvordan den passer ind i deres nuværende arbejdsgange. De ønsker at vide, om appen løser et signifikant problem eller gør deres arbejde lettere.
• Sekundære Brugere: Direkte brugere interagerer med selve appen. Sekundære brugere er afhængige af appens produkter eller resultater. Ny software skal producere resultater i et format, der passer ind i de sekundære brugeres arbejdsgange. At glemme denne gruppe kan skabe et problem, mens et andet løses, f.eks. at generere rapporter i et format, som sekundære brugere ikke kan integrere i deres analyser.
• Modtagere (Beneficiaries): Dette omfatter alle, der påvirkes af appens produkter. Termen dækker en bred base af kunder og leverandører, der fokuserer mere på resultater end på processen. Deres input bør centrere sig om de tjenester eller informationer, appen vil levere.

2. Projektets Udviklingsteam (Project Build Team)

God softwareudvikling er en balanceakt mellem drømme og virkelighed. Slutbrugere kan nogle gange skabe en urealistisk liste af funktioner og krav. Udviklingsteamet fungerer som fornuftens stemme, der holder projektet inden for et håndterbart omfang. Deres opgave er at finde en måde at opfylde så mange af ønskelisterne som muligt, samtidig med at de opfylder forretningsmål og overholder tids- og budgetmål. Hvert medlem af udviklingsteamet har et forskelligt fokus:

• Ledelse og Virksomhedskontakter: Træffer de endelige beslutninger om tidsplan, budget og omfang. De er bemyndiget til at tilføje tid eller skære funktioner.
• Projektledere: Former udviklingsprocessen. De holder styr på alle bevægelige dele for at maksimere effektiviteten og fungerer som kontaktpunkt for andre stakeholders. Deres primære interesse er at skabe et solidt produkt og efterlade kunderne tilfredse.
• Udviklere: Bygger softwaren baseret på feedback fra andre stakeholders, men er også stakeholders i sig selv. De har den nødvendige teknologiske ekspertise til at rådgive ledelsen om, hvilke funktioner der er mulige, og hvor lang tid hver især vil tage at bygge.
• Partnere: Henviser her til eksterne grupper, der er involveret i selve udviklingsprocessen. Det kan være ejere af tredjepartsværktøjer eller en kundes forretningspartnere, der skal sikre kompatibilitet med deres systemer.

3. Myndigheder (Authorities)

Nogle personer er ikke direkte involveret i projektet, men har en form for autoritet over det. Dette inkluderer juridiske og regulerende organer, aktionærer og virksomhedsejere. Selvom de ikke har daglig interaktion med appen, styrer de dens anvendelse. Det er vigtigt at få deres input under opdagelsen for at undgå at blive lukket ned senere.

Interne vs. Eksterne Stakeholders

Hver af disse kategorier kan yderligere opdeles i interne og eksterne stakeholders.

• Interne Stakeholders: Er en del af klientvirksomheden: ledere, medarbejdere, bestyrelsesmedlemmer og aktionærer. Deres mål er at løse presserende forretningsproblemer gennem optimerede processer, øget salg, bedre indsigt eller en anden målbart fordel.
• Eksterne Stakeholders: Befinder sig uden for klientvirksomheden, såsom kunder, regulerende organer, juridiske embedsmænd og de omkringliggende samfund. De ønsker at opnå den største fordel fra projektet med mindst mulig risiko for deres egne interesser.

Begge grupper har tilsyneladende modstridende motiver, men i praksis er der et mellemgrund, hvor alle kan finde værdi. Samarbejde fra en mangfoldig gruppe af stakeholders er nøglen til at finde dette mellemgrund.

Identifikation af Stakeholders

At inkludere enhver individuel stakeholder i opdagelsesfasen ville være uhyre dyrt, både i tid og ressourcer. Heldigvis er det ikke nødvendigt. At vælge repræsentanter fra hver relevant gruppe giver et godt arbejdsmæssigt billede af projektets behov. Se på alle projektets faser, fra koncept til faktisk brug, for at identificere stakeholders.

Overvejelser ved Oprettelse af Stakeholderliste:

• Hvem vil bruge eller blive påvirket af det endelige produkt?
• Hvem bruger det nuværende værktøj eller software, som den nye software skal erstatte?
• Hvilke afdelinger bruger produkterne fra både det nuværende og det foreslåede software?
• Hvordan vil arbejdsgangene ændre sig? Vil stillinger blive ændret eller oprettet?
• Hvilke juridiske begrænsninger og regler gælder? Hvem ved nok om dem til at rådgive udviklingsteamet?
• Hvem har bemyndigelse til at foretage ændringer i udviklingsplanen, når den er færdiggjort?
• Er der nogen, hvis støtte er absolut vital for projektets succes? Hvem skal have deres køb?

Ofte bruges stedfortrædere (stand-ins) for eksterne stakeholders. Juridisk rådgivning kan dække regulerende organer og lokalregering, f.eks., og fokusgrupper fungerer som barometerer for offentlig opinion. Det er også nyttigt at overveje, hvem der ønsker, at projektet skal lykkes, og hvem der endnu ikke er ombord. At bringe en person, der er tilbageholdende med at adoptere ny teknologi, ind i stakeholder-teamet kan være en måde at give dem en følelse af ejerskab, der kan ændre deres mening. Tilsvarende kan entusiastiske støtter give energi til et projekt, som andre er usikre på.

Nøglespillere for Løbende Support

Interim fremdriftsmøder behøver ikke at omfatte alle stakeholders, hvis input bruges under opdagelsen. Udviklere kan indsamle krav og forslag fra en større gruppe i begyndelsen og derefter identificere nøglespillere til at give løbende feedback under udviklingen. Hvad adskiller nøgle-stakeholders? Se efter dem med to eller flere af følgende karakteristika:

• Vil have direkte kontakt med det endelige produkt (projektledere og slutbrugere).
• Er den øverste repræsentant for en gruppe vigtige stakeholders (afdelingsledere).
• Har unik viden eller indsigt, der kan forme udviklingsprocessen (fageksperter).
• Er så vitale for succes, at projektet ikke let kan lykkes uden deres støtte (ledere, forretningspartnere, slutbrugere).

Tænk over, hvis input eller godkendelse er nødvendig på løbende basis i modsætning til dem, der blot ønsker at godkende konceptet. Husk også, at stakeholders ikke behøver at møde op personligt for at blive inkluderet. Agile udviklingsmetoder som kontinuerlig levering åbner f.eks. døren for at indsamle regelmæssig feedback fra slutbrugere i form af funktionsanmodninger og anmeldelser.

Eksempel på Stakeholder-udvælgelse

Hvordan ser stakeholder-udvælgelse ud i praksis? Forestil dig en mellemstor detailhandler – lad os kalde dem ExampleCorp – der gennemgår en digital transformation. ECorp ønsker at gøre deres salgs-, marketing- og lagerdata tilgængelige for ledere i hele virksomheden. De beslutter at bygge et samlet rapporteringsdashboard, der indsamler indkommende analysestrømme og viser dem i et intuitivt, letforståeligt format. Hvem er deres stakeholders i dette projekt?

ECorp starter med at udarbejde en liste over alle, hvis input bør overvejes under opdagelsen. For dette analyseprojekt bør de konsultere:

• Ledelse
• Virksomhedskontakt
• Marketingteam
• Social Media Manager
• Salgsmedarbejdere
• Kundeserviceafdeling
• Juridisk afdeling (for rådgivning om databeskyttelsesregler)
• Administrativt personale, der aktuelt trækker rapporter
• IT-afdeling, der vil vedligeholde og træne i dashboardet (inklusive databaseadministrator)
• Virksomhedens aktionærer
• Projektledere
• Udviklingsteam

Deres nøgle-stakeholders, der deltager i fremdriftsmøder under udviklingen, er en mindre gruppe. Projektlederen, IT-teamet og virksomhedskontakten deltager stadig selv. Salgs-, marketing- og kundeserviceafdelingerne sender blot repræsentanter for at rapportere om, hvordan de seneste opdateringer modtages af slutbrugerne. Hvis en bestemt funktion læner sig kraftigt mod en bestemt afdeling, kan flere medarbejdere ønske at deltage, men ellers kan repræsentanterne bære bekymringer til møderne i stedet for, at hele teamet misser arbejde for at deltage.

Afsluttende tanker

Den indsats, der bruges under opdagelsesfasen, omsættes til penge sparet under udviklingen. Brug tid på at indsamle input fra alle stakeholders og høst fordelene af en glattere, mere fokuseret udviklingsproces. Hvis du kæmper med at udarbejde en omfattende liste over nøgle-stakeholders, er der ingen grund til at gå alene. Udnyt Conceptas årtier lange erfaring inden for appudvikling til at identificere de væsentlige spillere for dit projekt. Fra stakeholder-mapping til sofistikerede udviklingsmetoder tilbyder vi en 360-graders tilgang, der ikke kun hjælper med at identificere stakeholders, men også med at holde dem engagerede gennem hele projektets livscyklus.