Bör testare ta plats i styrgruppen för projektet?

Jag har under det senaste halvåret återkommande hamnat i diskussioner gällande testledares vara eller icke vara i frågan om närvarande i styrgrupper. I denna frågeställning är jag övertygad att det inte finns något definitivt rätt eller fel, så därför tänkte jag ta mig friheten att dela med mig av mina personliga tankar och reflektioner.

Ett styrgrupp ska stödja projektbeställaren, den ska behandla projektets prioriteringar, resurser och status. Projektbeställaren bör vara den drivande kraften i styrgruppen och ärenden ska behandlas på en övergripande nivå. Se gärna Wenells projektmodell för ytterligare information över en styrgrupps uppgift.  http://www.wenell.se/styrgrupp.html

Det som en del förespråkar i vår testbransch är att vi bör få vara med i styrgrupperna för att kunna erbjuda effektiv statusrapportering av projektets status. Detta kan verka smidigt då testare oftast känner till systemet och teamets arbete väl och för att på detta sätt synas och därigenom höja testarens status. Denna trend att testare bör ta över mycket av projektledarens huvudsakliga uppgifter har dock en baksida som kan vara värd att beakta innan vi tycker att detta är en bra idé.

Den statusrapportering som bör presenteras för styrgrupper bör vara på en mycket övergripande nivå. Denna avrapportering kring projektets status bör projektledaren ha förståelse för och i sin tur kunna presentera för styrgruppen. Vinsten av detta är självklart att projektledaren får ett automatiskt incitament att faktiskt ha kontroll på sitt egna projekt. Testare har ibland en förmåga att grotta ner sig i smaskiga kvalitetsrelaterade fakta på en alltför detaljerad nivå som inte berör styrgruppen. Detta kan medföra att styrgruppen blir alltför “operativ” och samtalen halkar ner på en alltför detaljerad nivå. Jag har varit med om ett flertal gånger när styrgrupper har en oförmåga att ta tag i övergripande problemområden såsom resursförstärkning då det är mycket enklare (och roligare) att diskutera designbuggar i användargränssnittet eller varför funktionalitet som fungerade förra månaden nu är trasig till exempel.

Med argumentet “vi vill vara där för att höja vår status” kan det i längden bli förhållandevis trånga styrgruppsmöten då det kan leda till att utevcklingsledaren även vill kunna prata “för sin sak” och sen följer måhända kravanalytikern, arkitekten och användarrepresentanter på.

Testledande har liksom all annan verksamhet en begränsande faktor, tiden. Om vi lägger ett par timmar i veckan på att sätta oss in i sådant som normalt är projektledarens ansvar såsom projektets progress och kostnader, så tar det fokus från annat. Så är det bara.

Nu, med detta sagt vill jag belysa det faktum att alla projekt är olika och ingen styrgrupp är den andra lik. Behovet av information kring projektet kan vara fundamentalt annorlunda så det finns inget rätt och fel här. Jag personligen håller mig gärna utanför styrgruppens diskussioner och fokuserar gärna på annat som regel. Men om jag ser att styrgruppen behöver hjälp med att förstå projektstatus och jag blir ombedd att förklara för dem är mitt ansvar i projektet att leverera värdefull information och således faller detta innanför min expertis och roll. Om situationen är annorlunda, att jag ser att risken är stor att utvecklarna inte förstår sig på kravspecarna, eller att kravanalytikern inte förstått sig på verklighetens mångfacetterade situationer så väljer jag att stötta projektet genom att fokusera på att jaga buggar eller granska kravspecar. Och med handen på hjärtat tror jag att jag i regel tillför större nytta i projektet när jag jobbar med det senare än att styrgruppen får kontinuerliga detaljerade testrapporter på en nivå som de inte har behov av.

Som ni märker använder jag mig mycket av ordval som “i regel” och det är ett tecken på att jag inte vill påstå att jag sitter inne med någon sorts sanning och facit. Jag vill endast att vi blir medvetna om vad vi vill, varför vi vill det och vad vi riskerar genom att föreslå det. Jag är rädd att vi kanske inte får högre status genom att argumentera för vårt deltagande i styrgruppsmötena, utan att i värsta fall kan effekten bli det rakt motsatta.

About fredrik_scheja

Fredrik Scheja
Sogeti

5+ års erfarenhet av mjukvarutest som profession, men totalt 30+ års generell testerfarenhet genom livet. Testkonsult hos Sogeti med extra ansvar för utveckling av testområdet inom Sogeti Center of Test Excellence i Lund.
Fredrik började arbeta med test 2003 och är specialiserad på kombinationen mellan strukturerade testprocesser, såsom TMap, tillsammans med utforskande test, agil utveckling samt testarens yrkesroll.