kravspec best brains 4. okt. 2012

BestBrains 4. oktober 2012

Hvorfor kravspecifikationen skal dø.

Klaus SilberbauerPartner, Creative DirectorThink! Digital

Strategy

Tactics

Operations

} UX mindset

Strategy

Tactics

Operations

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.

孫子 SUN TZU, 500 B.C.

“

Sorø Kommune

EPN 24 sep 2012

Svar på kravspecifikation

Løst

Delvist løst

Ikke løst

“Der må ikke tages forbehold”

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.“

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.

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.

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.

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


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


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”


Æ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


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


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


“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


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


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

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

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

Hvad gør vi så?

Start med interface design

IndsigtForretning

BrandMål / KPI

SucceskriterierBrugere

Realitycheck

TechArkitekturPlatform

Data/Integration

AgileDev

TestDesign

DesignStruktur

InteraktionDialog

Visuelt Design

Projektledelse

Beslutningstagere

IxD / IA

AD / Design

Testbrugere

?

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.

kravspec best brains 4. okt. 2012

Documents