Under utvikling · Simulerte demonstrasjonerLogg inn

Eksempler

Ulike utfordringer.
Et resultat å ta stilling til.

Se hvilke fagperspektiver en oppgave trenger, hva vurderingene bygger på og hvordan ditt valg endrer utkastet.

Dette er fire illustrative oppgaver, med forhåndsskrevne team og resultater. De er simuleringer av planlagt arbeidsform.

01 · Utvikling i en eksisterende løsning · Illustrasjon

Produktutvikling og koding

Vi har en enkel kundeportal og vil gi kundene oversikt over prosjektstatus. Vi trenger en avgrenset funksjon og et kodeutkast vi kan gjennomgå.

Det som holder arbeidet igjen

Kundene mangler status i portalen. Det er ikke avklart om neste milepæl skal inngå eller hvem som oppdaterer den.

Ønsket resultat

Et gjennomgåbart forslag til prosjektoversikt, med synlig kodeendring og tydelige kriterier før videre arbeid.

Foreslått leveranse

Brukerflate, kodeutkast og testgrunnlag for én avgrenset funksjon.

Kompetanse med et tydelig mandat

Retning og prioritering

Knytt funksjonen til kundens behov. Avklar om status og neste milepæl skal inngå i første versjon.

Maja · AI-profil

Fullstack-utvikling

Skisser frontend og datakontrakt. Vis kodeendringen og testtilfellene som følger med kundens valg.

Odexa · AI-rolle

Sikkerhet og tilgang

Avklar hvem som skal se prosjektdata. Beskriv tilgangskontrollen som må verifiseres på serveren.

Noah · AI-profil

Fra krav til en konkret prosjektoversikt

Forhåndsskrevet simulering

Teamets vurderinger

Produkt ønsker status og neste milepæl for å svare på kundens neste spørsmål. Utvikling anbefaler status først, fordi milepældata og vedlikeholdsansvar mangler.

Retning og prioritering

Maja · AI-profil

Status og neste milepæl kan gjøre oversikten mer nyttig. Jeg vil ha begge dersom milepælen har en tydelig eier og et pålitelig datagrunnlag.

Grunnlag: Den forhåndsskrevne eksempeloppgaven. Ingen kunder er intervjuet.

Forutsetning: Kunden trenger både dagens status og en forståelig retning videre.

Påvirker: Krav og akseptansekriterier

Fullstack-utvikling

Odexa · AI-rolle

Jeg anbefaler status først. Det gir et mindre kodeutkast og færre datakrav. Velger du milepæl, utvides datakontrakten og testgrunnlaget.

Grunnlag: Illustrert datakontrakt og kodeutdrag. Ingen eksisterende kodebase er koblet til.

Forutsetning: Prosjektnavn og status finnes allerede; milepældata er ikke avklart.

Påvirker: Brukerflate, kode og testgrunnlag

Sikkerhet og tilgang

Noah · AI-profil

Begge valg trenger kontroll av kundetilhørighet på serveren. Å skjule et prosjekt i brukerflaten er ikke tilstrekkelig tilgangskontroll.

Grunnlag: Eksempeloppgavens kundeportal. Ingen tilgangsregler er testet.

Forutsetning: Portalen viser prosjektdata som skal avgrenses til hver kunde.

Påvirker: Brukerflate, kode og testgrunnlag

Arbeidsresultat

Simulert utkast · v1

Fra krav til en konkret prosjektoversikt

1. Krav og akseptansekriterier

Kunden skal kunne forstå status for sitt eget prosjekt. Første versjon trenger lesbar status, håndtering av manglende data og verifisert kundetilgang. Milepældata må avklares dersom feltet tas med.

2. Teknisk ramme

Eksempelet viser et TypeScript/React-utdrag for brukerflaten og dataene den trenger. API, servervalidering, lasting og feilhåndtering inngår i videre arbeid; dette utdraget implementerer dem ikke.

3. Brukerflate, kode og testgrunnlag

Før omfanget er valgt, viser utkastet bare prosjektnavnet. Velg status alene eller status med neste milepæl. Valget oppdaterer brukerflaten, kodeutdraget og testgrunnlaget under.

Illustrert brukerflate · Eksempeldata

