Spring naar content

Hoe schrijf ik een goede opdracht voor een DevOps engineer?

DevOps-engineer bureau met open notitieboek vol handgetekende diagrammen, laptop met terminal en miniatuur serverrack.

Een goede opdracht voor een DevOps engineer bevat een heldere omschrijving van de technische omgeving, de gewenste werkwijze, de looptijd en het doel van de opdracht. Hoe concreter je bent, hoe beter de match met de juiste professional. Dit geldt zeker binnen de overheid, waar opdrachtomschrijvingen ook juridisch en procedureel aan eisen moeten voldoen. De vragen hieronder helpen je stap voor stap een sterke opdrachtomschrijving op te stellen die de juiste DevOps engineer aantrekt.

Welke informatie moet een goede opdrachtomschrijving bevatten?

Een goede opdrachtomschrijving voor een DevOps engineer bevat minimaal: de context van de opdracht, de concrete werkzaamheden, de technische omgeving, het verwachte kennisniveau, de looptijd, het aantal uren per week en de locatie. Zonder deze elementen is de omschrijving te vaag om de juiste kandidaat aan te trekken.

Begin altijd met de organisatiecontext. Wat doet de afdeling? Welk probleem wil je oplossen of welk doel wil je bereiken? Een DevOps engineer die begrijpt waarom een opdracht bestaat, kan beter inschatten of zijn profiel aansluit.

Voeg daarna de volgende onderdelen toe:

  • Werkzaamheden: Wat gaat de engineer concreet doen? Denk aan het opzetten van CI/CD-pipelines, het beheer van cloudinfrastructuur of het verbeteren van deploymentprocessen.
  • Technische omgeving: Welke tools, platforms en systemen worden gebruikt? Denk aan Azure, AWS, Kubernetes, Terraform of Jenkins.
  • Samenwerking: Met welke teams werkt de engineer samen? Scrum, SAFe of een andere werkwijze?
  • Resultaat: Wat moet er aan het einde van de opdracht zijn opgeleverd of verbeterd?
  • Praktische details: Looptijd, optie op verlenging, uren per week, locatie (on-site, hybride of remote) en tarief of tariefbandbreedte.

Een volledige opdrachtomschrijving bespaart tijd aan beide kanten. Professionals kunnen sneller beoordelen of ze passen, en jij ontvangt minder irrelevante reacties.

Hoe specifiek moet je zijn over technische vereisten?

Wees zo specifiek als de opdracht vereist, maar vermijd het opstellen van een verlanglijstje dat geen enkele kandidaat volledig invult. Benoem de technologieën die echt worden gebruikt in de opdracht en maak daarbij onderscheid tussen wat verplicht is en wat een pré is. Een te lange lijst met eisen schrikt goede kandidaten af.

Een handige aanpak is het onderverdelen van technische vereisten in twee categorieën:

  • Verplicht: Kennis of ervaring zonder welke de engineer de opdracht niet kan uitvoeren. Bijvoorbeeld: aantoonbare ervaring met Kubernetes en GitLab CI/CD.
  • Gewenst: Kennis die nuttig is maar niet doorslaggevend. Bijvoorbeeld: ervaring met Ansible of kennis van compliance-eisen binnen de overheid.

Bij overheidsorganisaties speelt ook het ervaringsniveau een rol. Geef aan hoeveel jaar relevante werkervaring je verwacht en in welk type omgevingen. Een DevOps engineer met vijf jaar ervaring bij een commercieel softwarebedrijf heeft een ander profiel dan iemand met vijf jaar ervaring binnen een Rijksoverheidsomgeving.

Vermijd vage termen als “hands-on mentaliteit” of “teamspeler” zonder verdere toelichting. Die zeggen weinig en dragen niet bij aan een betere match.

Wat is het verschil tussen een DevOps engineer en een DevSecOps engineer?

Een DevOps engineer richt zich op het integreren van ontwikkeling en operationeel beheer, met als doel snellere en betrouwbaardere softwareleveringen. Een DevSecOps engineer doet hetzelfde, maar integreert informatiebeveiliging structureel in het gehele ontwikkel- en deploymentproces. Het verschil zit in de expliciete verantwoordelijkheid voor security.

In de praktijk betekent dit dat een DevSecOps engineer kennis heeft van beveiligingsscans in de pipeline, kwetsbaarheidsbeheer, compliance-eisen en veilige coderingsstandaarden. Binnen de overheid, waar systemen gevoelige data verwerken en strenge beveiligingseisen gelden, is de vraag naar DevSecOps-profielen de afgelopen jaren sterk gegroeid.

