Onredelijke "garantieperiode" op te ontwikkelen software?

[nickelz]

Beste mede-tweaker/zzp-er,

Bij een nieuwe klant van mij, is er een onderdeel in het contract waarbij ze aangeven dat er een garantieperiode van 3 maanden wordt verwacht. Ik moet de software nog ontwikkelen voor hen, maar er staat een heel stuk in over dat als de "prestatie" niet deugdelijk is uitgevoerd, ik alsnog moet "uitvoeren"... Naar mijn gevoel is dit heel breed te interpreteren; als de klant kwaad in de zin heeft (wat ik absoluut niet verwacht hoor) dan zou hij dit heel breed kunnen trekken en ik dus 3 maanden door mag ontwikkelen tot het naar "wens" is, daarboven op misschien geld "verschuldigd" zijn..

Ik heb zelf een standaard contract laten opstellen door mijn jurist destijds; daar heeft hij dit niet in benoemd..

Ik ben een zzp-er (nog niet heel lang) en ben benieuwd of een mede-tweaker dit is tegengekomen, oftewel: wat vinden jullie hiervan?


Alvast bedankt voor jullie reacties!

Nico

[MAX3400]

Aangezien software vaak niet meer aan output levert dan "goed" of "fout", is het dus meetbaar wat zij onder "prestatie" scharen.

Dan maak je dus een baseline, een test-traject, afspraken over reproduceerbare KPI's en klaar.

/edit: oh, contract is al getekend en rechtsgeldig?

[ Voor 10% gewijzigd door MAX3400 op 12-08-2020 11:55 ]

[CodeCaster]

Klinkt alsof zij met vage specs jou goedkoop een half systeem willen laten afleveren, en je vervolgens drie maanden gratis willen gebruiken om het af te maken.

Ik zou dus heel goed specificeren wat je precies moet opleveren.

[ Voor 17% gewijzigd door CodeCaster op 12-08-2020 11:55 ]

[Lelletje]

Het lijkt me goed dat er volgende zaken afgesproken zijn:
- uurtarief of all-in prijs?
- wat moet er precies opgeleverd worden? Kader dat goed in.
- wat is de testperiode dat ze mogen testen? 10 werkdagen?
- wanneer wordt er goedkeuring op gegeven op wat je geleverd hebt?

Als je namelijk goed afgekaderd hebt wat opgeleverd moet worden, kan er veel voorkomen worden.

Als de klant opeens iets anders of iets nieuws wilt, dan stel je een nieuw contract op met de prijzen en afkaderingen erbij.

[Freeaqingme]

Ik zou zorgen voor een goede acceptatieomgeving. Daar kan de klant op testen, en als ze daar zeggen dat alles oke is, dan pas live zetten. Dan leg je de verantwoordelijkheid bij de klant dat deze het goed test (gebeurt zelden). Verder zou ik de garantie beperken tot bugs, en niet missende features.

CodeCaster schreef op woensdag 12 augustus 2020 @ 11:55:
Klinkt alsof zij met vage specs jou goedkoop een half systeem willen laten afleveren, en je vervolgens drie maanden gratis willen gebruiken om het af te maken.

Het hoeft echt geen kwade wil te zijn natuurlijk. Voor klanten die niet heel bekend zijn met softwareontwikkeling is een softwareproduct net een auto. Je zegt wat je wilt ("een zwarte, vier wielen, stuur links"), en dan krijg je dat - met garantie en alles. Dat er dan geen coffee cup holders etc in zitten (want niet gespecificeerd) vindt de klant een probleem ("ondeugdelijk") want iedere auto heeft dat toch... Maar het is dan denk ik meer onbewust onbekwaam waar je je klant in moet begeleiden, dan dat ze er vooraf op uit zijn om de leverancier het leven zuur te maken.

[ Voor 58% gewijzigd door Freeaqingme op 12-08-2020 11:58 ]

[XyritZz]

MAX3400 schreef op woensdag 12 augustus 2020 @ 11:54:
Aangezien software vaak niet meer aan output levert dan "goed" of "fout", is het dus meetbaar wat zij onder "prestatie" scharen.

