Upload
think-digital
View
3.199
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
BestBrains 4. oktober 2012
Hvorfor kravspecifikationen skal dø.
tirsdag den 9. oktober 12
Klaus SilberbauerPartner, Creative DirectorThink! Digital
tirsdag den 9. oktober 12
Strategy
Tactics
Operations
tirsdag den 9. oktober 12
Strategy
Tactics
Operations
tirsdag den 9. oktober 12
} UX mindsetStrategy
Tactics
Operations
tirsdag den 9. oktober 12
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.“
tirsdag den 9. oktober 12
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
tirsdag den 9. oktober 12
Sorø Kommune
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
EPN 24 sep 2012
tirsdag den 9. oktober 12
Svar på kravspecifikation
Løst
Delvist løst
Ikke løst
“Der må ikke tages forbehold”
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
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
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 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 programmering og HTML-tags.
tirsdag den 9. oktober 12
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 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 programmering og HTML-tags.
tirsdag den 9. oktober 12
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 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 programmering og HTML-tags.
tirsdag den 9. oktober 12
Eksempel
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
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
Reduktion ad absurdamHvad 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 krav
• Leverandøren skal kunne forstå det eksisterende IT-landskab, herunder hvilke systemer der skal integreres med. Her nævnes også krav til oppetid, svartider, back-up, clustering, load-balancing, dynamisk/statisk levering
• Implementering: Hvilke krav er der til projektledelse og gennemførelse af projektet. Hvilken rolle er det tilsigtet at leverandøren skal have? Hvilke arbejdsgange skal forbedres? Hvordan ser det ud fra brugerens synsvinkel? Hvad er forbindelsen fra de forretningsmæssige mål til kravene? Skal leverandøren bruge bestemte metoder og værktøjer (f.eks. use cases, prototyping, agile, extreme programming, usability test). Hvor meget træning er nødvendig?
• Leverandør kvalifikationer og referencer.
• Yderligere information fra leverandøren: Hvis leverandøren har relevant, men ikke påkrævet information at tilføje
• Pris: Hvordan skal dette præsenteres?
• Kontrakt og licensaftale: Alle juridiske detaljer
• Bilag, der indeholder relevant information, så som netværksdiagrammer, projektplaner og forretningskrav.
• De enkelte punkter i kravspecifikationen kan med fordel 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
Agile / best practiceKonventionel kravspec
Man har fokus på målene og visionen - problemer løses undervejs.
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
tirsdag den 9. oktober 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.
Beslutninger låses tidligt
tirsdag den 9. oktober 12
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.
Vi leverer “til spec”
tirsdag den 9. oktober 12
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.
Ændringer bliver svære
tirsdag den 9. oktober 12
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
tirsdag den 9. oktober 12
Agile / best practiceKonventionel kravspec
Drift er udvikling og udvikling er drift.
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
tirsdag den 9. oktober 12
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”
Kombineret med udbud, ak
tirsdag den 9. oktober 12
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
tirsdag den 9. oktober 12
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
tirsdag den 9. oktober 12
Dræbende interaktionsfejl
tirsdag den 9. oktober 12
Dræbende interaktionsfejl
Misforståelser af brugerens kontekst
Forkert navngivning.
Processer understøttes
forkert.
tirsdag den 9. oktober 12
Dræbende interaktionsfejl
Misforståelser af brugerens kontekst
Forkert navngivning.
Processer understøttes
forkert.
Konceptmæssige fejl
Overflødig funktionalitet
Manglende funktionalitet
tirsdag den 9. oktober 12
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
Brugerforstår ikke systemes brugerflade
tirsdag den 9. oktober 12
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
Brugerforstår ikke systemes brugerflade
Diskursmæssige fejl
Systemet taler ned til brugeren
Systemet er indforstået
tirsdag den 9. oktober 12
“Fail early”
tirsdag den 9. oktober 12
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
tirsdag den 9. oktober 12
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
Interaktionsfejlfint
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
Interaktionsfejlproblematiske
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
Interaktionsfejlproblematiske
Interaktionsfejlekstremt
problematiske
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
Interaktionsfejlproblematiske
Interaktionsfejlekstremt
problematiske
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
“Amanda”
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
Interaktionsfejlproblematiske
Interaktionsfejlekstremt
problematiske
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
“Amanda”
RisikominimeringScope down
tirsdag den 9. oktober 12
Interaktionsfejlfint
Interaktionsfejlacceptable
Interaktionsfejlproblematiske
Interaktionsfejlekstremt
problematiske
“Fail early”K
om
ple
ksit
et /
pri
s /
risi
ko
Tid
Sketching Wireframing Prototyping
Visual design Development
“Amanda”
RisikominimeringScope down
tirsdag den 9. oktober 12
Hvad gør vi så?
tirsdag den 9. oktober 12
Start med interface design
IndsigtForretning
BrandMål / KPI
SucceskriterierBrugere
Realitycheck
TechArkitekturPlatform
Data/Integration
AgileDev
TestDesign
DesignStruktur
InteraktionDialog
Visuelt Design
tirsdag den 9. oktober 12
tirsdag den 9. oktober 12
Projektledelse
Beslutningstagere
IxD / IA
AD / Design
Testbrugere
?
tirsdag den 9. oktober 12
Et nyt paradigme
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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
Et nyt paradigmeVæ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
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Et nyt paradigmeVæ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.
tirsdag den 9. oktober 12
Think! Digital is a Copenhagen based, strategic digital agency, firmly rooted in the tradition of user experience design.
Digital is business.
facebook.com/thinkdigitaldktwitter.com/[email protected]+45 3164 0100
tirsdag den 9. oktober 12