1. BestBrains 22. maj 2013
Hvorfor
kravspecifikationen
skal dø.
torsdag den 23. maj 13
2. Think! Digital is a Copenhagen
based, strategic digital agency,
firmly rooted in the tradition of
user experience design.
Digital is business.
Strategy
Tactics
Operations
User experience
Started December 2011 / 16 Employees / Offices in Copenhagen
torsdag den 23. maj 13
8. 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.
“
Yours truly.
torsdag den 23. maj 13
9. 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)
Aktøren har mulighed for at tilføje et vilkårligt antaltorsdag den 23. maj 13
10. Eksempel
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)
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:
Aktøren har oprettet en brevskabelon uden brug af
Elendigt interaktionsdesign!
Lad som ingenting.Kod
skidtet og tjen penge på et
change request når kunden
finder ud af at det ikke virker.
Elendigt interaktionsdesign!
Gør kunden opmærksom herpå
med risiko for at man ikke
kan leve op til udbuddets krav.
torsdag den 23. maj 13
11. Agile / best practiceKonventionel kravspec
Man har fokus på målene og
visionen - problemer løses
undervejs når man kender dem.
Man anvender designmetodikker til
problemløsning.
Man skal (forsøge) at tage hensyn til
alle scenarier. Typisk uden at
gennemføre en egentlig designfase.
Man skal forudse problemer, der
ikke er opstået endnu og situationer,
man ikke har kendskab til.
Beslutninger låses tidligt
torsdag den 23. maj 13
12. Agile / best practiceKonventionel kravspec
Alle optioner holdes åbne til sidste
øjeblik. Designbeslutninger tages
først når indsigten er størst.
Designbeslutninger tages uden
indsigt, og låses kontraktligt.
Dårlige beslutninger cementeres
torsdag den 23. maj 13
13. Agile / best practiceKonventionel kravspec
Målene sættes løbende i dialog
mellem kunde og leverandør.
Målene er realistiske og bliver
konstant holdt op imod den værdi,
som slutproduktet skal afføde.
En leverandør er fristet til at levere
“til spec” og ikke til virkeligheden.
“Til spec” opfylder kravene, men
resultatet kan være en skandale når
løsningen møder virkeligheden.
Vi leverer “til spec”
torsdag den 23. maj 13
14. Agile / best practiceKonventionel kravspec
Ændringer er nødvendige.
Processen lærer os nye ting og vi
skal kunne adaptere undervejs.
Ændringer undervejs kan kræve
change requests og dermed store
summer i projektledelse.
Man vil derfor typisk forsøge at
undgå ændringer. Man vil fastholde
dårlige beslutninger fordi det er for
dyrt at lave dem om.
Ændringer bliver svære
torsdag den 23. maj 13
15. Agile / best practiceKonventionel kravspec
Vi ved, at resultatet aldrig er som
specificeret, for ny viden opnået
undervejs i processen giver os nye
idéer.
Tilbudsfasen går nemmest, hvis
man blot accepterer kravene
(selvom kunden skriver, at man skal
udfordre kravspec’en).
Det er fristende at acceptere
tåbelige krav mod bedre vidende.
Kunden får en ja-siger
torsdag den 23. maj 13
16. Agile / best practiceKonventionel kravspec
Drift er udvikling og udvikling er
drift. Et digitalt projekt er aldrig
færdigt, men en del af forretningen.
Kravpec’en cementerer opfattelsen
af web- eller IT-udvikling som et
projekt med en start, slutning og et
klart defineret produkt.
Man skelner typisk mellem udvikling
og drift
Forsimplet syn på udvikling
torsdag den 23. maj 13
17. Agile / best practiceKonventionel kravspec
“Hvem vil indgå i et samarbejde på
disse vilkår, hvor begge parter gør
alt for at skabe værdi indenfor
givne økonomiske rammer”.
“Hvem kan bygge noget ud fra en
dårlig opskrift, på mindst tid og til
færrest penge - helst uden at stille
for mange spørgsmål.”
Kombineret med udbud, ak
torsdag den 23. maj 13
18. Agile / best practiceKonventionel kravspec
Kunden og leverandøren bruger de
+2.000 timer til sammen at
formulere udfordringerne, målene
og opnå tillid og enighed.
Et komplekst udbud med stor
kravspec kan tage +1.000 timer at
skrive og +1.000 timer at besvare.
Disse penge skal ind - prisen stiger.
Pris
torsdag den 23. maj 13
19. Agile / best practiceKonventionel kravspec
Risikominimerende - product
owners en del af løsningen, jurister
sjældent nødvendige. Fælles
interesser.
Risikomaksimerende -
projektledere på overarbejde og
jurister stand-by. Modstridende
interesser parterne i mellem.
Risiko
torsdag den 23. maj 13
20. Dogmet om kravspec’en
Hvad skal en kravspecifikation indeholde?
Det bedste forsvar mod tilbud af ringe kvalitet er at lave en
godt organiseret kravspecifikation, som leverandører kan
følge.
I grove træk skal en kravspecifikation indeholde følgende
afsnit:
• Opsummering: Hvilket problem skal løses, og hvilke behov søges
tilfredsstillet
• Målbare succeskriterier.
• Administrativ information: Kontakt data, deadline, formalia,
vigtige definitioner og afgrænsning
• Tekniske kravtorsdag den 23. maj 13
21. Dræbende interaktionsfejl
Misforståelser af brugerens
kontekst
Forkert
navngivning.
Processer
understøttes
forkert.
Konceptmæssige fejl
Overflødig
funktionalitet
Manglende
funktionalitet
Brugervenligheds-
mæssige fejl
Bruger forstår
ikke systemes
brugerflade
Diskursmæssige fejl
Systemet
taler ned til
brugeren
Systemet er
indforstået
torsdag den 23. maj 13
24. Start med interface design
Indsigt
Forretning
Brand
Mål / KPI
Succeskriterier
Brugere
Reality
check
Tech
Arkitektur
Platform
Data/Integration
Agile
Dev
TestDesign
Design
Struktur
Interaktion
Dialog
Visuelt Design
torsdag den 23. maj 13
25. 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.
Afsæt ikke et projektbudget,
men et løbende proces-
budget.
Begge parter: Undgå kompleksitet,
hvor muligt. Selvom man kan
sælge mange timer på indviklet
kode, så er det sjældent risikoen
værd.
Sats på langvarigt
samarbejde og
tillidsopbygning. Læg stor vægt på fælles
konceptudvikling.
Kunden: Insister på, at der
sættes et team, ikke bare sælges
timer.
Leverandøren: Insister på at
kunden dedikerer tid og
nøglepersoner, ikke blot
kommunikerer pr. skrift.
Indse, at ingen spec er
fuldkommen, at software
udvikles over tid og at tillid er
den eneste vej.
torsdag den 23. maj 13
