Kravprofilen som faktiskt ger rätt kandidater

När en konsult behövs snabbt är det lockande att återanvända en gammal kravprofil. Problemet är att den ofta beskriver en tidigare person snarare än det aktuella behovet. Börja i stället med tre frågor: Vad ska vara annorlunda när uppdraget är klart? Vilka leveranser ska konsulten ansvara för? Vad hindrar er från att nå dit med befintlig bemanning? Svaren hjälper er att skilja ett verkligt kompetensbehov från en allmän önskan om förstärkning.

Beskriv sedan uppdragets första månader med konkreta resultat. För en utvecklare kan det vara att ta över förvaltningen av två integrationer, leverera en ny funktion och få automatiserade tester på plats. För en projektledare kan det vara att fastställa omfattning, förankra en genomförandeplan och hantera beroenden till tre verksamhetsområden. Undvik formuleringar som ”driva digitalisering” om ni inte samtidigt förklarar vad det betyder i praktiken.

Dokumentera också förutsättningarna: teamets sammansättning, systemens skick, tillgängligt stöd och kända beroenden. En konsult som ska bygga nytt med ett erfaret team behöver inte samma profil som någon som ensam ska stabilisera ett äldre system. Resultat och arbetsmiljö ska styra resten av kravprofilen.

En titel räcker sällan för att beskriva ett konsultuppdrag. ”Tech lead” kan innebära teknisk samordning i ett team, arkitekturansvar över flera system eller huvudsakligen operativ utveckling. Ange därför rollens viktigaste arbetsuppgifter i prioritetsordning. Beskriv gärna den ungefärliga fördelningen mellan exempelvis utveckling, granskning och samordning. Det gör det lättare för både konsulten och förmedlaren att avgöra om uppdraget passar.

Tydliggör även gränserna mot andra roller. Vem prioriterar arbetet? Vem fattar arkitekturbeslut? Vem ansvarar för personal, budget och leverantörer? Om konsulten förväntas ta ansvar för en leverans måste ni beskriva vilket mandat och vilka resurser som följer med ansvaret. Att kräva helhetsansvar utan möjlighet att påverka prioriteringar skapar en oklar beställning som inte kan lösas genom fler kompetenskrav.

Var särskilt uppmärksamma på kombinationsroller. En person kan ibland vara både utvecklare och teknisk ledare, men krav på djup specialistkompetens, omfattande projektledning och verksamhetsutveckling samtidigt kan göra urvalet onödigt smalt. Pröva om behovet egentligen består av två uppdrag. Om ni ändå kombinerar rollerna bör ni ange vilken del som väger tyngst och vad som kan prioriteras ned.

Antal år i yrket är ett enkelt filter men ett ofullständigt mått på förmåga. Två konsulter med lika lång erfarenhet kan ha arbetat med helt olika ansvar och svårighetsgrad. Beskriv därför nivån genom vad personen ska kunna göra självständigt. Ska konsulten genomföra tydligt avgränsade uppgifter, välja lösning inom givna ramar eller formulera angreppssättet när både problemet och förutsättningarna är oklara?

En användbar nivåbeskrivning kan vara: ”Konsulten ska självständigt kunna felsöka integrationsproblem i produktion, föreslå åtgärder och förankra förändringar med berörda systemägare.” Den säger mer än enbart ”senior integrationsutvecklare”. Komplettera med relevant komplexitet, exempelvis flera beroende system, höga tillgänglighetskrav eller många intressenter. Efterfråga erfarenhet som liknar de faktiska utmaningarna, inte bara en viss titel från ett tidigare uppdrag.

Kalibrera sedan nivån mot budget och tillgängligt stöd. Om uppdraget främst består av avgränsade utvecklingsuppgifter med handledning kanske ni inte behöver en senior specialist. Om personen däremot ska reda ut otydliga krav och leda tekniska vägval bör det avspeglas i både nivån och ersättningen. Där ett ramavtal definierar kompetensnivåer behöver ni följa dessa och precisera uppdraget inom de ramarna.

