Fout in mijn gemaakte opdracht...

[Remy]

Ik zie de fout ook niet ontstaan..

Ik heb wel verstand van AS2 (AS3 moet ik toch echt binnenkort eens gaan leren..), dus als je de code naar me kan PM'en, wil ik er wel even naar kijken.

[mvds]

Het is inmiddels 3 maanden na de laatste post in dit topic, maar als nieuwbakken member vind ik het toch leuk hier nog wat aan toe te voegen, omdat het zo'n lastig onderwerp is, en omdat ik mijn visie niet teruggelezen heb.

(en ik ben ook wel een beetje benieuwd of en hoe de kwestie is opgelost...)

Ik ben ook werkzaam als freelancer in de it. En soms bouw je iets waar later een bug in blijkt te zitten. In het begin had ik soms moeite met de vraag of ik uren hiervoor in rekening kon brengen of niet.

Je gevoel zegt: je eigen bug, jouw probleem. Maar ik ben er later anders over gaan denken. Ik werk X uur en lever iets af wat ik in X uur heb kunnen maken. Als het perfect en bug-vrij moest zijn, had ik er wel 2*X uur ingestoken om niet voor verrassingen komen te staan. Economisch gezien moet je klant blij zijn dat jij een "bijna perfect" product levert in X uur. Als er later 10% extra tijd/kosten bij komt, omdat pas in dagelijks/normaal gebruik een bug naar voren komt, dan is dat voor de klant nog steeds voordelig. Het kost onevenredig veel tijd om als (freelance) ontwikkelaar steeds uitvoerig "normaal gebruik" (op elke browser en elk platform) te simuleren voordat iets online kan - tenzij je dit afspreekt.

Een en ander hangt natuurlijk helemaal af van hoe je je opdrachten afspreekt. Per project of per uur, met of zonder een toetsmoment waarop de klant zegt "ja het is klaar, ik ben tevreden", in- of exclusief bugfixes, etc.

Ik spreek bij projectmatig werk meestal af dat "kleine bugfixes" inbegrepen zijn. Dat kan je later in goed overleg nog wel invullen. Bij uurtje factuurtje kijk ik zelf wat ik redelijk vind. Als het een extreem domme/genante fout van mezelf is, fix ik het zelf. Als het een systematische denkfout is in het systeem wat ik samen met de klant heb uitgedacht, dan reken ik wel.

Je moet ook niet te aardig willen zijn, je bent gewoon zakelijk bezig. Terugbetalen omdat het niet 100% is, gaat veel te ver. Het is business-to-business en ook nog eens custom built (AS2 was ook niet jouw eigen keuze begrijp ik), wat betekent dat het niet te vergelijken is met een consumentenkoop of de aanschaf van een standaardprodukt als een computer. Je moet je ook afvragen of je een produkt of een dienst levert - ik zou zeggen het laatste.

Belangrijkste les is denk ik dat je bij het aangaan van een opdracht zulke dingen voor jezelf bedenkt, en zo nodig communiceert. Hoeft echt niet in een contract of algemene voorwaarden, gewoon over mailen is vaak al genoeg.

En ik vind het overigens een prima oplossing als je op basis van no-cure no-pay ergens 50 euro's uitlooft voor de oplossing. Als ik zelf iets van AS2 had geweten was ik er direct ingedoken - de meeste it'ers laten de kans om in 1 minuut 50 euro te verdienen (of zich te bewijzen tegenover een evt. nieuwe opdrachtgever) niet liggen!

[Rub3n]

Ik vind de laatste post erg raar.

Je moet een product gewoon 100% goed afleveren. Daar ben ik het volledig mee eens met de topic starter!

[nancy_kelpie]

Het blijft een lastige vraag... nu maak ik alleen nog tekeningen en animaties en laat dus iemand anders de code doen. In tekeningen en animaties kunnen niet echt "bugs" zit en hoeveel correctie rondes ik doe staat in het contract. Ik heb er dus niet meer echt mee te maken.

