![]() |
Om man köper kodning och betalar per timme så är det givetvis så att man betalar lite för att programmeraren letar fel i sin egen kod i viss mån. Ingen gör väl 100% helt rätt precis hela tiden. Det ingår ju liksom. Oftast är det så små saker att de knappast ens märks tidsmässigt.
Men om det dyker upp en bugg och programmeraren inte hittar den utan lägger ner timme efter timme på att leta efter felet, var går gränsen? Hur mycket felsökningstid är det rimligt att betala för egentligen? |
Oj, det var en svår fråga. Köper du timme så är det per timme du betalar oavsett hur lång tid programmeraren håller på men jag förstår dilemmat. I såna här lägen är ett avtal bra att kunna luta sig mot där det är reglerat hur mycket tid som är avsatt för just avlusning men det förutsätter att du inte anställt programmeraren. Själv brukar jag sätta en gräns att om jag inte hittat felet på två timmar så blir det till att arbeta runt det. Är det ett fel jag själv gjort (t.ex. tankevurpa) så brukar jag inte ta betalt för det. Är det en brist i logiken (det överenskomna flödet) eller fel hos tredje part (webbhotell, sqlbugg osv.) så tar jag fullt betalt.
|
En vettig utvecklare bör åtminstone kontakta dig efter ett par timmars fruktlös felsökning för att stämma av.
|
Jag köper aldrig kodning per timme när jag anlitar någon annan, php kod skriver jag iofs själv, men när det gäller grafik osv så betalar jag per job och sedan per modifikation, fast pris. Men om du betalar per timme och inte per job, så har du ju inte redan betalat för att han skall fixa sina buggar, så då är det nog bara att betala. Sen kan man ju ifrågasätta hur buggig kod man får skriva.. men då får man väll byta till någon annan nästa gång.
|
Ja, visst sjunker chanserna att man kommer tillbaka. Men det är ju alltid bekvämast att anlita samma person, eftersom det är denne som skrivit koden från början och således inte behöver sätta sig in i kod som någon annan skrivit.
Det är ju just det att man blir lite grinig tillslut när det blir dyrt, eftersom det är han själv som är orsaken till felet. Man har ju lite mer överseende för att det kan vara svårt att hitta ett fel i någon annans kod. Fast å andra sidan är det kanske inte så, man blir hemmablind också. Det ska sägas att det är en åtminstone relativt duktig och erfaren person det handlar om, det är ingen nykläckt som inte lämnat källaren ännu. |
Jag skall ge support på egen-skriven kod. Du som kund har ju betalat (antaligen ;)) för en funktion som skall fungera. Du betalar inte för buggar.
Sedan om buggarna beror på att det är någon felinställning på servern så är det inte nödvändigtvis utvecklarens fel, så i det fallet borde han/hon få betalt för den upplupen tid att få det fixat hos webbhotellet/servern. |
Citat:
|
Citat:
|
Vid sådana här fall kan det vara bra att ha en "extra" programmerare som bollplank åt orginal-programmeraren. Köp en timmes konsulttid av din "extra" programmerare och få ett utlåtande av honom.
|
Det har tidigare talats om att när man skall leverera kod till en kund så brukar man beräkna tidsåtgången som att 30% av tiden går åt till att utveckla och 70% går åt till att buggtesta och fixa.
|
Citat:
Ibland meckar jag lite själv, bland annat fick jag hybris igårkväll och trodde att jag kunde. Men jag ska nog hålla mig till text och bilder för imorse var inkorgen full med mail från kunder som inte kunde beställa... :blink: Så det var bara att ladda upp de gamla filerna igen. Har dock inget med den aktuella buggen att göra. I det här fallet handlade det om en funktion som tillsynes fungerade utmärkt, men defacto fungerar ibland och ibland inte. |
Citat:
|
Om koden är någorlunda vettigt skriven och kommenterad tar det inte lång tid att sätta sig in i dom delar som behövs. För att felsöka en del av koden behöver man oftast inte sätta sig in i hur allt är uppbyggt.
Det viktiga är en så utförlig felbeskrivning som möjligt. Kan man återskapa felet går det ofta ganska fort att hitta felkällan även om man aldrig sett koden innan. Om det är väldigt rörig och oorganiserad kod tar det självklart längre tid. |
Citat:
|
Det är en lite klurig situation du sitter i.
Nu vet jag inte vad din programmerare har sagt till dig om hur buggen skall fixas men jag vet med erfarenhet att buggar som är kluriga och tillsynes helt oförklarliga inte direkt hamnar långt upp på prioritetslistan - och som du själv säger, buggen uppstår bara ibland / sällan. MEN: I mitt tycke skall programmeraren i alla fall kolla på buggen, beräkna tid att fixa den, och sedan prata med dig om ett konstnaddsförslag. OM: Det handlar om PHP och MySQL kan jag bidra med att titta på / analysera buggen utan kostnad (utan restriktioner för när det ska vara gjort/klart). EDIT: Stavning. |
Du har väl köpt funktioner som skall utvecklas?
Om funktionen inte fungerar som den skall så skall det åtgärdas. Egentligen börjar du i fel ända, dvs att du borde ha specat när du köpte utveckling hur eventuella fel skulle åtgärdas. Men det är för sent nu. Jag tycker inte att du skall betala extra för felsökningstid alls. Det är inte ditt problem. |
Det är svårt med buggar, sitter själv och felsöker och rättar sådana då och då. Generellt så tycker jag man inte alls kan ta betalt för felsökningen, om det inte i slutänden visar sig vara kunden som är orsaken, eller en tredjepartare. Det kan t. ex vara att kunden ändrat arbetsrutiner eller avviker från det tänkta flödet, ändringar i något tredjepartsprogram eller något sådant.
Är det rena felaktigheter i min kod så får jag se till att rätta detta, utan att det ska behöva drabba kunden. Extra svårt är det givetvis med luddiga buggar, som kanske inte ens kan återskapas. Min grundregel är att jag ger det en halvtimme till att börja med för att återskapa felet, men om inte det låter sig göras får jag höra av mig till kunden och diskutera hur vi går vidare. |
Det har jag råkat ut för som beställare och efter att jag gjorde klart för honom att hans offert gällde en fungerande lösning så var det slut med att debitera buggfixtid.
Ändringar i efterhand är en annan sak, så det gäller att hålla käften som beställare. Annars kan det bli dyrt. |
Jag jobbar som utvecklare och jag tycker att man självklart till en viss mån (2-3timmar kanske) kan fixa buggar i efterhand. Men när kunden har testat och godkänt leverans så är systemet levererat i sitt befintliga skick. System och miljö ändras ju efterhand och de förutsättningar som gällde innan kanske inte gäller längre. Man kan ju inte sitta och ge gratis support för ett system hela livet heller. Även utvecklare behöver ha mat på bordet :) Du säger att du går in och grejar själv i koden, även fast du inte har de kunskaperna, det är inte ett beteende som får en att ha dig som drömkund precis :)
Den som är beställare har en väldigt stor roll i hur bra systemet blir. Skriver du ingen vidare kravspec eller testar av leveranser så blir det ofta inte så bra. |
Nja, om jag grejar i koden själv så kör han alltid en jämförelse och kollar mina ändringar, så det är aldrig något problem. Det är bara pluttgrejer jag gör egentligen flyttar lite saker och så. Igår tog jag bort faxinfo ifrån kunduppgifterna. Vad ska vi med deras faxnummer till, det är bara onödigt. Så hade jag missat en detalj som gjorde att det sket sig med databasen.
Sedan är det förmodligen så att ni föreställer er att det är ett mycket större system än vad det är. Jag skulle kunna räkna upp precis alla filer som ingår, och säga vilken fil som innehöll vad. Därför är buggen ännu mer oförklarlig... Det är inte större än så. Det kommer inte bli någon konflikt angående detta, jag tyckte mest att det var en intressant diskussion. För övrigt är jag en drömkund :D , eftersom jag förstår vad han pratar om och anpassar mina önskemål efter hur koden redan ser ut. |
Det är en intressant diskussion helt klart. Detta är saker man måste brottas med dagligen. Självklart vill man ha en sån bra och ärlig relation med sin kund och om du har så pass bra koll och dessutom vet när det är du som gjort fel och inte skyller allt på leverantören så visst, du är inte helt långt ifrån drömkund då :)
|
Det bästa ni kan göra i det här läget är som någon föreslog tidigare att köpa några timmar av en programmerare som inte varit inblandad tidigare. Köp 3-4 timmar först och gör en avstämning sen.
Det är lätt hänt att man tänker i stil med "det där fungerade tidigare, så där kan det inte vara". Det gör inte någon som inte varit med tidigare. Om systemet inte är speciellt stort tar det dessutom inte lång tid för en erfaren programmerare att sätta sig in i det. |
Citat:
Jag får nog göra som du och flera andra talat om och ringa Erik och Homa som är de enda andra kodare i Gbg jag känner lite. Hänger ni här på WN, grabbar? |
Jag gillar produkt/support-uppbygget. Man köper in produkten och sen skaffar supportavtal med utvecklaren alá du pyntar 2,000 kr per månad kanske mot att han åtar sig att fixa alla buggar under tiden du har supportavtal med honom.
|
Alla tider är GMT +2. Klockan är nu 22:15. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson