Termijn voor oplossen bugs in website

[natalie-d]

Welke reparatietermijn gebruiken jullie meestal in jullie contracten voor het oplossen van Bugs? (bugs in website van klant)

en wat gebeurt er als het probleem langer duurt dan de termijn?

 

[titel aangepast - mod]

 

[R.I.P. | Peter Bonjernoor]

"Zo snel mogelijk"

 

Je kunt op voorhand niet inschatten hoelang het zal duren om een bug die je nog niet kent te repareren. Na analyse kun je dat wel zeggen, en is de kans dat je die termijn overschrijdt ook veel kleiner.

[Dixon]

Wij noemen geen termijnen in onze overeenkomsten anders dan dat we ons maximaal zullen inspannen om e.e.a. z.s.m. op te lossen.

 

Het is op voorhand natuurlijk erg moeilijk om hiervoor een vaste termijn te benoemen.

 

In de praktijk gewoon proberen 'bugs' etc. echt z.s.m. op te lossen.

 

[natalie-d]

maar 'z.s.m.' en 'maximaal inspannen' zijn zo vaag voor de klant.

die wil toch weten waar die aan toe is..

 

[willemj]

maar 'z.s.m.' en 'maximaal inspannen' zijn zo vaag voor de klant.

die wil toch weten waar die aan toe is..

 

Vraag je dit als afnemer van de software of de leverancier? In het laatste geval heb je waarschijnlijk nog nooit te maken gehad met een 'goede bug' ;) Je weet als maker dan namelijk ook niet waar je aan toe bent.

[natalie-d]

 

 

Vraag je dit als afnemer van de software of de leverancier? In het laatste geval heb je waarschijnlijk nog nooit te maken gehad met een 'goede bug' ;) Je weet als maker dan namelijk ook niet waar je aan toe bent.

 

als afnemer vraag ik dit inderdaad.

Ik begrijp nu dat het heel moeilijk is om de tijd van te voren in te schatten, maar als afnemer wil je toch iets op schrift hebben hierover, anders kan het ook weken gaan duren.

Als afnemer weet je ook niet of de leverancier er echt druk mee bezig is of dat deze een andere nieuwe opdracht voor laat gaan omdat er toch geen 'boetes' zijn.

 

Lastige kwestie, om met toch iets te komen op schrift wat voor beide partijen acceptabel is.

Iemand een idee?

 

 

 

 

[robberttk]

Je zou afspraken kunnen maken over de responstijd, bv reageren binnen 48 uur met een tijdsindicatie voor een oplossing. Het blijft met software en websites lastig om exacte tijden af te spreken, tenzij je bereid bent veel geld te betalen natuurlijk.

[natalie-d]

een tijdsindicatie

bedankt robberttenk

 

bedoel je dat de reactietijd en de tijdsindicatie voor een oplossing vooraf worden vastgelegd in het contract, of dat de leverancier bij zijn reactie binnen de 48 uur de tijdsindicatie doorgeeft?

[willemj]

Ik begrijp nu dat het heel moeilijk is om de tijd van te voren in te schatten, maar als afnemer wil je toch iets op schrift hebben hierover, anders kan het ook weken gaan duren.

Als afnemer weet je ook niet of de leverancier er echt druk mee bezig is of dat deze een andere nieuwe opdracht voor laat gaan omdat er toch geen 'boetes' zijn.

 

Met iets op schrift kan het ook weken duren. Ook als er op dat schrift 48 uur staat. Zoals met zoveel dingen in het leven gaat het om een stuk vertrouwen en inzet. Ik zie een contract meer als een vangnet voor wanneer dat wegvalt. En als je op dat punt bent aangekomen zal bij de rechter waarschijnlijk 'redelijkheid en billijkheid' gelden.

 

Lastige kwestie, om met toch iets te komen op schrift wat voor beide partijen acceptabel is. Iemand een idee?

 