Kundeportal

Prosjekt: Ny nettside

Status avklares

ProjectStatus.tsx · Illustrert utdrag

type Props = { project: { name: string } };

export function ProjectStatus({ project }: Props) {
  return <h2>{project.name}</h2>;
}

Testgrunnlag · Ikke kjørt

  • Avklar hvilke statusverdier kunden skal se.
  • Avklar om neste milepæl inngår i første versjon.
  • Verifiser at prosjekter avgrenses til riktig kunde.

Forhåndsskrevet simulering. Ingen kode kjøres, tester utføres eller repository endres.

Beslutning kreves

Hva skal første versjon vise: status alene, eller status og neste milepæl?

Valget endrer «Brukerflate, kode og testgrunnlag» i en simulert v2.

Se begge beslutningsvalg

Status først

Bruk prosjektnavn og status. Neste milepæl utsettes; kundetilgang og feilhåndtering må fortsatt verifiseres.

Slik endres «Brukerflate, kode og testgrunnlag» i v2

Valgt omfang: vis prosjektnavn og status. Kodeutdraget får et statusfelt, og testgrunnlaget dekker visning, feiltilstander og kundetilgang. Ingen milepældata kreves i denne versjonen.

Illustrert brukerflate · Eksempeldata

Kundeportal

Prosjekt: Ny nettside

Status: Pågår

ProjectStatus.tsx · Endring fra v1

Før: bare prosjektnavn. Disse feltene og linjene er lagt til.

+ status: string;
+ <p>Status: {project.status}</p>
Se hele det illustrerte kodeutdraget
type Props = {
  project: { name: string; status: string };
};

export function ProjectStatus({ project }: Props) {
  return (
    <article>
      <h2>{project.name}</h2>
      <p>Status: {project.status}</p>
    </article>
  );
}

Testgrunnlag · Ikke kjørt

  • Vis prosjektets navn og status fra eksisterende datagrunnlag.
  • Avvis innsyn i en annen kundes prosjekt på serveren.
  • Håndter manglende status og feil ved henting av data.

Forhåndsskrevet simulering. Ingen kode kjøres, tester utføres eller repository endres.

Status og neste milepæl

Utvid datakontrakten med neste milepæl. Avklar datakilde og oppdateringsansvar før funksjonen tas i bruk.

Slik endres «Brukerflate, kode og testgrunnlag» i v2

Valgt omfang: vis prosjektnavn, status og neste milepæl når den finnes. Kodeutdraget får et valgfritt milepælfelt, og testgrunnlaget utvides. Datakilde og oppdateringsansvar må avklares før videre arbeid.

Illustrert brukerflate · Eksempeldata

Kundeportal

Prosjekt: Ny nettside

Status: Pågår

Neste milepæl: Designgjennomgang

ProjectStatus.tsx · Endring fra v1

Før: bare prosjektnavn. Disse feltene og linjene er lagt til.

+ status: string;
+ nextMilestone?: string;
+ <p>Status: {project.status}</p>
+ {project.nextMilestone ? (
+   <p>Neste milepæl: {project.nextMilestone}</p>
+ ) : null}
Se hele det illustrerte kodeutdraget
type Props = {
  project: {
    name: string;
    status: string;
    nextMilestone?: string;
  };
};

export function ProjectStatus({ project }: Props) {
  return (
    <article>
      <h2>{project.name}</h2>
      <p>Status: {project.status}</p>
      {project.nextMilestone ? (
        <p>Neste milepæl: {project.nextMilestone}</p>
      ) : null}
    </article>
  );
}

Testgrunnlag · Ikke kjørt

  • Vis navn, status og en bekreftet neste milepæl.
  • Skjul milepælfeltet når datagrunnlaget mangler.
  • Avvis innsyn i en annen kundes prosjekt på serveren.
  • Avklar hvem som holder milepælen oppdatert før funksjonen tas i bruk.

Forhåndsskrevet simulering. Ingen kode kjøres, tester utføres eller repository endres.

Det som mangler: Ingen kundedata, kodebase eller API er tilkoblet. Koden er et illustrert utdrag og er ikke kjørt. Testtilfellene har ingen beståttstatus. Datagrunnlag, brukerbehov og tilgang må verifiseres i et faktisk oppdrag.

