Kravinnsamling: Komplett veiledning & mal
Kravinnhenting er en prosess som lar deg avklare og håndtere forventninger med interessenter, forhindre ukontrollert utvidelse av prosjektomfanget og redusere uklarhet rundt hva prosjektet faktisk leverer.
Jo mer kravdokumentasjon du har, desto mindre rom er det for feil og antakelser. Kontrollmekanismene og avveiningene vil gagne teamets felles forståelse av prosjektet og kundens forventninger til sluttproduktet.
Hva er kravinnhenting i prosjektledelse?
Kravinnhenting er prosessen med å fastslå hva prosjekteierne og de viktigste interessentene trenger fra prosjektet. Prosjektledere arbeider med å identifisere hva som etterspørres, og detaljene rundt forespørselen.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Disse forespørslene blir til prosjektets kravliste. Leveransen opp mot kravene avgjør om arbeidet regnes som et vellykket prosjekt eller ikke.
Prosjektledere bruker kravdokumenter og verktøy for kravhåndtering for å holde oversikt over disse kravtypene gjennom hele prosjektet:
- Funksjonelle krav
- Tekniske krav
- Ikke-funksjonelle krav
- Systemkrav
Hvorfor er kravinnhenting viktig?
Kravinnhenting er viktig av følgende grunner (det samme gjelder dokumentasjon av kravene):
- Det fungerer som et referansepunkt for å dokumentere utviklingen av et prosjekt, prosjektets ulike deler og implementeringen av det
- Det fungerer som en veiledning som gjør det enklere for prosjektets interessenter å forstå hva de kan forvente av prosjektet (hva, hvor, når og hvorfor prosjektet gjennomføres).
- Det reduserer rommet for feil og uklarheter, fordi kravene er tydelig dokumentert og avtalt før arbeidet starter.
- Det gir kontrollmekanismer og avveininger gjennom hele prosjektproduksjonen og kvalitetssikringen, slik at prosjektlederne og teammedlemmene kan gå tilbake til det når det oppstår tvil om hvordan de skal gå videre.
I tillegg til å beskrive hva de kan forvente, bør en effektiv plan for kravhåndtering beskrive hva de ikke kan forvente. Det er klokt å ta med en del om «Antakelser» og/eller «Avgrensninger» for å eliminere risikoen for den fryktede kundens fantasi.
Et eksempel på en kravspesifikasjon for programvare
Her er et eksempel på en kravspesifikasjon for et netthandelsprosjekt:
- Hva: PayPal-integrasjon
- Hvor: Utsjekking
- Når: I trinn 3 av 4 i utsjekkingsprosessen (etter nettskjemaet for leveringsadresse, før bekreftelsen)
- Hvorfor: En etablert integrasjon (f.eks. PayPal) er i dette tilfellet en bedre løsning enn en robust, spesialutviklet integrasjon for en betalingstjeneste, fordi den enkelt oppfyller forretningskravene.
- Antakelser
- Fast pris for all frakt og håndtering
- All frakt skjer innenfor USA (ikke inkludert Alaska eller Hawaii)
- Skatter gjelder ikke
- Avgrensninger
- Spesialberegninger av frakt- og håndteringsgebyrer
- Frakt til andre land, Alaska eller Hawaii
- Skatteregler
Husk: jo mindre forskjellen mellom kundens forventninger og virkeligheten med det digitale produktet deres er, desto mer fornøyd kommer kunden til å være med sluttresultatet. Kvaliteten på kravhåndteringen korrelerer direkte med din evne som prosjektleder til å redusere eventuelle gråsoner når det gjelder kundens forventninger.
Som oftest vil en kunde være positiv til at du begrenser omfangsutvidelse hvis det betyr at du beskytter budsjettet deres. Hvis du gir kunden tilstrekkelig opplæring i hvorfor en funksjon vil bli håndtert (eller ikke håndtert), og deretter dokumenterer logikken bak denne tilnærmingen i kravene, er det langt mer sannsynlig at kunden vil samarbeide.
Det er mer sannsynlig at de godkjenner løsningen, og senere, når de gjennomfører brukerakseptansetesting (UAT), vil de ha et bedre utgangspunkt for å forstå «hvorfor» teamet ditt har valgt denne løsningen.
Prosess for innsamling av krav i 6 trinn
Selv om innsamlingen av krav bør starte så snart et oppdrag begynner og fortsette gjennom hele prosjektets livssyklus, er det aldri for tidlig å begynne å samle inn og dokumentere krav. Faktisk burde du ha startet i går.
Her er trinnene for hvordan du samler inn krav.
1. Ta notater
I hvert møte du deltar i – enten det er internt med prosjektteamet ditt eller eksternt med kunden – bør du alltid ta notater. Ikke anta at noen andre gjør det.
I øyeblikket kan det være lett å anta at alt som blir diskutert, vil bli husket, men tre måneder og 15 møter senere vil både teamet ditt og kunden takke deg for at du har en oversikt over diskusjonene å se tilbake på.
Her finner du noen av prosedyrene jeg anbefaler for å ta notater om krav:
- Før møtet bør du klargjøre notatdokumentet slik at det gjenspeiler agendaen din, slik at det blir enklere å organisere oppgaver og punkter. På denne måten husker du hva som trengs, samtidig som du samler relatert informasjon på en organisert måte.
- Etter hvert møte bør du sette av 15–30 minutter til å gå gjennom notatene dine, fordøye det som ble diskutert, prioritere oppgavene og identifisere utfordringer/varselsignaler eller behov for avklaringer eller flere møter.
- Send notatene dine til det interne prosjektteamet. Be dem gå gjennom og bekrefte det du har identifisert som oppgaver, varselsignaler og så videre.
- Når teamet har gitt deg sin godkjenning, sender du notatene til kunden.
- Til slutt bør du bruke notatene dine som grunnlag for å opprette oppgaver fra hvert enkelt punkt. Legg all ny informasjon inn i kravdokumentasjonen, og planlegg eventuelle møter som trengs for videre kartlegging eller diskusjon.
2. Gå gjennom de kreative kravene
Ikke overlat design- og stilbeslutninger til de enkelte teammedlemmene: formaliser de kreative kravene når det er mulig. Kreative retningslinjer er uvurderlige for utviklere. Sørg i det minste for at du har en stilguide tilgjengelig – selv om den bare inneholder grunnleggende informasjon som skrifttyper og merkevarefarger.
Samle inn kreative ressurser, som merkevarelogoer eller merkevareskrifttyper, og last dem opp til et felles område (for eksempel programvare for håndtering av digitale ressurser) slik at hele teamet får tilgang og oversikt.
3. Skriv kravdokumentet
Når du går i gang med dokumentasjonen, må du huske at første gang du dokumenterer krav, vil være den vanskeligste. Hvorfor? Fordi du ikke har et tidligere dokument å ta utgangspunkt i (også kjent som KOPIER OG LIM INN). Heldigvis inneholder denne artikkelen en mal for kravdokumentasjon som kan danne grunnlaget for arbeidet ditt.
Som vist i denne malen deler jeg kravdokumentasjonen min inn i fire deler:
- Merknad: Inneholder numrene fra det annoterte designet ditt. Hvis sidedesignet ditt har 8 elementer, vil du ha 8 merknader, og merknadskolonnen vil ha 8 rader
- Element: Inneholder elementtitler slik de er knyttet til hver merknad
- Funksjonelt krav: Inneholder en definisjon (kravene, spesifisert) for hvert element
- Administrasjons-/CMS-funksjonalitet: Definer eventuell administrasjons- og/eller CMS-funksjonalitet som er knyttet til det tilsvarende elementet
4. Gjennomfør en intern gjennomgang
I denne delen av prosessen for innsamling av krav skal du planlegge et nytt internt møte med prosjektteamet ditt for å gjennomgå kravdokumentasjonen. Dette er en siste intern kontroll for å sikre at dere har en felles forståelse av implementeringen.
Hvis det er mulig, bør du la teamet gjennomgå kravdokumentasjonen før møtet, slik at de kan møte forberedt med spørsmål og/eller tilbakemeldinger. Bruk møtet til å diskutere eventuelle spørsmål eller tilbakemeldinger om kravene.
Gjør nødvendige endringer i dokumentasjonen basert på den interne diskusjonen. Send til slutt den reviderte kravdokumentasjonen til teamet på nytt for en siste godkjenning. Når det interne prosjektteamet har gitt sin endelige godkjenning av kravdokumentasjonen, lagrer du dokumentet som PDF for å sikre at det forblir i ferdigstilt tilstand til neste trinn: utarbeiding av oppgaver.
5. Utarbeid oppgaver
Gi PDF-versjonen av kravdokumentasjonen til utviklingsteamet ditt. Ideelt sett vil utviklerne eller utviklingslederen stå for utarbeidingen av oppgavene for leveransen.
Selv om noen organisasjoner kan ha en prosess der prosjektledere utarbeider alle oppgavene, foretrekker jeg at utviklerne utarbeider sine egne oppgaver. De få timene dette tar for dem, er verdt det.
Du kan fortsatt gi teamet nyttige retningslinjer mens de utarbeider utviklingsoppgavene og leveransene sine. Etter at oppgavene er utarbeidet, vil du kunne få et endelig timeestimat.
Sammenlign denne prognosen med prosjektplanen som tidligere er kommunisert til kunden, og håndter dette deretter ved behov. Hvis du vil vite mer om estimering av prosjekter, kan du se denne fullstendige veiledningen for prosjektestimering.
6. Gjennomfør en ekstern gjennomgang
Det er på tide å presentere kravdokumentasjonen for kunden. Lever den som PDF for å sikre at ingen endringer blir gjort. Dette (1) viser at du investerer i å sikre kundens forståelse av den digitale løsningen, og (2) fungerer som en forsikring for deg, slik at du kan si «det sa jeg jo» (men langt mer velformulert) når prosjektets omfang uunngåelig begynner å vokse.
Opplær kunden. Gå gjennom denne verdifulle dokumentasjonen som du har satt sammen for dem med stor omhu. Husk: De er ekspertene på sin egen virksomhet. Du er eksperten på den digitale løsningen du tilbyr dem. De betaler deg for denne løsningen. Opplær og gi kunden mulighet til å ta informerte beslutninger.
Når kunden har bekreftet at de forstår kravdokumentasjonen, er det på tide å innhente formell godkjenning. Send den signerte og godkjente kravdokumentasjonen til teamet ditt, og lagre den på et delt sted, slik at det finnes en formell bekreftelse på at utviklingen kan begynne.
Teknikker for innsamling av krav
Her er noen teknikker som kan hjelpe deg med å sikre at du utfører det viktige arbeidet med å samle inn krav så godt som mulig:
1. Kom i gang med en gang
Kravdokumentasjonen bør begynne så snart samtalene starter, før du har fastsatt den nøyaktige prosjektplanen eller prosjektmålene. Ta vare på alt du kan, og snevr det deretter inn. Her er noen strategier du kan prøve med kunden:
- Send dem et spørreskjema om hva de ønsker å se i prosjektet
- Gjennomfør en idédugnad
- Arranger en fokusgruppe
I stedet for å fjerne informasjon fra dokumentet kan du kategorisere den i hva som er inkludert, og hva som ikke er inkludert. Dette hindrer at kunden gjør antakelser senere i prosessen.
Du vil kunne hente frem kravdokumentasjonen din som er under arbeid, og vise hvor informasjonen ble tatt med, hvorfor den kanskje ikke er inkludert, begrunnelsen bak beslutningen og datoen da dette ble dokumentert, slik at det kan spores.
2. Bruk maler
Når du har noen kravdokumenter på samvittigheten, kan du begynne å utnytte dem og lage maler av dem for fremtidig bruk i andre prosjekter. Særlig hvis du har et spesifikt fokus på prosjekter innen e-handel eller læringsapplikasjoner, vil du begynne å se funksjonalitetsmønstrene dukke opp. Identifiser hvor du kan gjenbruke.
3. Samarbeid gjør drømmen mulig
Hvis det er ulike typer teammedlemmer på et prosjekt, kan kravene for hvert kompetanseområde utarbeides av de respektive ekspertene.
I mange tilfeller er samtalen om krav en kronglete rekke telefonsamtaler, ulike separate møter og samtaler osv. Derfor er det avgjørende at du fordeler dokumentasjonen av kravene til de respektive teammedlemmene etter hvert som dere innhenter og sammenstiller kravene.
4. Ikke bare dokumenter kravene – lær
Gjør mer enn å ta notater. Forvent mer enn at ressurspersoner sender deg en vegg av tekst som utgjør deres del av kravene. Ta deg tid til å sette deg ned med utviklerteamet ditt og lære om løsningene teamet ser for seg å implementere. Diskuter hvorfor og hvordan. Still spørsmål.
Før du sier: «Men vi har bare så mye tid i løpet av dagen – og hva med budsjettet?», bør du forstå dette: Hvis en løsning du arbeider med kan brukes i mer enn ett prosjekt, trenger ikke denne ekstra tiden for å oppnå forståelse nødvendigvis være fakturerbar. Du bygger opp fagkompetansen din, noe som forbedrer det daglige arbeidet ditt direkte.
5. Hold kunden orientert
Ha et internt kravdokument samt et WIP-kravdokument rettet mot kunden. I det interne dokumentet trenger du ikke å være like tilbakeholden med å inkludere mer transparente notater.
Hvis du ikke håndterer sensitiv informasjon, kan du opprette dette delte arbeidsområdet i et Google-dokument, med tillatelser som gir kunden mulighet til å kommentere. Hvis du håndterer sensitiv informasjon, kan du dele en versjon av kravdokumentet ukentlig for å gi kunden et øyeblikksbilde av hva som er dokumentert.
6. Anta at kunden alltid vil vite mer
I stedet for å risikere å anta at kunden vet mer enn de faktisk gjør (og senere få svi for det), bør du anta at kunden alltid vil vite mer. For hver merknad kan du stille deg selv spørsmålet «Hvorfor?» fem ganger for å sikre at hvert krav er grundig.
Å stille deg selv «Hvorfor?» fem ganger for hvert krav utfordrer deg til virkelig å vurdere logikken bak hvert element og hver funksjon på hver sidetype. Du kan bli overrasket over hvor mye du lærer (eller innser at du trenger å lære).
3 eksperttips for å skrive et prosjektkravdokument
1. Skriv kravene for globale elementer separat
For å unngå overflødighet bør du dekke alle globale elementer i en del av kravdokumentasjonen som heter «Globale elementer». Dette gjelder globale elementer som hovedmenyelementene, alt i den globale toppteksten og alt i bunnteksten.
Når du har skrevet kravene for disse globale elementene, trenger du ikke å kommentere dem på de andre sidene; kommenter bare elementer som er spesifikke for de aktuelle sidene.
2. Kopier og lim inn identisk funksjonalitet for å sikre konsistens
Dette er ganske enkelt et tips du bør ha i bakhodet for å bevare din egen (og kundens) mentale helse. Du vil se dette oftest med vanlige sideelementer som hero-/bannerbilder, topptekster eller «tilbake»-ikoner – blant et stort antall gjentatte funksjoner på tvers av sidetyper (som ikke må forveksles med globale elementer).
3. Ta høyde for administrasjon og CMS (eller fraværet av dette)
Når vi er så fokuserte på funksjonaliteten til hvert sideelement, er det lett å overse administrasjons- og/eller CMS-funksjonalitet. Hvis du implementerer en løsning som tilbyr administrasjons- og/eller CMS-funksjonalitet, må du sørge for å inkludere dette som en egen kolonne i kravene. Eksempel nedenfor:
Mal for kravdokument [Last ned]
Det spesifikke innholdet i kravdefinisjonen din vil avhenge av forholdet ditt til kunden, teamets erfaring og andre faktorer.
Du trenger imidlertid fortsatt de grunnleggende delene av et kravdokument for prosjektet, som beskriver en funksjons funksjonalitet, plassering, utforming og så videre. Her er malen vår for kravdokumentasjon (du må være medlem for å få tilgang til den):
Få opp farten med over 100 premium-maler
Bli DPM-medlem for å få tilgang til et ubegrenset antall ekspertlagde maler som hjelper deg med å jobbe raskere og mer effektivt.
