Ga naar inhoud
  • 0

Termijn voor oplossen bugs in website

Aanbevolen berichten

18 antwoorden op deze vraag

  • 0
Senior     58 1

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.

 


Wij adviseren, begeleiden en geven concrete invulling op het gebied van CLOUD oplossingen.

Link naar reactie
  • 1
Legend     3,3k 192

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.

Link naar reactie
  • 0
Senior     46 0

 

 

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?

 

 

 

 

Link naar reactie
  • 0
Legend     3,3k 192
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.

Link naar reactie
  • 0
Senior     46 0

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...

Link naar reactie
  • 0
Legend     3,3k 192

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?

Link naar reactie
  • 0
Senior     46 0

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.

 

 

 

 

 

Link naar reactie
  • 0
Legend     3,3k 192
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.

Link naar reactie
  • 0
Senior     46 0

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 )

 

 

 

Link naar reactie
  • 0
Gast Verwijderd account
Guests

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.

Link naar reactie
  • 0
Legend     916 47

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).

 

:)

 

 

Link naar reactie
  • 1
Retired Mod     8,7k 582
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.

Link naar reactie
Gast
Dit topic is nu gesloten voor nieuwe reacties.
Verberg sidebar
  • Wie is er online?
    0 leden, 40 Gasten

  • Breng jouw businessplan naar een higher level!

    Op dit forum worden alle onderwerpen m.b.t. ondernemerschap besproken.

    • Stel jouw ondernemersvragen
    • Antwoorden/oplossingen van collega ondernemers
    • > 65.000 geregistreerde leden
    • > 100.000 bezoekers per maand
    • 24/7 bereikbaar / binnen < 6 uur antwoord
    •  Altijd gratis

  • Ook interessant:

×
×
  • Nieuwe aanmaken...

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.