Het uurtje-factuurtje model in de dienstverlening heeft zijn langste tijd wel gehad, ook in de testwereld. Testuurtje-factuurtje gaat steeds minder makkelijk op. Het is een ondoorzichtig en achterhaald model. Opdrachtgevers kunnen maar moeilijk nagaan welke dienst er nou eigenlijk geleverd is en tegen welke prijs. Zeker nu er kritisch naar alle kosten gekeken wordt, is dat voor veel klanten niet wenselijk.
Klanten vragen steeds vaker naar wat een project hun oplevert, binnen welk tijdspad en wat het totale kostenplaatje daarvan is. Zo voorkomen ze alsmaar oplopende kosten waardoor budgetten worden overschreden. Vandaag de dag rekenen ook steeds meer testdienstverleners af met het denken in uren maal tarief en stappen over naar het leveren van testdiensten in plaats van testuren. Het resultaat staat hierbij centraal.
Om deze omslag te maken, zijn een aantal aandachtspunten van belang. Het vergt namelijk niet alleen een omschakeling in het aanbieden van de dienst, maar ook de uitvoering. Waar moet je opletten bij het aanbieden en uitvoeren van de dienst om de ‘nieuwe’ testsamenwerking tussen klant en dienstverlener prettig te laten verlopen? Ik heb hieronder vast een voorzet gedaan van de aandachtspunten.
Aanbieding
De nieuwe testsamenwerking begint bij een passend aanbod. Van belang is het dus om de wensen van de klant goed op je netvlies te hebben om de dienst passend te kunnen krijgen. In het algemeen gesteld, verwacht de klant een helder aanbod waaraan een duidelijke doelstelling is gekoppeld. Je spreekt over een deliverable. Hieraan koppel je een prijs en een tijdspad. Op deze manier weet de klant precies welke testdienst hij geleverd krijgt tegen welke prijs en binnen een gestelde termijn.
Bij een herhalende opdracht is het slim de klant te laten kiezen uit een lijst met vooraf vastgestelde testen met standaard prijzen, een ‘cafetaria-model’. Maar dan ben je er nog niet. Het is in wederzijds belang dat er tevens duidelijke randvoorwaarden worden opgesteld. In praktisch en operationeel opzicht, maar ook voor wat betreft de beschikbaarheid en kwaliteit van de benodigde documentatie.
Randvoorwaarden
Een voorbeeld van een randvoorwaarde op operationeel niveau is bijvoorbeeld dat de klant beschikbaar moet zijn voor contact, input en feedback. Hoe kun je immers op tijd leveren als de klant geen terugkoppeling geeft? Kan immers knap lastig worden om de userstories te testen als je die nog niet binnen hebt. Dit hangt nauw samen met de kwaliteit van de benodigde documentatie.
Zijn de userstories up-to-date? Is het functioneel of technisch ontwerp beschikbaar en volledig? Ook dat zijn zaken van essentieel belang om de test goed uit te kunnen voeren. De documentatie van de klant dient op een bepaald niveau te zijn. Dit zijn zaken om op te nemen in de randvoorwaarden. Bedenk bij het opstellen van de randvoorwaarden dat deze de samenwerking moeten bevorderen en dat het geen ellenlange lijst wordt die afschrikt.
Uitvoering
Een helder aanbod en overeengekomen randvoorwaarden is een goede toolkit voor de testers om aan de slag te gaan. Toch vergt het nieuwe testsamenwerken juist in de praktijk een behoorlijke omslag om te voorkomen dat de testdienstverlener het schip in gaat. Van oudsher zijn testers gewend om dienstverlenend te zijn en dat de uren die daarbij komen kijken, kunnen worden doorbelast.
In de huidige situatie zie je dat uren worden verbrand aan het op orde brengen van de documentatie en aan het verkrijgen van input. Als de klant zich niet houdt aan de randvoorwaarden, is het van groot belang dat er aan de bel getrokken wordt. Alles dat buiten de deliverables valt, is immers niet door te belasten zonder vooraf overleg.
Levering
Om tot een concrete en heldere levering te komen kan je de klant voorzien van een vrijgavedocument. Het vrijgavedocument bevat niet alleen een rapportage van de testresultaten, maar ook een rapportage van de uitgevoerde werkzaamheden. Hierdoor heeft de klant volledig inzicht in hoe de tests zijn uitgevoerd en wat hij daadwerkelijk geleverd heeft gekregen. De klant heeft nu een goed inzicht in zijn value for money.
Zeker als de tester werkt vanaf een externe locatie is niet altijd de notie van kwaliteit aanwezig bij de klant. De werkzaamheden van de tester zijn dan immers niet direct zichtbaar. Daarom is het zinvol om te bezien of er voor de klant objectieve kwaliteitscriteria te definiëren zijn. Ten tijde van de levering kan dan de score op deze criteria het inzicht in kwaliteit en value for money ondersteunen.
De testdienstverlening kan met een vooruitziende blik om een passend aanbod op te stellen gecombineerd met een kritisch oog om de voortgang te bewaken volgens mij goed mee komen in deze tijd. Zijn er nog extra aandachtspunten die volgens jou een prettige samenwerking bevorderen?
Welk probleem los je nu eigenlijk op? Van het testbedrijf die moeite heeft zijn dienst ver verkopen? Of de opdrachtgever om hem te behouden niet teveel te betalen voor testen?
Software ontwikkeling en testen zijn vrij complexe processen. Specificaties en vereisten zijn nooit volledige en vrij van interpretatie. In een proces van mensen hoe je altijd een spanningsveld.
Natuurlijk is het fijn als je standaard diensten voor standaard prijzen kunt aanbieden, dat maakt het voor de opdrachtgever gemakkelijk. Maar dat werkt alleen goed als een partij volledige controle heeft over zijn inspanning.
Wat is het probleem van uurtje factuurtje? Dit zijn namelijk wel de metrics waarin je eigen kosten als opdrachtnemer aan berekend worden en daarmee het “eerlijkst”, alleen brengt dat voor een opdrachtgever risico’s met zich mee.
Ik maak voor veel werkzaamheden waarbij de controle op inspanning niet gegarandeerd is -ofwel er zijn afhankelijkheden- dan maak ik gewoon een urenschatting. Als je dan toch onverhoopt dreigt uit te lopen geef je zo vroeg mogelijk hier een signaal over af en met een onderbouwing. Heb je zelf een inschattingsfout gemaakt dan doe je een voorstel waarin je het verlies neemt of eventueel deelt met de opdrachtgever. Ligt het bij de opdrachtgever dan is het logisch dat deze de meeste van de onvoorziene kosten voor zijn rekening neemt.
Hiermee komt je niet in een pad stelling terecht en zolang je goed communiceert en presteert werkt dit best.
Dus het denken in uren maal tarief, wiens probleem los je nu op?
@Henri: jouw oplossing werkt het beste vanuit één persoon, die ook nog eens resultaatverantwoordelijkheid voelt voor alles waaraan hij/zij zich gecommit heeft. Maar voor detachering in zijn algemeenheid loop je toch tegen het probleem aan dat de regie niet bij de opdrachtnemer ligt en resultaatverplichting meer dan de individu omvat.
Dat is m.i. iets wat moet worden aangepakt. Het leveren van een dienst kan een oplossing zijn, maar ook andere afspraken met een opdrachtgever. Bijvoorbeeld wel resultaat- en doorlooptijdverplichtingen en een bonus/malus-regeling die je kunt benutten cq ontlopen door te variëren met inzet zonder de oorspronkelijke afspraken te hoeven aantasten.
Het blijft overigens lastig om tegengestelde belangen tussen opdrachtgevers en opdrachtnemers op een natuurlijke manier bij elkaar te brengen in een win-win. Nogmaals: voor een ZZP-er geldt dit in veel mindere mate.
@Leen: Ik begrijp je reactie, maar ik ben het er niet mee eens dat het alleen voor ZZP geldt.
Je hebt inhuur / detachering en dat is en blijft in mijn ogen vooralsnog uurtje factuurtje, ook voor de enterprise, ofwel inspanningsverplichting zonder resultaatverplichting.
En je hebt projecten, en daarin zie ik echt geen onderscheid tussen een freelancer en een opdrachtnemer die wellicht wel tien man inzet, de resultaatverplichting verplaatst gewoon naar een ander persoon die binnen zijn eigen organisatie werkzaamheden moet laten dimensioneren door 1 of meerdere personen. Maar de onderliggende principes blijven gelijk.
Over de rest van de reactie kan ik het wel met je eens zijn 🙂
Maar zolang er geen goede nieuwe modellen zijn zul je toch vaak in uren maal tarief blijven denken.
Ik ben benieuwd hoe de afspraken eruit zagen tussen Cap Gemini en de politie academie….
In het artikel wordt nog te veel uitgegaan van testen als een fase achteraf. Veel agile methoden, bijvoorbeeld Scrum, zien testen als onderdeel van een continu proces en de tester is een actief lid van het ontwikkelteam. Resultaat- en doorloopverplichtingen gelden dan niet voor de tester persoonlijk, maar voor het gehele team.
Additioneel is het begrip kwaliteit binnen de ICT nogal ver te zoeken, met name omdat dat kosten met zich meebrengt. Hierdoor wordt met name het testproces (als onderdeel van kwaliteit) vaak te beperkt uitgevoerd.
ITIL/PRINCE2/AGILE leveren allemaal prima mogelijkheden om te meten wat er is gepresteerd voor elk uur dat gefactureerd is. Hoezo achterhaald en ondoorzichtig. Software ontwikkeling en testen zijn vrij complexe processen, zoals Henri al meldt. Fixed price nodigt weer uit tot leveren van minimale kwaliteit. Loodgieter wordt toch ook per uur betaald. Ik wil er zeker geen die zegt alles te fixen voor 75 euro zonder dattie precies weet wat die bij de klant kan verwachten.
De eeuwige discussie: wel of geen fixed price?
Fixed price is alleen haalbaar als zowel de vraag als de daarop te leveren dienst goed zijn gedefinieerd, overeengekomen en vastgelegd, waarbij duidelijk is wie (de opdrachtgever) de regie voert over het totale traject van vraag en aanbod.
Ik begrijp de opmerking van @Leen niet over de tegengestelde belangen. Opdrachtgever en opdrachtnemer hebben juist complementaire belangen. Dienstverleners die werken vanuit eigenbelang en niet vanuit de visie dat het leveren van de dienst primair gericht is op het oplossen van een probleem van de opdrachtgever (wat de werkelijke rechtvaardiging van hun business is) zijn naar mijn mening niet goed bezig.