Ik snap wel waarom je er extra geld voor zou vragen, maar als ik een freelancer inhuur voor code (wat ik vaak doe voor computergames waarbij ik wel de tekeningen/animaties maak), en hij zou geld voor bugs vragen zou ik wel boos worden. Ik heb dan immers al een offerte aan de klant gegeven en moet dan doorgeven dat het duurder word terwijl ik daar zelf ook niet achter sta Ik blijf er dus bij dat het gewoon goed moet wezen.

Als je er geld voor wil kan je beter bij de 1e offerte de prijs iets ruimer schatten. Je belazerd de klant dan niet, dat extra uurtje (uren bij groter project) gebruik je om de klant het helemaal naar de wens te maken. Dat kunnen bugs zijn, maar als er geen bugs zijn ook het project zelf fine-tunen, tijd maken om met de klant mee te denken, etc. Voor grote/moeilijke/nieuwe projecten plan je daar iets meer tijd voor in dan bij makkelijke projecten. Dat is nu mijn oplossing en vind ik professioneler dan achteraf meer geld vragen.

Hoe het trouwens is afgelopen:
Ik ben achter de fout gekomen en de fout bleek in de opzet van de website te zitten. De opzet van de website had de opdrachtgever gemaakt, dus niet echt mijn schuld. (al had ik misschien van te voren moeten controleren of de aangeleverde website geschikt was voor wat ik ging maken). Ik heb haar wel uitgelegd hoe ze het kon oplossen.

Toen vertelde echter de opdrachtgever dat de uiteindelijke klant de "bug" eigenlijk niet erg vond. Het was meer dat de opdrachtgever het toevallig merkte. Zo had ik het verhaal nog niet opgevat, dus goed communiceren kan ook een hoop helpen. De opdrachtgever heeft het volgens mij niet veranderd (zou ook een hoop werk zijn), en ook al heb ik nog geen nieuwe opdrachten van haar, ik spreek haar nog wel en volgens mij is het wel goed opgelost.

[ramon fincken]

Oorspronkelijk geplaatst door Rub3n

Ik vind de laatste post erg raar.

Je moet een product gewoon 100% goed afleveren. Daar ben ik het volledig mee eens met de topic starter!

Dat kan alleen als je alle (use-)cases goed doorloopt, continue test en aan stresstesting doet. Erg lastig dus.

Mijn support is altijd gratis, echte bugs komen zelden voor.

[mvds]

Oorspronkelijk geplaatst door Rub3n

Ik vind de laatste post erg raar.

Je moet een product gewoon 100% goed afleveren. Daar ben ik het volledig mee eens met de topic starter!

Daar ben ik het ook mee eens (hoewel 100% goed niet bestaat - wijs mij 1 stuk software aan zonder fouten in versie 1.00, zelfs voor OpenSSH gold dat niet!), mits je het als project hebt aangenomen voor een fixed fee. Als je een offerte doet voor een geschat aantal uren, en achteraf de werkelijke uren afrekent, kan het best gebeuren dat later alsnog een bug opduikt. In dat geval vind ik dat je je extra uren best mag rekenen. Waarom moet dat jouw risico zijn?

De vorm waarin je je afspraken hebt gemaakt (die topic starter onvermeld laat), bepaalt natuurlijk voor een groot deel welke risico's bij wie liggen. Techneuten (waaronder it'ers) leggen m.i. de schuld te snel bij zichzelf, ik vermoed uit een soort eergevoel. Aan het andere eind van het spectrum heb je juristen, die daar doorgaans veel minder moeite mee hebben.

Verder ben ik van mening dat hier geen sprake is van een product, maar van een dienst, temeer daar het mede gaat om het inbouwen in een bestaande site en het een eenmalig project is. Dat maakt het ook anders.

