Softwarelevering

Engineering-consultaties voor softwareteams

Een engineering-consultatie is een werksessie waarin een ervaren engineer bekijkt hoe uw team software bouwt, test, uitbrengt en beheert, en u daarna vertelt wat u als eerste moet aanpakken. De kaart hieronder laat zien wat er aan bod komt.

Wat omvat een engineering-consultatie?

Zestien gebieden van een deliveryplatform, van het eerste ticket tot het cloudaccount eronder.

Open een gebied
Zet het op uw agenda
Kopieer uw agenda0

01Plannen en coderen

Ticketbeheer

Elke wijziging heeft een ticket, en de issue key gaat met de wijziging mee tot in productie.

Release notes die uit het hoofd worden geschreven.
Elke dag de vraag of het al live staat.

Kunnen uw tools laten zien wat er in de laatste release zat?
Hoe lang wacht werk voordat iemand eraan begint?

Verder lezenTraceerbaarheid, van ticket tot productie

Versiebeheer

Code, pipelines en configuratie staan in versiebeheer. Branches worden binnen een paar dagen naar mainline gemerged.

Merges zijn zeldzaam en pijnlijk.
Buildstappen die alleen op één server bestaan.

Hoe oud is uw oudste openstaande branch?
Kunt u de release van vorig kwartaal opnieuw bouwen vanaf de tag?

Verder lezenWelke branchingstrategie kiest u?

Code review

Kleine pull requests krijgen binnen enkele uren een eerste review, en goedkeuringen worden vastgelegd.

Pull requests wachten dagen op een review.
Grote wijzigingen worden blind goedgekeurd.

Wat is de mediane wachttijd tot een eerste review?
Wie mag productiecode goedkeuren?

Verder lezenWijzigingsbeheersing van configuraties

02Bouwen en testen

Continuous integration

Elke push wordt binnen minuten gebouwd en getest, en een rode build wordt als eerste hersteld.

Builds die zo traag zijn dat mensen wijzigingen opsparen.
Eén persoon is eigenaar van de pipeline.

Hoe lang duurt het van een push tot een resultaat?
Hoe vaak was mainline vorige maand rood?

Verder lezenCI/CD-automatisering: hoe een wijziging van commit naar productie komt

Testautomatisering

Snelle tests draaien bij elke commit, en een falende test wijst altijd op een echt defect.

Opnieuw draaien tot alles groen is, geldt als normaal.
Discussies over gereedheid op basis van spreadsheets.

Welke tests worden het vaakst opnieuw gedraaid?
Waar kijkt u om een build gereed te verklaren?

Verder lezenDe ASML-case: één overzicht van de releasegereedheid

Artifacts

Elke build levert één geversioneerd artifact op, dat ongewijzigd door elke omgeving gaat.

Een nieuwe build per omgeving.
Afhankelijkheden schuiven mee naar de nieuwste versie.

Draait productie het artifact dat u hebt getest?
Kunt u elke afhankelijkheid in de laatste release opsommen?

Verder lezenHoe maakt u een build reproduceerbaar?

03Releasen en deployen

Omgevingen

Omgevingen worden vanuit code opgebouwd en verschillen alleen in configuratie.

Groen in staging, kapot in productie.
Teams staan in de rij voor één testomgeving.

Wat verschilt er tussen staging en productie?
Hoe lang duurt het om een nieuwe testomgeving te krijgen?

Verder lezenWat is GitOps?

Deployment

Eén gescripte deploy werkt overal, iedereen kan hem starten en de rollback is geoefend.

Voor een deploy is één bepaalde persoon nodig.
Niemand heeft in maanden een rollback gedaan.

Hoeveel handmatige stappen heeft een deploy naar productie?
Wanneer hebt u voor het laatst een rollback gedaan?

Verder lezenDe Nike-case: deploys naar staging van 10 tot 15 minuten naar ongeveer 3

Releasebeheer

Goedkeuringen gebeuren in de pipeline, en elke release laat automatisch een change record achter.

Wijzigingen wachten dagen op een change board.
Hotfixes slaan het proces over.

Hoe lang wachten wijzigingen op goedkeuring?
Volgen spoedwijzigingen de normale route?

Verder lezenWat automatiseert u als eerste?

04Draaien en bewaken

Observability

Wie on-call is, ziet welke release draait en kan vragen beantwoorden die niemand had voorzien.

Klanten vinden problemen eerder dan de alerts.
Elke nieuwe vraag vraagt om een nieuw dashboard.