Vraag jezelf bij het schrijven van de opdracht af: moet de engineer actief bijdragen aan beveiligingsvraagstukken, of is dat een verantwoordelijkheid van een apart securityteam? Als het eerste het geval is, zoek je een DevSecOps engineer en moet je dat expliciet benoemen in je opdrachtomschrijving. Zo voorkom je dat je een DevOps engineer aantrekt die niet is ingericht op die extra beveiligingslaag.

Hoe schrijf je een opdracht die ook freelancers aanspreekt?

Een opdracht die freelancers aanspreekt, is transparant over het tarief of de tariefbandbreedte, de looptijd inclusief verlengingsopties, en de mate van zelfstandigheid. Freelancers beoordelen een opdracht snel op haalbaarheid en aantrekkelijkheid. Ontbreekt cruciale informatie, dan haken ze af.

Naast de inhoud zijn er een paar praktische punten die het verschil maken voor zelfstandige professionals:

  • Tarief: Geef een indicatie van het uurtarief of een bandbreedte. Freelancers plannen hun portfolio en kunnen zonder tariefindicatie niet inschatten of de opdracht past.
  • Contractvorm: Maak duidelijk of de opdracht direct wordt uitgezet of via een intermediair loopt, en welke contractvorm van toepassing is.
  • Zelfstandigheid: Freelancers willen weten in hoeverre ze zelfstandig kunnen werken. Beschrijf de mate van aansturing en de verwachte beschikbaarheid.
  • Verlengingsopties: Geef aan of verlenging mogelijk is. Een opdracht van drie maanden zonder verlengingsoptie is voor veel freelancers minder aantrekkelijk dan een opdracht van zes maanden met optie op verlenging.

Wil je weten hoe freelancers opdrachten beoordelen en wat zij belangrijk vinden? Bekijk dan onze informatie voor freelancers bij Ubuntu Staffing voor meer context.

Welke veelgemaakte fouten maken opdrachtgevers bij het schrijven van een DevOps opdracht?

De meest voorkomende fout is een opdrachtomschrijving die te generiek is. Termen als “CI/CD-ervaring” of “cloudkennis” zonder verdere specificatie zijn te breed om een goede selectie op te maken. Andere veelgemaakte fouten zijn het ontbreken van context, een onrealistisch eisenpakket en het weglaten van praktische informatie zoals looptijd en tarief.

Hieronder staan de fouten die in de praktijk het vaakst voorkomen:

  • Geen onderscheid tussen must-haves en nice-to-haves: Alles staat op gelijk niveau, waardoor kandidaten niet weten waar de prioriteit ligt.
  • Te veel eisen: Een lijst van twintig technische vereisten is onrealistisch. Beperk je tot wat echt nodig is voor deze opdracht.
  • Geen omschrijving van de omgeving: “Overheidsorganisatie” zegt weinig. Geef aan welk type systemen, welke schaal en welke werkwijze van toepassing zijn.
  • Onduidelijk resultaat: Wat is de definitie van succes? Zonder dat weet een engineer niet wat er van hem of haar verwacht wordt.
  • Geen tariefindicatie: Zeker voor freelancers en leveranciers is dit een drempel om te reageren.
  • Verouderde functietitels: “Systeembeheerder met DevOps-ervaring” is iets anders dan een volwaardige DevOps engineer. Gebruik de juiste terminologie om de juiste doelgroep te bereiken.

Wanneer is het slim om een intermediair in te schakelen voor je DevOps opdracht?

Het inschakelen van een intermediair is slim wanneer je snel een gekwalificeerde DevOps engineer nodig hebt, wanneer je niet beschikt over een eigen netwerk van ICT-professionals, of wanneer de opdracht via een raamcontract of DAS-systeem moet worden uitgezet. Een intermediair neemt de werving, selectie en administratieve afhandeling uit handen.

Binnen de overheid is het gebruik van een intermediair vaak ook een vereiste. Veel overheidsopdrachten worden uitgezet via aanbestedingen of dynamische aankoopsystemen waarbij je als organisatie niet rechtstreeks met freelancers contracteert. Een gespecialiseerde intermediair kent deze structuren en kan de juiste kandidaten snel aandragen via de juiste contractroute.

Een intermediair voegt ook waarde toe bij het opstellen van de opdracht zelf. Een gespecialiseerde partij kan helpen de opdrachtomschrijving aan te scherpen, realistisch te maken en aantrekkelijk te formuleren voor de doelgroep.

Hoe Ubuntu Staffing helpt met jouw DevOps opdracht

