Beställare kan sällan beställa. Och byråer ställer ofta för få frågor
Beställaren behöver inte kunna lösningsdesign. Byrån behöver undersöka behovet och testa den gemensamma förståelsen innan bygget börjar.
Beställaren beskriver vad den vill ha. Byrån antecknar och föreslår en lösning. Alla går därifrån med känslan att de är överens.
Några veckor senare:
”Det var inte det här vi menade.”
”Men vi byggde det ni bad om.”
Det hjälper inte särskilt mycket att reda ut vem som kan citera beställningen bäst. Ni behöver förstå varför ni såg olika saker framför er.
Behovet försvann på vägen till lösningen
Beställaren kan sin verksamhet och vet vad som krånglar. Men den behöver inte kunna beskriva ett tekniskt upplägg eller ett användarflöde.
Byrån kan bygga, men kan inte utgå från att ord som ”portal”, ”enkelt” eller ”automatiskt” betyder samma sak för alla.
Därför behöver ni undersöka beställningen tillsammans. Annars riskerar den som kan minst om lösningsalternativen att råka bestämma det viktigaste teknikvalet.
Visa innan ni låser er
Be beställaren visa hur uppgiften görs idag. Följ med där arbetet händer och prata med dem som ska använda resultatet.
Rita sedan ett enkelt flöde eller en skiss och gå igenom ett konkret fall tillsammans. Vad händer här? Vilka uppgifter behövs? Vad händer om något saknas?
Det ger er något att upptäcka missförstånd i innan de byggts in i systemet.
Skriv ner det ni faktiskt kommit överens om
En berättelse om användarens uppgift kan hjälpa er att förstå behovet. Sedan behöver ni också tydliga krav och ett sätt att avgöra om leveransen uppfyller dem.
Beskriv vad som ingår, vad som fortfarande är öppet och vem som fattar beslut om ändringar. Låt båda sidor rätta bilden.
Det tar tid i början. Men att bygga om något som båda trodde var självklart brukar ta mer.
Så när någon säger ”vi behöver en app”, börja gärna med: ”Visa mig vad ni försöker få gjort.”