Det optimala IT-utvecklingsteamet 7 - kunskapsinventering

Vi diskuterade också hur ett utvecklingsteam kan bemannas upp och vilka kompetenser/erfarenheter vi ska fokusera på och hur dessa är kopplade till målen. 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. I den här artikeln tänkte jag i stället fokusera på hur du kan inventera ansvars- och kompetensområden på ett enkelt, men effektivt sätt.

Det allra första att fokusera på är en inventering av vilka ansvarsområden som egentligen ligger på teamets bord. Under detta arbete kan du ta hjälp av chefer och ledning som kan förklara vad de förväntar sig att teamet tar hand om och ansvarar för. Du kan också studera de dokument och webbsidor som beskriver teamet och lite om varför det bildades. Det kan också ge lite ledtrådar till vad teamet ansvarar för. 

Efter denna inventering eller parallellt med den så bör du boka in ett brainstormingmöte med teamet där alla får i uppgift att berätta om vad de jobbar med. Stort som smått – ju mer desto bättre. Lägg inga värderingar i detta arbete utan anteckna endast vad alla säger i en lång lista som du delar på en storskärm så att alla ser. Enklast är gå laget runt så att var och en får säga allt de kommer på. Om det är team på cirka tio personer brukar den här övningen kunna klaras av på cirka en och en halv timme. Men om du ser att det blir lite tight med tid så rekommenderar jag att du bokar upp ytterligare ett tillfälle med teamet så att slipper forcera igenom mötet. Omvänt gäller också. Om ni klarar av det på en timme så är det bara bra. Ingen mening med att sitta längre än ni behöver.

Efter brainstormingmötet har det så blivit dags att sammanställa allt som kom fram och renodla listan. Syftet med sammanställningen är att bli av med dubbletter, gruppera olika arbetsuppgifter inom ansvarsområden och att försöka nå en någorlunda liknande nivå på alla områden och arbetsuppgifter. Det här inget enkelt jobb och det kan vara smart att ta hjälp av någon kollega som kan hjälpa dig med arbetet. Räkna med åtskilliga timmar innan du är någorlunda nöjd med listan. Se till att den blir så bra som möjligt. Lägg hellre för mycket än för lite tid på att finslipa den. Tänk också på att förankra detta med den input du fick från chefer, ledning och den dokumentation du använde dig av i första steget. I listan har du nu till slut ett antal ansvarsområden med tillhörande arbetsuppgifter inom varje område. Den listan kan du nu förankra med chefer och ledning om du tycker att det behövs, men om den överensstämmer med deras syn är detta ett överflödigt steg.

När listan är sammanställd har det blivit dags att förankra den i teamet. Boka in ett möte med hela teamet där ni gemensamt kan gå igenom alla ansvars- och kompetensområden. Syftet med mötet är att fastställa listan och se om det är något som är överflödigt och bör tas bort, hitta dubbletter eller saker som tangerar varandra och komma på om något behöver läggas till. Sedan är ju också tanken att teamet ska komma överens om listan och ställa sig bakom den. Det är ju trots allt den som beskriver hela teamets åtaganden.

Under mötet är det också viktigt att alla funderar på vilka kompetenser som behövs för att kunna utföra alla arbetsuppgifter som behöver göras under respektive ansvarsområde. Dessa kompetenser kommer ni nämligen behöva fördjupa er i ytterligare framöver. På samma sätt som du gjorde när du hade brainstormingmötet kring ansvarsområden kan du göra med de kompetenser som krävs. 

Om t.ex. ett ansvarsområde är att ansvara för vidareutvecklingen av en frontendapplikation vid namn ”Kundportalen” så kanske det innehåller arbetsuppgifter som kräver kompetens inom områden som JavaScript, TypeScript, React, HTML, CSS, VS Code, responsiv design och så vidare men det är också viktigt med egenskaper som kreativitet, flexibilitet, engelska, pedagogik, retorik, samarbetsförmåga, problemhantering med mera. Vad jag vill säga är att du inte ska snöa in för mycket på tekniska kompetenser utan också beakta andra typer av egenskaper som är värdefulla för att ta hand om ett visst område.

Tänk också på att några kompetenser tenderar att bli väldigt generella och kanske är bra att ha inom alla ansvarsområden. Kompetenser som samarbetsförmåga, pedagogik, flexibilitet, nyfikenhet med mera är alla exempel på förmågor som kan betraktas som generella och därför kan ingå i ett mer övergripande område som du kan kalla för ”Egenskaper viktiga för hela teamet” eller något liknande och lyfta bort dem från respektive ansvarsområde.

Nu när vi har våra ansvarsområden och tillhörande kompetenser har det blivit dags att komma ner på individnivå. Med det menar jag att gå igenom alla områden och tilldela ansvarsområden till enskilda individer. Detta görs genom en kombination av enskilda samtal och möten med hela teamet. Under de enskilda samtalen får du en chans att känna teamets medlemmar på pulsen och se lite vad de vill och hur deras mål och ambitioner ser ut. De flesta ansvarsområden brukar gå ganska smidigt att tilldela eftersom dessa personer redan arbetar med området, men det brukar också finnas andra områden där det inte är lika självklart vem som ska ansvara för vad. Tänk också på att utse en primärt ansvarig och minst en sekundärt ansvarig för varje område.

En primärt ansvarig är den person som kan mest om området och den som jobbar med det mest av alla i teamet. Den sekundärt ansvariga är den person som kan rycka in när den primära inte är på plats, t.ex. under ledigheter eller sjukdom. Den sekundära är inte riktigt lika insatt i området som den primära, men kan klara enklare återkommande arbetsuppgifter som behöver göras. Det kan röra sig om enklare felsökning, återkommande supportfrågor eller att förklara hur ett system hänger ihop och vilka beroenden det har till andra system. Den sekundära förväntas inte hålla på med strategiska frågor rörande systemets arkitektur eller andra viktiga ställningstaganden.

Tänk dig den primära och den sekundära som ömsesidigt beroende. Det ligger i den primäras intresse att se till att lära den sekundära så mycket som möjligt för att undvika att bli störd på ledigheter t.ex. Det är ju inte så kul att ligga i hängmattan på en strand i Spanien och samtidigt behöva ta hand om supportavtal som den sekundära inte kan hantera. Och likadant är det för den sekundära som kanske inte tycker det är jättekul att förväntas ta hand om ärenden som hen inte har en aning om hur de ska hanteras och i stället bli tvungen att störa den primära på sin semester.

Genom att säkerställa vilka personer i teamet som har det primära respektive det sekundära ansvaret och dessutom ha listat alla kompetenser har du kommit en bra bit på väg med att tydliggöra allt arbete som sker i teamet. Nästa steg blir att kommer ner på ännu lägre nivå och värdera vilka nivåer på de olika kompetenserna vi har i teamet.