Bestbrains - kravspecifikationen må dø - 8 oktober 2012
1. Hvorfor
kravspecifikationen
skal dø.
BestBrains 4. oktober 2012
tirsdag den 9. oktober 12
2. Klaus Silberbauer
Partner, Creative Director
Think! Digital
tirsdag den 9. oktober 12
3. Strategy
Tactics
Operations
tirsdag den 9. oktober 12
4. Strategy
Tactics
Operations
tirsdag den 9. oktober 12
5. Strategy
Tactics
Operations
} UX mindset
tirsdag den 9. oktober 12
6. “ Strategy without tactics is the slowest route to victory.
Tactics without strategy is the noise before defeat.
tirsdag den 9. oktober 12
7. “ Strategy without tactics is the slowest route to victory.
Tactics without strategy is the noise before defeat.
孫子
SUN TZU, 500 B.C.
tirsdag den 9. oktober 12
18. “ Kravspecifikationer til web er ofte resultatet af, at en gruppe
mennesker uden indsigt i mediet og under tidspres bliver bedt
om at finde løsninger på problemer, de endnu ikke kender.
tirsdag den 9. oktober 12
19. Eksempel
Formål:
At oprette brevskabeloner, der kan anvendes af XXXXXX i
givne XXXXXX-processer.
Aktører: Redaktionen
Før-tilstand, forudsætninger:
Aktøren er logget på systemet
Beskrivelse:
For aktøren er oprettelsen af en brevskabelon kendetegnet
ved at være dialogbaseret, brugervenlig og overskuelig.
Aktøren vælger at oprette en skabelon. Når aktøren vælger
at oprette en ny skabelon, vælges i en trinvis dialog,
hvilke felter der skal anvendes på formularen:
Indtastningsfelter (input) , Enten-eller felter (radio-
buttons) , Både-og felter (checkboxe) , Rullegardiner
(dropdowns), Kommentar-felt (text-area)
tirsdag den 9. oktober 12
Aktøren har mulighed for at tilføje et vilkårligt antal
20. Aktøren er logget på systemet
Eksempel Beskrivelse:
For aktøren er oprettelsen af en brevskabelon kendetegnet
ved at være dialogbaseret, brugervenlig og overskuelig.
Aktøren vælger at oprette en skabelon. Når aktøren vælger
at oprette en ny skabelon, vælges i en trinvis dialog,
hvilke felter der skal anvendes på formularen:
Indtastningsfelter (input) , Enten-eller felter (radio-
buttons) , Både-og felter (checkboxe) , Rullegardiner
(dropdowns), Kommentar-felt (text-area)
Aktøren har mulighed for at tilføje et vilkårligt antal
felter og i en vilkårlig rækkefølge. For hvert felt der
tilføjes, angiver aktøren overskrift til feltet. Gældende
for alle typer af skabeloner er, at aktøren angiver
overskrift og brødtekst til skabelonen samt udløbsdato for
formularen.
Når udløbsdatoen er overskredet kan skabelonen ikke
længere anvendes af slutbrugerne på XXXXXXX.
Skabelonens opsætning følger de fastsatte design
retningslinier for XXXXXX, og aktøren har ikke mulighed
for at ændre på denne opsætning.
Efter-tilstand, resultat:
tirsdag den 9. oktober 12
Aktøren har oprettet en brevskabelon uden brug af
21. Aktøren er logget på systemet
Eksempel Beskrivelse:
For aktøren er oprettelsen af en brevskabelon kendetegnet
ved at være dialogbaseret, brugervenlig og overskuelig.
Aktøren vælger at oprette en skabelon. Når aktøren vælger
at oprette en ny skabelon, vælges i en trinvis dialog,
hvilke felter der skal anvendes på formularen:
Indtastningsfelter (input) , Enten-eller felter (radio-
buttons) , Både-og felter (checkboxe) , Rullegardiner
(dropdowns), Kommentar-felt (text-area)
Aktøren har mulighed for at tilføje et vilkårligt antal
felter og i en vilkårlig rækkefølge. For hvert felt der
tilføjes, angiver aktøren overskrift til feltet. Gældende
for alle typer af skabeloner er, at aktøren angiver
overskrift og brødtekst til skabelonen samt udløbsdato for
formularen.
Når udløbsdatoen er overskredet kan skabelonen ikke
længere anvendes af slutbrugerne på XXXXXXX.
Skabelonens opsætning følger de fastsatte design
retningslinier for XXXXXX, og aktøren har ikke mulighed
for at ændre på denne opsætning.
Efter-tilstand, resultat:
tirsdag den 9. oktober 12
Aktøren har oprettet en brevskabelon uden brug af
24. Formålet med at bygge en
bro er broen i sig selv.
En webløsnings mål er
ikke løsningen i sig selv,
men den værdi,
løsningen skal skabe.
tirsdag den 9. oktober 12
25. Reduktion ad absurdam
Hvad skal en kravspecifikation • Implementering: Hvilke krav er der til projektledelse og
gennemførelse af projektet. Hvilken rolle er det tilsigtet at
indeholde? leverandøren skal have? Hvilke arbejdsgange skal forbedres?
Hvordan ser det ud fra brugerens synsvinkel? Hvad er
• Det bedste forsvar mod tilbud af ringe kvalitet er at lave en
forbindelsen fra de forretningsmæssige mål til kravene?
godt organiseret kravspecifikation, som leverandører kan
Skal leverandøren bruge bestemte metoder og værktøjer
følge.
(f.eks. use cases, prototyping, agile, extreme programming,
• I grove træk skal en kravspecifikation indeholde følgende usability test). Hvor meget træning er nødvendig?
afsnit:
• Leverandør kvalifikationer og referencer.
• Opsummering: Hvilket problem skal løses, og hvilke behov
søges tilfredsstillet Målbare succeskriterier. • Yderligere information fra leverandøren: Hvis leverandøren
har relevant, men ikke påkrævet information at tilføje
• Administrativ information: Kontakt data, deadline, formalia,
vigtige definitioner og afgrænsning • Pris: Hvordan skal dette præsenteres?
• Tekniske krav • Kontrakt og licensaftale: Alle juridiske detaljer
• Leverandøren skal kunne forstå det eksisterende IT-landskab, • Bilag, der indeholder relevant information, så som
netværksdiagrammer, projektplaner og forretningskrav.
herunder hvilke systemer der skal integreres med. Her
nævnes også krav til oppetid, svartider, back-up, clustering, • De enkelte punkter i kravspecifikationen kan med fordel
load-balancing, dynamisk/statisk levering markeres med et “K” for krav og et “Ø” for ønske. Kravene er
forbeholdt de elementer, som er strengt nødvendige, mens
ønskerne forventes tilgodeset. Se eksempler på krav i vores
artikel om rimelige forretningskrav.
tirsdag den 9. oktober 12
26. Beslutninger låses tidligt
Konventionel kravspec Agile / best practice
Man skal (forsøge) at tage hensyn til Man har fokus på målene og
alle scenarier. Typisk uden at visionen - problemer løses
gennemføre en egentlig designfase. undervejs.
Man skal forudse problemer, der
ikke er opstået endnu og situationer,
man ikke har kendskab til.
tirsdag den 9. oktober 12
27. Beslutninger låses tidligt
Konventionel kravspec Agile / best practice
Designbeslutninger tages uden Alle optioner holdes åbne til sidste
indsigt, og låses kontraktligt. øjeblik. Designbeslutninger tages
først når indsigten er størst.
tirsdag den 9. oktober 12
28. Vi leverer “til spec”
Konventionel kravspec Agile / best practice
En leverandør er fristet til at levere Målene sættes løbende i dialog
“til spec” og ikke til virkeligheden. mellem kunde og leverandør.
Målene er realistiske og bliver
“Til spec” opfylder kravene, men konstant holdt op imod den værdi,
resultatet kan være en skandale. som slutproduktet skal afføde.
tirsdag den 9. oktober 12
29. Ændringer bliver svære
Konventionel kravspec Agile / best practice
Ændringer undervejs kan kræve Ændringer er nødvendige.
change requests og dermed store Processen lærer os nye ting og vi
summer i projektledelse. skal kunne adaptere undervejs.
Man vil derfor typisk forsøge at
undgå ændringer.
tirsdag den 9. oktober 12
30. Kunden får en ja-siger
Konventionel kravspec Agile / best practice
Tilbudsfasen går nemmest, hvis Vi ved, at resultatet aldrig er som
man blot accepterer kravene specificeret, for ny viden opnået
(selvom kunden skriver, at man skal undervejs i processen giver os nye
udfordre kravspec’en). idéer.
Det er fristende at acceptere
tåbelige krav mod bedre vidende.
tirsdag den 9. oktober 12
31. Forsimplet syn på udvikling
Konventionel kravspec Agile / best practice
Kravpec’en cementerer opfattelsen Drift er udvikling og udvikling er
af web- eller IT-udvikling som et drift.
projekt med en start, slutning og et
klart defineret produkt.
Man skelner typisk mellem udvikling
og drift
tirsdag den 9. oktober 12
32. Kombineret med udbud, ak
Konventionel kravspec Agile / best practice
“Hvem kan bygge noget ud fra en “Hvem vil indgå i et samarbejde på
dårlig opskrift, på mindst tid og til disse vilkår, hvor begge parter gør
færrest penge” alt for at skabe værdi indenfor givne
økonomiske rammer”.
tirsdag den 9. oktober 12
33. Pris
Konventionel kravspec Agile / best practice
Et komplekst udbud med stor Kunden og leverandøren bruger de
kravspec kan tage +1.000 timer at +2.000 timer til sammen at
skrive og +1.000 timer at besvare. formulere udfordringerne, målene
og opnå tillid og enighed.
Disse penge skal ind - prisen stiger.
tirsdag den 9. oktober 12
34. Risiko
Konventionel kravspec Agile / best practice
Risikomaksimerende - projektledere Risikominimerende - product
på overarbejde og jurister stand-by. owners en del af løsningen, jurister
Modstridende interesser parterne i sjældent nødvendige. Fælles
mellem. interesser.
tirsdag den 9. oktober 12
52. Start med interface design
Design Test
Indsigt Design Reality Agile
Forretning
Brand
Struktur
Interaktion
check Dev
Mål / KPI Dialog
Succeskriterier Visuelt Design
Brugere
Tech
Arkitektur
Platform
Data/Integration
tirsdag den 9. oktober 12
56. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
tirsdag den 9. oktober 12
57. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Formulér hvilke mål den endelige
løsning skal opfylde. Der kan være
100 forskellige veje derhen - lyt til
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end
man troede.
tirsdag den 9. oktober 12
58. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Formulér hvilke mål den endelige Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end
man troede.
tirsdag den 9. oktober 12
59. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Formulér hvilke mål den endelige Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
60. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Sats på langvarigt
samarbejde og
tillidsopbygning.
Formulér hvilke mål den endelige Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
61. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Sats på langvarigt
samarbejde og Læg stor vægt på fælles konceptudvikling.
tillidsopbygning.
Formulér hvilke mål den endelige Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
62. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Kunden: Insister på, at der
Sats på langvarigt sættes et team, ikke bare sælges
samarbejde og timer. Læg stor vægt på fælles konceptudvikling.
tillidsopbygning.
Formulér hvilke mål den endelige Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
63. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg
med tal og typisk pålagt store risiko-buffere.
Kunden: Insister på, at der
Sats på langvarigt sættes et team, ikke bare sælges
samarbejde og timer. Læg stor vægt på fælles konceptudvikling.
tillidsopbygning.
Leverandøren: Insister på at
kunden dedikerer tid og
Formulér hvilke mål den endelige nøglepersoner, ikke blot Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være kommunikerer pr. skrift. men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
64. Et nyt paradigme
Vælg leverandør på baggrund af meritter, ikke på
baggrund af et tilbud, som for det meste er ren leg Indse, at ingen spec er
med tal og typisk pålagt store risiko-buffere. fuldkommen, at software
udvikles over tid og at tillid er
Kunden: Insister på, at der den eneste vej.
Sats på langvarigt sættes et team, ikke bare sælges
samarbejde og timer. Læg stor vægt på fælles konceptudvikling.
tillidsopbygning.
Leverandøren: Insister på at
kunden dedikerer tid og
Formulér hvilke mål den endelige nøglepersoner, ikke blot Afsæt ikke et projektbudget,
løsning skal opfylde. Der kan være kommunikerer pr. skrift. men et løbende proces-
100 forskellige veje derhen - lyt til budget.
leverandørens idéer. Det kan typisk
gøres nemmere og billigere, end Begge parter: Undgå kompleksitet,
man troede. hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
tirsdag den 9. oktober 12
65. Think! Digital is a Copenhagen based,
strategic digital agency, firmly rooted in the
tradition of user experience design.
Digital is business.
facebook.com/thinkdigitaldk
twitter.com/thinkdigitaldk
www.thinkdigital.dk
lets@thinkdigital.dk
+45 3164 0100
tirsdag den 9. oktober 12
