De klant heeft deze getest en goedgekeurd (schriftelijk).
De klant ontdekt na enige tijd een probleem en na onderzoek kom ik erachter dat er nog meer bugs in het geleverde zit. Deze bugs had de klant zelf niet kunnen vinden tijdens het testen.
Wie moet er dan voor de kosten opdraaien?
De klant, want hij heeft akkoord gegeven?
Ik, want ik heb de bugs zelf niet gevonden?
(dit is dus hypothetisch, want als ik zou programmeren was er slechts 1 bug geweest, het hele product
)Maar stel je nou maar eens voor, dat het niet hypothetisch was.
In dit geval is er sprake van een formele afname-test, die schriftelijk afgetekend is door de klant. Er is geen sprake van garantie in dit soort gevallen, tenzij dit in de afspraken/contract tussen klant en leverancier is vastgelegd.quote:Op donderdag 25 oktober 2012 13:39 schreef Winterman het volgende:
Jij blijft verantwoordelijk voor je product. Dat heet garantie.
Hoe TS hier mee om moet gaan hangt af van :
- de afspraken/contract;
- de tijd/kosten die TS moet maken om het op te lossen;
- de mentaliteit van TS;
- de relatie die TS met de klant heeft en eventueel wil behouden.
Oplevering ontslaat je niet van je verantwoordelijkheden. In een beetje een fatsoenlijk contract leg je dit natuurlijk vast.quote:Op donderdag 25 oktober 2012 13:38 schreef Kreator het volgende:
...de klant betaalt, want opgeleverd.
Maar stel je nou maar eens voor, dat het niet hypothetisch was.
Ja. Maar dus niet zoals TS het stelt. Hypothetisch dan hè.quote:
[..]
Oplevering ontslaat je niet van je verantwoordelijkheden. In een beetje een fatsoenlijk contract leg je dit natuurlijk vast.
Als de bug tijdens de test niet is gezien of niet gezien had kunnen worden betekend het natuurlijk niet dat je als leverancier totaal geen plichten meer hebt.quote:
[..]
In dit geval is er sprake van een formele afname-test, die schriftelijk afgetekend is door de klant. Er is geen sprake van garantie in dit soort gevallen, tenzij dit in de afspraken/contract tussen klant en leverancier is vastgelegd.
Hoe TS hier mee om moet gaan hangt af van :
- de afspraken/contract;
- de tijd/kosten die TS moet maken om het op te lossen;
- de mentaliteit van TS;
- de relatie die TS met de klant heeft en eventueel wil behouden.
Bij fixed-price betaalt de klant een vooraf vastgestelde prijs voor een afgerond product binnen de afgesproken kwaliteitseisen. Als het product hier niet aan doet (bugs), dan moet de ontwikkelaar dit oplossen. Aangzien hierbij alle risico's bij de ontwikkelaar liggen, liggen de prijzen op basis van de estimates vaak hoger dan bij uurtarief.
Bij een uurtarief moeten er gewoon meer uren gewerkt worden om de bugs op te lossen, dus betaalt de klant meer. Natuurlijk kan de partij die de ontwikkeling doet coulance toepassen, maar dat lijkt me niet verplicht.
[ Bericht 2% gewijzigd door MyOwnSavior op 25-10-2012 13:48:34 (nuancering) ]
Dat ligt helemaal aan de afspraken. Ook bij een fixed price project kun je afspreken dat na goedkeuring van de klant de verantwoordelijkheid van de leverancier eindigt.quote:
Bij fixed-price betaalt de klant een vooraf vastgestelde prijs voor een afgerond product binnen de afgesproken kwaliteitseisen. Als het product hier niet aan doet (bugs), dan moet de ontwikkelaar dit oplossen. Aangzien hierbij alle risico's bij de ontwikkelaar liggen, liggen de prijzen op basis van de estimates vaak hoger dan bij uurtarief.
Alles bij elkaar komt het simpelweg neer op wat er in het contract staat. Als daar een garantie termijn opgenomen is dan is de leverancier gedurende die termijn verantwoordelijk. Is er geen garantie termijn opgenomen dan is de acceptatie van de klant ook meteen décharge.
TS kan op basis van onderhouds-afspraken, of op basis van coulance, het alsnog oplossen, maar dat is geen plicht tenzijn dat in die afspraken is opgenomen. Na een oplevering waar een afname-test een onderdeel van is, is het product geleverd tenzijn er duidelijk sprake is van een wanprestatie van de kant van TS.quote:
[..]
Als de bug tijdens de test niet is gezien of niet gezien had kunnen worden betekend het natuurlijk niet dat je als leverancier totaal geen plichten meer hebt.
Gewoonlijk zit in de prijsstelling van een project verwerkt of er na de acceptatie door de klant nog onderhoud geleverd wordt, en tegen welke prijs. Niet ongebruikelijk is dat de leverancier nog een vooraf bepaalde hoeveelheid aan werk zal leveren om optredende problemen op te lossen, maar daarna zijn wijzigingen rekening klant.
Waar een discussie met een collega al niet toe kan leidenquote:
[..]
In dit geval is er sprake van een formele afname-test, die schriftelijk afgetekend is door de klant. Er is geen sprake van garantie in dit soort gevallen, tenzij dit in de afspraken/contract tussen klant en leverancier is vastgelegd.
Hoe TS hier mee om moet gaan hangt af van :
- de afspraken/contract;
- de tijd/kosten die TS moet maken om het op te lossen;
- de mentaliteit van TS;
- de relatie die TS met de klant heeft en eventueel wil behouden.
Ik dacht dus heel simpel of klant of leverancier.
Ik zei leverancier, want fout kan niet door klant ontdekt worden, dus ook niet geconstateert bij de formele afnametest.
Hij zegt klant, want hij heeft geaccepteerd.
In principe zou je altijd een service-/garantiecontract moeten hebben om dit soort problemen te voorkomen?
Nu vervangen het woord 'leverancier' door een bedrijf. Stel Microsoft.
Je koopt Windows, er zitten bugs in die je niet had kunnen zien en Microsoft vraagt geld voor het herstel / een update. (gelukkig levert Microsoft
Als er door de bugs sprake is van een ondeugdelijk product lijkt me dat TS het moet oplossen, onafhankelijk van wat er uit de afname test is gekomen.quote:
[..]
TS kan op basis van onderhouds-afspraken, of op basis van coulance, het alsnog oplossen, maar dat is geen plicht tenzijn dat in die afspraken is opgenomen. Na een oplevering waar een afname-test een onderdeel van is, is het product geleverd tenzijn er duidelijk sprake is van een wanprestatie van de kant van TS.
Gewoonlijk zit in de prijsstelling van een project verwerkt of er na de acceptatie door de klant nog onderhoud geleverd wordt, en tegen welke prijs. Niet ongebruikelijk is dat de leverancier nog een vooraf bepaalde hoeveelheid aan werk zal leveren om optredende problemen op te lossen, maar daarna zijn wijzigingen rekening klant.
De klant heeft het product in deze vorm geaccepteerd, dus er is geen sprake van "moeten".quote:
[..]
Als er door de bugs sprake is van een ondeugdelijk product lijkt me dat TS het moet oplossen, onafhankelijk van wat er uit de afname test is gekomen.
Als iemand het daar niet mee eens is staat het hem natuurlijk vrij om naar de rechter te stappen, maar die zal terughoudend zijn tenzij er sprake is van grove nalatigheid, wat vaak lastig is hard te maken.
Volgens mij moet het geleverde voldoen aan de verwachtingen die koper er redelijkerwijs van mocht verwachten. Mocht hij redelijkerwijs een bugvrij product verwachten? Of was de test juist wat bepaalde dat het aan de verwachtingen voldeed? Is de test niet verantwoordelijkheid van de afnemer en kun je de gebrekkigheid daarvan om bugs op te sporen aan de leverancier tegenwerpen?quote:
[..]
Als er door de bugs sprake is van een ondeugdelijk product lijkt me dat TS het moet oplossen, onafhankelijk van wat er uit de afname test is gekomen.
Het niet kunnen testen door een klant is niet zo moeilijk.quote:
Hoe kan het dat een klant een onderdeel niet kan testen? Voor elk onderdeel is iemand verantwoordelijk. Diegene zal dan ook moeten betalen om dat onderdeel te fixen. Mocht het een beheer stuk zijn waar alleen TS toegang toe zou moeten hebben is TS dus daar verantwoordelijk voor.
Bijvoorbeeld.
Systeem gebouwd bestaande uit een voorkant voor de gebruiker en een database.
Aan de voorkant werkt alles goed.
Wil je echter iets in de database doen, dan blijkt hier een bug te zitten.
Alleen de leverancier kan bij de database en hoeft hier eigenlijk alleen bij als er problemen zijn.
Of iets niet volgens de specs werkt is soms moeilijk te zeggen, als die specs niet eenduidig zijn. In sommige gevallen kan het onderscheid tussen een "bug" en een "change/feature request" nogal vaag zijn. Daarom is het heel erg belangrijk dat je de features en specs van te voren schriftelijk vastlegt in een technisch en functioneel ontwerp, dan heb je daar achteraf geen nare discussies over.
Maar los daarvan; als je moeilijk gaat doen over het oplossen van problemen kweek je geen klanttevredenheid. Dat kleine beetje extra service kan veel verschil in perceptie maken. Van regelneuken wordt niemand blij.
Het is vaak onmogelijk om een productie-omgeving volledig in een test-omgeving na te spelen. Als het al kan is het vaak onbetaalbaar.quote:
Hoe kan het dat een klant een onderdeel niet kan testen? Voor elk onderdeel is iemand verantwoordelijk. Diegene zal dan ook moeten betalen om dat onderdeel te fixen. Mocht het een beheer stuk zijn waar alleen TS toegang toe zou moeten hebben is TS dus daar verantwoordelijk voor.
Problemen die je ziet zijn vollopende buffers, of performance die niet lineair maar exponentieel afneemt bij veel grotere aantallen.
Dat hangt dus af van de kosten van het oplossen, als je een extern team hebt ingehuurd om het bouw-werk te doen, dan kan het knap lastig worden als dat team niet meer beschikbaar is. En daarom is het zo belangrijk om in een contract ook over onderhoud afspraken te maken.quote:
Een bug is iets dat niet volgens de specs werkt; een fabricagefout, dus m.i. altijd voor rekening van de leverancier.
[quote]
Toch even in de echte wereld terugkeren. Klant heeft getest en geaccepteerd, en daarmee is de formele verantwoordelijkheid van de leverancier ten einde, tenzij er afspraken zijn gemaakt over het oplossen van bugs.
[quote]
Maar los daarvan; als je moeilijk gaat doen over het oplossen van problemen kweek je geen klanttevredenheid. Dat kleine beetje extra service kan veel verschil in perceptie maken. Van regelneuken wordt niemand blij.
it's no bug it's a featurequote:
Stel ik heb een product gemaakt voor een klant.
De klant heeft deze getest en goedgekeurd (schriftelijk).
De klant ontdekt na enige tijd een probleem en na onderzoek kom ik erachter dat er nog meer bugs in het geleverde zit. Deze bugs had de klant zelf niet kunnen vinden tijdens het testen.
Wie moet er dan voor de kosten opdraaien?
De klant, want hij heeft akkoord gegeven?
Ik, want ik heb de bugs zelf niet gevonden?
(dit is dus hypothetisch, want als ik zou programmeren was er slechts 1 bug geweest, het hele product
Dat is Microsoft's antwoordquote:
Zeggen we bij ons op het werk ook altijd. Echter wij maken maatwerk software en soms schieten klanten iets in als bug. Is het een bug lossen we dat gratis op. En stellen we een nieuwe versie ter beschikken voor de klant is het een feature/change request dan gaan ze daar voor betalen als het er asap in moet. Is het iets wat wij denken van dat kunnen andere klanten ook wel gebruiken dan maken we dat voor een Major release. Zonder kosten. En kunnen ze die versie dan krijgen naargelang wat voor contract ze met ons hebben (Onderhoudscontract)quote:
Wij hebben ook te maken met een test/acceptatie bij de klant. In feite moet de klant het product van ons testen op hun station / werkstations en dan een handtekening zetten. Is er daarna iets mis zijn we nooit te beroerd geweest om het naderhand nog op te lossen doormiddel van een patch/ of een EBF (Emergency Bug Fix) versie. Zonder kosten
Want er gaat niks boven een tevreden klant. Kan je alleen maar prospects opleveren van andere afdelingen/klanten
[ Bericht 100% gewijzigd door GodZZila op 25-10-2012 18:58:34 ]
Feit is wel dat gebruikers vaak het verschil niet weten tussen een bug en een change request.quote:
[..]
Zeggen we bij ons op het werk ook altijd. Echter wij maken maatwerk software en soms schieten klanten iets in als bug. Is het een bug lossen we dat gratis op. En stellen we een nieuwe versie ter beschikken voor de klant is het een feature/change request dan gaan ze daar voor betalen als het er asap in moet. Is het iets wat wij denken van dat kunnen andere klanten ook wel gebruiken dan maken we dat voor een Major release. Zonder kosten. En kunnen ze die versie dan krijgen naargelang wat voor contract ze met ons hebben (Onderhoudscontract)
Wij hebben ook te maken met een test/acceptatie bij de klant. In feite moet de klant het product van ons testen op hun station / werkstations en dan een handtekening zetten. Is er daarna iets mis zijn we nooit te beroerd geweest om het naderhand nog op te lossen doormiddel van een patch/ of een EBF (Emergency Bug Fix) versie. Zonder kosten
Want er gaat niks boven een tevreden klant. Kan je alleen maar prospects opleveren van andere afdelingen/klanten
Zo'n bedrijf mag van mij wel met naam genoemd wordenquote:
[..]
Zeggen we bij ons op het werk ook altijd. Echter wij maken maatwerk software en soms schieten klanten iets in als bug. Is het een bug lossen we dat gratis op. En stellen we een nieuwe versie ter beschikken voor de klant is het een feature/change request dan gaan ze daar voor betalen als het er asap in moet. Is het iets wat wij denken van dat kunnen andere klanten ook wel gebruiken dan maken we dat voor een Major release. Zonder kosten. En kunnen ze die versie dan krijgen naargelang wat voor contract ze met ons hebben (Onderhoudscontract)
Wij hebben ook te maken met een test/acceptatie bij de klant. In feite moet de klant het product van ons testen op hun station / werkstations en dan een handtekening zetten. Is er daarna iets mis zijn we nooit te beroerd geweest om het naderhand nog op te lossen doormiddel van een patch/ of een EBF (Emergency Bug Fix) versie. Zonder kosten
Want er gaat niks boven een tevreden klant. Kan je alleen maar prospects opleveren van andere afdelingen/klanten
In mijn voorbeeld kom ik (de ontwikkelaar) achter de bugs, dus de klant hoeft geen verschil te zien.quote:
[..]
Feit is wel dat gebruikers vaak het verschil niet weten tussen een bug en een change request.
Voortbordurend...
Ik zie bugs die de klant niet weet (en misschien nooit zal ontdekken omdat hij niet komt waar ik de bug gevonden heb). Moet ik dat dan aan de klant melden?
Dan is het dus ook geen bug. Als de functionaliteit van de software voor de klant niet in gevaar is, moet je het ook niet gaan aanpassen.quote:
Ik zie bugs die de klant niet weet (en misschien nooit zal ontdekken omdat hij niet komt waar ik de bug gevonden heb).
Dat is ook een oplossing ja.quote:
[..]
Dan is het dus ook geen bug. Als de functionaliteit van de software voor de klant niet in gevaar is, moet je het ook niet gaan aanpassen.
Het is wel een fout, maar de klant zal de fout zelf nooit krijgen, dus het is geen fout
Dat doen we hier maar niet dat is dan reclame.quote:
[..]
Zo'n bedrijf mag van mij wel met naam genoemd worden
Maar kan wel zeggen dat we Facility/Maintenance Management software maken. En in NL alleen hebben we ongeveer 700 Klanten.
Als een bug niet reproduceerbaar is, dan bestaat de bug niet. WONTFIX!quote:
[..]
Dat is ook een oplossing ja.
Het is wel een fout, maar de klant zal de fout zelf nooit krijgen, dus het is geen fout
En ondertussen mis je de deadline en betaal je daarvoor weer een boete..quote:
Als zij meer uren moeten betalen voor onderhoud en updates etc omdat die bugs het proces langer laten duren, lijkt het me dat je het moet fixen. Ook al komt de klant de bugs zelf niet tegen.
Klopt. Als een probleem zich maar één keer voordoet dan heet dat een Incident en wordt alleen gezorgd dat er na dat incident doorgewerkt kan wordne.quote:
Als een bug niet reproduceerbaar is, dan bestaat de bug niet. WONTFIX!
Als een probleem zich 3 keer voordoet is het pas echt een issue in de software en moet het opgelost worden.
Ergo: Als iets niet reproduceerbaar is, is het waarschijnlijk PEBCAK of een data issue veroorzaakt door PEBCAK. Helaas kun je dat niet oplossen.
Ja dan wel he!quote:
Maar stel je nou maar eens voor, dat het niet hypothetisch was.
Feature requests ga je natuurlijk niet gratis doen.
Wat een onzinquote:
[..]
Klopt. Als een probleem zich maar één keer voordoet dan heet dat een Incident en wordt alleen gezorgd dat er na dat incident doorgewerkt kan wordne.
Als een probleem zich 3 keer voordoet is het pas echt een issue in de software en moet het opgelost worden.
Ergo: Als iets niet reproduceerbaar is, is het waarschijnlijk PEBCAK of een data issue veroorzaakt door PEBCAK. Helaas kun je dat niet oplossen.
Programmeur zeker?
Nope, 15 jaar ervaring in service coördinatie. Het is niet voor niets dat ITIL dit ook zegt.quote:Op maandag 29 oktober 2012 08:14 schreef Kapt-Ruigbaard het volgende:
Wat een onzin
Programmeur zeker?
Je kunt het onzin noemen maar de praktijk liegt niet.
Ik zou zeggen dat je bij een incident het incident oplost dan wel een workaround biedt, indien je het incident niet kunt reproduceren. Als het zich vaker voordoet zonder oplossing/workaround dan spreek je over een problem, en verdiend dat extra aandacht.quote:
[..]
Klopt. Als een probleem zich maar één keer voordoet dan heet dat een Incident en wordt alleen gezorgd dat er na dat incident doorgewerkt kan wordne.
Als een probleem zich 3 keer voordoet is het pas echt een issue in de software en moet het opgelost worden.
Ergo: Als iets niet reproduceerbaar is, is het waarschijnlijk PEBCAK of een data issue veroorzaakt door PEBCAK. Helaas kun je dat niet oplossen.
Maar, het kan ook zijn dat een incident zich meerdere keren voordoet omdat de klant foutieve handelingen uitvoert. Dus, dan is of de opleiding niet duidelijk geweest, de werkinstructie niet duidelijk geweest of de klant is gewoon koppig. In al die gevallen is er nog steeds geen sprake van een fout in de software hoor.
Exact. De oplossing of workaround is in dat geval vaak eerstelijns werk.quote:
Ik zou zeggen dat je bij een incident het incident oplost dan wel een workaround biedt, indien je het incident niet kunt reproduceren. Als het zich vaker voordoet zonder oplossing/workaround dan spreek je over een problem, en verdiend dat extra aandacht.
Ook eensch. Ook een werkinstructie is een probleem van de aanleverende partij (hoewel niet altijd de software bouwers). Valt weliswaar onder PEBCAK maar kan de verantwoordelijkheid zijn van iemand anders dan het probleem.quote:Maar, het kan ook zijn dat een incident zich meerdere keren voordoet omdat de klant foutieve handelingen uitvoert. Dus, dan is of de opleiding niet duidelijk geweest, de werkinstructie niet duidelijk geweest of de klant is gewoon koppig. In al die gevallen is er nog steeds geen sprake van een fout in de software hoor.