WGR Werk, Geldzaken, Recht en de Beurs
Hier kun je alles kwijt over sollicitaties, werksituaties, belastingen, (handelen op) de beurs, hypotheken, beleggingen en salarissen, arbeidscontracten of geschillen met je (huis)baas. Alles over werk, geldzaken en recht dus.
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
)
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
)
...de klant betaalt, want opgeleverd.
Maar stel je nou maar eens voor, dat het niet hypothetisch was.
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.
Sam the American Eagle : You, sir, are a demented, sick, degenerate, barbaric, naughty freako!
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
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.
"We are all atheists about most of the gods that humanity has ever believed in. Some of us just go one god further." - Richard Dawkins
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.
"We are all atheists about most of the gods that humanity has ever believed in. Some of us just go one god further." - Richard Dawkins
Waar ik werk ligt het er aan of het een fixed-price project is, of op uurtarief.
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) ]
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.
Sam the American Eagle : You, sir, are a demented, sick, degenerate, barbaric, naughty freako!
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
ligt aan de hypothetiesche afspraken die je hierover hypothetisch hebt gemaakt.
Trots lid van het 👿 Duivelse Viertal 👿
Een gedicht over Maanvis
Het ONZ / [KAMT] Kennis- en Adviescentrum Maanvis Topics , voor al je vragen over mijn topiques!
Een gedicht over Maanvis
Het ONZ / [KAMT] Kennis- en Adviescentrum Maanvis Topics , voor al je vragen over mijn topiques!
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.
"We are all atheists about most of the gods that humanity has ever believed in. Some of us just go one god further." - Richard Dawkins
Als je in de toekomst klanten wilt houden dan los je dit op, ookal ben je eigenlijk ontslagen van alle verantwoordelijkheid.
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.
Sam the American Eagle : You, sir, are a demented, sick, degenerate, barbaric, naughty freako!
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
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.
Hangt van de gemaakte afspraken in het contract af. Alles mag. Een garantietermijn komt vaak voor. Uurtje-factuurtje (dus bijbetalen voor bugs!) ook. Het is vaak een politiek spelletje natuurlijk. Hoe beter de eisen en afspraken zijn vastgelegd, hoe makkelijker het voor partijen is om te bepalen wie de lul is bij een bepaalde bug.
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.
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.
Ik in een aantal worden omschreven: Ondernemend | Moedig | Stout | Lief | Positief | Intuïtief | Communicatief | Humor | Creatief | Spontaan | Open | Sociaal | Vrolijk | Organisator | Pro-actief | Meedenkend | Levensgenieter | Spiritueel
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.
Wees gehoorzaam. Alleen samen krijgen we de vrijheid eronder.
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.
Een bug is iets dat niet volgens de specs werkt; een fabricagefout, dus m.i. altijd voor rekening van de leverancier.
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.
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.
Sam the American Eagle : You, sir, are a demented, sick, degenerate, barbaric, naughty freako!
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
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.
Sam the American Eagle : You, sir, are a demented, sick, degenerate, barbaric, naughty freako!
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
Alice Cooper : Why, thank you!
Sam the American Eagle : Freakos: One. Civilization: Zero.
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
|
|