Varje måstekrav utesluter kandidater. Det ska därför finnas en tydlig anledning till att kravet är obligatoriskt. Fråga er vad som händer om konsulten saknar just den erfarenheten vid start. Blir leveransen omöjlig, uppstår en oacceptabel risk eller behövs bara en rimlig introduktion? Klassificera kraven som obligatoriska, meriterande eller möjliga att lära under uppdraget. Skriv också varför de viktigaste måstena behövs.

För ett uppdrag med omedelbart ansvar för en befintlig Java-applikation kan aktuell Java-erfarenhet vara ett måstekrav. Erfarenhet av ert ärendehanteringsverktyg kan däremot ofta läras in. Samma avvägning gäller branschbakgrund: kunskap om specifika regelverk kan vara avgörande, medan tidigare arbete i exakt samma typ av organisation inte alltid är nödvändigt. Krav på svenska bör kopplas till konkreta arbetsuppgifter, exempelvis att skriva beslutsunderlag eller leda verksamhetsmöten på svenska.

Undvik att stapla närliggande tekniker som separata absoluta krav utan att pröva behovet. Ange när likvärdig erfarenhet kan accepteras och vad ni menar med likvärdig. För offentliga upphandlingar behöver obligatoriska krav och utvärderingskriterier hanteras enligt underlaget och tillämpliga regler. Utgå inte från att ett onödigt snävt krav enkelt kan bortses från senare i processen.

En kravprofil blir användbar först när den går att bedöma konsekvent. Koppla därför varje centralt krav till ett sätt att verifiera det. Teknisk erfarenhet kan styrkas genom relevanta uppdrag och en strukturerad teknisk intervju. Förmåga att leda förändring kan undersökas genom konkreta exempel på beslut, motstånd och resultat. Bestäm i förväg vad som är ett tillräckligt svar så att bedömningen inte blir beroende av vem som intervjuar.

Ersätt vaga egenskaper med observerbara beteenden. I stället för ”kommunikativ” kan ni skriva att konsulten ska kunna förklara tekniska risker för verksamhetsansvariga och dokumentera beslutsalternativ. Fråga sedan: ”Beskriv ett tillfälle när ni behövde förankra ett tekniskt vägval hos personer utan teknisk bakgrund. Hur gjorde ni och vad blev utfallet?” Följ upp kandidatens egen insats, inte bara vad teamet åstadkom.

Använd samma grundfrågor för samtliga kandidater och dokumentera svaren i en enkel bedömningsmatris. Skilj mellan verifierat, delvis verifierat och ännu inte verifierat. Ett kort, uppdragsnära arbetsprov kan komplettera intervjun när det är motiverat, men bör inte bli gratis produktionsarbete. Referenser kan sedan användas för att följa upp specifika frågetecken om exempelvis självständighet, leveransförmåga eller samarbete.

Innan kravprofilen skickas ut bör beställare, tekniskt ansvarig och inköp vara överens om prioriteringarna. Säkerställ att ni beskriver samma behov och att budgeten är förankrad. Ange startdatum, uppdragslängd, omfattning, arbetsort och villkor för distansarbete. Beskriv även eventuella säkerhetskrav och praktiska förutsättningar för åtkomst till system. Sådant påverkar vilka konsulter som faktiskt kan ta uppdraget, även när kompetensen är rätt.

Gör en sista kontroll: Kan ni sammanfatta rollens huvudansvar i en mening? Är nivån beskriven genom ansvar och självständighet? Har varje måstekrav en motivering och en verifieringsmetod? Framgår det vilka kompetenser som är meriterande? Bestäm också vem som återkopplar, vem som fattar beslut och när intervjuer kan genomföras. En tydlig kravprofil tappar värde om kandidaterna sedan blir liggande utan besked.

Om urvalet blir svagt, undersök orsaken innan ni lägger till fler krav. Är rollen för bred, villkoren för snäva eller budgeten felkalibrerad? Justera där processen och avtalen tillåter det, och dokumentera ändringarna så att alla bedömer samma version. Målet är inte flest möjliga kandidater, utan ett relevant urval som ni kan jämföra på sakliga grunder.