Når vi web-kunder møtes, hender det at spørsmålet om leverandører kommer på banen. "Hvem har laget løsningen deres?" spør vi hverandre da, og svarer gjerne med ett eller annet større bransjenavn.
Neste spørsmål er uunngåelig: "Er dere fornøyd?"
Til dags dato har jeg ennå til gode å høre noen svare ubetinget "ja" på dette spørsmålet. Det beste man får høre er et nølende "tjah, i det store og hele så er vi vel det ...". Dette svaret betyr som oftest at vedkommende er redd for å røpe hvor mye penger han egentlig har kastet bort.
_logo.svg.png){kind=logo}
Er kunden mindre diskret, får man høre skrekkhistorier fra virkeligheten. Om tidsoverskridelser på både måneder og år, om dobling og tripling av pristilbud, om løsninger som kneler under første forsøk på stresstesting, og om buglister på hundrevis av punkter. Veien tilbake til tegnebrettet er velkjent for alle som noen gang har hatt ansvar for et større utviklingsprosjekt.
Og i anstendighetens navn: noe av skylden må vi ta selv. Som kunder, mener jeg. For det er et godt, gammelt jungelord som sier at jo mindre kunden vet om web, jo større problemer kommer prosjektet til å få. Det er så sant som det er sagt!
På den annen side sett så mener jeg faktisk at en bedrift som påtar seg et millionoppdrag - eller et oppdrag i hundre- eller titusenkronersklassen, for den sakens skyld - faktisk plikter å fortelle kunden sin hva han kommer til å få. På en måte som kunden skjønner.
Og det er dette som egentlig er sakens kjerne: Kommunikasjonsproblemet. Eller rettere sagt: Forståelses-problemet. For kunden og leverandøren kommuniserer en hel masse med hverandre. Det er bare at fint lite av det som sies betyr det samme for begge parter.
For eksempel: Når kunden ber om en "oversikt" over nettstedet, mener han et navigasjonskart. Det leverandøren tror han mener er et flytskjema. Når leverandøren snakker om "grensesnitt", mener han informasjonsarkitektur. Det kunden tror han snakker om er grafisk design. Når kunden sier "en skisse" mener han en grafisk framstilling av forsiden. I fire farger. Det han kommer til å få, er to A4 sider med tekst som beskriver teknisk funksjonalitet.
Og dette er bare i løpet av de første fem minuttene av møtet.
Prosessen går som følger: Kunden beskriver behovene sine for leverandøren. Jo mindre erfaren kunden er, jo mer vag og utydelig er beskrivelsen.
Leverandøren tolker og gjetter etter beste evne, og svarer med en kravspesifikasjon som er så teknisk og så detaljert at kunden ikke forstår et kvidder. Nå har kunden to muligheter:
1: Han kan innrømme at han ikke forstår, og be om å få spesifikasjonen forklart i klartekst, i detalj, med alle mulige konsekvenser.
Fordelen med denne løsningen er at han da faktisk har en sjanse til å få det han vil ha (- men det er langt fra sikkert). Ulempen er at han må tåle å fremstå som en dust som ikke skjønner en kravspesifikasjon, og at han dessuten med dette har pålagt sitt eget prosjekt en ikke uvesentlig forsinkelse og fordyring for den tiden som kommer til å gå med til selve avklaringsprosessen.
Derfor velger de fleste alternativ nummer
2: Han kan late som om han skjønner spesifikasjonen, ha tillit til at leverandøren har forstått ham riktig, og signere i god tro. Fordelen er at han beholder ansikt - for en kort stund. Ulempen er at han etter all sannsynlighet kommer til å ende opp med en løsning som er noe helt annet enn det han ville ha.
Dette skjønner han imidlertid ikke før løsningen er blitt så konkret at han faktisk kan se konturene av den. Da innser kunden med stigende panikk at dette er helt på jordet i forhold til det han hadde tenkt seg.
Så er det tilbake til tegnebrettet med hele gjengen, og begynne på nytt - bortsett fra at det nå har påløpt en betydelig regning som kommer i tillegg til prosjektprisen, og at det er gått uker, kanskje måneder, som må legges til endelig ferdigstillingsdato.
Slik kan man fortsette i flere runder, alt mens utviklerne skriver timelister og leverandørens kassaapparater plinger tusenlappene inn. Og mens tiden går.
Nå biter kunden negler til benet, fordi han har bestilt reklamekampanjer som han allerede har skjøvet på flere ganger, og han har lovet lansering minst fem ganger med forskjellige tidsfrister. Faktisk er ikke situasjonen ideell for leverandøren heller, som antakelig har andre prosjekter som venter.
Så kommer endelig lanseringen. Blitzene lyner og tjenesten vises på storskjerm. Og krasjer. Gedigent, og foran et samlet pressekorps. Og datapressen er faktisk forbausende overbærende med den slags - antakelig fordi de fleste har vært i samme båt selv.
Men før eller senere har kunden tjenesten sin oppe og går, og skal drive den på egenhånd. Hvor lang tid det tar før han begynner å stange på begrensningene, varierer fra dager til i beste fall måneder. Helt til den dagen han trenger å opprette en ny seksjon, og oppdager at det ikke er mulig. Eller ønsker å endre navigasjonen, bare for å oppdage at han er utestengt fra denne delen av systemet. Eller begynner å få sinte tilbakemeldinger fra brukere med nyere nettlesere og plattformer.
Dermed er det tilbake til start igjen, enten med den samme leverandøren (på tross av dårlige erfaringer sist, fordi de har solgt ham en proprietær løsning) - eller med en ny, som kommer til å bruke minst like lang tid på å sette seg inn i den eksisterende løsningen som de vil bruke på å starte fra scratch.
Det er catch 22 - en runddans som det ikke finnes noen god vei ut av. Ikke før kundene lærer seg å skjønne IT-teknisk fagterminologi, eller leverandørene lærer å forklare løsningene sine (og konsekvensene av dem) på godt norsk.
Men i mellomtiden finnes det en nisje i det norske leverandør-markedet. En nisje for et firma som både forstår og blir forstått av kundene sine. Et firma som faktisk leverer det de har lovet, til det tidspunktet de har sagt, til den prisen som er avtalt.
Et slikt firma vil faktisk kunne gjøre rent bord med de største web-kundene i Norge.
Og kanskje kundene til og med vil kunne si noe pent om dem etterpå.
Hvis du tror at du allerede forstår leverandøren din, kan du jo ta en titt på "The Tao of Programming" :