Dan maak je dus een baseline, een test-traject, afspraken over reproduceerbare KPI's en klaar.

/edit: oh, contract is al getekend en rechtsgeldig?

Nou ja, dat is wel heel simplistisch gezien. Als je bijv. een website moet opleveren en die genereert een response in 800ms terwijl de klant het binnen 100ms verwacht kan je daar wel gedoe over krijgen.

Als je voor een vaste prijs de software maakt is het zaak de specificaties behoorlijk dicht te timmeren zodat er zo min mogelijk ruimte voor discussie is. Daarnaast zou ik een risico percentage meenemen in de prijs; zodat je als er discussiepunten ontstaan wat sneller geneigd bent gewoon toe te geven; je hebt er tijd voor gereserveerd in dat percentage.

Als je volgens een uurtarief/nacalculatie werkt; dan zou ik de garantie beperken tot "Ik sta voor u klaar". Als ze bug-x binnen het project gevonden hadden, dan had je de tijd gewoon doorbelast dus na livegang doe je dat ook. De garantie die je dan geeft is dat je niet 100% voor een volgende klant aan het werk bent en geen tijd hebt om issues op te lossen.

[nickelz]

Wow wat een snelle reacties! Dankjewel!

Hier heb ik heel veel aan; ik zal het contract laten aanvullen met de genoemde punten!

@Lelletje : Ja ik heb een uurtarief, nee het is een standaard contract van hen; dus ik zal moeten aanvullen wat er precies opgeleverd moet worden. De testperiode; goed punt! Hiermee kan ik dus al afdekken dat ze niet zomaar na die periode van alles "missen"

@Freeaqingme: Ook een goed punt! De garantie beperken tot bugs en niet missen features!

@MAX3400 : Duidelijk! Met duidelijke KPI's afkaderen!

Nu is het wel zo dat ze zelf nog niet compleet duidelijk hebben wat ze uiteindelijk verwachten, het is een "ongoing" ontwikkeling met voortschrijdend inzicht op de features die ze willen hebben. Maar ik begrijp dat als ze zo'n strak contract voor m'n neus gooien, dat ik zelf heel duidelijk moet afkaderen wat er opgeleverd gaat worden.

Is het verstandig om toekomstige problemen, hier een jurist naar te laten kijken? Of met jullie genoemde punten zou ik al geholpen zijn m.b.t. dit onderdeel?

[MAX3400]

XyritZz schreef op woensdag 12 augustus 2020 @ 12:01:
[...]


Nou ja, dat is wel heel simplistisch gezien. Als je bijv. een website moet opleveren en die genereert een response in 800ms terwijl de klant het binnen 100ms verwacht kan je daar wel gedoe over krijgen.

Hoezo simplistisch? Dat beschrijf ik toch: je maakt afspraken over wat de software moet doen, daarna ga je pas soebatten hoe je dat wel/niet haalt.

Jij draait het om; je zegt dat de klant het binnen 100ms verwacht en de code doet 800ms. Waar is de afspraak? Nergens.

En dat is dus exact waarom je reproduceerbaar en ondubbelzinnig een test/acceptie/produktie moet optuigen en afspreken.

[nickelz]

Ik zie veel opmerkingen over een test/acceptatie/productie omgeving; sterk! Dat zal ik er bij in opnemen, hiermee voorkom ik denk ik al veel problemen?

[Lumics]

nickelz schreef op woensdag 12 augustus 2020 @ 12:08:
Ik zie veel opmerkingen over een test/acceptatie/productie omgeving; sterk! Dat zal ik er bij in opnemen, hiermee voorkom ik denk ik al veel problemen?

Problemen voorkom je aan het begin van het traject! Tijdens het traject komen problemen aan het licht.
Zorg dus voor duidelijk afspraken. Klant stelt SMART Requirements en hieraan voldoen jij in de oplevering. Voorkomen is beter dan genezen.

[XyritZz]

MAX3400 schreef op woensdag 12 augustus 2020 @ 12:04:
[...]

Hoezo simplistisch? Dat beschrijf ik toch: je maakt afspraken over wat de software moet doen, daarna ga je pas soebatten hoe je dat wel/niet haalt.