Prøv dette eksempelet

Åpner det samme forhåndsskrevne teamet på forsiden. Ingen beslutning lagres eller handling utføres.

02 · Oppstart og produkt · Illustrasjon

Ny skytjeneste

Vi skal lansere en ny skytjeneste, men mangler teknisk arkitekt og en tydelig plan for første versjon.

Det som holder arbeidet igjen

For mange funksjoner før vi har testet én viktig brukerflyt.

Ønsket resultat

En avgrenset første versjon som kan testes med kunder, med tydelige tekniske rammer.

Foreslått leveranse

Pilotplan med teknisk skisse, avgrensning og åpne spørsmål.

Kompetanse med et tydelig mandat

Retning og prioritering

Avgrens første versjon. Samle kravene og avklar hva eieren må beslutte.

Maja · AI-profil

Systemarkitektur

Foreslå enkel arkitektur. Kartlegg dataflyt, avhengigheter og teknisk risiko.

Elias · AI-profil

Kunde og marked

Gjør kundebehovet konkret. Foreslå hva piloten bør teste før flere funksjoner bygges.

Solveig · AI-profil

Fra idé til en avgrenset pilot

Forhåndsskrevet simulering

Teamets vurderinger

En bredere kundetest gir mer å undersøke. En smalere pilot gir færre tekniske avhengigheter.

Kunde og marked

Solveig · AI-profil

Jeg vil teste to brukerflyter for å se hvilken kunden trenger mest. Det kan gi et bedre grunnlag for prioriteringen.

Grunnlag: Eksempeloppgaven. Ingen kundeintervjuer er gjennomført.

Forutsetning: De to flytene kan undersøkes med samme kundetype.

Påvirker: Avgrensning

Systemarkitektur

Elias · AI-profil

Jeg anbefaler én flyt først. To flyter kan kreve flere data og integrasjoner før vi har avklart tilgangen.

Grunnlag: Eksempeloppgaven. Datakrav er ikke kartlagt.

Forutsetning: En samlet tjeneste kan dekke den første flyten.

Påvirker: Teknisk retning

Retning og prioritering

Maja · AI-profil

Start med én flyt. Velger du to, må datakrav og ressursbehov avklares før bygging. Valget skrives inn i avgrensningen.

Grunnlag: De to illustrerte fagvurderingene over.

Forutsetning: Pilotens omfang avklares før arbeidet tas videre.

Påvirker: Avgrensning

Arbeidsresultat

Simulert utkast · v1

Fra idé til en avgrenset pilot

1. Mål for piloten

La en kunde fullføre én prioritert oppgave fra start til slutt. Bruk tilbakemeldingen til å velge neste steg.

2. Teknisk retning

Én samlet tjeneste med tydelig skille mellom brukerflate, tilgang og data. Integrasjoner avgrenses til det piloten trenger.

3. Avgrensning

Rapportering, flere kundesegmenter og avansert automatisering vurderes etter piloten.

Beslutning kreves

Velg én eller to brukerflyter for pilotens avgrensning.

Valget endrer «Avgrensning» i en simulert v2.

Se begge beslutningsvalg

Én brukerflyt

Avgrens piloten. Flere flyter og avansert automatisering utsettes.

Slik endres «Avgrensning» i v2

Valgt avgrensning: én prioritert brukerflyt fra start til slutt. Flere flyter, rapportering og avansert automatisering utsettes. Datakrav avklares før bygging.

To brukerflyter

Utvid kundetesten. Avklar ekstra datakrav og ressursbehov før bygging.

Slik endres «Avgrensning» i v2

Valgt avgrensning: to brukerflyter for samme kundetype. Ekstra datakrav, integrasjoner og ressursbehov må avklares før bygging. Rapportering og avansert automatisering utsettes.

Det som mangler: Kundeintervjuer, datakrav og kostnadsgrunnlag mangler. Arkitekturen er et illustrert utkast.

Prøv dette eksempelet

Åpner det samme forhåndsskrevne teamet på forsiden. Ingen beslutning lagres eller handling utføres.

03 · Små bedrifter og vekstselskaper · Illustrasjon

