"Vaste prijs - zeker resultaat"
- Maatwerkprojecten tegen een vaste prijs op basis van een vooraf bepaald resultaat
- Zeker weten waar u aan toe bent
Softwareontwikkeling en testen van software kan op verschillende manieren worden uitgevoerd. U bepaalt zelf wat voor u de beste manier van werken is. Heeft u behoefte aan 1 of enkele mensen als toevoeging op uw eigen teams, een volledig ontwikkelteam inclusief QA en testing of wilt u het ontwikkelen volledig uitbesteden, inclusief een vaste prijs?
Uiteraard kunt u van ons een goed advies verwachten rondom de uitvoering van uw maatwerksoftware project. Op basis van een gedegen vooronderzoek zijn wij meestal prima in staat om een goede inschatting te maken voor (en deel van) een project. Mocht dit niet zo zijn, dan krijgt u dit ook van ons te horen.
Wanneer wij een project uitvoeren tegen een vaste prijs is het uiteraard belangrijk om duidelijk te zijn over het op te leveren product. Onze business analisten, lead developers en QA managers kunnen, in samenwerking met u, duidelijkheid krijgen over uw verwachting over het op te leveren product. Van tevoren worden afspraken gemaakt en gedurende het traject wordt de voortgang gerapporteerd. Alleen als het voor beide partijen helder is wat er moet gebeuren en wat het eindresultaat moet zijn, is het mogelijk om een project goed in te schatten. Met onze ervaring zijn wij dan in staat om precies dat te leveren wat afgesproken is, binnen het afgesproken budget, op tijd en met de kwaliteit die u verwacht.
Het moeilijkste deel bij het voorbereiden van een project met een vaste prijs is het vaststellen van de prijs en het tijdschema, Beide kunnen alleen worden bepaald op basis van een duidelijk afgebakende scope. De verzameling gebruikersverhalen kan in verschillende sessies plaatsvinden, die in totaal niet langer dan 1 of 2 dagen mogen duren. Op dit punt is het belangrijk om de "definition of done" voor gebruikersverhalen, herhalingen en releases met de klant goed te keuren.
Om de gebruikersverhalen optimaal te structureren, moeten onder andere de volgende vragen beantwoord worden:
Het is belangrijk om zoveel mogelijk toekomstige projectdeelnemers bij het proces te betrekken, zodat de beoordeling samen wordt gedaan. Onze bedrijfsanalisten, hoofdontwikkelaars en QA-managers staan voor dit doel tot uw beschikking met al hun kennis en branchekennis.
Onderdeel van het vooronderzoek is o.a. om de snelheid van het geplande team te bepalen. Om schattingen van tijd en kosten voor projecten met een vaste prijs te kunnen geven, moeten we de snelheid (teamsnelheid) bepalen aan de hand van de volgende begincriteria:
Egor Gucinsky QA Manager
Door mensen uit de praktijk van software ontwikkelen, worden projecten met een vaste prijs vaak gezien als schadelijk voor het partnerschap tussen twee bedrijven. Veel agile specialisten vinden zelfs dat we ze gewoon moeten vermijden. Soms kunnen ze echter niet worden vermeden. We moeten dus manieren vinden om met onze klanten samen te werken om het doel te bereiken, namelijk; goede software ontwikkelen.
Uit mijn praktijk blijkt dat sommige aspecten van projecten met een vaste prijs eigenlijk beter zijn voor agile teams. We zijn er namelijk wel degelijk aan gewend om binnen een goed gedefinieerde tijdspanne te werken. En dat is precies wat een vaste leverdatum in een contract met een vaste prijs eigenlijk betekent: een duidelijk gedefinieerd tijd- en functionaliteitskader. Helaas is de focus wel erg sterk op de tijd en functionaliteit. Hierdoor is het enige dat ons echt bezighoudt in een dergelijk project, is de poging van de klant om meer zekerheid en vertrouwen te krijgen van zijn leverancier. En daar gaat het allemaal om - vertrouwen.
We weten dat alleen een getuigenis van hoe goed ons team het doet voor de klant, onvoldoende is voor daadwerkelijk vertrouwen van een nieuwe klant. Agile ontwikkeling biedt hier mogelijkheden om dit probleem op te lossen. Met elke iteratie kunnen wij waarde toegevoegen voor onze klanten. Maar wat nog belangrijker is, we focussen ons eerst op het leveren van de belangrijkste functies. De daadwerkelijk, continue, geleverde software moet vertrouwen wekken bij de klant. Elke sprint moet het enkele werkende delen van de belangrijkste functionaliteiten bevatten. Werkende software is het beste bewijs dat je de rest ook kunt bouwen. Daarnaast heeft de klant ook de mogelijkheid om te beslissen over de snelheid (snelheid) van het team en uiteindelijk om de volgende stap te zetten.