Zo'n reactieperiode voor een indicatie vind ik wel een goed uitgangspunt. Verder zou je aan fouten die de werking van de software verminderen en waar niet omheen gewerkt kan worden een periode kunnen koppelen van een week (eigenlijk al niet realistisch....) Maar dat is, wat Robert al zegt, een kwestie van geld. Contractueel een prestatieverplichting vastleggen voor een project van 1000 euro is bijvoorbeeld niet gangbaar.

[natalie-d]

En als je op dat punt bent aangekomen zal bij de rechter waarschijnlijk 'redelijkheid en billijkheid' gelden.

 

wie moet bewijzen dat de termijn redelijk was, de afnemer of de leverancier?

en hoe kan dit worden bepaald ?

Houden leveranciers een 'historie'-bestand bij?

 

 

Contractueel een prestatieverplichting vastleggen voor een project van 1000 euro is bijvoorbeeld niet gangbaar.

het is wel wat meer dan 1000 euro...

[willemj]

wie moet bewijzen dat de termijn redelijk was, de afnemer of de leverancier?

Degene die naar de rechter stapt moet aantonen dat zijn claim correct is.

 

en hoe kan dit worden bepaald ?

De rechter bepaald wat 'redelijk en billijk is'.

 

Houden leveranciers een 'historie'-bestand bij?

Historie van wat? Foutrapporten van klanten? Ik wel.

 

Zit je al in de situatie dat een fout niet opgelost wordt?

[natalie-d]

Willemj,dank voor je snelle antwoord.

 

Ik ben bezig met het contract op dit moment.

 

Ik bedoel 'Historie' van foutrapporten, en van fouten in software en hoe ze het hebben opgelost, dat programmeurs bijhouden wat de fouten waren, wat ze eraan hebben gedaan etc.

Ik dacht: op die manier kan de leverancier aantonen dat het een ingewikkelde bug was die veel tijd kostte.

 

 

Je zegt: "Zoals met zoveel dingen in het leven gaat het om een stuk vertrouwen en inzet."

Dat is helemaal waar, het liefst ga je niet naar de rechter, maar ik zag eerder deze week hier op het forum dat iemand zelfs problemen had met een familielid die een website had gemaakt.

In het begin is alles altijd goed, maar je weet maar nooit hoe de relatie gaat,

er zou toch iets op schrift moeten staan over de termijnen en gevolgen, lijkt me.

 

 

 

 

 

[willemj]

Ik dacht: op die manier kan de leverancier aantonen dat het een ingewikkelde bug was die veel tijd kostte.

Zo simpel is het niet. Het kan lang duren omdat de bug in een stuk code zit van een derde partij. Als ik die niet kan fixen ben ik afhankelijk van die derde partij. Sommige bugs doen zich alleen voor in heel specieke omstandigheden. Om die te achterhalen kun je (in extreme gevallen) een dag zoniet dagen bezig zijn. Als ik jou een rapport geef met '8 uur geprobeerd bug te vinden' zegt dat jou niets terwijl ik hard bezig ben geweest.

 

Dat is helemaal waar, het liefst ga je niet naar de rechter, maar ik zag eerder deze week hier op het forum dat iemand zelfs problemen had met een familielid die een website had gemaakt.

Je moet ook geen zaken doen met vrienden en familie. Juist een grotere kans dat er problemen ontstaan.

 

In het begin is alles altijd goed, maar je weet maar nooit hoe de relatie gaat,er zou toch iets op schrift moeten staan over de termijnen en gevolgen, lijkt me.

Iets jazeker. Dat ze leveren wat afgesproken is en bugs zo snel mogelijk herstellen. Een vaste termijn met een boete clausule is niet realistisch (zonder hoge kosten)

 

Spreek een testperiode af met je leverancier. Hij levert de site / software op, jij betaalt een gedeelte en gaat vervolgens testen. Als je fouten vindt meldt je die en pas na het testen betaal je de rest. Als jij heel goed test hoef je helemaal geen dingen over bugs op te nemen :D

 

