bestbrains 22. maj - træt af it-skandaler

BestBrains 22. maj 2013

Hvorfor kravspecifikationen skal dø.

torsdag den 23. maj 13

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 / O!ces in Copenhagen


Clients (since december 2011)


EPN 24 sep 2012


Svar på kravspecifikation

Løst

Delvist løst

Ikke løst

“Der må ikke tages forbehold”


§torsdag den 23. maj 13

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.


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å systemetBeskrivelse: 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.


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å systemetBeskrivelse: 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.

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.


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



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



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 a!ø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”



Æ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



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



“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



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


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


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


Interaktionsfejlfint

Interaktionsfejlacceptable

Interaktionsfejlproblematiske

Interaktionsfejlekstremt

problematiske

“Fail early”K

om

ple

ksit

et /

pri

s /

risi

ko

Tid

Sketching Wireframing Prototyping

Visual design Development

“Amanda”

Risikominimering

Scope 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


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-bu!ere.

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.


facebook.com/thinkdigitaldktwitter.com/thinkdigitaldklinkedin.com/thinkdigitaldkyoutube.dk/thinkdigitaldkwww.thinkdigital.dkklaus.silberbauer@thinkdigital.dk31 64 01 01

Tak


http://www.thinkdigital.dk

http://www.thinkdigital.dk

bestbrains 22. maj - træt af it-skandaler

Documents