De uiteindelijke oorzaak en oplossing van de bug wijzen erop dat het allemaal volledig buiten de invloed van opdrachtnemer lag. In dat licht moet je er toch niet aan denken dat je het hele bedrag had teruggeboekt! Zelfs als je fixed fee te werk bent gegaan zou je in theorie nog kunnen naberekenen, omdat je een probleem hebt opgelost dat niet het jouwe was (hoewel dat weer af te raden is ivm de goede verhoudingen )

[edit: en in reactie op ramon fincken: gratis support is mooi, maar daar moet je denk ik wel rekening mee houden in je prijsstelling. Bovendien gaat zo'n regel denk ik niet in alle gevallen op, even extreem gesteld: als je een klant in korte tijd erg gelukkig maakt met een hele eenvoudige quick fix van 1 uur werk, en later blijkt het toch wat complexer te liggen en moet je er reeel gezien toch 10 uur in steken, dan hoeft dat toch niet gratis?]

[jesse]

Ik vind dat Rub3en toch nog gelijk heeft.
Je dienst of product moet gewoonweg goed zijn! Het siert Nancy alleen maar dat zij zich direct zelf verantwoordelijk voelt om het probleem op te lossen, ook al lag de schuld niet bij haar.

De klant zal dat extra waarderen en dat zal zeker meer werk kunnen opleveren. Bovendien zal het haar geen windeieren leggen want de service die zij geeft is heel klantgericht en dat kan deze klant nu alleen maar beamen. Weer een goede ambassadeur erbij.

P.S. ik schrijf voor het gemak zij maar mocht je een hij zijn dan kan je hij/hem invullen.

[ramon fincken]

Nou het probleem is dat "goed" nogal relatief is mbt scripting ..

als iets werkt is het niet per definitie goed

en als je tests allemaal slagen is het ook niet per definitie goed ..

[jesse]

Dat is uiteraard ook van toepassing op andere diensten.

Ik kan ook niemand garanderen dat hij/zij meer omzet gaat genereren als hij/zij mijn communicatieadvies volgt. Een klant mag wel verwachten dat je je best doet om hem/haar tegemoet te komen als iets echt niet werkt.

In mijn geval zou dat zijn dat als ik bijvoorbeeld een brochure ontwikkel; het foutloos geschreven is, dat de info naar tevredenheid van de opdrachtgever is. En dat het past bij het imago/huisstijl van de klant, etc.

[mvds]

En nu zijn we denk ik bij de kern van de zaak: een brochure kan 100% "af" zijn. Een server-side script, waarbij je volledige controle hebt over de server (geen shared hosting, maar dedicated en in eigen beheer), kan je misschien 99% goed krijgen - er zitten bugs in bijv. php zelf waar je gewoon niet zo snel achter komt(*), of je loopt tegen vage bugs in bijvoorbeeld IE aan. Bij shared hosting kom je moeilijk aan 90% goed ivm onvrijwillige upgrades van webserver, database, libraries e.d., en begin je aan client side scripting (javascript e.d.) dan is het hek van de dam - zoveel browsers zoveel talen. Doe je dat ook nog eens in een obscure omgeving (ik noem AS2) dan valt er weinig te garanderen.

De "het moet gewoon goed zijn" reacties miskennen dat software-ontwikkeling zo complex kan zijn. Ik leg mijn klanten altijd duidelijk uit hoe eea zit, met plezier licht ik ook de ins en outs toe van programmeren en voorkomende bugs. Klanten vinden het interessant om aan te horen (hoewel ze het misschien nauwelijks volgen) en krijgen het gevoel dat ik het beste met ze voor heb, dat ik terzake deskundig ben en dat ik ze niet belazer maar ook geen charitatieve instelling ben. En dat pakt zowel op korte als lange termijn prima uit.



(*) voor de duidelijkheid: dan heb ik het dus niet over programmeerfouten in het php script, maar bugs waardoor php botweg crasht als je het net te ingewikkeld maakt. Onlangs zelf nog aan de stok gehad met o.a. preg_match() en libcurl - niks geen foutmelding, maar pats boem apache dood.