Verder kun je nog kijken naar de rechten die je krijgt op de software. Als alle rechten bij jou liggen kun je zowiezo naar een derde stappen om een bug te laten fixen in een conflict situatie.

[natalie-d]

bedankt willemj, je antwoorden maken heel veel duidelijker. :)

 

Spreek een testperiode af met je leverancier. Hij levert de site / software op, jij betaalt een gedeelte en gaat vervolgens testen. Als je fouten vindt meldt je die en pas na het testen betaal je de rest. Als jij heel goed test hoef je helemaal geen dingen over bugs op te nemen :D

alles van te voren uittesten ben ik wel van plan (alleen kan je wel eens een dingetje over het hoofd zien natuurlijk).

maar ik dacht dat zijn programmerfouten.

en bugs zijn fouten die later in het programma komen.

Klopt dat?

 

 

(p.s. ja, met vrienden of familie kan je beter geen zaken doen, daar ben ik ook al achter gekomen.. :-\ ;D )

 

 

 

[Gast Verwijderd account]

Na een uitgebreide testperiode zijn vrijwel alle bugs die leiden tot uitval van kritieke functionaliteit verwijderd. "Nieuwe" bugs zijn meestal reeds bestane bugs die pas later aan het licht komen. Des te langer dat duurt en des te ingewikkelder het is om het gevolg van de bug te reproduceren, des te meer u zich dient af te vragen of het verhelpen van de bug nog wel onder de dienstverlening valt waar destijds een contract voor is afgesloten.

 

Ik zal nooit in het contract laten opnemen dat alle bugs verholpen gaan worden. Laat staan dat ik daar een tijdslimiet voor ga instellen. Stel dat een klant na maanden ontdekt dat hij door 10 ongewone handelingen een bug tevoorschijn kan halen, dan is het niet wenselijk dat hij met het contract in de hand herstel kan eisen; zeker niet binnen een bepaalde tijd. Hetzelfde geldt voor het geval dat hij de software opeens anders installeert in een andere omgeving waardoor het programma niet meer correct functioneert.

 

Heel goed oppassen dat het zogenaamd verhelpen van een bug niet in feite neerkomt op het realiseren van nieuwe functionaliteit waar in beginsel niet voor betaald is.

[robberttk]

Daar heb je een goed punt inderdaad. Veel "bugs" zijn eigenlijk missende functionaliteiten of ontwerptechnische zaken.

 

De programmeur of ontwerper doet uiteindelijk wat hij gespecificeerd krijgt. Als je als klant iets anders in je hoofd hebt, kunnen daar problemen gaan ontstaan.

 

Zorg ervoor dat je je plan zoveel mogelijk, en zo gedetailleerd mogelijk uitwerkt. Daarmee voorkom je meer ellende dan met het beste contract ter wereld. (kijk, op pagina 14 onderin zie je aan mijn screenshot dat het er anders uit moet zien, fix het, etc etc).

 

:)

 

 

[R.I.P. | Peter Bonjernoor]

Stel dat een klant na maanden ontdekt dat hij door 10 ongewone handelingen een bug tevoorschijn kan halen, dan is het niet wenselijk dat hij met het contract in de hand herstel kan eisen;

 

Dat ligt er aan - als het ongewone handelingen zijn die hij toch eens in de zoveel tijd uit zal moeten voeren, dan hindert deze bug de werking van de site en moet hij opgelost worden. Als er gemakkelijk omheen gewerkt kan worden door de gebruiker kan gekozen worden het inet op te lossen.

 

Wederom in redelijk overleg.

[natalie-d]

Stel dat een klant na maanden ontdekt dat hij door 10 ongewone handelingen een bug tevoorschijn kan halen, .......

 

een bug tevoorschijn halen..

in welke gevallen kan dat?

[R.I.P. | Peter Bonjernoor]

een bug tevoorschijn halen..

in welke gevallen kan dat?

 

Hij bedoelt dat een bug soms pas ontdekt wordt na een reeks handelingen die normaal gesproken niet of zelden wordt uitgevoerd.