Lønnsom vekst

Vi får flere kunder, men lønnsomheten følger ikke med. Hva bør vi gjøre før vi ansetter flere?

Det som holder arbeidet igjen

Vi kjenner omsetningen, men mangler et bilde av lønnsomhet per kunde.

Ønsket resultat

Et beslutningsgrunnlag for lønnsom vekst før kapasiteten økes.

Foreslått leveranse

Beslutningsnotat med databehov, alternativer og en avgrenset kundepilot.

Kompetanse med et tydelig mandat

Retning og prioritering

Finn beslutningen som må tas. Hold tiltakene innenfor kundens mandat.

Ingrid · AI-profil

Økonomi og ressurser

Kartlegg kostnadsdriverne og hva som mangler før vi kan vurdere en ansettelse.

Torbjørn · AI-profil

Kunde og marked

Vurder kundeverdien og foreslå en liten pilot før priser eller tjenesten endres.

Solveig · AI-profil

Finn begrensningen før neste ansettelse

Forhåndsskrevet simulering

Teamets vurderinger

Økonomi vil avklare kostnadene først. Kundeperspektivet vil undersøke et tydeligere tjenestenivå parallelt.

Økonomi og ressurser

Torbjørn · AI-profil

Kartlegg tidsbruk og kostnader før vi utformer en pilot. Ellers kan vi teste et tjenestenivå som fortsatt gir svak lønnsomhet.

Grunnlag: Eksempeloppgaven. Ingen regnskapsdata er analysert.

Forutsetning: Tidsbruk og direkte kostnader kan fordeles per kundetype.

Påvirker: Første tiltak

Kunde og marked

Solveig · AI-profil

Jeg vil skissere en liten kundepilot mens kostnadene kartlegges. Da kan vi undersøke kundeverdien tidligere.

Grunnlag: Eksempeloppgaven. Kundebehov er ikke verifisert.

Forutsetning: Pilotutforming kan gjøres uten prisendring eller kundekontakt.

Påvirker: Avgrenset pilot

Retning og prioritering

Ingrid · AI-profil

Avklar kostnadene først. Du kan velge parallell pilotutforming, men ingen kundekontakt eller prisendring inngår i valget.

Grunnlag: De to illustrerte fagvurderingene over.

Forutsetning: Eksterne handlinger krever et eget mandat.

Påvirker: Avgrenset pilot

Arbeidsresultat

Simulert utkast · v1

Finn begrensningen før neste ansettelse

1. Beslutningen

Hva bør forbedres før kapasiteten økes? Skill mellom pris, leveranseomfang og arbeidsprosess.

2. Første tiltak

Samle tidsbruk og direkte kostnader for et lite utvalg kunder. Sammenlign med inntektene.

3. Avgrenset pilot

Test ett tydelig tjenestenivå. Ingen prisendringer eller kundekontakt utføres uten separat mandat.

Beslutning kreves

Velg rekkefølgen for kartlegging og pilotutforming.

Valget endrer «Avgrenset pilot» i en simulert v2.

Se begge beslutningsvalg

Kartlegging først

Vent med pilotutforming til kostnadsbildet er klarere.

Slik endres «Avgrenset pilot» i v2

Valgt rekkefølge: kartlegg tidsbruk, kostnader og inntekter først. Pilotutforming vurderes når kostnadsbildet er klarere. Ansettelse, prisendring og kundekontakt inngår ikke i dette steget.

Parallelle forberedelser

Skisser piloten samtidig med kartleggingen. Ingen kunder kontaktes.

Slik endres «Avgrenset pilot» i v2

Valgt rekkefølge: kartlegg lønnsomheten og skisser pilotkriterier parallelt. Piloten gjennomføres ikke i dette steget. Ansettelse, prisendring og kundekontakt krever egne beslutninger.

Det som mangler: Ingen kundedata eller regnskap er analysert. Alle vurderinger er illustrasjoner.

Prøv dette eksempelet

Åpner det samme forhåndsskrevne teamet på forsiden. Ingen beslutning lagres eller handling utføres.

04 · Fagmiljøer, universitet og forskning · Illustrasjon

Tverrfaglig prosjekt

