”Allt är IT”
är en fras som dyker upp allt oftare. Om detta nu är sant, är uppdelningen
mellan den så kallade kärnverksamheten och IT-avdelningen då verkligen
relevant? Och om den är det, hur kan vi förbättra kommunikationen? År 2016
borde det finnas effektivare metoder än röksignaler och stelbenta
ärendehanteringssystem.
I ett av mina
första uppdrag som testare - för vad som nu är ganska många år sedan - fanns
det ett
enda sätt att kommunicera med de utvecklare som skrev koden för
produkten vi testade: ett felrapporteringssystem. Det säger sig självt att
kommunikationen blir ganska bristfällig om det är den enda kommunikationsvägen
och ledtiderna var extrema, det tog dagar och ibland veckor att få svar på en
fråga eller att få tillbaka den för testare så bekanta frasen ”cannot
reproduce”.
Som tur är
förändras saker och ting, och kommunikationen är kanske en av de saker som
förändrats mest. Jag minns att vi var överlyckliga när vi fick möjlighet att
maila direkt till utvecklarna och diskutera den vägen, och senare dök också ett
chatprogram upp som ytterligare minskade gapet och tröskeln att ta kontakt. Var
de satt hade vi fortfarande ingen aning om, men telefonen tog oss förstås ännu
ett steg närmare.
Förändringarna
har fortsatt och idag arbetar väldigt många i agila utvecklingsteam där man
ofta sitter tillsammans och har ett väldigt tätt samarbete mellan de olika
rollerna i gruppen. Vissa har tagit det ännu längre och börjat lösa upp
rollerna som sådana – vi är alla utvecklare där vissa kanske har mer fokus på
till exempel test, eller så skriver vi kod en dag och testar nästa. Oavsett
upplägg så finns det förstås stora fördelar med att arbeta så tätt, inte minst
så ökar kunskapen och förståelsen för alla i gruppen avsevärt.
När vi nu
brutit ner många av de barriärer som i många fall funnits inom
mjukvaruutveckling, så har testarna bättre insikt i koden vilket kan göra det
lättare att förstå hur och vad som behöver testas. Utvecklarna i sin tur har en
bättre förståelse för testarnas behov, och inte minst så har alla
förhoppningsvis god tillgång till kraven och en kravansvarig som kan berätta
vad det är kunden behöver.
Här finns det
dock enligt min erfarenhet en extremt tydlig gräns: kunden, det vill säga
kärnverksamheten, och IT-avdelningen, där nyutveckling och modifiering sker av
det IT-stöd som verksamheten behöver.
Är detta
verkligen en relevant uppdelning? IT är ju idag en så stor och viktig del av många
arbetsprocesser som finns inom ett större företag – ”allt är IT” är en fras som
hörs ibland. Om vi nu har sådan närhet i utvecklingsprocessen, varför måste
just kraven och verksamhetsförståelsen gå via den ibland trånga tratt som
kravanalytikern kan vara?
Den närhet,
direkta kommunikation och förståelse för varandra som kommer av att vara ett
gemensamt team och gärna arbeta nära varandra rent fysiskt, det är något som
skulle kunna gynna både IT och verksamhet.
Testare med
god insikt i verksamheten (eller som faktiskt är en del i verksamheten) har en
större förståelse för vad som är viktigt att testa, hur tester kan ske och hur
de bör prioriteras. De kan förstås också på ett bättre sätt bedöma lämpligheten
i en IT-lösning och dessutom göra bedömningar av användbarheten hos systemet.
För en
utvecklare är fördelarna likartade, för oavsett hur bra och väl specificerade
kraven och designen är, så måste det fattas en mängd beslut under
utvecklingsprocessen. Med en god insikt om användarna och användandet blir det
lättare att fatta beslut som i slutändan leder till en bättre produkt.
Även
verksamheten skulle ha mycket att vinna, till exempel är min erfarenhet att de
som ställer krav och kommer med önskemål kan ha svårt att tänka utanför boxen
och verkligen tänka nytt. En del i detta är att man inte har någon uppfattning
om vilka möjligheter som finns, eller hur svårt respektive lätt det är att
genomför vissa idéer. Kanske vågar man inte ställa vissa krav eller så behöver
man helt enkelt inspiration utifrån för att tänka om.
Jag säger
inte att man behöver eller över huvud taget ska ta över varandras
arbetsuppgifter, men bara något så enkelt som att sitta i samma kontorslandskap
skulle göra otroligt stor skillnad. Förutom den informella kommunikationen i att
ha personer lätt till hands för att ställa frågor, stämma av saker med, snabbt
visa eller demonstrera något, så är det mycket information som flyger genom
luften som går att snappa upp. Det är denna informationsmängd sammantaget som
bygger upp kunskapen, medvetet eller omedvetet.
Som en bonus
kan man tänka sig att de som arbetar främst med IT-utveckling kan känna en
större tillhörighet till bolaget i stort, när man är närmare bolagets
kärnverksamhet, det bolaget ”egentligen gör”.
IT kommer
framöver troligtvis bli en allt större del av de flestas arbeten, och med det en
förhoppning hos mig att den traditionella IT-avdelningen är dödsdömd. Jag vill
uppmana alla som jobbar inom IT att sträva efter en tätare kommunikation med
verksamheten, inte bara för att komma närmare detta mål utan för att jag tror
det hjälper oss i våra arbeten. Låt oss bara hoppas att vi slipper kommunicera
via runstenar eller röksignaler – eller för den delen ett stelbent
ärendehanteringsprogram.
/Gabriel
Johansson
Kravanalytiker,
test manager och lärare
Gabriel Johansson är utbildad interaktionsdesigner på Malmö
Högskola och har idag mer än tio års erfarenhet inom test och kravhantering i
agila projekt, testautomatisering och usability testing.
Erfarenheten sträcker sig över en rad branscher som telekom, logistik, industri,
bank och finans samt detaljhandel.
Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här
1 kommentarer :
Många från "IT-sidan" uppskattar att jobba närmare verksamheten - och vice versa, tätare dialog och möter förväntningar tidigare som följd. Upplever att ditt inlägg kanske missar perspektivet att IT-förändringen är en del i det behov (problem) som man vill lösa. IT är inte allt. IT är heller inte begränsat till IT-utveckling. Upplever sällan att en testare från "IT" (om än med god verksamhetsförståelse), har bättre förståelse för VAD som är viktigt att testa eller kan bättre bedöma prioritering. Prioritering bygger ju på beställningens förväntade utkomst. Berätta, hur menar du att mottagaren av beställningen är bättre att prioritera VAD som är viktigt. Jag skulle påstå att prio om VAD som är viktigt ligger främst i beställarens händer, HUR man säkerställer ligger främst i testarens händer. TILLSAMMANS når man bättre resultat för båda perspektiv. Du håller säkert med?
SvaraSkicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.