Kvalitet og trivsel

Når folk spør hva jeg jobber med, er det korte svaret at jeg jobber med å kvalitetssikre it-løsninger. Om jeg sitter og kontrollerer kravspesifikasjoner, lager automatiske tester eller skriver utarbeider teststrategi så er faktisk det å kvalitetsikre løsningenen som er det ultimale målet. Kvalitetsikring kan utføres på mange forskjellige måter, men en av de viktigste faktorene som påvirker kvaliteten til en leveranse er etter min mening trivsel hos de involverte partene. For å begrunne hvorfor jeg mener dette, vil jeg beskrive to prosjekter: én med dårlig arbeidsmiljø, og ett med godt arbeidsmiljø — og høyere trivsel hos de involverte.

Dårlig arbeidsmiljø — lite trivsel og mye feil

Hvordan kan trivsel være en suksessfaktor for en leveranse, tenker du.

La oss anta at en bestiller ikke har det bra på jobb. Vedkommende føler at han/hun ikke blir lyttet til, eller ikke får bidratt med det vedkommende er best på eller trives mest med. Hvordan tror du bestillingene fra en slik person kommer til å være? La oss anta at det er behov for endring i domenet som vedkommende jobber innen. Kommer spesifikasjonen knyttet til endringsønsket til å være strukturert og lett å forstå? Kommer spesifikasjonen til å inneholde all informasjon som er nødvendig for at en prosjektleder eller produkteier klarer å prioritere saken korrekt?

Ofte blir bestillinger med vanskelige eller ustrukturerte spesifikasjoner plassert nederst i køen når disse kommer til produkteier. Når en slik bestilling omsider blir løftet frem og går videre til utvikleren, hvordan tror du utvikleren føler seg etter å ha fått halvferdige eller uklare bestillinger i fanget? Tror du at det som da blir levert er i henhold til bestillerens ønske og behov? Hvis bestillingen har ligget en stund i en kø fordi man ikke har forstått behovet ordentlig og ikke prioritert den korrekt, tror du bestiller er i samarbeidsmodus til å forklare ønsket funksjonalitet på en god måte? Hva om bestiller har byttet arbeidsplass i mellomtiden? En utviklers trivsel pleier i slike situasjoner å være delvis dalende. La oss anta at det blir levert et stykke arbeid som går til kodegjennomgang og til test.

Når testressursen (som ofte er sånne kresne mennesker som meg), får beskjed om at implementasjonen er ferdig med en spesifikasjon som kun var halvferdig. Hvordan tror du vi angriper saken? Sist gang jeg fikk en slik sak, prøvde jeg virkelig å forstå den halvferdige spesifikasjonen. Jeg hadde to valg: jeg kunne teste implementasjonen etter min forståelse av bestillingen (noe som mest sannsynlig ville være feiltolket), eller jeg kunne sende saken tilbake til bestiller eller en annen ansvarlig ved å stille noen spørsmål som muligens ville gjøre bestillingen litt mer forståelig.

En slik retur så sent i utviklingsløpet er sikkert et stort irritasjonsmoment for vedkommende kan jeg tenke meg. Vedkommende har muligens ikke tid til å svare på mine spørsmål, kanskje heller ikke lyst. Siden jeg da sitter og føler meg halveis dum og halveis irritert pga mangelfull kravspesifikasjon vil jeg neppe bidra til økt trivsel i gruppen. Jeg erfarer at man ofte i slike situasjoner ikke får svar på spørsmålene man stiller. Etter en tid havner endringen ut i produksjon, kall det gjerne en svikt i systemet, men det er en realitet. Noen pusher det ut til slutt, etter å ha gått lei av å vente, noe som mest sannsynlig vil føre til produksjonsfeil og enda dårligere trivsel…

Godt arbeidsmiljø — høy trivsel og lite feil

La meg ta dere gjennom et annet prosjekt hvor situasjonen var noe helt annet..

Vi har en bestiller som blir sett og hørt, og som har klare ansvarsområder. Et nytt behov dukker opp i hans/hennes arbeidshverdag som det er ønskelig blir løst med en ny funksjon. Vedkommende legger inn en god beskrivelse av ønsket endring. Vedkommende er også trygg i sin rolle og kan ta kontakt med andre for å eventuelt få hjelp til å spesifisere endringsønsket bedre. Siden endringen i denne situasjonen er lett å forstå, kan det også hende at den blir prioritert opp og sendt videre til utvikling raskere enn saken fra en frustrert bestiller.

Utvikleren har når vedkommende tar saken nå, mest sannsynlig mer informasjon tilgjengelig og kanskje forstår hovedpoengene knyttet til endringen. Det kan være detaljer som er uklare, men nå forstår utvikleren mer enn før. Siden vi nå har et arbeidsmiljø som er sunt og trygt vil også utvikleren ta kontakt med bestiller uten å være redd for å skape dårlig stemning og få svar på sine spørsmål. Og muligens også legge inn informasjon om dette i saken som benyttes til å spesifisere endringsønsket.

Når denne saken så kommer til mitt bord og jeg er i mitt vanlige blide hjørne, vel da har jeg ingen andre ønsker enn å kvalitetssikre saken etter beste evne. Jeg kommer til å stille spørsmål til bestiller og utvikler, men dette vil ikke være spørsmål som oppleves som vanskelig eller tidskrevende. Finner jeg ingen feil, vil denne gå videre til produksjon og brukerne vil da kunne nyttiggjøre seg av funksjonalitet som igjen bidrar med å gjøre arbeidshverdagen litt bedre enn før.

Konklusjon

Eksemplene over er hentet fra prosjekter jeg har jobbet med. Jeg ser på det som en del av mine arbeidsoppgaver å gjøre et sted med dårlig stemning til et sted hvor folk trives. Jeg skal være ærlig, det trengs flere enn testressursen for å få til dette og jeg har også vært steder hvor jeg har sett at dette ikke vil la seg gjøre, da det ikke er ønskelig med endring. Men på steder hvor endringer er velkomne, hva kan du gjøre?

Skap et arbeidsmiljø hvor folk trives og se at feilraten går nedover. Men et godt arbeidsmiljø er kanskje vanskelig å få til, tenker du. Vi menesker er så forskjellig at det er litt vanskelig. Men det er egentlig ikke så mye som skal til:

1. Husk å gi mennesker klare ansvarsoppgaver — sørg for at folk føler at arbeidsfordelingen er klar og rettferdig
2. Friheten og muligheten til å yte sitt beste — ikke overbelast folk med oppgaver. Følg med og sjekk om det er behov for å gjøre endringer i ansvarsområdene, men gjør dette i tett dialog med de involverte partene.
3. Kontinuerlig forbedring — har du ingen som kommer med en ny ide eller ønske om endring, mener jeg at du har et problem. Kanskje de ikke føler seg trygge?
4. Lytt og se folk — spør gjerne hva som skal til for at hver enkelt skal trives eller ha det litt bedre enn tidligere

Et godt arbeidsmiljø fører til økt velvære og produktivitet.

Er du en som vil utfordre deg selv og bidra til å høyne kvaliteten i samfunnskritiske prosjekter? Da passer du nok inn hos oss!