Jij draait het om; je zegt dat de klant het binnen 100ms verwacht en de code doet 800ms. Waar is de afspraak? Nergens.

En dat is dus exact waarom je reproduceerbaar en ondubbelzinnig een test/acceptie/produktie moet optuigen en afspreken.

Dan begreep ik je verkeerd . Ik dacht dat je bedoelde dat de output van software simpelweg correct of incorrect is; ik wilde aangeven dat het soms iets dieper gaat. De correcte output, te traag op het scherm kan alsnog onacceptabel zijn voor klanten.

Wel iets om rekening mee te houden; ga niet alleen de functionele werking van de software documenteren maar ook de niet functionele werking. Performance, security etc.

[purge]

Begrijp ik goed dat je een standaard contract hebt laten maken. En dat de nieuwe klant een extra artikel van de genoemde garantieperiode erbij wilt hebben? Daar vanuitgaande.

Ik lees net je opmerking over het contract. Prima om met hun overeenkomst verder te gaan. Laat dit wel juridisch checken.Wel zo handig om een ‘basis’ te pakken waar zo weinig mogelijk aan hoeft te gebeuren. Aan jouw kant maar ook die van de klant.

Helemaal onredelijk is zoiets niet. Maar natuurlijk niet, zoals je zelf al aanvoelt, zomaar. Het moet naar beide partijen wel redelijk blijven, toch. Boven mij zijn al enige suggesties gedaan.

Ben je niet heel erg benieuwd wat de reden van dit verzoek is? Maar het bespreekbaar waarbij je aangeeft dat dit voor jou ‘niet prettig’ voelt. Waarschijnlijk heeft de klant ook zijn/haar argumentatie. Ga erover met ze in gesprek. Misschien is je jurist van toen bereid om met je mee te denken.

Ik heb genoeg kleine en grote software projecten zien leiden tot gefrustreerde mensen, aan beide kanten. Veelal door (gebrek aan) communicatie en/of kennis.

Ik denk dat het doel van jou en de klant is om op een prettige manier tot een acceptabel resultaat te komen.
Natuurlijk heel fijn als het contract op papier goed in elkaar zit, ook voor jou. Maar als uiteindelijk je een naar gesprek met elkaar hebt over: Zit ‘iets’ wel of niet ‘in scope’ / wel of niet goed en op tijd getest / ... dat wil je zoveel mogelijk voorkomen.

Stop vooral in het begin energie in de overeenkomst en de opdracht. Waarbij beide partijen zoveel mogelijk op een lijn zitten. Veel vragen is een methode hiervoor.


Toevoeging: De volgende vraag komt bij mij op. Staat de gevraagde garantieperiode wel in verhouding tot de grootte van de opdracht? Als je 2 weken bezig bent dan denk ik dat 3 maanden garantie wel veel is. Als je 2 jaar bezig bent dan valt 3 maanden wel mee. Misschien is het aanpassen van deze periode ook een mogelijkheid. Zeg dat je (natte vinger) 2% van de werkelijk gemaakte uren als garantie wilt geven. Dan borg je iig een verlies. In het ergste geval dus 2% minder omzet.

De opmerking hieronder is een mooie 🙂

[ Voor 21% gewijzigd door purge op 12-08-2020 12:26 ]

[emnich]

Bij een uurtarief heb je een inspanningsverplichting en geen resultaat verplichting. Van garantie kan dan m.i. geen sprake zijn.

[Freeaqingme]

Voor wat betreft de voorbeelden van laadtijden zou ik me er niet te veel op vastleggen. In mijn ervaring zijn die zeer zelden relevant voor de klant. En ook al zijn de laadtijden goed, als het in de beleving van de klant langzaam is, dan gaat 'ie hoe dan ook ontevreden zijn (gemiddelde mkb'er ziet geen verschil tussen 100ms en 2s laadtijd).

Having said that, als je zorgt dat je allebei op dezelfde golflengte zitten voorkom je verre weg het meeste problemen. Daar kan geen jurist tegenop. Juist met een jurist heb je kans dat je allebei een eigen werkelijkheid creeert, die uiteindelijk absoluut niet op elkaar aansluiten <insert anekdote van een miljoenencontract waarbij leverancier en klant beiden met een zelfgeschreven functionele beschrijving werkten - en welke elkaar meer dan eens tegen spraken/>

