Wat kost het om zelf software te maken? 2/2

Wanneer kies je voor het ontwikkelen van eigen software?

Beslisschema

• Aan welke criteria moet er minimaal aan worden voldaan?
• Ga je voor een standaardoplossing of besluit je toch voor maatwerk te gaan?
• Welke prioriteiten hanteer je en voeg je daar nog wegingsfactoren aan toe?
• Wat zijn de initiële kosten, verwachte beheerkosten- en trainingskosten, licentiekosten?
• Wat zijn de verwachtingen voor ontwikkelings- en uitbreidingskosten?

Vraag: kiezen voor een bestaande oplossing of zelf gaan ontwikkelen?

• Hoe uniek zijn de procedures binnen je organisatie?
• Welke software draagt het meest bij aan jouw ambitie?
• Hoeveel tijd heb je voor het begeleiden van een ontwikkeltraject?
• Hoeveel kennis heb je in huis?
• Kan ICT mij voldoende ondersteunen?
• Gaan we de software zelf hosten? Of in de cloud?

Vergelijken van standaard software met een maatwerk applicatie

Welke factoren bepalen de kosten?

1. Inventarisatiekosten 
2. Uurtarief van de ontwikkelaars 
3. Vakkundigheid van de ontwikkelaars 
4. Technologie; toekomstbestendig van code en architectuur 
5. Bestaande componenten; open source of hergebruik van basis functionaliteit 
6. Intellectueel eigendom 
7. Onderhouds- en hostingkosten 
8. Interne uren of externe kennis 

1. Inventarisatiekosten
   Dit zijn de kosten voor het analyseren en vastleggen van de eisen en wensen voor de software. Dit kan variëren van workshops en offertegesprekken tot een proof of concept. Hoe grondiger de inventarisatie, hoe beter de verwachtingen worden afgestemd.
   
   
2. Uurtarieven
   De uurtarieven van ontwikkelaars verschillen sterk, afhankelijk van hun ervaring, locatie, en expertise. Lokale ontwikkelaars zijn vaak duurder (€80 tot €150 per uur), terwijl outsourcing naar landen als Oost-Europa of Azië lagere tarieven kan bieden (€40 tot €80 per uur), maar dit kan ook communicatie-uitdagingen opleveren. Wij hebben daar geen goede ervaringen mee. Een tegenmaatregel zou kunnen zijn om aanvullende projectbegeleiding in te zetten.
   
   
3. Vakkundigheid van de ontwikkelaars
   Meer ervaren ontwikkelaars werken sneller en leveren kwalitatief betere code, wat op lange termijn kosten kan besparen. Ook is hun expertise op het gebied van security, privacy en data van belang. En hoe is een partner ingewerkt in jouw branche? Of moet er nog veel tijd gestoken worden om de informatiepositie te versterken?
   
   
4. Technologie; toekomstbestendig van code en architectuur
   De keuze voor technologieën (zoals programmeertalen, frameworks, en databases) heeft invloed op de kosten. Het is belangrijk om te kiezen voor toekomstbestendige technologieën die goed onderhouden worden, om problemen en extra kosten in de toekomst te voorkomen. Ga je voor een gesloten systeem van een leverancier waarbij je bepaalde afhankelijkheden aan durft?
   
   
5. Bestaande componenten; open source of hergebruik van basisfunctionaliteit
   Het gebruik van open-source software of hergebruik van eerder ontwikkelde componenten kan de kosten verlagen. Denk aan bestaande inlogs, rapportagetools, of dashboards die niet helemaal vanaf nul gebouwd hoeven te worden. Ook een groot voordeel van een open-source oplossing: over een langere periode kan je veel besparen op licentiekosten (per gebruiker).
   
   
6. Intellectueel eigendom
   Wie de eigenaar is van de broncode kan de kosten beïnvloeden. Als jij als klant het intellectueel eigendom wilt hebben, kan dit leiden tot hogere kosten. Dit biedt echter wel de vrijheid om de software later zelf aan te passen of verder te ontwikkelen.
   
   
7. Onderhouds- en hostingkosten
   Na de oplevering moeten de applicaties gehost worden, waarvoor servers en infrastructuur nodig zijn. Daarnaast zijn er kosten voor het onderhouden en up-to-date houden van de software (via een SLA - Service Level Agreement).
   
   Neem mee in jouw berekening dat een applicatie vanaf de start nog niet af is. De meeste applicaties worden afhankelijk van de diepgang en reikwijdte meer intensief gebruikt door (nieuwe) klantengroepen en vragen meer onderhoud en neem mee dat er ook uitbreidingsverzoeken komen. Het is dan slim om de uitbreidingskosten wel te budgetten. 
   
   
