O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Bestbrains - kravspecifikationen må dø - 8 oktober 2012

3.424 visualizações

Publicada em

Publicada em: Tecnologia
  • Hørt. God gennemgang og argumentation.
    Heldigvis har jeg faktisk ikke været med til at svare på en kravspecifikation i løbet af de seneste 2 år, så mange kunder er også ved at modnes væk fra det forhold til løsninger, leverandører - og ikke mindst brugere!
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

Bestbrains - kravspecifikationen må dø - 8 oktober 2012

  1. 1. Hvorfor kravspecifikationen skal dø. BestBrains 4. oktober 2012tirsdag den 9. oktober 12
  2. 2. Klaus Silberbauer Partner, Creative Director Think! Digitaltirsdag den 9. oktober 12
  3. 3. Strategy Tactics Operationstirsdag den 9. oktober 12
  4. 4. Strategy Tactics Operationstirsdag den 9. oktober 12
  5. 5. Strategy Tactics Operations } UX mindsettirsdag den 9. oktober 12
  6. 6. “ Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.tirsdag den 9. oktober 12
  7. 7. “ 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
  8. 8. tirsdag den 9. oktober 12
  9. 9. Sorø Kommunetirsdag den 9. oktober 12
  10. 10. tirsdag den 9. oktober 12
  11. 11. tirsdag den 9. oktober 12
  12. 12. tirsdag den 9. oktober 12
  13. 13. tirsdag den 9. oktober 12
  14. 14. EPN 24 sep 2012tirsdag den 9. oktober 12
  15. 15. Svar på kravspecifikation “Der må ikke tages forbehold” Løst Delvist løst Ikke løsttirsdag den 9. oktober 12
  16. 16. tirsdag den 9. oktober 12
  17. 17. tirsdag den 9. oktober 12
  18. 18. “ 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
  19. 19. 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) tirsdag den 9. oktober 12 Aktøren har mulighed for at tilføje et vilkårligt antal
  20. 20. Aktøren er logget på systemet Eksempel 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:tirsdag den 9. oktober 12 Aktøren har oprettet en brevskabelon uden brug af
  21. 21. Aktøren er logget på systemet Eksempel 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:tirsdag den 9. oktober 12 Aktøren har oprettet en brevskabelon uden brug af
  22. 22. Eksempeltirsdag den 9. oktober 12
  23. 23. tirsdag den 9. oktober 12
  24. 24. 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
  25. 25. Reduktion ad absurdam Hvad skal en kravspecifikation • Implementering: Hvilke krav er der til projektledelse og gennemførelse af projektet. Hvilken rolle er det tilsigtet at indeholde? 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.tirsdag den 9. oktober 12
  26. 26. Beslutninger låses tidligt Konventionel kravspec Agile / best practice Man skal (forsøge) at tage hensyn til Man har fokus på målene og alle scenarier. Typisk uden at visionen - problemer løses gennemføre en egentlig designfase. undervejs. Man skal forudse problemer, der ikke er opstået endnu og situationer, man ikke har kendskab til.tirsdag den 9. oktober 12
  27. 27. Beslutninger låses tidligt Konventionel kravspec Agile / best practice Designbeslutninger tages uden Alle optioner holdes åbne til sidste indsigt, og låses kontraktligt. øjeblik. Designbeslutninger tages først når indsigten er størst.tirsdag den 9. oktober 12
  28. 28. Vi leverer “til spec” Konventionel kravspec Agile / best practice En 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.tirsdag den 9. oktober 12
  29. 29. Ændringer bliver svære Konventionel 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 vi summer i projektledelse. skal kunne adaptere undervejs. Man vil derfor typisk forsøge at undgå ændringer.tirsdag den 9. oktober 12
  30. 30. Kunden får en ja-siger Konventionel kravspec Agile / best practice Tilbudsfasen går nemmest, hvis Vi ved, at resultatet aldrig er som man blot accepterer kravene specificeret, for ny viden opnået (selvom kunden skriver, at man skal undervejs i processen giver os nye udfordre kravspec’en). idéer. Det er fristende at acceptere tåbelige krav mod bedre vidende.tirsdag den 9. oktober 12
  31. 31. Forsimplet syn på udvikling Konventionel kravspec Agile / best practice Kravpec’en cementerer opfattelsen Drift er udvikling og udvikling er af web- eller IT-udvikling som et drift. projekt med en start, slutning og et klart defineret produkt. Man skelner typisk mellem udvikling og drifttirsdag den 9. oktober 12
  32. 32. Kombineret med udbud, ak Konventionel 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ør færrest penge” alt for at skabe værdi indenfor givne økonomiske rammer”.tirsdag den 9. oktober 12
  33. 33. Pris Konventionel kravspec Agile / best practice Et komplekst udbud med stor Kunden og leverandøren bruger de kravspec kan tage +1.000 timer at +2.000 timer til sammen at skrive og +1.000 timer at besvare. formulere udfordringerne, målene og opnå tillid og enighed. Disse penge skal ind - prisen stiger.tirsdag den 9. oktober 12
  34. 34. Risiko Konventionel kravspec Agile / best practice Risikomaksimerende - projektledere Risikominimerende - product på overarbejde og jurister stand-by. owners en del af løsningen, jurister Modstridende interesser parterne i sjældent nødvendige. Fælles mellem. interesser.tirsdag den 9. oktober 12
  35. 35. Dræbende interaktionsfejltirsdag den 9. oktober 12
  36. 36. Dræbende interaktionsfejl Misforståelser af brugerens kontekst Processer understøttes Forkert forkert. navngivning.tirsdag den 9. oktober 12
  37. 37. Dræbende interaktionsfejl Misforståelser af brugerens kontekst Processer understøttes Forkert forkert. navngivning. Manglende Overflødig funktionalitet funktionalitet Konceptmæssige fejltirsdag den 9. oktober 12
  38. 38. Dræbende interaktionsfejl Misforståelser af brugerens Brugervenligheds- mæssige fejl kontekst Processer Brugerforstår understøttes Forkert ikke systemes forkert. navngivning. brugerflade Manglende Overflødig funktionalitet funktionalitet Konceptmæssige fejltirsdag den 9. oktober 12
  39. 39. 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 fejltirsdag den 9. oktober 12
  40. 40. “Fail early”tirsdag den 9. oktober 12
  41. 41. “Fail early” Kompleksitet / pris / risiko Tidtirsdag den 9. oktober 12
  42. 42. “Fail early” Kompleksitet / pris / risiko Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  43. 43. “Fail early” Kompleksitet / pris / risiko Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  44. 44. “Fail early” Interaktionsfejl Kompleksitet / pris / risiko fint Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  45. 45. “Fail early” Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko fint acceptable Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  46. 46. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko fint acceptable problematiske Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  47. 47. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko fint acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  48. 48. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl “Amanda” Kompleksitet / pris / risiko fint acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Tidtirsdag den 9. oktober 12
  49. 49. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl “Amanda” Kompleksitet / pris / risiko fint acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Risikominimering Scope down Tidtirsdag den 9. oktober 12
  50. 50. “Fail early” Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl “Amanda” Kompleksitet / pris / risiko fint acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Risikominimering Scope down Tidtirsdag den 9. oktober 12
  51. 51. Hvad gør vi så?tirsdag den 9. oktober 12
  52. 52. Start med interface design Design Test Indsigt Design Reality Agile Forretning Brand Struktur Interaktion check Dev Mål / KPI Dialog Succeskriterier Visuelt Design Brugere Tech Arkitektur Platform Data/Integrationtirsdag den 9. oktober 12
  53. 53. tirsdag den 9. oktober 12
  54. 54. IxD / IA ? Projektledelse Testbrugere AD / Design Beslutningstageretirsdag den 9. oktober 12
  55. 55. Et nyt paradigmetirsdag den 9. oktober 12
  56. 56. 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.tirsdag den 9. oktober 12
  57. 57. 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.tirsdag den 9. oktober 12
  58. 58. 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 Afsæt ikke et projektbudget, løsning skal opfylde. Der kan være 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 man troede.tirsdag den 9. oktober 12
  59. 59. 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 Afsæt ikke et projektbudget, løsning skal opfylde. Der kan være 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.tirsdag den 9. oktober 12
  60. 60. 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. Sats på langvarigt samarbejde og tillidsopbygning. Formulér hvilke mål den endelige Afsæt ikke et projektbudget, løsning skal opfylde. Der kan være 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.tirsdag den 9. oktober 12
  61. 61. 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. Sats på langvarigt samarbejde og Læg stor vægt på fælles konceptudvikling. tillidsopbygning. Formulér hvilke mål den endelige Afsæt ikke et projektbudget, løsning skal opfylde. Der kan være 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.tirsdag den 9. oktober 12
  62. 62. 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. Kunden: Insister på, at der Sats på langvarigt sættes et team, ikke bare sælges samarbejde og timer. Læg stor vægt på fælles konceptudvikling. tillidsopbygning. Formulér hvilke mål den endelige Afsæt ikke et projektbudget, løsning skal opfylde. Der kan være 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.tirsdag den 9. oktober 12
  63. 63. 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. Kunden: Insister på, at der Sats på langvarigt sættes et team, ikke bare sælges samarbejde 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.tirsdag den 9. oktober 12
  64. 64. 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ælges samarbejde 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.tirsdag den 9. oktober 12
  65. 65. Think! Digital is a Copenhagen based, strategic digital agency, firmly rooted in the tradition of user experience design. Digital is business. facebook.com/thinkdigitaldk twitter.com/thinkdigitaldk www.thinkdigital.dk lets@thinkdigital.dk +45 3164 0100tirsdag den 9. oktober 12

×