Ik onderneem ook al een tijd, en ik heb wel grote klussen opgepakt zonder enige schriftelijke overeenkomst. Dat zou je dom kunnen noemen, maar de klant en ik zitten op dezelfde golflengte en de klant waardeert juist het snelle schakelen zonder 'gedoe' met overeenkomsten.

offtopic:
Uiteraard heb ik me wel een beetje ingedekt. Er wordt ondernomen vanuit een BV, algemene voorwaarden zijn van toepassing, er is een aansprakelijkheidsverzekering en echt belangrijke afspraken worden wel vastgelegd in een email of ticketsysteem

.

Gaat het wel eens mis? Zeker. Maar juist omdat je op dezelfde golflengte zit is het dan prima bespreekbaar, los je het op, en drink je - bij wijze van spreken - daarna nog een pilsje.

[Miyamoto]

Normaliter is garantie een onderdeel van de prijsopbouw. Dus langere garantie betekend hogere prijs. Echter wel van belang om helder te hebben wat er voor verwacht wordt.

[kwaakvaak_v2]

nickelz schreef op woensdag 12 augustus 2020 @ 12:01:

Nu is het wel zo dat ze zelf nog niet compleet duidelijk hebben wat ze uiteindelijk verwachten, het is een "ongoing" ontwikkeling met voortschrijdend inzicht op de features die ze willen hebben. Maar ik begrijp dat als ze zo'n strak contract voor m'n neus gooien, dat ik zelf heel duidelijk moet afkaderen wat er opgeleverd gaat worden.

Dit klinkt als een project dat je zeker niet waterval of fixed scope moet aanpakken en zeker niet het type klant, wat je beschrijft. Dit is een potentiële leegloper voor jou als uitvoerrder.

Wellicht dat je beter af bent om een MVP te maken en dan met sprints het voortschrijdend inzicht opvangt.

Dat doen wij steeds meer met webprojecten, en dat scheelt verassingen achteraf zolang je maar duidelijk bent in wat je in sprint kan oppakken qua tijd en afkadering van het ticket.

En nee je hoeft niet gelijk volledig agile te gaan, want dat is voor een eenpitter niet te doen. Maar je kunt wel je klant wensen laten maken in een ticket systeem, en vervolgens die wensen te begroten qua tijd (min/max -> avg) en af te spreken hoeveel tijd ze per iteratie / sprint inkopen.

Zolang je er maar op hamert dat één ticket één wens is, en duidelijk staat wat de wens is en hoe hij de wens interpreteert en denkt uit te gaan voeren. En ja dat kost je ook tijd, maar die kun je handig mee pakken uit het sprint budget zelf

Het risico blijft wel dat je niet goed ingeschat hebt, dat hoort bij risico wat je als ondernemer altijd blijft houden.

[Gomez12]

MAX3400 schreef op woensdag 12 augustus 2020 @ 12:04:
[...]

Hoezo simplistisch? Dat beschrijf ik toch: je maakt afspraken over wat de software moet doen, daarna ga je pas soebatten hoe je dat wel/niet haalt.

Jij draait het om; je zegt dat de klant het binnen 100ms verwacht en de code doet 800ms. Waar is de afspraak? Nergens.

En dat is dus exact waarom je reproduceerbaar en ondubbelzinnig een test/acceptie/produktie moet optuigen en afspreken.

En dit zijn nu net van die leuke dingetjes die veel gezeik kunnen opleveren.

Is in dit soort gevallen de afspraak niet impliciet en als logisch gevolg van uitspraken van google en goede seo.

Want als je zegt dat het nergens vastgelegd staat vind je dan ook dat een pageload van 1 minuut acceptabel is, of een volledige site in flash.

Maar @nickelz : Ik zou simpelweg zeggen : Klant, specificeer even wat een deugdelijke prestatie is en ik kan ernaar kijken. Want zeker als ze nu nog geen exact idee hebben wat het moet worden, dan zou ik me niet branden aan dit soort voorwaarden.

