Leverandørdressur
Forholdet mellom teknisk leverandør og kunde er ofte preget av misforståelser . Leverandøren snakker sitt tekniske språk, som kunden ikke skjønner, og kunden snakker sitt dagligdagse språk som blir for teknisk upresist til at leverandøren får klar beskjed.
Dette er et problem for begge parter. Kunden får ikke det han vil ha, og leverandøren får ikke klar beskjed om hva som skal til. – Jeg skrev en svært frustrert artikkel om dette på digi.no i 1999. Du kan lese den her:
Verden har heldigvis gått litt framover etter dette. Kunder er blitt mer erfarne, leverandører leverer i stadig større grad ferdig utprøvd hyllevare, og begge parter har fått en mer samkjørt forståelse av hva en kravspesifikasjon er.
MEN: Det forandrer ikke det faktum at det er kunden som betaler kalaset, og han/hun har krav på valuta for pengene. Derfor, her er noen praktiske råd. (NB! Dette er rådene som i sin tid skaffet meg rykte som “Kunden fra Helvete”. Disse tipsene gjør deg ikke populær – bare effektiv.)
I kravspesifiseringsfasen:
- Skaff deg en teknisk kyndig person (fortrinnsvis en systemarkitekt) som er på din side . Det kan være en i egen organisasjon, en samarbeidspartner eller en ekstern konsulent. Det er IKKE en som jobber i leverandørbedriften.
- Få denne personen (over) til å hjelpe deg å skrive kravspesifikasjonen , og til å være med i alle møter med leverandøren. MEN: Denne personen skal ikke legge premissene, han skal fungere som tolk for deg.
- Hvis du ikke kan skaffe en slik person, er det likevel bedre at du skriver kravspesifikasjonen enn at leverandøren gjør det. Ty i så fall til funksjonalitets-spesifisering , det vil si at du beskriver i størst mulig detalj hvordan du ønsker at tjenesten skal fungere. Eksempel: “Brukeren skal kunne bestille brosjyrer fra en egen bestillingsside. På denne siden skal bruker kunne fylle ut ønsket antall av gitte brosjyrer, samt navn og adresse. Når samme bruker kommer tilbake til nettstedet senere og går inn på bestillingssiden, skal navn og adresse komme opp ferdig utfylt”.
I dialog med leverandøren:
- Hvis du har skrevet kravspesifikasjon uten teknisk bistand: Be leverandøren om å få beskjed dersom det er selvmotsigelser i den kravspesifikasjonen du har skrevet. (Enkelte ting er faktisk teknisk sett uforenlige.) Spør også leverandøren eksplisitt om det er noen funksjonalitet du har spesifisert som er spesielt dyr og krevende . Det kan hende du kan redusere prisen vesentlig ved å gi avkall på et par relativt uvesentlige detaljer.
- Hvis leverandøren har skrevet spesifikasjonen, forlang å få ta den med deg og gå gjennom den med en teknisk kyndig tredje part før du godtar noe som helst.
- Spør uttrykkelig og eksplisitt om hva begrensningene er, og om konsekvenseneav alle valg.
- Alle leverandører sier “alt er mulig”. Dette betyr egentlig at “alt er mulig, hvis vi bytter ut hele serverparken og bruker to år og fire millioner kroner på egenutvikling”. Godta aldri det generelle svaret at “alt er mulig”. Spør heller konkret : Hvordan skal dette gjøres? Hva koster det? Hvor lang tid tar det?
- Noen gode kontrollspørsmål til alle webleverandører er: “Kan jeg forandre stilsett og designmaler selv?” “Kan jeg skrive inn rå HTML?” ” Kan jeg opprette nye seksjoner og undersider fritt?” “Hvis jeg vil, kan jeg ta løsningen med meg til et annet firma om to år og få dem til å arbeide videre med den?”
I kontraktsfasen:
- Forlang en akseptanseperiode på minst en måned i kjøpekontrakten. Dette gir deg tid til å finne ut om løsningen fungerer etter hensikten før du formelt aksepterer at leveransen er i tråd med din spesifikasjon.
- Forlang nedfelt i avtalen at bugs som hindrer funksjonalitet i henhold til kravspesifikasjon skal rettes omgående og uten kostnad ved skriftlig (e-post) bugmelding fra deg.
- Be om en klausul om dagbøter dersom leveransen er forsinket i forhold til kjøpekontrakten. (Dette må naturligvis ikke gjelde forsinkelser du selv er skyld i.) Det er ikke sikkert du får det, men det er lov å prøve.
Ønsker du å lære mer om leverandørdressur i webprosjekter?
Ta en titt på Webgruppens kurs i strategi og kravspesifikasjon.