Det optimala IT-utvecklingsteamet 8 - kunskapsnivåer

Jag kom också in på de agila principerna och Scrum och hur du kan komma igång med att använda det i praktiken. Sen pratade jag lite om kommunikation, samarbete och hur viktigt det är att lära känna varandra. Efter det kom jag in på hur du kan implementera CI/CD-tänket i ditt team och hur det kan bidra till att teamets leveranser alltid är uppdaterade. Till sist publicerade jag en artikel som handlade om konflikthantering och stressiga situationer, vad man kan göra för att förbereda sig på det och hur man kan hantera det på lite olika sätt. Slutligen skrev jag lite om om hur du kan inventera ansvars- och kompetensområden på ett enkelt, men effektivt sätt. Och jag tänkte nu spinna vidare lite på detta och undersöka hur du enkelt kan bedöma kunskapsnivåer inom olika kompetensområden.

Nu när vi har inventerat både ansvars- och kompetensområden blir nästa steg att undersöka hur vi ligger till rent kunskapsmässigt i teamet. Det finns flera syften med den här övningen och här listar jag de mest uppenbara:

• Klargöra var vi behöver stärka upp teamets kompetenser och var vi redan ligger på en tillfredsställande nivå. Kan användas både utåt mot ledning och andra intressenter men också internt inne i teamet.
• Tydliggöra inom teamet vem som ansvarar för vad och vilka kompetenser olika personer i teamet har. Gör att det blir lättare att veta vem man ska kontakta vid olika tillfällen.
• Skapa individuella utvecklingsplaner och tydliggöra interna karriärvägar.
• Ge bättre underlag till både lönesamtal och utvecklingssamtal med närmaste chef.

Det finns många olika sätt att skapa bra skalor att använda sig av, men det kommer aldrig bli perfekt. Nöj dig i stället med att få till en skala som är användbar och som verkar fungera i praktiken. Jag har själv upptäckt att det kan vara svårt att jobba med en alltför grov skala med få värden. Ett exempel på en sådan skala kan vara:

1. Nybörjare
2. Medel
3. Expert

Den kan säkert fungera om du snabbt vill få ihop en bild av ett teams kompetensnivåer, men den ger alltför bristfällig information om var vi ska satsa våra resurser för att stärka teamet. Tänk också på att motivera de olika nivåerna och vad de egentligen innebär. Ju mer konkret desto bättre. Nedanstående är ett exempel på en tiogradig skala som jag har använt mig av vid ett antal tillfällen:

1. Har bara hört talas om området, men aldrig arbetat inom det
2. Vet ungefär vad området handlar om i stora drag, men har knappt någon egen erfarenhet inom det.
3. Har en del teoretiska kunskaper om området, men väldigt lite praktisk erfarenhet.
4. Har en del teoretiska kunskaper om området och har arbetat en del med det.
5. Kan en hel del om området och har arbetat en del med det. Är dock inte helt självständig.
6. Kan mycket om området och kan jobba ganska självständigt med det. Kan aktivt söka information.
7. Kan mycket om området och kan jobba helt självständigt med det.
8. Näst intill expert inom området och bidrar aktivt med att hjälpa andra inom detta.
9. Expert inom området, håller föredrag/seminarier och hjälper andra både inom och utanför företaget.
10. Ledande inom området. Blir ofta anlitad för att hålla externa föreläsningar med mera.

Men trots att du här har en tiogradig att utgå ifrån kan det ändå vara lite av en utmaning att få med alla på tåget och få till en rättvis bedömning som alla kan stå för. Den metod som jag har sett varit mest framgångsrik är enskilda möten med var och en i teamet där vi tillsammans fastställer nivån på varje kompetensområde, både inom primära och sekundära ansvarsområden. En extra rolig twist på det hela kan du få om du väljer att själv göra en värdering innan mötet och sedan ber respektive person göra samma sak för sig själv. Det kan leda till en del intressanta diskussioner.

Tänk också på att skalan kan göras relativ med gott samvete. Vad jag menar med det är att du kan jämföra kompetenser med andra i teamet. Ett konkret exempel på det är om du sitter med en person i teamet som tycker att hen är på nivå 8 inom ett specifikt område, t.ex. programmering i scriptspråket Python men du tycker att det borde vara max en sexa. Då kan du t.ex. jämföra med en annan person i teamet som är väldigt duktig på Python och ställa frågan till personen du sitter med hur hen upplever sin kompetens i förhållande till den andra personen. Ofta blir svaret att den personen är jätteduktig och samtidigt kommer det automatiskt lite självinsikt där personen konstaterar att hen kanske borde ligga kring nivå 5 eftersom personen som är väldigt duktig ligger på nivå 8.

När du väl har fått ihop alla ansvarsområden, kompetensområden och värderingar är det bra att sammanställa detta på en gemensam yta så att alla kan komma åt informationen på ett enkelt sätt. Tänk också på att löpande uppdatera informationen när saker och ting förändras, speciellt när någon ny börjar eller när någon slutar, men också när ansvarsfördelningen förändras på grund av andra orsaker. Du kan behöva skapa lite olika vyer för att skapa en lättförståelig bild av alla individers kompetenser, men den viktigaste är kanske den som ska användas internt av teamet. En fallgrop är också att vara alltför detaljerad när du sammanställer listorna. Tänk på att det ska gå att hantera löpande så fort saker och ting förändras. Och då kan det bli lite tungrott om du har hundratals kompetenser listade.

Men tro mig! Om du och resten av teamet verkligen lägger lite tid på att få det här så bra som möjligt så kommer ni också ha stor nytta av det här framöver. Tänk på de fyra punkterna jag räknade upp i början av den här artikeln. Alla dessa kommer du att kunna tillfredsställa. För att få ut ytterligare ur det här arbetet kan man också tänka sig att skapa en en alternativ vy för alla kompetenser, nämligen den som visar en viss kompetens, t.ex. Kunskaper i Python-programmering och sedan visar vilka i teamet som har den kompetensen och vilken nivå de ligger på. Denna vy skiljer sig från teamets vy på så sätt att teamvyn är mer fokuserad på vad varje individ ansvarar för och kan inom de olika kompetensområden som listas medan den andra vyn fokuserar på ett visst kompetensområde och listar alla i teamet som har den kompetensen.

Sist men inte minst vill jag bara poängtera vikten av att kunna visa upp för lönesättande chef exakt vilka ansvarsområden du ansvarar för och vilka kompetenser du har och indirekt också tydliggöra de interna karriärvägarna och i jämförelse med tidigare listor visa hur du har utvecklats sedan sist. Detta blir väldigt viktig information för både chefen och dig i kommande lönesamtal och utvecklingssamtal. Men nog om det. I den sista och avslutande artikeln i den här serien tänkte jag ta mig en närmare titt på hur vi kan implementera DevOps i teamet.