Kravprofil för utvecklare - mall och åtta vanliga misstag

För att få till en riktigt bra rekrytering behövs en tydlig, genomarbetad och användbar kravprofil att utgå från. Kravprofilen är avgörande, och nedan ska vi redogöra för hur du skriver den för roller inom Tech.
Artikeln kommer utgå från åtta vanliga misstag som görs, så att ni slipper trilla ner i samma fällor själva.

En bra grundregel är att kravprofilen ska vara ett arbetsverktyg genom rekryteringen, inte bara en önskelista. Den bör innehålla information om uppdrag/roll, önskat resultat efter 6–12 månader, tekniska skallkrav, meriterande tekniska erfarenheter, senioritet/mandat, stack/teamkontext, villkor och såklart hur varje skallkrav ska verifieras. Får en rekryterare det i handen har rekryteringsprocessen startat bra!

Samla rätt personer för att skapa kravprofilen

En användbar kravprofil behöver förankras hos dem som faktiskt vet vad jobbet innebär. Rekryterande chef har koll på verksamhetens mål, medan en tech lead eller utvecklare i teamet kan beskriva vardagen och de tekniska utmaningarna. Rekryteraren bidrar med perspektivet från kandidatmarknaden och kan utmana krav som riskerar att göra sökningen onödigt snäv. Boka därför en gemensam genomgång innan ni börjar leta. Det är betydligt enklare att reda ut olika förväntningar där än efter den tredje kandidatintervjun.

Använd gärna ett konkret exempel från teamets arbete för att testa om ni menar samma sak. Om den nya utvecklaren ska ”ta stort eget ansvar”, hur skulle det märkas i ett aktuellt projekt? Vad ska personen kunna lösa själv, och när finns stöd från andra? Sådana frågor gör det lättare att enas om vilken kompetens ni faktiskt behöver. När kravprofilen är klar ska alla som deltar i rekryteringen kunna förklara vad som är viktigast och varför.

Åtta vanliga misstag när ni gör en kravprofil, och hur ni undviker dessa

1. Återanvänder en gammal kravprofil. Den förra rekryteringen hade andra förutsättningar, teamets sammansättning kan ha förändrats. Förmodligen finns variationer i techstacken också.

   Detta undviks genom att ompröva uppdraget och de befintliga kraven. Vad är det som ska göras? Vilka kompetenser saknas i teamet? Vad ska en lyckad rekrytering ha åstadkommit de första 6 månaderna?

2. Alla krav blir skallkrav. Så fort ett önskemål blir obligatoriskt så krymper också poolen av kandidater att leta bland. Och en utvecklare kan faktiskt vara rätt för uppdraget även om en viss förkortning saknas i CV. Och vissa saker har ni säkert ett team som är jätteduktiga på att lära ut snabbt till en annars erfaren systemutvecklare.

   Undvik detta genom att dela upp era krav i krav som personen måste kunna från start för att matcha rollen och i krav som går att lära sig efter hand för en person med rätt inställning och potential.

3. Senioritet mäts bara i antal år. Att någon har ”fem års erfarenhet av…” säger egentligen ganska lite av vad personen kan åstadkomma med ett visst verktyg eller teknik. Utvecklare som jobbat exakt lika länge, kan ha nått väldigt olika långt i sin utveckling beroende på hur komplexa system de jobbat med, hur mycket ansvar de har fått, eller behövt ta.

   Det här kan undvikas genom att titta på vad senioriteten innebär hos just er. Ska personen ta beslut kring arkitektur, agera mentor, hantera luddiga otydliga krav? Beskriv så konkret som möjligt, gör förväntningarna tydliga. Det kommer hjälpa både rekryterare och kandidater.

4. Teknikstacken blir en inköpslista. Om programmeringsspråk, ramverk, databaser, molnplattformar och verktyg hamnar i samma kravlista, då blir det oklart vad rollen faktiskt kräver djup kompetens inom.

   Undvik det här misstaget genom att självklart beskriva den tekniska miljön (det är bra info, som kandidater är nyfikna på), men särskilj den listan från de tekniker som kandidaten verkligen behöver behärska från start. Och beskriv i vilka fall närliggande erfarenhet kan fungera.

