📝 Legger til dokumentasjon for prosjektet
Co-authored-by: Markus A. R. Johansen <markus.aleksander.rakil.johansen@nav.no> Co-authored-by: Amalie Erdal Mansåker <amalie.erdal.mansaker@nav.no>
This commit is contained in:
Sindre Kjelsrud
parent
35d623cd96
commit
8e8f6e8a92
2 changed files with 452 additions and 53 deletions
|
|
@ -1,53 +0,0 @@
|
|||
# Dependencies
|
||||
|
||||
## Frontend
|
||||
|
||||
- Typescript
|
||||
> Javascript med typeing
|
||||
|
||||
- Next.js
|
||||
> React-basert frontend rammeverk
|
||||
|
||||
- TailwindCSS
|
||||
> CSS rammeverk bestående av små utility-klasser
|
||||
|
||||
- Axios
|
||||
> HTTP klient-rammeverk/bibliotek
|
||||
|
||||
- Aksel
|
||||
> NAVs design system som inkluderer ikoner, komponenter etc.
|
||||
|
||||
- useSWR
|
||||
> Bibliotek som forenkler datafetching over Axios
|
||||
|
||||
## Backend
|
||||
|
||||
- Kotlin
|
||||
> Moderne Java basert språk
|
||||
|
||||
- HikariCP
|
||||
> Database connection pool som etablerer forbindelser mellom database og backend
|
||||
|
||||
- PostgreSQL
|
||||
> SQL database rammeverk
|
||||
|
||||
- Ktor
|
||||
> Asynkron HTTP server ~ RESTAPI
|
||||
|
||||
- JUnit
|
||||
> Testrammeverk for backend i Kotlin
|
||||
|
||||
- Flyway
|
||||
> Databasemigrering rammeverk
|
||||
|
||||
- Exposed
|
||||
> ORM for å skrive SQL-spørringer i Kotlin
|
||||
|
||||
- Logback
|
||||
> Loggføringsbibliotek
|
||||
|
||||
## Build
|
||||
|
||||
- yarn
|
||||
|
||||
- gradle
|
||||
452
Dokumentasjon.md
Normal file
452
Dokumentasjon.md
Normal file
|
|
@ -0,0 +1,452 @@
|
|||
# Sprik
|
||||
|
||||
## Introduksjon
|
||||
Som en del av forarbeidet til utviklingen av Sprik ble det gjort omfattende dokumentasjon av behovet for en ny løsning, og hvordan en eventuell løsning ville være hensiktsmessig å utforme.
|
||||
|
||||
Dokumentasjonen er resultatet av brukerintervjuer, innsiktsarbeid, prototyping og funksjonalitetsprioritering.
|
||||
|
||||
Dokumentasjonen beskriver teknologien bak applikasjonen, referater fra innsiktsarbeidet, lenker til prototypeskissering i Figma, ROS og definerer problemet som Sprik skal løse.
|
||||
|
||||
## Innholdsfortegnelse
|
||||
|
||||
[Prosjekt plan](#prosjekt-plan)
|
||||
|
||||
- [Bakgrunnsinfo](#bakgrunnsinfo)
|
||||
|
||||
- [Problemdefinisjon](#problemdefinisjon)
|
||||
|
||||
- [Objective / Mål](#objective--mål)
|
||||
|
||||
- [Key Results](#key-results)
|
||||
|
||||
[Teknologier](#teknologier)
|
||||
|
||||
- [React & Typescript](#react--typescript)
|
||||
- [Aksel & TailwindCSS](#aksel--tailwindcss)
|
||||
- [Axios & Ktor](#axios--ktor)
|
||||
- [Kotlin](#kotlin)
|
||||
- [PostegreSQL & Flyway](#postgresql--flyway)
|
||||
- [HikariCP & Exposed](#hikaricp--exposed)
|
||||
- [JUnit & Cypress](#junit--cypress)
|
||||
- [Yarn & Gradle](#yarn--gradle)
|
||||
|
||||
[Kartlegging](#kartlegging)
|
||||
|
||||
- [Brukerintervjuer/tester](#brukerintervjuertester)
|
||||
|
||||
- [Utviklingsteam](#utviklingsteam)
|
||||
|
||||
- [Utvikler #1](#utvikler-1)
|
||||
|
||||
- [Utvikler #2](#utvikler-2)
|
||||
|
||||
- [Fagperson](#fagperson)
|
||||
|
||||
- [Saksbehandlere](#saksbehandlere)
|
||||
|
||||
- [Saksbehandler #1](#saksbehandler-1)
|
||||
|
||||
- [Saksbehandler #2](#saksbehandler-2)
|
||||
|
||||
- [Saksbehandler #3](#saksbehandler-3)
|
||||
|
||||
- [Saksbehandler #4](#saksbehandler-4)
|
||||
|
||||
- [Saksbehandler #5](#saksbehandler-5)
|
||||
|
||||
- [Brukerhistorier og ønsker](#brukerhistorier-og-ønsker)
|
||||
|
||||
- [Funksjonalitet basert på ønsker og problemløsning (MoSCoW)](#funksjonalitet-basert-på-ønsker-og-problemløsning-moscow)
|
||||
|
||||
[Jus & Ros](#jus--ros)
|
||||
|
||||
[Design](#design)
|
||||
|
||||
## Prosjekt plan
|
||||
|
||||
### Bakgrunnsinfo
|
||||
Når saksbehandlere oppdager feil eller avvik i sykepengeløsningen Speil må dette meldes til utviklingsteamet.
|
||||
|
||||
Vår oppgave var å få innsikt i utfordringer ved dagens løsning, behovene til saksbehandlere og utviklingsteamet, samt påbegynne en løsning basert på innsiktsarbeidet.
|
||||
|
||||
#### Utfordringer med dagens løsning
|
||||
- Dagens løsning for kommunikasjon mellom saksbehandlere og teamet er både treig og lang. Saksbehandler → Teams → Coach → slack → Teams
|
||||
|
||||
- Det er ikke tilstrekkelig tilgangskontroll for å verne om brukere (personvern), under innmelding av saker. Saker relatert til kode 6 og 7 brukere er veldig utsatte i dagens løsning da de kan formidles mot mange som ikke har tjenstlig behov for informasjonen.
|
||||
|
||||
- De fleste saksbehandlere har ikke direkte mulighet til å melde ifra om feil og feature requests hvilket kan føre til at mange feil går under radaren.
|
||||
|
||||
- Uoversiktlig presentasjon og formidling av saker fører til at saker rapporteres inn gjentatte ganger (dobbelt arbeid), at de kan glemmes bort, og i verste fall gå uløst.
|
||||
|
||||
- Det er et utydelig skille mellom feature-requests og innmeldte feil i dagens løsning.
|
||||
|
||||
- Det er vanskelig å se hvem som er egnet til å besvare
|
||||
|
||||
### Problemdefinisjon
|
||||
Applikasjonens formål er i henhold til oppgaveteksten:
|
||||
|
||||
> Lage en applikasjon der saksbehandlere kan melde inn feil/mangler/ønsker. Og potensielt en visning over hva som er meldt inn.
|
||||
>
|
||||
|
||||
> Feil med speil skal kunne gi både saksbehandlere og utviklere en raskere og bedre flyt i kommunikasjonen. Dette vil føre til at vi utviklere kan oppdage og rette opp i feil raskere. Det vil forhåpentligvis også føre til en bedre saksbehandleropplevelse.
|
||||
>
|
||||
|
||||
### Objective / Mål
|
||||
"Lage et fantastisk produkt som har ekstremt stor verdi for de fine saksbehandlerne og strålende utviklerne."
|
||||
|
||||
Dette mener vi at vi har fått til når:
|
||||
- 80% av saksbehandlere klarer å melde inn feil (KR1)
|
||||
- 75% av brukere synes Sprik er mer oversiktlig enn dagens løsninger (KR2)
|
||||
- Ingen uten tjenstlig behov har tilgang til persondata i innmeldte saker (KR3)
|
||||
|
||||
#### Key Results
|
||||
*KR1 og KR2:*
|
||||
- Ikke hatt brukertester med saksbehandlere der de får prøve å bruke applikasjonene selv grunnet mangel på tid. Derfor har vi ikke målbare tall.
|
||||
|
||||
*KR3:*
|
||||
- Har foreløpig ikke implementert tilgangskontroll.
|
||||
|
||||
*Fokus i sommer:*
|
||||
- Viktige saker første fire uker:
|
||||
- Få på plass basic funksjonalitet
|
||||
- Forstå hva tjenesten innebærer og illustrere dette i prototype
|
||||
- Få deploya applikasjonen i devmiljø
|
||||
- Viktige saker siste fire uker:
|
||||
- Ha en brukervennlig applikasjon
|
||||
- Et utvalg av brukere har begynt å teste/ta i bruk applikasjonen
|
||||
- Ha en overføringsklar dokumentasjonsbase
|
||||
- Implementere alle must-haves
|
||||
|
||||
## Teknologier
|
||||
|
||||
### React & Typescript
|
||||
Frontend applikasjonen bygges med React på TypeScript
|
||||
|
||||
### Aksel & TailwindCSS
|
||||
Applikasjonen er hovedsaklig bygget av komponentbiblioteket til NAVs designsystem Aksel, men egen styling gjøres gjennom utility-first rammeverket TailwindCSS. Tailwind sine små utilityklasser er kompatible med Aksel og gjør at styling går svært fort. Ikoner og farger er også hentet fra Aksel.
|
||||
|
||||
### Axios & Ktor
|
||||
Axios benyttes som HTTP klient-rammeverk for kommunikasjon med endepunkter i backend. Ktor er en asynkron HTTP server, som brukes som et HTTP API. Ktor hører til Kotlin språket.
|
||||
|
||||
### Kotlin
|
||||
Kotlin er et moderne javabasert språk. Applikasjonens backend er skrevet i Kotlin.
|
||||
|
||||
### PostgreSQL & Flyway
|
||||
Databasen er skrevet i PostgreSQL og i backenden brukes Flyway rammeverket for migrering av databasen slik at en enkelt kan gjøre endringer på databasen
|
||||
|
||||
### HikariCP & Exposed
|
||||
HikariCP danner en database connection pool mellom DB og backend. Exposed er jetbrains sin SQL-ORM for Kotlin, som brukes til å gjøre spørringer mot databasen. Sammen utgjør de kommunikasjonen mellom Backend og database.
|
||||
|
||||
### JUnit & Cypress
|
||||
JUnit er et Kotlin kompatibelt testrammeverk, og Cypress er et testrammeverk for frontend som kan utføre både komponenttesting og ende-til-ende testing. Cypress-axe er en pakke for cypress som kan brukes til UU-testing.
|
||||
|
||||
### Yarn & Gradle
|
||||
Yarn og Gradle er dependency-management verktøyene for frontend og backend applikasjonene.
|
||||
|
||||
## Kartlegging
|
||||
|
||||
### Brukerintervjuer/tester
|
||||
|
||||
#### Utviklingsteam
|
||||
|
||||
##### Utvikler #1
|
||||
- *Hva anser du som en utfordring ved å bruke dagens løsning (slack)?*
|
||||
- Utfordring at mange av saksbehandlerne ikke er på slack
|
||||
- Teams = møk
|
||||
- Delayed rapportering fordi det er en lang vei
|
||||
- Gjentakende rapportering av samme feil
|
||||
- Noen kan vurdere det som meldes inn før det går videre til teamet.
|
||||
- Usikker på om redteam er nødvendig i kommunikasjonsprosessen
|
||||
- Tråd kommunikasjonen er tungvinnt
|
||||
- Ting vi har avklart drukner i slack
|
||||
|
||||
- *Er det noe du er fornøyd med rundt dagens løsning?*
|
||||
- Redteam løsningen vi har i dag fungerer ganske bra, med tanke på å rotere på hvem som er redteam
|
||||
|
||||
- *Hva slags arbeidsflyt ønsker du å ha med ny løsning?*
|
||||
- Varslinger nice, ellers lite preferanser
|
||||
|
||||
- *Hva er spesielt viktig for saksbehandlere/utviklere/jurister/designer/… å få ut av en slik plattform.*
|
||||
- Vanskelig å fange opp hvor stor grad en feil skjer.
|
||||
- Jetbrains har en issue tracker med voting
|
||||
- De kan se hvilke feil som er meldt inn og saksbehandlere skal kunne vote opp spesiellt relevante cases for å se “hvor skoen trykker i systemet”
|
||||
|
||||
- *Hvilke data ønsker du skal være presentert om en sak i Sprik?*
|
||||
- Greit å ha med innmelder av en sak
|
||||
- Greit at utvikler kan labele saker mtp app og sann
|
||||
- Kunne generere lapper i Trello.
|
||||
|
||||
- *Hvordan kunne du sett for deg at dataen presenteres i sprik?*
|
||||
- Enkelt kunne skille feil og feature requests
|
||||
- Enkle detaljer
|
||||
- Sortere etter traction etc
|
||||
- Kanskje tenk gallery view, eller feed.
|
||||
- Type feil: Feilinfo, handlingsfeil, grensesnittsfeil etc.
|
||||
|
||||
##### Utvikler #2
|
||||
- *Feature requests*
|
||||
- Vanskelig å sørge for at saksbehandlere ikke blir demotiverte dersom endringene ikke skjer.
|
||||
- Feature voting side hvor man kan vote opp feature forslag
|
||||
- Lar utviklere se hvor skoen trykker
|
||||
- Veldig delte meninger
|
||||
|
||||
- *Hvilke behov ønsker du at applikasjonen skal dekke? (forstå hva folk vil bruke det til)*
|
||||
- “Jeg bruker appen når jeg er redteam”
|
||||
- Enkel måte å få vite om noe er galt, vite om noe haster eller ikke”
|
||||
- Ikke en stor blob med tekst men kategorisert og organisert.
|
||||
- Voting er bra for å se hva som er veldig aktuellt.
|
||||
- Hashtags/emneknagger/tags for å organisere i type feil → ser antall feil av en type.
|
||||
|
||||
- *Hvilken funksjonalitet er det viktig for deg at er med i applikasjon?*
|
||||
- “Feilen kommer lett frem”, “beskrivelse av casen” hadde vært enkelt med en kort tittel på problemet.
|
||||
- Oversikt over hva som er meldt inn tidligere
|
||||
|
||||
- *Hvilken funksjonalitet tenker du har mest verdi for deg? Altså hva er viktigst først?*
|
||||
- Å kunne kategoriesere hvilke feil man har
|
||||
- Få inntrykk av hvilke features som eksisterer samt muligheten til å komme med tilbakemelding.
|
||||
|
||||
- *Hva anser du som en utfordring ved å bruke dagens løsning (Slack)?*
|
||||
- Ikke god oversikt over hva som er meldt ifra før
|
||||
- Vanskelig å se hvem som passer til å svare på spm
|
||||
|
||||
- *Hva er den største av disse utfordringene?*
|
||||
- Vanskelig å ha oversikt over hva som er meldt inn (enklere med status, men tungvinnt).
|
||||
- Mistenker dobbelt arbeid
|
||||
|
||||
- *Er det noe du er fornøyd med rundt dagens løsning?*
|
||||
- Mulighet til å ta kontakt med saksbehandlere hvis det trengs (ved feks ønske om flere opplysninger)
|
||||
- Trådsvar - nais to have, ikke kritisk
|
||||
|
||||
- *Hva slags arbeidsflyt ønsker du å ha med ny løsning?*
|
||||
- Er en del felter som ville gjort det enklere (Dette går under data også)
|
||||
- Skjermbilde
|
||||
- Tags
|
||||
- AktørID
|
||||
- Egendefinerte tags
|
||||
- Kan være en utfordring med flere måter å definere et begrep (grunnbeløp vs G vs 6G)
|
||||
- Tildele til personer
|
||||
|
||||
- *Hva er spesielt viktig for saksbehandlere/utviklere/jurister/designer/… å få ut av en slik plattform.*
|
||||
- Unngå dobbeltarbeid
|
||||
- Sortere traction eller hvor kritisk det er
|
||||
|
||||
- *Hvilke data ønsker du skal være presentert om en sak i Sprik*
|
||||
- +aktøride
|
||||
- +skjermbilde
|
||||
- +tags
|
||||
- +tittel,
|
||||
- +status
|
||||
- +innmeldt saksbehandler
|
||||
- statusflagg?
|
||||
- forklarende bilde?
|
||||
- Saksnummer?
|
||||
- Beskrivelse?
|
||||
- innsender?
|
||||
- mer?
|
||||
|
||||
- *Hvordan kunne du sett for deg at dataen presenteres i sprik?*
|
||||
- Galleri-visning
|
||||
|
||||
- *Syntes du at redteam ordningen som et vaktlag skal implementeres videre? har du noe forslag*
|
||||
- Red team har tatt lang tid å få til å fungere
|
||||
- Er ikke nødvendigvis beste løsning
|
||||
- Handler om at man skal rullere for å få noen til å ta ansvar
|
||||
|
||||
##### Fagperson
|
||||
- *Hva er din opplevelse av dagens løsning?*
|
||||
- Skille mellom innspill og feil kan være litt uklart
|
||||
- Det er bra med direkte kontakt (fine med meldingstjenesten)
|
||||
- En del som meldes inn flere ganger
|
||||
- En del saksbehandlere man ikke har kontakt med
|
||||
|
||||
- *Hvorfor fungerer ikke dagens løsning?*
|
||||
- Ikke kontakt med alle saksbehandlere ~ saksbehandler-kanalen kan bli litt uoversiktelig
|
||||
- Viktig-info kanalen funker fint ettersom det kun kommer enveis-meldinger
|
||||
- Er nok en del feil som glipper (går under radaren/ikke blir meldt inn)
|
||||
|
||||
- *Hva er de største utfordringene i dagens løsning?*
|
||||
- Går under radaren
|
||||
- Hvorfor? Travel hverdag
|
||||
- Slack ikke optimal til oppfølging
|
||||
|
||||
- *Hva fungerer godt i dagens løsning?*
|
||||
- Funker bra at det er en direkte kontakt mellom saksbehandlere og utviklingsteam (ikke erstatte dette)
|
||||
- Gir ett forhold til brukeren og løsninga si
|
||||
- Mange ting som blir fiksa fortløpende
|
||||
|
||||
- *Hva er det viktigste for deg som (utvikler/saksbehandler/…) å oppnå med plattformen?*
|
||||
- Hjelpe dem med å jobbe med de riktige tingene
|
||||
- Slippe å bruke unødvendig tid
|
||||
|
||||
- *Hva tenker du er formålet med Sprik?*
|
||||
- Å fjerne gapet mellom saksbehandlere og utviklingsteam
|
||||
- Gapet = de som ikke er i Slack, ikke alle tør å poste i Slack (fører til lite kontakt)
|
||||
- Få flere informerte saksbehandlere
|
||||
|
||||
- *ukategorisert*
|
||||
- en ting som kunne vært kult hvis vi skal jobbe med målinger, kunne vært kult med temperaturmålinger for saksbehandling (hvordan trives du med å jobbe i speil, får du hjelp når du trenger det, hvordan har du det, hvordan er motivasjonen, målt over tid for å påvirke prouktet)
|
||||
- hvordan gjøres: brukt en vanlig helsesjekk i starten for å sjekke om de vil bruke denne, evt. spesiallaget noe i speil der det kommer en boble i speil eksempelvis hver fredag som tar 30sek å svare på
|
||||
- kunne forbedret dagens løsning
|
||||
- vanlig spørsmål og svar (q&a forum)
|
||||
- hvordan gjør jeg dette og dette
|
||||
- løsning: faq side
|
||||
- tips
|
||||
- intervjue de som ikke er i slack av saksbehandlere (ikke like mye innsikt, mer realistisk brukeropplevelse)
|
||||
- rammeverk å tenke på når vi skal arbeide:
|
||||
- kjapt å lage → tar lang tid å lage (x akse)
|
||||
- lav verdi ^ høy verdi (y akse)
|
||||
- lapper med forslag man plasserer på grafen
|
||||
- prioriterer kjapt å lage med høy verdi
|
||||
- redteam fungerer?
|
||||
- funker, men må kanskje gjøres på en annen måte ved ny løsning
|
||||
- det de blir tagga i blir oftest løst, men er fortsatt ting som kan forsvinne pga. mengden meldinger
|
||||
- ikke alle i redteam er like på, eksempelvis jurister, til å svare på saker
|
||||
|
||||
#### Saksbehandlere
|
||||
|
||||
##### Saksbehandler #1
|
||||
- *Hva skal vi kalle hvert element (lapp, feilmelding, feil)?*
|
||||
- Innmeldte feil (med parantes på)
|
||||
- *Hva syntes du om statuslappene?*
|
||||
- Likte statuslabelsa
|
||||
- Dropdown var veldig intuitivt
|
||||
- *For å holde oversikt over egne saker, syntes du det funker å bare bruke filtrering for dette? (evt. bruke egne farger for lapper eller labels)*
|
||||
- filtrering enten høyere eller venstre side, mer naturlig på venstresiden
|
||||
- egne saker → filtrer etter initialer
|
||||
- filtrer automatisk etter kronologisk tid, tidligst først
|
||||
- egen farger for egne saker kan bli litt mye
|
||||
- *Hva tenker du om å se feil på denne måten? (oversiktelig?)*
|
||||
- Førsteinntrykk er mye, men etterhvert veldig oversiktelig
|
||||
- “melde inn feil/funksjonalitetsønsker”-knapper legges høyere
|
||||
- *Hva er det første du ser?*
|
||||
- Mye informasjon, mye tekst, må bruke litt tid for å forstå hva det egt er
|
||||
- “Hva er søkefeltet til”-spørsmål
|
||||
|
||||
##### Saksbehandler #2
|
||||
- *Hvordan syntes du det er å jobbe med speil idag?*
|
||||
- *Kan du fortelle litt om hvordan du bruker Speil i dag?*
|
||||
- Skjønte ikke helt spørsmålet her
|
||||
- *Hvordan går du frem når du finner feil i Speil i dag?*
|
||||
- Tar kontakt med coacher eller super
|
||||
- De melder videre
|
||||
- eller kan melde fra i support-kanal på teams
|
||||
|
||||
- *Hvordan synes du feilinnmelding angående Speil fungerer i dag?*
|
||||
- Slack ble fjernet som forstyrrende element i arbeid
|
||||
- mener de fortsatt burde hatt slack, lavere terskel for å melde inn
|
||||
- tungvinnt å gå via coacher
|
||||
- La kanskje til henne en mening om lang vei??
|
||||
|
||||
##### Saksbehandler #3
|
||||
- *Hvordan syntes du det er å jobbe med speil idag?*
|
||||
- *Kan du fortelle litt om hvordan du bruker Speil i dag?*
|
||||
- *Hvordan går du frem når du finner feil i Speil i dag?*
|
||||
- Går til coach som melder til utvikler
|
||||
- Svarer som de gjør fordi hovedproblemet med å jobbe med sykepenger fordi det er for mange som ikke kan sykepenger
|
||||
- omfattende domene
|
||||
- Noen er raske fordi vi har produksjonstall
|
||||
- Lang tid å skaffe domene kunnskap
|
||||
- Mange tror de kan sette seg ned og bare gjøre ting, det er mye å sette seg inn i
|
||||
|
||||
- *Hvordan synes du feilinnmelding angående Speil fungerer i dag?*
|
||||
- Det er så som så
|
||||
- tror at utfordringen er at noen enheter er flinke til å bruke faglige ressurser rundt seg, samtidig som andre bruker support rollen
|
||||
- Bruker ikke mye tid der, men drukner i repetetive innmeldinger.
|
||||
- brukerutbetaling skaper mange feil → større konsekvens
|
||||
- Siden det er så komplisert det vi jobber med (sykepenger) → fordi ting gjøres automatisk
|
||||
|
||||
##### Saksbehandler #4
|
||||
- *Hva er det viktigste for deg i en ny løsning for feilinnmelding?*
|
||||
- det må være toveiskommunikasjon
|
||||
- å melde inn er ikke nok så lenge man ikke får noe respons
|
||||
|
||||
##### Saksbehandler #5
|
||||
- *Hvordan synes du feilinnmelding angående Speil fungerer i dag?*
|
||||
- *Er det noe som fungerer godt?*
|
||||
- *Er det noe som fungerer mindre godt?*
|
||||
- ordinær opplæring innenfor fag og systemer, fungerte ikke fordi ingen har kunnskaper om speil
|
||||
- er veldig misfornøyd med oversikten over benken min
|
||||
|
||||
### Brukerhistorier og ønsker
|
||||
| Ønsker | Intervjuobjekt | Prioritet | Brukerhistorie |
|
||||
| - | - | - | - |
|
||||
| Kunne se helt tydelig, uten å grave i diskusjonstråd, hva status og konklusjon er for en sak. | Saksbehandler | | - Jeg vil se behandlingsstatus på en sak <br /> - Jeg ønsker å enkelt kunne finne frem konklusjonen for en lukket sak |
|
||||
| Ønsker type nyhets feed eller gallery view | Utvikler | | - Jeg vil se en ryddig og organisert visning av innmeldte saker |
|
||||
| Ryddig oversikt over innmeldte saker | Utvikler | | - Jeg vil se en ryddig og organisert visning av innmeldte saker |
|
||||
| Voting er bra for å se hva som er aktuelt | Utvikler | | - Jeg vil se hvor aktuell en sak er |
|
||||
| Måle “traction” på ulike saker for å fange opp i hvor stor grad en feil skjer. Foreslår et voting system. Hvor trykker skoen i systemet. Fint om utviklere kan sortere etter traction | Utvikler | Største ønske | - Jeg vil se hvor akutell en sak er <br /> - Jeg ønsker å sortere etter hvor aktuell en sak er |
|
||||
| Se om en sak er rapportert tidligere evt behandlet (unngå gjentakende rapportering) | Saksbehandler | Største ønske | - Jeg vil sjekke om en sak er rapportert inn tidligere <br /> - Jeg vil se behandlingsstatus på en sak |
|
||||
| Tydelig skille mellom rapporterte feil og feature requests | Utvikler | | - Jeg vil se tydelig skille mellom feature requests for en sak jeg "følger" |
|
||||
| Bli varslet om aktivitet på en sak/post (diskusjon, status endringer, etc.). Da slipper man å overvåke. | Saksbehandler | | - Jeg vil varsles ved endringer/aktiviteter for en sak jeg "følger" |
|
||||
| Kunne være i direkte kontakt med utviklere | Saksbehandler | | - Jeg ønsker å ha direkte kontakt med saksbehandler/utvikler |
|
||||
| Utvikler skal kunne varsle saksbehandler dersom mer informasjon om sak trengs for å løse den. | Saksbehandler | | - Jeg ønsker å ha direkte kontakt med saksbehandler/utvikler |
|
||||
| Kunne kontakte saksbehandler dersom det trengs for ytterligere info om saken | Utvikler | | - Jeg ønsker å ha idrekte kontakt med saksbehandler/utvikler |
|
||||
| Kunne søke opp saker på nøkkelord | Saksbehandler | Største ønske | - Jeg ønsker å kunne søke opp saker på nøkkelord og tagger |
|
||||
| Generere lapper på en sak i Trello | Utvikler | Nice to have | - Jeg ønsker å lage en lapp på en sak i Trello |
|
||||
| Mulighet til å initiere samtale relatert til posten. Utviklere og saksbehandlre kan ha en dialog som kan organiseres i en tråd festet til en post. | Saksbehandler | | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak |
|
||||
| Trådsvar | Utvikler | Nice to have | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak |
|
||||
| Kunne se en diskusjonstråd eller annen aktivtet/varsler rundt en sak. | Saksbehandler | | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak <br /> - Jeg vil varsles ved endringer/aktiviteter for en sak jeg "følger" |
|
||||
| En sak skal kunne innehold skjermbilder, beskrivelse, aktør-id og dato(er) | Saksbehandler | | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus |
|
||||
| Innmelder må være felt på en sak, type feil (grensesnitt, handlingsfeil, verdifeil) | Utvikler | | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus |
|
||||
| Feilen kommer lett frem med en beskrivelse og tittel | Utvikler | | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus |
|
||||
| Sak burde ha aktørid, mulighet for skjermbilde opplastning, tags, tittel, status. innmelder (saksbehandler) | Utvikler | | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus |
|
||||
| Oversikt over hva som støttes i Speil. Funksjonalitetsoversikt (kommunikasjonskanal for ny funksjonalitet i Speil) | Saksbehandler | | - Jeg ønsker å se hvilken funksjonalitet som Speil har |
|
||||
| Få inntrykk av hvilke features som eksisterer samt. muligheten til å komme med tilbakemelding | Utvikler | Største ønske | - Jeg ønsker å se hvilken ufnksjonalitet som Speil har |
|
||||
| Se om saken haster å løse | Utvikler | | - Jeg ønsker å se om en sak haster å løse |
|
||||
| Utviklere skal kunne gi en label til en sak ifht. relatert app | Utvikler | | Jeg ønsker å tildele en sak en emneknagg |
|
||||
| Kategoriere hvilke typer feil som finnes | Utvikler | Største ønske | - Jeg ønsker å tildele en sak en emneknagg |
|
||||
| Hashtags/emneknagger|tags for å organisere i type feil -> ser antall feil av en type. Disse kan være egendefinerte | Utvikler | | - Jeg ønsker å tildele en sak en emneknagg <br /> - Jeg ønsker å se antall aktive saker på en emneknagg |
|
||||
| Ha et "beredskapsteam" (redteam), som svarer raskt | Saksbehandler | REDTEAM | |
|
||||
| Låse en løst tråd??? | Saksbehandler | | |
|
||||
| Vurdere en innmeldt sak før den sendes videre til utviklingsteam - for å unngå gjentakende rapportering | Utvikler | |
|
||||
|
||||
|
||||
### Funksjonalitet basert på ønsker og problemløsning (MoSCoW)
|
||||
|
||||
| Funksjonalitet | Implementasjonsdetaljer | MoSCoW | Status |
|
||||
| - | - | - | - |
|
||||
| Oppdatere innmeldt feil | | Must have (dev) | Done (mangler aktorid) |
|
||||
| Saksbehandlere skal kunne melde inn saker | • Legge til en god beskrivelse av saken (~ juss) <br /> ◦ Skjermbilder, aktør-id, datoer <br /> ◦ Se en oversikt over meldte saker (egne saker? ~ juss) | Must have (dev) | Done |
|
||||
| Kunne se innmeldte feil | | Must have (dev) | Done |
|
||||
| Teamet skal kunne gi beskjed om at saker er løst | | Must have (dev) | Done |
|
||||
| Enkelt se konklusjon av en sak | | Must have (dev) | Done |
|
||||
| Søkefunksjonalitet | | Must have (dev) | Done |
|
||||
| Redigere innmeldt feil | | Should have | Done |
|
||||
| Filtrering av saker etter type feil og lables | | Should have | Started frontend |
|
||||
| Gi labels/kategorisering av/til feil | | Should have | Not started |
|
||||
| Kunne oppdage at noe er meldt inn tidligere | | Could have | Not started |
|
||||
| Kunne stemme på saker for å måle "hvor skoen trykker i systemet" | | Could have | Not started |
|
||||
| Trådsvar | | Could have | Not started |
|
||||
| Oversikt over kjente feil / løsninger | | Could have | Not started |
|
||||
| Opprette Trello lapper direkte fra appen på en rapportert sak | | Will not have | Not started |
|
||||
| Formidle støttet funksjonalitet i Speil | | Will not have | Not started |
|
||||
| Komme med tilbakemelding på støttet funksjonalitet i Speil | | Will not have | Not started |
|
||||
| FAQ side om Speil | | Will not have | Not started |
|
||||
| Sortering av saker etter traction | | Will not have | Not started |
|
||||
| Ved jobbing med målinger hadde det vært kult med temperaturmålings for saksbehandling (spørsmål rundt trivsel målt over tid for å påvirke produktet) | | Will not have | Not started |
|
||||
| Direkte kontakt mellom de to partene | | Must have (prod) | Not started |
|
||||
|
||||
## Juss & ROS
|
||||
|
||||
Hensyn å ta:
|
||||
- Hvem har tjenstlig behov for å se innmeldte feil?
|
||||
- Tilgangskontroll
|
||||
- Logging og sporing
|
||||
- Skal alle kunne se alle felter av innmeldte feil?
|
||||
- Skal kun RedTeam se saker?
|
||||
- Personvernhensyn
|
||||
- Akørid må nesten med både for å kunne sjekke en sak, men også for å logge hvordan en brukers info er behandlet
|
||||
- Ha info-bokser for å minne på at personopplysninger ikke skal deles
|
||||
- Kan ha en pop-up som kommer når man trykker "meld inn sak" som ber innmelder dobbeltsjekke personopplysninger
|
||||
- Deling av personopplysninger i skjermbilde?
|
||||
- Færre muligheter for å skrive fritekst kan redusere sannsynligheten for å dele for mye, men kan bli vanskelig med standard kategorier som er dekkende
|
||||
- Spesielle hensyn å ta ang. kode 6 og 7?
|
||||
|
||||
> ROS er påbegynt og registert i TryggNok
|
||||
|
||||
## Design
|
||||
- Applikasjonen er skissert i Figma.
|
||||
- Figma prosjektet finner du [her](https://www.figma.com/files/810213623608415105/team/1256163063148444981).
|
||||
- Underveis i designprosessen har UX/UI-Designer i PO-Helse gitt råd.
|
||||
- Prototypen er raffinert gjennom flere iterasjoner med brukerintervjuer av fagfolk, utviklere og saksbehandlere.
|
||||
- Prototypen bygges på designsystemet Aksel sine tokens og komponenter.
|
||||
Reference in a new issue