Markeren uw dashboards elke release?
Welke alerts zijn vorige maand genegeerd?

Verder lezenObservability versus monitoring: wat senior engineers in 2026 moeten weten

Incidentafhandeling

Elk incident heeft één eigenaar, het herstel begint bij wat er veranderd is, en acties uit de postmortem worden uitgevoerd.

De oorzaak vinden duurt langer dan het herstel.
Hetzelfde incident komt steeds terug.

Hoe lang duurde het oplossen van uw laatste drie incidenten?
Hoeveel acties uit postmortems staan nog open?

Verder lezenTraceerbaarheid, zodat u altijd weet wat er veranderd is

05Fundamentonder elke fase

Cloudaccounts

Een nieuw team krijgt een account waarin netwerk, logging en governance al geregeld zijn.

Nieuwe omgevingen kosten weken aan tickets.
Productie en test delen een account.

Hoe lang duurt het om een nieuw account te krijgen?
Welke guardrails gelden voor elk account?

Verder lezenCloudinfrastructuur: de landing zone, laag voor laag

Identiteit en toegang

Eén identity provider, een rol per functie en beheerdersrechten die verlopen.

Gedeelde beheerdersaccounts.
Wie vertrekt, houdt wekenlang toegang.

Wie kan vandaag productie wijzigen?
Hoe logt uw pipeline in bij de cloud?

Verder lezenDe identiteitslaag van een landing zone

Secrets

Secrets staan in een secrets manager en worden geroteerd. Pipelines gebruiken kortlevende credentials.

API-sleutels in CI-variabelen of in de Git-geschiedenis.
Credentials die al jaren niemand heeft geroteerd.

Hoeveel statische secrets hebt u?
Wat gebeurt er als er een uitlekt?

Verder lezenSecrets Management in 2026: Sprawl, Non-Human Identities en de Keuze tussen Vault en Workload Identity

Infrastructure as code

Wijzigingen lopen via een gereviewd plan, en drift wordt volgens schema gecontroleerd.

Wijzigingen in de console die niemand heeft vastgelegd.
Mensen vermijden het draaien van een plan.

Hoeveel van productie is in code vastgelegd?
Wanneer liet een plan voor het laatst drift zien?

Verder lezenInfrastructure as code en policy as code

Kosten

Elke resource heeft een eigenaar, teams zien hun eigen uitgaven en ongebruikte omgevingen gaan uit.

De cloudrekening verrast elke maand iemand.
Testomgevingen draaien het hele weekend door.

Ziet elk team wat zijn services kosten?
Wat draait er buiten kantooruren, en waarom?

Verder lezenGrip op cloud financial management: de vier kerngebieden die je moet kennen

Kies een tegel. Elke tegel laat zien:

Hoe gezond eruitziet
Signalen dat het u tijd kost
Vragen die een engineer zou stellen
Waar u verder kunt lezen

Zet een gebied op uw agenda, dan verschijnen de vragen onder de kaart.

Uw agenda voor de consultatie

Nog geen gebieden

Voeg de gebieden toe die uw team tijd kosten. Hun vragen verschijnen hier in de volgorde van de levenscyclus, klaar om te kopiëren.

Voor de sessie

Hoe bereidt u zich voor op een engineering-consultatie?

Wie er aan tafel zit en welke cijfers u meeneemt, bepalen wat u eruit haalt. Ruwe cijfers zijn prima; een ontbrekend cijfer is zelf een bevinding.

Wie moet erbij zijn

De engineer die uw laatste release uitvoerde, niet alleen de manager
Wie releases goedkeurt: wijzigingsbeheer, beveiliging of product
Iemand die on-call is voor productie
Een sponsor die iets met de uitkomst kan doen

Wat u meeneemt

Uw laatste release, stap voor stapHet ticket, de pipelinerun en de chat erover
Doorlooptijd van wijzigingen en deploymentfrequentieDeploy-logs en tijdstempels van commits
Faalpercentage van wijzigingen en hersteltijdRollbacks, hotfixes en de incidenten erachter
Uw laatste drie tot vijf incidentenHun tijdlijnen of postmortems
Vastgelegde goedkeuringenWanneer elke wijziging is aangevraagd en goedgekeurd
Pipelinedefinities en runbooksWat geautomatiseerd is, en wat niet

DORA definieert deze metrics voor leverprestaties en past ze per applicatie of service toe. Hoe meet u een CI/CD-pipeline? laat zien waar u elke metric afleest.

De sessie

