Hoe we softwareprojecten redden die ontspoord zijn

Er zijn weinig dingen frustrerender dan maanden — of zelfs jaren — investeren in een softwareproject, om er vervolgens achter te komen dat het niet oplevert wat je bedrijf nodig heeft.

Soms blijven deadlines maar verschuiven. Soms wordt de code onmogelijk te onderhouden. En het komt vaker voor dan je denkt dat de oorspronkelijke ontwikkelpartner simpelweg van de aardbodem verdwijnt.

Het goede nieuws? Niet elk problematisch softwareproject hoeft vanaf nul opnieuw te beginnen. Niet alle investeringen zijn verloren en met het juiste plan… gaat je software gewoon live.

Bij We Do Dev Work hebben we diverse projecten overgenomen die als "te ingewikkeld" of "onherstelbaar" werden beschouwd. Hoewel elke situatie uniek is, blijft onze aanpak opvallend consistent.

Stap 1: Blijf rustig

Het eerste gesprek gaat zelden over code.

Het gaat om het begrijpen van waar het misging, wat er nog wel werkt en wat de business vandaag de dag echt nodig heeft.

Veel klanten gaan ervan uit dat ze alles wat ze hebben opgebouwd moeten weggooien. Vaak is dat niet waar.

Een reddingsoperatie begint bij feiten, niet bij aannames.
Emoties vormen geen herstelplan.

Stap 2: Verspil geen tijd aan het beschuldigen van het vorige team

Het is verleidelijk om met de vinger te wijzen.

Wij doen dat niet.

Elk ontwikkelteam werkt met andere budgetten, deadlines, vereisten en beperkingen. Zonder het volledige verhaal te kennen, is het onmogelijk om de gemaakte beslissingen te beoordelen.

Falen geeft ons bovendien informatie die ons helpt om te slagen. Dus zelfs als het vorige team faalde: ze hebben ons geholpen om onze klant te helpen.

Belangrijker nog: de vorige ontwikkelaars de schuld geven helpt het project niet vooruit.

We hebben meer dan eens meegemaakt dat ze juist graag wilden helpen en ons waardevolle feedback gaven. De meeste mensen bedoelen het goed en hopen vaak dat wij het project wel tot een goed einde brengen.

Onze taak is om het probleem op te lossen, niet om schuldigen aan te wijzen.

Stap 3: Terug naar de bedrijfsdoelen

Voordat we ook maar één broncodebestand openen, kijken we opnieuw naar de oorspronkelijke bedrijfsdoelstellingen.

Vragen die we doorgaans stellen zijn:

• Welk probleem moet de software oplossen?

• Welke functies zijn essentieel?

• Welke vereisten zijn tijdens de ontwikkeling veranderd?

• Hoe ziet een succesvolle lancering er daadwerkelijk uit?

• Welke verwachtingen zijn realistisch binnen het beschikbare budget?

Pas nadat deze vragen beantwoord zijn, definiëren we een duidelijke scope en roadmap.

Zonder deze stap kan zelfs technisch perfecte software falen.

Stap 4: Voer een eerlijke technische audit uit

Pas dan duiken we in de codebase.

Ons doel is niet om fouten te zoeken, maar om te begrijpen wat er realistisch gezien hergebruikt kan worden.

We kijken naar zaken als:

• Architectuur

• Codekwaliteit

• Beveiliging

• Performance

• Onderhoudbaarheid

• Testing

• Documentatie

• Deployment-proces

De meeste projecten zijn niet volledig goed of volledig slecht.

Meestal is er sprake van een mix van degelijk werk en onderdelen die aanzienlijke verbetering behoeven.

Stap 5: Behoud wat logisch is (Vervang wat niet werkt)

Dit is waar ervaring het verschil maakt.

Sommige bureaus raden direct aan om alles te herschrijven. Anderen proberen elke regel code te behouden. Beide benaderingen kunnen erg duur uitvallen.

In plaats daarvan evalueren we elk component individueel. Als iets stabiel en onderhoudbaar is en in de toekomstige architectuur past, behouden we het. Als het technische schuld is geworden die meer kost om te onderhouden dan om te herbouwen, vervangen we het.

Het doel is simpel: de snelste weg naar een stabiel, onderhoudbaar product.

Echte voorbeelden

Mooie woorden, We Do Dev Work, maar brengen jullie dit ook in de praktijk?
Beste lezer, jazeker!

En elk reddingsproject ziet er anders uit.

PUT-IT-ON

Bij dit project was de backend op een solide fundament gebouwd.

In plaats van deze te vervangen, besloten we het grootste deel van de backend te behouden, terwijl we de frontend volledig vernieuwden voor een modernere en beter onderhoudbare gebruikerservaring.

Hierdoor konden we de eerdere investering van de klant beschermen en tegelijkertijd het product aanzienlijk verbeteren.

Waterleau

Dit project vroeg om de tegenovergestelde aanpak.

De frontend voldeed al redelijk aan de zakelijke behoeften, maar de backend-architectuur beperkte toekomstige ontwikkelingen.

In plaats van de interface te herschrijven, ontwierpen we een nieuwe backend-architectuur en introduceerden we nieuwe API-endpoints die het systeem schaalbaarder en gemakkelijker te onderhouden maakten.

Ook hier was het doel niet om alles te herschrijven.

Het doel was om alleen te herschrijven wat echt herschreven moest worden.

Soms is de beste oplossing geen volledige rewrite

Een van de grootste misvattingen in softwareontwikkeling is dat mislukte projecten altijd een volledige herstart nodig hebben.

In werkelijkheid bevatten de meeste projecten waardevol werk.

De uitdaging is om te identificeren wat het verdient om te blijven en wat niet.

Door dat onderscheid te maken, kun je maanden aan ontwikkeltijd en een aanzienlijk deel van het projectbudget besparen.

Reddingsprojecten vereisen zakelijk inzicht

Het herstellen van een softwareproject is niet alleen een technische oefening.

Het gaat om het begrijpen van de business, het verminderen van risico's, het herstellen van vertrouwen en het nemen van pragmatische beslissingen.

Technologie moet je bedrijf ondersteunen, niet de hindernis worden die je tegenhoudt.

Als je huidige softwareproject niet vooruitgaat zoals het zou moeten, ga er dan niet vanuit dat alles weggegooid moet worden.

Soms is de slimste oplossing weten wat je precies moet behouden. Laten we dat gesprek eens voeren.