Kravspec best brains 4. okt. 2012

531 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
531
On SlideShare
0
From Embeds
0
Number of Embeds
83
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Kravspec best brains 4. okt. 2012

  1. 1. Hvorforkravspecifikationenskal dø.BestBrains 4. oktober 2012
  2. 2. Klaus SilberbauerPartner, Creative DirectorThink! Digital
  3. 3. Strategy TacticsOperations
  4. 4. Strategy TacticsOperations } UX mindset
  5. 5. “ Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. 孫子 SUN TZU, 500 B.C.
  6. 6. Sorø Kommune
  7. 7. EPN 24 sep 2012
  8. 8. Svar påkravspecifikation“Der må ikke tages forbehold” Løst Delvist løst Ikke løst
  9. 9. “ 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.
  10. 10. 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
  11. 11. Aktører: Redaktionen Før-tilstand, forudsætninger: Aktøren er logget på systemetEksempel 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.
  12. 12. Formålet med at bygge enbro er broen i sig selv.En webløsnings mål erikke løsningen i sig selv,men den værdi,løsningen skal skabe.
  13. 13. Reduktion ad absurdamHvad skal en kravspecifikation • Implementering: Hvilke krav er der til projektledelse og gennemførelse af projektet. Hvilken rolle er det tilsigtet atindeholde? 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.
  14. 14. Beslutninger låses tidligtKonventionel kravspec Agile / best practiceMan skal (forsøge) at tage hensyn til Man har fokus på målene ogalle scenarier. Typisk uden at visionen - problemer løsesgennemføre en egentlig designfase. undervejs.Man skal forudse problemer, derikke er opstået endnu og situationer,man ikke har kendskab til.
  15. 15. Beslutninger låses tidligtKonventionel kravspec Agile / best practiceDesignbeslutninger tages uden Alle optioner holdes åbne til sidsteindsigt, og låses kontraktligt. øjeblik. Designbeslutninger tages først når indsigten er størst.
  16. 16. Vi leverer “til spec”Konventionel kravspec Agile / best practiceEn 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.
  17. 17. Ændringer bliver sværeKonventionel 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 visummer i projektledelse. skal kunne adaptere undervejs.Man vil derfor typisk forsøge atundgå ændringer.
  18. 18. Kunden får en ja-sigerKonventionel kravspec Agile / best practiceTilbudsfasen går nemmest, hvis Vi ved, at resultatet aldrig er somman blot accepterer kravene specificeret, for ny viden opnået(selvom kunden skriver, at man skal undervejs i processen giver os nyeudfordre kravspec’en). idéer.Det er fristende at accepteretåbelige krav mod bedre vidende.
  19. 19. Forsimplet syn på udviklingKonventionel kravspec Agile / best practiceKravpec’en cementerer opfattelsen Drift er udvikling og udvikling eraf web- eller IT-udvikling som et drift.projekt med en start, slutning og etklart defineret produkt.Man skelner typisk mellem udviklingog drift
  20. 20. Kombineret med udbud, akKonventionel 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ørfærrest penge” alt for at skabe værdi indenfor givne økonomiske rammer”.
  21. 21. PrisKonventionel kravspec Agile / best practiceEt komplekst udbud med stor Kunden og leverandøren bruger dekravspec kan tage +1.000 timer at +2.000 timer til sammen atskrive og +1.000 timer at besvare. formulere udfordringerne, målene og opnå tillid og enighed.Disse penge skal ind - prisen stiger.
  22. 22. RisikoKonventionel kravspec Agile / best practiceRisikomaksimerende - projektledere Risikominimerende - productpå overarbejde og jurister stand-by. owners en del af løsningen, juristerModstridende interesser parterne i sjældent nødvendige. Fællesmellem. interesser.
  23. 23. Dræbende interaktionsfejl Misforståelser af brugerens Brugervenligheds- mæssige fejl kontekst Processer Brugerforstår understøttes Forkert ikke systemes forkert. navngivning. brugerflade Systemet er Manglende Overflødig indforstået Systemet funktionalitet funktionalitet taler ned til brugeren Konceptmæssige fejl Diskursmæssige fejl
  24. 24. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl “Amanda”Kompleksitet / pris / risiko fint acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Risikominimering Scope down Tid
  25. 25. Hvad gør vi så?
  26. 26. Start med interface design Design Test Indsigt Design Reality Agile Forretning Brand Struktur Interaktion check Dev Mål / KPI DialogSucceskriterier Visuelt Design Brugere Tech Arkitektur Platform Data/Integration
  27. 27. IxD / IA ?Projektledelse Testbrugere AD / Design Beslutningstagere
  28. 28. 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ælgessamarbejde 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.

×