Want zeker met Agile heb ik al meerdere keren gezien dat het in 1e instantie wel opgeschreven is, dat het vanwege tijdsdruk weer afgevoerd is, en dat aan het einde een brulaap met originele specs om de hoek komt zetten en vertellen dat het niet deugdelijk is uitgevoerd...

Oftewel ik zou van de klant vragen wat hij voor prestaties verwacht en ook zelf met wat suggesties aankomen (het openen van een schermpje en het daarna in dat schermpje kunnen werken mag max 2 seconden duren wmb, met uitzondering rapportages en jaarberekeningen etc)

[Sissors]

Freeaqingme schreef op woensdag 12 augustus 2020 @ 11:56:
Ik zou zorgen voor een goede acceptatieomgeving. Daar kan de klant op testen, en als ze daar zeggen dat alles oke is, dan pas live zetten. Dan leg je de verantwoordelijkheid bij de klant dat deze het goed test (gebeurt zelden). Verder zou ik de garantie beperken tot bugs, en niet missende features.


[...]


Het hoeft echt geen kwade wil te zijn natuurlijk. Voor klanten die niet heel bekend zijn met softwareontwikkeling is een softwareproduct net een auto. Je zegt wat je wilt ("een zwarte, vier wielen, stuur links"), en dan krijg je dat - met garantie en alles. Dat er dan geen coffee cup holders etc in zitten (want niet gespecificeerd) vindt de klant een probleem ("ondeugdelijk") want iedere auto heeft dat toch... Maar het is dan denk ik meer onbewust onbekwaam waar je je klant in moet begeleiden, dan dat ze er vooraf op uit zijn om de leverancier het leven zuur te maken.

Of ze zijn juist wel heel bekend met softwareontwikkeling, en hebben ervaring dat er een hoop bugs worden opgeleverd.

[Woy]

Sissors schreef op woensdag 12 augustus 2020 @ 19:44:
[...]

Of ze zijn juist wel heel bekend met softwareontwikkeling, en hebben ervaring dat er een hoop bugs worden opgeleverd.

Dan moet je inderdaad kwaliteit eisen afstemmen. Maar garantie is nogal gek om af te stemmen bij iets dat op uurbasis afgerekend wordt.

Het is dan gewoon zaak dat je juiste acceptatie criteria hebt. Sowieso zou ik voor een project op uurbasis geen garantie op bugs geven. Bij fixed price kan het wel, maar dan moet je wel goede specs hebben, en duidelijke afspraken over wat een bug is.

[Freeaqingme]

Sissors schreef op woensdag 12 augustus 2020 @ 19:44:
[...]

Of ze zijn juist wel heel bekend met softwareontwikkeling, en hebben ervaring dat er een hoop bugs worden opgeleverd.

Da's dan niet onterecht, maar toch ook niet ter kwader trouw? Wat ik daarmee bedoel is dat de klant bewust allerlei features vooraf verzwijgt, en achteraf zegt "waar is X, Y en Z?", en je ineens veel meer meerwerk hebt waarvan de klant claimt dat 't onder garantie zou moeten vallen.

[Gomez12]

Freeaqingme schreef op woensdag 12 augustus 2020 @ 20:22:
[...]


Da's dan niet onterecht, maar toch ook niet ter kwader trouw? Wat ik daarmee bedoel is dat de klant bewust allerlei features vooraf verzwijgt, en achteraf zegt "waar is X, Y en Z?", en je ineens veel meer meerwerk hebt waarvan de klant claimt dat 't onder garantie zou moeten vallen.

Dat is als je een kwade klant hebt, maar je hebt net zo goed kwade devvers die zeggen in 40 uur x op te leveren waarbij het na 120 uur nog niet werkt zoals aangegeven.
En dan krijg je een moment waarop de klant het moet afkappen (je kan niet eeuwig blijven devven)

En dan snap ik het vanuit de klant wel dat die een soort van garantie wil hebben.,

[Freeaqingme]

Gomez12 schreef op donderdag 13 augustus 2020 @ 11:29:
[...]