Wij ondersteunen overheidsorganisaties en publieke instellingen bij het vinden van de juiste interim DevOps engineer, van opdrachtomschrijving tot plaatsing. Als specialist in interim ICT-bemiddeling binnen het publieke domein weten wij wat werkt en wat niet bij het schrijven en uitzetten van een DevOps opdracht.

Wat wij bieden:

  • Ondersteuning bij het opstellen en aanscherpen van jouw opdrachtomschrijving
  • Toegang tot een netwerk van gekwalificeerde DevOps en DevSecOps professionals
  • Bemiddeling via bestaande raamcontracten en DAS-structuren binnen de overheid
  • Flexibele contractvormen: freelance, detachering of all-in verloning
  • Snelle schakeling zonder in te leveren op inhoudelijke kwaliteit

Wil je jouw interim DevOps opdracht snel en goed in de markt zetten? Neem contact met ons op en we denken graag met je mee.

Veelgestelde vragen

Hoe lang mag een opdrachtomschrijving voor een DevOps engineer zijn?

Een goede opdrachtomschrijving is zo lang als nodig, maar zo kort als mogelijk. In de praktijk is één tot twee A4 voldoende om alle essentiële informatie te communiceren. Zorg dat elke zin bijdraagt aan de match: weglaten van overbodige tekst vergroot de leesbaarheid en verhoogt de kans dat de juiste professional reageert.

Wat doe ik als ik zelf niet precies weet welk DevOps-profiel ik nodig heb?

Begin met het beschrijven van het probleem of doel dat je wilt bereiken, in plaats van het profiel. Wat moet er anders, beter of sneller worden? Een gespecialiseerde intermediair of een ervaren DevOps engineer kan je op basis van die context helpen bepalen welk profiel het beste past. Dit voorkomt dat je zoekt op een functietitel in plaats van op de werkelijke behoefte.

Hoe vermeld ik beveiligingseisen correct in een opdrachtomschrijving voor de overheid?

Benoem specifiek welke beveiligingskaders van toepassing zijn, zoals de BIO (Baseline Informatiebeveiliging Overheid), ISO 27001 of DigiD-auditeisen. Geef ook aan of de engineer een Verklaring Omtrent het Gedrag (VOG) of een veiligheidsonderzoek moet kunnen overleggen. Hoe concreter je de beveiligingseisen formuleert, hoe beter kandidaten kunnen beoordelen of zij aan de vereisten voldoen.

Kan ik een DevOps engineer ook volledig remote inzetten vanuit de overheid?

Dat hangt af van de aard van de systemen en de geldende beveiligingseisen binnen jouw organisatie. Opdrachten waarbij gewerkt wordt met geclassificeerde of gevoelige data vereisen vaak een gedeeltelijke of volledige on-site aanwezigheid. Geef in de opdrachtomschrijving duidelijk aan wat de verwachting is ten aanzien van locatie en leg uit waarom, zodat kandidaten een weloverwogen keuze kunnen maken.

Hoe snel kan ik een DevOps engineer verwachten na het uitzetten van een opdracht?

Bij een duidelijke en complete opdrachtomschrijving kunnen de eerste gekwalificeerde kandidaten binnen enkele werkdagen worden aangedragen, zeker wanneer je werkt via een intermediair met een actief netwerk. De doorlooptijd wordt langer als de opdracht via een formele aanbestedingsprocedure of DAS-systeem moet verlopen. Reken in dat geval op één tot drie weken, afhankelijk van de procedure.

Wat is een realistisch uurtarief voor een interim DevOps engineer binnen de overheid?

Het uurtarief voor een ervaren DevOps engineer ligt in de huidige markt doorgaans tussen de €85 en €130 per uur, afhankelijk van het ervaringsniveau, de gevraagde specialisaties en de complexiteit van de omgeving. DevSecOps-profielen of engineers met specifieke overheidservaring zitten vaker aan de bovenkant van dit spectrum. Een tariefbandbreedte vermelden in je opdracht helpt om realistische verwachtingen te scheppen aan beide kanten.

Hoe zorg ik ervoor dat mijn opdrachtomschrijving vindbaar is voor de juiste DevOps professionals?

Gebruik gangbare en correcte functietitels en technische termen die professionals zelf ook hanteren, zoals ‘DevOps Engineer’, ‘Platform Engineer’ of ‘Site Reliability Engineer’. Vermijd intern jargon of afkortingen die buiten jouw organisatie niet bekend zijn. Wanneer je de opdracht via een intermediair uitzet, zorgt die partij doorgaans voor de juiste verspreiding binnen het relevante netwerk en op de juiste platforms.

Wij helpen je graag!

Heb je vragen? We helpen je graag!

Deel deze publicatie

Gerelateerde blogs