Wat gebeurt er in een engineering-consultatie?

Zo pakt Mateusz Ulas het aan. Van elke goede adviseur mag u iets vergelijkbaars verwachten.

Benoem eerst de beslissing, zoals wat u als eerste aanpakt of wat er met een tool gebeurt, anders wordt de sessie een rondleiding. Loop daarna uw laatste release door met de mensen die hem uitvoerden en goedkeurden, en leg elke stap vast zoals die op de dag zelf echt verliep: dezelfde regel die de value stream mapping van DORA hanteert. Meet elke stap twee keer, als handwerk en als wachttijd, deel daarna elk knelpunt in als pipeline, proces of platform en rangschik de oplossingen naar uren per jaar, inspanning en eigenaar.

In de Nike-case bracht het doorlopen van de release aan het licht dat upgrades van Windows-servers in 900+ winkels met de hand gebeurden, verdeeld over vijf teams; in de ASML-case dat integratiestappen met de hand liepen en dat er geen centrale plek was om de releasegereedheid te beoordelen.

Voorbeeldrelease, stap voor stap

Handwerk
Wachten

Mergen en taggen15 mingeen wachttijd
Testomgeving regelen15 min22 uur wachten
Deploy naar test, controles draaien45 min3 uur wachten
Goedkeuring van de wijziging15 min48 uur wachten
Deployvenster voor productie1 uur9 uur wachten
Controleren en aankondigen30 mingeen wachttijd

3 uur handwerk82 uur wachten85 uur doorlooptijd

Illustratie: een voorbeeldrelease. Drie uur werk kostte drieënhalve dag.

Het resultaat

Wat moet een engineering-consultatie u opleveren?

Een werkvolgorde op papier, geen stapel bevindingen. Sta op uren per jaar als eenheid: uw financiële team kan die controleren, en zo vergelijkt u een verbetering van de pipeline met een extra medewerker.

Resultaat van de consultatie5 punten

Uw release zoals die echt verloopt, met handwerk en wachttijd per stap
Elk knelpunt ingedeeld als pipeline, proces of platform
Oplossingen gerangschikt naar uren per jaar, inspanning en eigenaar
Een antwoord op de beslissing die u benoemde, en de opties die u niet koos
Een eerste verbetering waar uw team zonder de adviseur mee kan beginnen

Veelgestelde vragen

Vragen over engineering-consultaties

Hoe lang duurt een engineering-consultatie?

Ongeveer een uur om één release met de juiste mensen door te lopen. Een releaseflow meten uit uw eigen data kost Mateusz twee weken.

Is een consultatie een audit of een verkoopgesprek?

Een consultatie stelt een diagnose: ze meet waar uw releases tijd en risico verliezen, en eindigt met een werkvolgorde. Een audit toetst uw beheersmaatregelen aan vooraf vastgelegde criteria; de woordenlijst van NIST omschrijft een audit als een onafhankelijke beoordeling en een onderzoek van vastleggingen en activiteiten. Een verkoopgesprek herkent u met één vraag: zou de uitkomst u ook helpen als u de adviseur nooit inhuurt?

Hoe kiest u een adviseur voor een engineering-consultatie?

Aan wat de adviseur vraagt voordat die antwoordt. Vraag naar de metingen vóór en na een eerdere verbetering, of de adviseur in uw bestaande tools werkt en wat u overhoudt als de samenwerking stopt. Haak af bij een aanbeveling voor een tool voordat iemand uw laatste release heeft gezien, bij resultaten zonder nulmeting en bij werk dat eindigt zonder runbook, training of overdracht. 5 factoren waar je op moet letten bij het kiezen van een DevOps-dienstverlener legt uit waarom u doorvraagt over het einde van de samenwerking, niet alleen over de start.

Hebt u toegang nodig tot onze systemen?

Niet tot productie. Leestoegang tot de data uit CI/CD en tickets, of een export daarvan, is genoeg, en voor beide kan een NDA gelden.

En als het antwoord een nieuwe tool of een nieuw platform is?

Bepaal dan wat de overstap kost en oplevert, voordat iemand zich eraan vastlegt. Zie Softwaremigratie, en voor de cloudkant Clouddiensten.

Een eerste meting

Bekijk waar de tijd van uw laatste release naartoe ging

De gratis Release Check zet uw antwoorden om in uren en kosten per jaar, en laat zien of de tijd naar de pipeline, het proces of het platform ging. In minder dan 5 minuten, zonder gesprek.

Doe de gratis Release Check