8. Interne uren en externe kennis 
   De ontwikkeling van software vraagt tijd van je eigen team voor het geven van feedback, testen en het begeleiden van het proces. Als je zelf niet genoeg capaciteit of kennis hebt, kan het inhuren van een externe product owner of projectmanager noodzakelijk zijn.

Veelvoorkomende fouten bij softwareontwikkeling

1. Onduidelijke doelstellingen en eisen
   Een van de grootste fouten is het starten van een project zonder heldere, concrete doelen. Als je niet precies weet wat de software moet doen of welke problemen het moet oplossen, kunnen ontwikkelaars moeite hebben om de juiste functionaliteiten te leveren. Dit leidt vaak tot vertragingen, extra kosten en een product dat niet aansluit op de behoefte.
   
   
2. Gebrek aan planning en prioritering
   Softwareprojecten mislukken vaak door slechte projectplanning. Zonder een duidelijke roadmap en prioritering van functies kunnen ontwikkelteams verdwalen in een ongestructureerd proces. Het is belangrijk om eerst een Minimum Viable Product (MVP) te definiëren en vervolgens de roadmap te volgen voor toekomstige uitbreidingen.
   
   
3. Het niet betrekkenen van eindgebruikers in een vroeg stadium
   Veel bedrijven maken de fout om de software te ontwikkelen zonder gebruikers of stakeholders vroegtijdig te betrekken. Hierdoor wordt de software vaak ontwikkeld op basis van aannames die niet overeenkomen met de daadwerkelijke behoeften van gebruikers. Vroege en regelmatige feedback is cruciaal om fouten te voorkomen en de acceptatie te vergroten.
   
   
4. Verkeerde technologiekeuze
   Het kiezen van de verkeerde technologie of architectuur kan desastreuze gevolgen hebben voor de lange termijn. Vaak worden verouderde technologieën gekozen omdat het team er bekend mee is, terwijl nieuwe technologieën betere prestaties en toekomstbestendigheid zouden kunnen bieden. Dit kan leiden tot meer onderhoudskosten en zelfs de noodzaak om de software te herbouwen.
   
   
5. Slechte documentatie
   Het niet vastleggen van beslissingen, code en processen zorgt voor problemen bij onderhoud, opschaling en toekomstige uitbreiding van de software. Goede documentatie is essentieel om een project efficiënt te beheren, vooral als er nieuwe ontwikkelaars bij het project komen.
   
   
6. Onvoldoende testen
   Een veelvoorkomende fout is het overslaan of minimaliseren van tests. Dit kan leiden tot fouten en bugs die pas later, vaak in een productieomgeving, aan het licht komen. Het is belangrijk om zowel handmatig als automatisch testen uit te voeren en te investeren in kwaliteit om dure fouten te voorkomen.
   
   
7. Slechte communicatie binnen het team
   Gebrek aan communicatie tussen ontwikkelaars, projectmanagers en stakeholders leidt vaak tot misverstanden en verkeerde interpretaties van de vereisten. Het is belangrijk om duidelijke lijnen van communicatie en regelmatige updates en feedbacksessies te hebben.
   
   Wat ook regelmatig terugkeert zijn wisselingen in het kernteam. Wat voor vertragingen of extra kosten kan leiden.
   
   
8. Te veel functies in één keer willen bouwen
   De poging om meteen een volledig af product te bouwen kan leiden tot "feature creep," waarbij steeds meer functies worden toegevoegd en de complexiteit toeneemt. Dit zorgt vaak voor vertragingen en hogere kosten. Het is beter om een eerste werkbare versie (MVP) te bouwen en functies later stapsgewijs toe te voegen.
   
   
9. Geen aandacht voor schaalbaarheid en onderhoud
   Veel software wordt ontwikkeld zonder oog voor toekomstige schaalbaarheid en onderhoud. Als het product succesvol is en groeit, kan het zijn dat de software onvoldoende is voorbereid op een grotere gebruikersbasis of complexere eisen, wat kan leiden tot grote herstructureringskosten.
   
   
10. Verwaarlozen van beveiliging
    Beveiliging wordt vaak over het hoofd gezien in de vroege fasen van ontwikkeling, maar is van cruciaal belang om de integriteit en vertrouwelijkheid van gegevens te waarborgen. Het implementeren van security best practices vanaf het begin kan problemen en schandalen in de toekomst voorkomen.

Door deze valkuilen te vermijden en te focussen op goede planning, communicatie, testen en schaalbaarheid, kunnen veel problemen bij softwareontwikkeling worden voorkomen.

Conclusie

1. Ambities op lange termijn 
2. Bedrijfsdoelstellingen 
3. Beschikbare tijd en budget