5. Personliga kompetenser blir lätt tomma ord och floskler. För två olika personer kan ord som ”Driven”, ”Lagspelare” och ”Säljande” betyda olika saker.
   Undvik det här genom att beskriva de beteenden som verkligen behövs i arbetet. ”Kommunikativ” kan exempelvis innebära att kunna förklara tekniska vägval för en produktägare. ”Samarbetsförmåga” kan handla om att ge konstruktiv kodgranskning och lösa problem tillsammans med andra utvecklare.
6. Info om teamets uppbyggnad och mandat saknas. Samma titel kan innebära vitt skilda saker i olika bolag. En person som kommer in som utvecklare nummer 1 på ett företag har såklart andra förutsättningar och ansvar än en utvecklare som kliver in som person nummer 10 i ett redan fungerande team där det finns teamlead, produktägare och QA-stöd.

   Detta undviks genom att ni beskriver teamet och ansvarsfördelningen. Vilka ska den här personen samarbeta med? Det är också viktigt att beskriva vilka beslut personen kommer att få fatta. Fördelningen mellan utveckling, drift och förvaltning är också sådant som påverkar.

7. Kraven och det faktiska erbjudandet går inte ihop. Budgeten för lönen måste matcha den långa listan på tekniska krav. Även övriga villkor och utvecklingsmöjligheter blir här viktigt. Om lön och kontorsnärvaro kommer upp till ytan i dialogen för sent, kan ni och kandidaten ha lagt massa tid i onödan på en process som ändå aldrig kunde nå målet.

   För att undvika detta bör löneintervallet förankras innan sökningen börjar. Även övriga förmåner och policy för remote. Och är budgeten låst och/eller snäv gäller det att prioritera mellan ansvar, erfarenhet och upplärningsbehov.

8. Kravprofilen används inte när kandidaten bedöms. Det åttonde och kanske mest avgörande misstaget. En väl genomarbetad kravprofil gör ju inte så mycket nytta, om intervjuerna och bedömningarna sedan styrs av ”magkänsla” eller nya oväntade krav.

   Det här går också att undvika. Ni gör det genom att koppla varje centralt krav till ett sätt att bedöma just det. Det kan ske genom intervjufrågor, referenser eller case/arbetsprov. Bestäm hur ni kontrollerar vilken del, och dokumentera beläggen. Påminn sedan varandra och er själva under processens gång om vilken kravprofil det är ni faktiskt rekryterar mot.

Mall för kravprofiler

Här kommer en enkel användbar mall att ta med er in i nästa workshop då ni ska sätta er nästa kravprofil

Befattningen
Titel:
Närmaste chef:
Rapporterar till:
Personalansvar:
Samarbetar med:
Resor:
Arbetsuppgifter:

Kravspecifikation
Teknisk miljö:
Förkunskaper och färdigheter:
·      Skallkrav
·      Meriterande
·      Går att lära sig på plats
Utbildning:
Språkkunskaper:
Personliga kompetenser. Vilka konkreta beteenden krävs?
Teamets kompetens:
Vad saknas?
Senioritet och mandat:

Utveckling
Varför välja er som arbetsgivare?
Varför är tjänsten/bolaget lockande för kandidaten:
Konkurrensfördelar:
Faktorer som skulle kunna göra kandidater tveksamma till tjänsten:

Förväntningar
Arbetets fördelning, nyutveckling, förvaltning, teknisk skuld och eventuell drift eller beredskap:
Förväntning på kandidat:
Vilka resultat ska ha nått efter 6 respektive 12 månader?
Utvärderingsgrund, hur utvärderas varje skallkrav?

Anställningsvillkor
Provanställning:
Lön:
Bonus:
Pension:
Semester:
Arbetstid:
Övertidsersättning:
Arbete hemifrån:
Andra förmåner:

Anställningsprocess
Vem/vilka fattar beslut om anställning:
Ingående faser i intervjuprocessen:
Möte ett, vem genomför? Vad verifieras?
Möte två, vem genomför? Vad verifieras?
Möte tre, vem genomför? Vad verifieras?
Tester/Case, vad verifieras?