En dan snap ik het vanuit de klant wel dat die een soort van garantie wil hebben.,

Zeker. Als ik de indruk gewekt heb dat het onredelijk is garantie te vragen dan was dat niet mijnb edoeling. Zeker bij fixed price / fixed scope projecten is dat helemaal niet gek. Alleen er werd geopperd dat de klant het mogelijk ook zou kunnen doen om er misbruik van te maken. En de kans dat een klant vooraf dat snode plan ontwikkelt lijkt me niet zo heel groot.

offtopic:
Wel 1 keer meegemaakt toen ik nog in loondienst zat, dus het kan wel.

[NMe]

CodeCaster schreef op woensdag 12 augustus 2020 @ 11:55:
Klinkt alsof zij met vage specs jou goedkoop een half systeem willen laten afleveren, en je vervolgens drie maanden gratis willen gebruiken om het af te maken.

Ik zou dus heel goed specificeren wat je precies moet opleveren.

Niet alleen goed specificeren wat je gaat opleveren en hoe dat werkt, maar ook vastleggen dat interpretatiefouten in overleg gecorrigeerd worden. En dat na acceptatie wel nog bugs opgelost worden, maar geen features worden bijgemaakt zonder bijbetaling. De klant heeft bij acceptatie zelf de verantwoordelijkheid om te checken of alle features er zijn.

Overigens wordt dit soort zaken normaal gesproken afgedekt met een SLA, niet met een garantie.

[Ben(V)]

Garantie heeft enkel en alleen betrekking op het niet voldoen aan de gestelde specificaties.
Als er niets gespecificeerd is, dan is er ook geen garantie.

Dus dingen als performance moet je nooit specificeren, want die zijn bij software van heel veel zaken afhankelijk die buiten de software liggen.

En verder is garantie iets dat in Nederland ook nog wettelijk geregeld is.
Als je geen garantie afspreekt en na een half jaar komt de klant erachter dat er iets inzit dat niet aan de gespecificeerde functionaliteit voldoet, dan moet je dat oplossen of je nu wel of geen garantie hebt afgesproken.

Dus eerst specificeren, akkoord vragen van de klant en dan pas bouwen.
requirements >> specifications >>design >> build >> test >> document >> deliver

PS
En SLA's zijn alleen van toepassing als het over onderhoud contracten gaat en niet over enkel levering.
Dat heet niet voor niets Service Level Agreement en niet Build Agreement.

[ Voor 12% gewijzigd door Ben(V) op 15-08-2020 13:35 ]

[Douweegbertje]

Ik heb niet alle reacties gelezen maar ik kan je wel wat input geven. Ik ben namelijk jaren betrokken geweest bij dit soort opleveringen. Wat we altijd merkte is dat de klant alles wilt, maar daar eigenlijk niet veel voor over heeft. Vrij onrealistisch om daar zakelijk mee om te gaan.

Als je niet streng bent voor jezelf dan kan je je net zo goed nu al failliet laten verklaren want zo'n klant gaat dan helemaal los. Dus weet heel duidelijk in de spec maar laat vooral support op uren gaan en niet "erbij in". Want 3 maanden ongedefinieerde troep oplossen is gewoon het einde.

Laat de klant ook die verantwoording voelen. Dat kan prima met duidelijke specs. Geef de klant dan de keuze; "ik kan dit aanpassen maar dan vervalt Y" of... "dit nog extra toevoegen is X-uur meerwerk".

Aan de andere kant wilt een bedrijf soms ook iets van garantie op papier. De nuance is dat hier duidelijk in moet zijn dat het bugs zijn op basis van de specs. Niet bugs in de algemene zin. M.a.w. als het design een rode banner heeft, moet deze niet blauw zijn bij oplevering.

Een klant gaat alsnog proberen alles onder die noemer te gooien. Dat is het moment dat je gewoon heel zakelijk moet zijn.

Wat wij eigenlijk deden was:

- Vrij agile ontwikkeling. Klant was mede betrokken bij prio's en features. Komt klant er dan achter dat de spec niet in orde is, dan kan de klant zelf keuzes maken. Of die feature niet of extra $$ betalen
- Klant ruim de tijd geven om te testen (exact window van bijv. 2-3 weken) - Maar hier duidelijk onderscheid maken tussen: "bug in spec" of "ik wil dit toch anders" - is het het laatste dan mag hier voor betaald worden.
- Bepaalde "features" in zo'n test periode worden soms pas NA livegang opgepakt. Want we willen wel een project afronden.
- Na livegang is er nog 1 week support op whatever, weer de nuance dat niet alles onder de "garantie" valt.
- En nu is het gewoon allemaal op support (uurtje factuurtje) - Klant heeft kunnen testen voor 1 maand. Het is klaar nu. Punt.

Communicatie en duidelijkheid is hier echt mega belangrijk in. En ja, je hebt soms klanten die NIET begrijpen dat je niet gratis gaat werken. Maar even simpel gezegd moet je daar schijt aan hebben. Je moet gewoon echt betaald krijgen anders kan je niet bestaan.

[nickelz]

Ik zou wel alle reacties willen aanmerken als beste antwoord; het heeft mij enorm geholpen!

Ik heb met ze gesproken over de garantieperiode en aangegeven dat ik daar niet mee akkoord ga omdat ik niet een "all inclusive" tarief heb. En ik kader het meer af in de opdrachtomschrijving. Ook aangegeven dat ik het volgende wil opnemen in het contract:

- Een test, acceptatie en productieomgeving
- In de acceptatieomgeving zal een zogeheten beta release komen; hier kan de klant nog aangeven of er (kleine) missende features zijn, of fouten zijn ontdekt
- Na de acceptatie omgeving komt er een final release, die wordt uitgezet op de productieomgeving en dan is het klaar; wel nog minimale support leveren voor de periode van twee weken, maar hier mogen niet meer features in "gewenst" worden. Alle nieuwe features (bugs) zullen per nieuwe opdracht gaan, om het weer duidelijk opnieuw af te kaderen

Echt ontzettend bedankt mensen! Ben echt blij met al jullie reacties die mij hiermee geholpen hebben!

Groet!

[Gomez12]

Douweegbertje schreef op zaterdag 15 augustus 2020 @ 14:03:
Wat wij eigenlijk deden was:

- Vrij agile ontwikkeling. Klant was mede betrokken bij prio's en features. Komt klant er dan achter dat de spec niet in orde is, dan kan de klant zelf keuzes maken. Of die feature niet of extra $$ betalen
- Klant ruim de tijd geven om te testen (exact window van bijv. 2-3 weken) - Maar hier duidelijk onderscheid maken tussen: "bug in spec" of "ik wil dit toch anders" - is het het laatste dan mag hier voor betaald worden.
- Bepaalde "features" in zo'n test periode worden soms pas NA livegang opgepakt. Want we willen wel een project afronden.
- Na livegang is er nog 1 week support op whatever, weer de nuance dat niet alles onder de "garantie" valt.
- En nu is het gewoon allemaal op support (uurtje factuurtje) - Klant heeft kunnen testen voor 1 maand. Het is klaar nu. Punt.

Communicatie en duidelijkheid is hier echt mega belangrijk in. En ja, je hebt soms klanten die NIET begrijpen dat je niet gratis gaat werken. Maar even simpel gezegd moet je daar schijt aan hebben. Je moet gewoon echt betaald krijgen anders kan je niet bestaan.

Dit zie ik bij wel meer bedrijven, alleen mijn ervaring met dit soort praktijken is dat ze enkel werken als je compleet anti-DRY bent, of als je je klant simpelweg wil naaien...

Vaak genoeg gezien dat er in een DRY-omgeving 1 component vervangen werd door een ander component en dat er dan links en rechts allerlei dingen buiten de test-scope omvielen en devver maar blijven zeggen dat dat allemaal "nieuwe bugs" waren, nope dat zijn allemaal 100% herleidbare bugs doordat jij component 1 door 2 hebt vervangen en je kan zelf de scope van de wijziging niet meer overzien...

Dan krijg je de ietwat mindere discussies.

[pennywiser]

nickelz schreef op woensdag 19 augustus 2020 @ 09:55:
Ik zou wel alle reacties willen aanmerken als beste antwoord; het heeft mij enorm geholpen!

