Maatwerk software wat mag dat kosten?
De kosten voor het ontwikkelen van software variëren sterk, vooral bij maatwerksoftware. De kosten hangen onder andere af van de grootte en complexiteit van de applicatie die je wilt laten ontwikkelen. Een eenvoudige app kan enkele duizenden euro's kosten, terwijl een complexe app met veel logica aanzienlijk duurder (tonnen) kan zijn.
Functionaliteit/-tijd
Bij het ontwikkelen van maatwerksoftware staan de wensen van de eindgebruiker vaak centraal. De eisen die je stelt aan het systeem hebben direct invloed op de kosten. Hoge eisen aan code-kwaliteit (o.a. door testing), snelheid en gebruiksvriendelijkheid drijven kosten op. Meer functionaliteiten vereisen niet alleen extra ontwikkeluren, maar verhogen ook de belasting van het systeem.
Er zijn twee soorten eisen bij het opstellen van je wensen: functionele eisen en randvoorwaarden. Functionele eisen bepalen of de app doet wat je wilt, bijvoorbeeld of de gebruiker de beoogde taak kan uitvoeren. Randvoorwaarden verbeteren de gebruikservaring, zoals de snelheid en veiligheid van het systeem.
De juiste vragen bepalen de kosten
Om de kosten van jouw maatwerksoftware beter te prognotiseren, moet je eerst de juiste vragen stellen. Begin met het definiëren van je doel. Waarom wil je een nieuwe applicatie? Welke bedrijfsprocessen wil je versnellen? Wie gaat de app gebruiken? Is er bestaande standaard software die bepaalde maatwerk ontwikkeling overbodig en onnodig maakt?
Kostenopbouw van software
Het laten maken van software kent een bepaalde kostenopbouw. Als je deze opbouw begrijpt, krijg je een beter beeld van de te verwachtte kosten. Naast directe kosten zoals project- en ontwikkeluren, moet je ook rekening houden met indirecte kosten zoals vertragingen door bijvoorbeeld een nieuw management of aanpassingen en aanvullingen op de logica en functionaliteiten door voortschrijdend inzicht (o.a. marktontwikkelingen, inzetbare releases van standaard software).
Directe kosten
Directe kosten zijn kosten die rechtstreeks verband houden met het maken van de software. Hoe meer uren er aan gewerkt wordt, hoe (logisch) hoger de prijs. Voorbeelden van directe kosten zijn:
- Uitdenken /-werken van de architectuur
- Onderzoeken en designen van de gebruikerservaring (UX)
- Ontwikkeling van de techniek
- Hosting en licenties
Indirecte kosten
Indirecte kosten worden vaak over het hoofd gezien, maar kunnen aanzienlijk zijn. Door ook deze kosten in kaart te brengen, krijg je een nauwkeuriger beeld van de totale kosten en een betere kostenverwachting. Voorbeelden van indirecte kosten zijn:
- Juridische kosten
- Nieuwe updates die compatibel gemaakt moeten worden
- Verloren tijd en kennis door ziekte, zwangerschap, onboarding, rollenwisseling
Kostenbeheersing
Er zijn verschillende manieren om de kosten voor de ontwikkeling van maatwerksoftware te beheersen. Je kunt vooraf duidelijk afspreken welke functionaliteit er ontwikkeld moet worden binnen welke tijdspanne. Dit model, vaak gepaard met een vaste prijs en een vaste tijdsindeling, noemt men ook wel de Waterval-methodiek.
Een groot voordeel van deze methodiek is dat je vooraf weet wat je krijgt tegen welke kosten. Het prestatierisico ligt volledig bij de ontwikkelaar. De ontwikkelaar zal echter zijn prestatierisico meecalculeren, dit maakt de ontwikkeling duurder. Daarnaast krijg je te maken met schijnveiligheid, want; nadeel, in een Waterval-project is de kans op een mismatch tussen je wens en het eindproduct veel groter dan bij een bijvoorbeeld een moderne methodiek als Scrum. Veelal wordt deze methodiek dan ook toegepast bij kleinere transparante ontwikkelingen die vaak al een keer 'ontwikkeld' zijn. Denk bijvoorbeeld aan het leggen van bekende software-koppelingen. Een ontwikkelaar heeft een dergelijke koppeling mogelijk al meerdere keren gemaakt en weet de bottle necks of showstoppers vooraf in te schatten.
Voortschrijdend inzicht (we noemende hem al even) is een belangrijke factor die de ontwikkeling stuurt naar echt bruikbare software. De dag van morgen ziet er anders uit als de dag van gisteren. Nieuwe inzichten, nieuwe technieken, wellicht ontwikkelingen in de markt die om een hele andere benadering vragen. Maar denk ook aan juridische invloeden (regelgeving) of economische beïnvloeding (crisissen) die andere voorwaarden stellen aan de ontwikkeling.
De methodiek die hier het meest flexibel mee omgaat, en daarmee het risco op kosten ook beter beheersbaar maakt, is de Scrum-methodiek. De Scrum-methodiek is een bekende Agile werkwijze. Scrum staat tegenover de traditionele Waterval-methodiek. Door de flexibele Scrum-methodiek te hanteren, kun je het project bijsturen en altijd de meest logische vervolgstap nemen. Het uitspreken van een fixed price over deze werkzaamheden is echter moeilijk, aangezien het project op elk moment een andere richting kan opgaan.
Maar hoe beheers ik dan de kosten bij deze methodiek?
Een vaste prijs kan lijken, maar je zet jezelf onnodig vast op de functionaliteit. Een kostenmodel waarbij je geleidelijk dingen toevoegt, is bij met name grotere ontwikkelingen een veiligere optie. Door het project op te splitsen in meerdere sprints (Scrum), kun je tussentijds evalueren en bijsturen.
Het loslaten van de vaste prijs betekent overigens niet dat je een ontwikkelaar een vrijbrief geeft om helemaal lost te gaan. Veel ontwikkelaars hanteren een vast uurtarief en een flexibele (Agile) werkwijze tijdens de ontwikkeling van de software. In één of meerdere ontwikkelperiodes (dat noemen we: sprints) van 2 tot 3 weken wordt je de functionaliteit (of een deel ervan) opbouwend ontwikkeld. Elke sprint bestaat uit een vast aantal uren en aan het einde van elke sprint wordt het project bijgestuurd op basis van de voortgang.
Deze werkwijze geeft je inzicht in de voortgang en de flexibiliteit om op het juiste moment de juiste keuzes te maken. Doordat elke sprint een gelijk aantal uren heeft, weet je welke kosten je per sprint maakt.
Hoeveel sprints er nodig zijn om het product te laten voldoen aan de uiteindelijke eisen, is wel een vraag die je pas later in de ontwikkeling kunt beantwoorden. Maar door eerst met een 'klein' valide product feedback op te halen bij de gebruikers verklein je het risico op verkeerde en daarmee onnodig kostbare ontwikkeling die niet terugverdient gaat worden. Bijkomend beschik je altijd over een stuk werkbare software, waardoor je dus ook op ieder moment kunt afschalen, pauzeren of juist opschalen in ontwikkeling. Het voorbeeld van de step naar uiteindelijk de ontwikkeling van een auto wordt regelmatig aangehaald. Met een step kom je vooruit. Met een auto ook. Echter is de step spartaans (langzaam, minder veilig) en voldoet de auto aan alle vereisten (snel, veilig, droog, ect.).
Het inzichtelijk maken van de te verwachten kosten en de keuze voor de methodiek is niet altijd eenvoudig. Er zijn diverse factoren waarmee je rekening moet houden. Door alle factoren goed af te wegen, kun je een weloverwogen keuze maken die past bij jouw project en jouw organisatie.
Als onafhankelijk adviseur helpt eastpaq je graag bij de verschillen vanuit een meer onafhankelijke blik te bekijken zodat jij een nog beter en gemotiveerdere keuze kunt maken. Mocht je een eerlijk advies willen ontvangen specifiek op jouw eigen situatie? Vraag het ons. Tijdens een eerste kennismaking vertellen wij jou precies hoe wij ondernemers begeleiden naar minder afhankelijkheid en onzekerheid in de digitale organisatie.
