Beställa utveckling

Hur blir man bra på att beställa utveckling?

Många personer som jag kommer i kontakt med är osäkra på om de är tillräckligt duktiga beställare för att kunna jobba med ett utvecklingsteam på andra sidan jorden. Det finns en oro för att oavsett hur bra teamet är så kommer alltid flaskhalsen att vara deras egen förmåga som beställare.


Detta resonemang är rimlig givet att konsekvensen av problemet skulle bli ett utvecklingsteam som inte har något att göra eller gör fel saker.

Hur stort är problemet?

Jag vill absolut INTE hävda att det inte är ett problem alls. Dock vill jag hävda att problemet är långt mycket mindre än de flesta tror. Jag kan bara genom egen erfarenhet radda upp otaliga projekt där kvaliteten på beställningen har varit bristfällig till den grad att det påverkat slutresultatet negativt. Vad jag däremot hävdar med bestämdhet är att i stort sett vem som helst som är väl insatt i sin verksamhet kan lära sig att med ganska enkla medel lägga beställningar som är goda nog.

Jag har själv sett detta i många fall och hjälpt flera olika personer utan någon bakgrund som beställare av systemutvecklingstjänster att bli riktigt framgångsrika beställare.

Sammanhang

Det första man måste göra för att ställa tydliga krav är att se till att utvecklingsorganisationen förstår på riktigt de problem man löser eller de behov man fyller. Oftast gör man detta genom att berätta för teamet om bakgrunden till varför man är där man är och beskriva verkligheten för användarna av systemet idag.

Jag hävdar att alla som är förstår sig på sin egen verksamhet kan beskriva dessa saker och prata om dem tills ingen längre vill lyssna. Och det är precis detta de bör göra. Den absolut största konflikten mellan systemutveckling och verksamhet ligger i det faktum att för att lyckas måste man se till att båda parter förstår varandra och pratar samma språk. Man skulle kunna försöka lära verksamhetspersoner att förstå sig på programmering, men jag lovar att det nästan alltid kommer att vara lättare att få programmerare att förstå sig på verksamheten.

När väl ett programmeringsteam förstår sig på en verksamhet så är grunden för lyckade beställningar lagd. Det är inte du som beställare som behöver lära dig att prata med programmerare på deras vis utan det är programmeringsteamet som behöver lära sig att tolka dina önskemål utifrån den gemensamma verklighetsbeskrivning om dina användares vardag som ni har etablerat.

Ofta när beställningar av programmering inte når fram ordentlig är det för att man har ett utvecklingsteam som inte är bemannat för att ta emot beställningar från din verksamhet eller så ställer inte teamet rätt frågor.

Syfte

Som i all annan del av verksamheten är det viktigt att kunna förmedla varför man vill göra saker. Utan denna typ av information är det väldigt lätt att man utvecklar fel saker. Om ett utvecklingsteam inte förstår varför de skall utveckla en viss del av mjukvaran är det ganska stor risk att de kommer att hitta på sin egen anledning till Varför?

Det är en naturlig instinkt hos många att försöka formulera krav till utvecklingsteam genom att beskriva vad som skall göras. Detta är en av de vanligaste orsakerna till att utveckling misslyckas. När du ger instruktioner till ett utvecklingsteam om vad som skall göras missar du själva kärnan i budskapet…VARFÖR?

Om du formulerar dina krav i formen av att du definierar ett problem eller behov som dina användare har och samtidigt fokuserar på varför det är värt att lösa det problemet, då förmedlar du information till utvecklingsteamet som kräver att de sätter sig in i dina användares problem och behov men också att de faktiskt löser dina användares problem eller behov.

Sammanfattning

Var inte orolig för att du inte är en god nog beställare. Med rätt kompetens hos den mottagande parten bör de hjälpa dig att formulera dina behov på ett sätt som maximerar dina chanser att faktiskt få något som du är nöjd med.

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *