Introduktion

Även om ni i dessa projekt inte har en tilldelad kund så kanske vissa av er kommer att arbeta mot en extern kund eller uppdragsgivare. Nedan följer lite handledning och tips kring kundkontakt.

Kundkontakt är något de flesta stöter på i en arbetssituation. Antingen kanske man arbetar dagligen med kunder eller så kanske man möter kunder mer sporadisk för att reda ut detaljer i krav eller för att leverera systemet. Hur som helst är det viktigt att man ger ett bra och professionellt intryck. Första intrycket betyder kanske inte allt, men ett dåligt första intryck kan vara svårt att tvätta bort.

Kontakta er kund så snart som möjligt helst via telefon om det är möjligt. Tänk på att presentera er tydligt, d.v.s. vad du heter och att du är student på Linnéuniversitetet samt ditt ärende. Försök att boka in ett personligt möte med kunden och hela projektgruppen så snart som möjligt där ni kan diskutera kundens problem/nuvarande situation samt önskemål.

Tänk på att en kund är expert på just sitt område och att de säkerligen kommer använda termer och begrepp som ni inte har en aning om vad det är, samtidigt som ni kanske använder termer och begrepp som inte kunden förstår. Det är viktigt att ställa frågor och se till att man inte pratar förbi varandra. En ordlista där man definierar termer och begrepp är ofta till stor hjälp. Ibland kan man även läsa på de mest grundläggande begreppen tidigt i ett projekt, då kan man iaf. ha de grundläggande delarna klart för sig. Det är inte ovanligt att man efter en tid som mjukvaruutvecklare blir expert på att bygga system för olika områden, t.ex. bank- och finansväsen, sjukvård eller bilindustri. Man utvecklar helt enkelt en domänexpertis vilket gör att man kan utveckla effektivare.

Generellt kan man säga att man bör undvika tekniska lösningar när man diskuterar med kunden, men detta beror givetvis på kunden. Kanske är kunden van vid teknologi, kanske finns det befintliga system, eller krav på specifika teknologier. Kan man undvika krav på specifik teknologi så är man fri att välja den lösning som passar projektet bäst vilket ju är en fördel.

Det ni bör fokuser på i början är att få information så att ni kan börja att utforma en gemensam vision för projektet:

• Vad är problemet?
• Vem/vilka grupper av slutanvändare finns det?
• Några specifika mätbara mål som kan formuleras?
• Finns det liknande system som man kan jämföra med?
• Vilka baskrav finns på applikationen?

Kundengagemang och leverans

Den iterativa utvecklingsprocessen bygger på återkoppling från kund och slutanvändare. Det är alltså mycket viktigt att man engagerar kunden i projektet genom att leverera fungerande mjukvara och att aktivt lyssna på kundens förslag till förändringar.

Förändrade krav på olika nivå är således ett tecken på en engagerad kund och ska ses som något positivt. Dock är det ju så att man inte kan förändra saker helt okontrollerat utan det är snarare en dialog mellan kund och utvecklare som krävs där man tillsammans kan prioritera kraven, med avseende på kundnytta, teknisk risk och projektets resurser.

Det är väldigt viktigt att ni engagerar kunden i era leveranser. Vid en leverans är det viktigt att peka ut vad det är som ska fungera så att kunden kan testa detta utan att köra fast på sådant som uppenbarligen inte skall fungera än. Det är också en stor fördel att man har specifika frågeställningar kring leveransen och de delar där man är osäker. Desto mer specifik man kan vara desto bättre, ett generellt mail med innehållet “Hej! Du finner systemet på url: xxx, är det ok?” är alltså inte så bra. Istället bör man boka ett möte med kunden för leverans och gå igenom funktionaliteten tillsammans med kunden, och ställa konkreta frågor.

Beroende på kundens situation och önskemål kan man också kontakta kunden “mitt i” en iteration för att fastställa detaljer i krav. Det optimala är givetvis en daglig kontakt med kund och slutanvändare.

Om ni känner att ni inte når fram till er kund och inte har den nivå av engagemang ni skulle vilja ha så kontakta er handledare snarast då bristande kundengagemang är en väldigt stor risk i projekt!