Vi skal vurdere et tverrfaglig forskningsprosjekt. Vi trenger et felles kunnskapsgrunnlag og en realistisk avgrensning.

Det som holder arbeidet igjen

Ulike fagperspektiver bygger på forutsetninger som ikke er avklart sammen.

Ønsket resultat

Et felles forskningsspørsmål og en gjennomførbar plan for kunnskapskartlegging.

Foreslått leveranse

Prosjektnotat med hypoteser, kunnskapshull og kriterier for videre arbeid.

Kompetanse med et tydelig mandat

Retning og prioritering

Samle fagperspektivene og synliggjør hva prosjekteieren må avklare.

Amir · AI-profil

Forskningsmetode

Formuler hypoteser og skill mellom kildegrunnlag, antakelser og kunnskapshull.

Sana · AI-profil

Økonomi og ressurser

Avgrens ressursbehovet og vis hvilke kostnadsforutsetninger som må undersøkes.

Torbjørn · AI-profil

Et felles grunnlag før prosjektet utvides

Forhåndsskrevet simulering

Teamets vurderinger

En bredere faglig kartlegging kan fange flere perspektiver. En smalere kartlegging gir tydeligere ressursrammer.

Forskningsmetode

Sana · AI-profil

Jeg vil ta med flere fagperspektiver i første kartlegging. En smal avgrensning kan overse kunnskap som endrer spørsmålet.

Grunnlag: Eksempeloppgaven. Ingen vitenskapelige kilder er gjennomgått.

Forutsetning: Fagperspektivene kan sammenlignes med felles kildekriterier.

Påvirker: Kunnskapsgrunnlag

Økonomi og ressurser

Torbjørn · AI-profil

Avgrens første kartlegging før den utvides. Bredere dekning krever et tydeligere bilde av kapasitet og finansiering.

Grunnlag: Eksempeloppgaven. Ressursgrunnlag mangler.

Forutsetning: En mindre kartlegging kan vise hvor mer arbeid trengs.

Påvirker: Neste avgrensning

Retning og prioritering

Amir · AI-profil

Start avgrenset og registrer kunnskapshull. Velger du bredere dekning, må faglig kapasitet og tidsramme avklares først.

Grunnlag: De to illustrerte fagvurderingene over.

Forutsetning: Spørsmål og kildekriterier avklares før konklusjoner trekkes.

Påvirker: Neste avgrensning

Arbeidsresultat

Simulert utkast · v1

Et felles grunnlag før prosjektet utvides

1. Forskningsspørsmål

Formuler ett spørsmål som de ulike fagene kan undersøke sammen.

2. Kunnskapsgrunnlag

Definer kriterier for litteratur, datakvalitet og relevante fagperspektiver. Registrer motstridende funn.

3. Neste avgrensning

Velg en kunnskapskartlegging. Vurder videre prosjektarbeid når kilder, metode og ressurser er avklart.

Beslutning kreves

Velg omfanget for den første kunnskapskartleggingen.

Valget endrer «Neste avgrensning» i en simulert v2.

Se begge beslutningsvalg

Avgrenset kartlegging

Prioriter ett forskningsspørsmål. Registrer øvrige kunnskapshull.

Slik endres «Neste avgrensning» i v2

Valgt omfang: en avgrenset kunnskapskartlegging rundt ett forskningsspørsmål. Felles kildekriterier brukes, og andre fagperspektiver registreres som kunnskapshull for senere vurdering.

Bredere faglig dekning

Ta med flere fagperspektiver. Avklar kapasitet og tidsramme før start.

Slik endres «Neste avgrensning» i v2

Valgt omfang: flere fagperspektiver vurderes med felles kildekriterier. Faglig kapasitet, finansiering og tidsramme må avklares før kartleggingen starter. Ingen faglig konklusjon er trukket.

Det som mangler: Ingen vitenskapelige kilder er gjennomgått. Eksempelet demonstrerer arbeidsformen.

Prøv dette eksempelet

Åpner det samme forhåndsskrevne teamet på forsiden. Ingen beslutning lagres eller handling utføres.

Hva skal arbeidet gjøre mulig?

Fortell kort om behovet ditt. Se hvordan det første steget mot tilgang kan se ut.

Be om tilgang