Ik heb met ze gesproken over de garantieperiode en aangegeven dat ik daar niet mee akkoord ga omdat ik niet een "all inclusive" tarief heb. En ik kader het meer af in de opdrachtomschrijving. Ook aangegeven dat ik het volgende wil opnemen in het contract:

- Een test, acceptatie en productieomgeving
- In de acceptatieomgeving zal een zogeheten beta release komen; hier kan de klant nog aangeven of er (kleine) missende features zijn, of fouten zijn ontdekt
- Na de acceptatie omgeving komt er een final release, die wordt uitgezet op de productieomgeving en dan is het klaar; wel nog minimale support leveren voor de periode van twee weken, maar hier mogen niet meer features in "gewenst" worden. Alle nieuwe features (bugs) zullen per nieuwe opdracht gaan, om het weer duidelijk opnieuw af te kaderen

Echt ontzettend bedankt mensen! Ben echt blij met al jullie reacties die mij hiermee geholpen hebben!

Groet!

Kan je aangeven hoe hun reactie toen was, en hoe jullie het eens geworden zijn? Daar leren we weer van

[Douweegbertje]

Gomez12 schreef op woensdag 19 augustus 2020 @ 10:37:
[...]

Dit zie ik bij wel meer bedrijven, alleen mijn ervaring met dit soort praktijken is dat ze enkel werken als je compleet anti-DRY bent, of als je je klant simpelweg wil naaien...

Vaak genoeg gezien dat er in een DRY-omgeving 1 component vervangen werd door een ander component en dat er dan links en rechts allerlei dingen buiten de test-scope omvielen en devver maar blijven zeggen dat dat allemaal "nieuwe bugs" waren, nope dat zijn allemaal 100% herleidbare bugs doordat jij component 1 door 2 hebt vervangen en je kan zelf de scope van de wijziging niet meer overzien...

Dan krijg je de ietwat mindere discussies.

Het is maar net aan welke kant je staat.
Zo kan ik hem omdraaien dat ik dit wel vaker zie bij klanten, die denken dat ze voor een dubbeltje op de eerste rang zitten en letterlijk nergens voor willen betalen. In welke redelijkheid moet een bedrijf voor alles op draaien? Ook bijvoorbeeld na 1 jaar na dato?
Ik heb wel eens gehad dat een plugin bijv. niet meer supported was en een upgrade nodig had. Simpelweg LCM. Ik vind het helemaal niet gek dat een klant hiervoor mag betalen. Dat is iets wat je duidelijk kan beschrijven.

Het is typerend dat jij het gelijk hebt over "klanten naaien" - ik bekijk het gewoon zakelijk. Links of rechtsom zal er werk verzet moeten worden. Die post moet ERGENS naar toe. Dus je krijgt dan OF dat het product 100x duurder is OF dat je gewoon uur/factuur krijgt. Want als ik bijv. garantie moet geven dat jij 2 jaar lang niets hoeft te betalen aan LCM, dan gaan we even in het begin een totaal andere prijs berekenen voor de oplevering van het product (zie bijv. dat voorbeeld van die plugin).

Juist dat niet afhandelen zorgt voor vervelende situaties waarbij er continue discussie is en gezeik over geld.

[nickelz]

pennywiser schreef op woensdag 19 augustus 2020 @ 10:45:
[...]

Kan je aangeven hoe hun reactie toen was, en hoe jullie het eens geworden zijn? Daar leren we weer van

Zoo, late reactie.. Nou jullie tips hebben absoluut geholpen! Het garantie stuk hadden ze klakkeloos van een of andere advocaat overgenomen (die blijkbaar 0 verstand heeft van software). Ik heb aangegeven aangezien ik per uur factuur en het 'as service' is, dus geen garantie kan geven. Heb aangeboden om een all-inclusive tarief (+€25 per uur boven op normale tarief) te doen en dan "garantie" aan te bieden, maar dat wilden ze niet 😬

Dus het stuk is eruit gesloopt en we kabbelen weer rustig verder op mijn contract 🎉

Nogmaals bedankt iedereen!!