Bliv gratis medlem
|
Jeg vil gerne støtte op om det første indlæg, Jeg havde skrevet en kransspek., som jeg har brugt lang tid på (møder, uddannelse , læsning, andres kommentarer, en masse møder og gennemgang), og så sidder jeg lige nu med én programør, som jeg har holdt rigtigt mange møder med for at forklare hele konceptet, bl.a at min målgruppe udelukkende forstår dansk. Nu får alle mine brugere teksten på engelsk. Det skrev jeg til ham. Jeg måtte sidde, mens teksten ligger live på siden og oversætte hvad han havde sat op. Og fik en regning på at rettet det. (det står skrevet i karavsspek., at det skal være på dansk) Uden at han kunne give mig al den teksten på forhånd. Jeg fik bare lov til at oplevet det live.... Selv om jeg tiggende og bad i mail efter mail. om at han sendte det – på forhånd og inden for aftale. Og nej, det var ikke billigt. Det er til fuld pris. Jeg har fået en ekstra-regning på at han skulle up-loade sitet. Det havde taget ham en time, at se filer uplodes, mens han drak kaffe. Og så dag jeg bare på regningen og tænkte – WHAT – jeg har lavet små 15 hjemmesider, før han kom på banen. Og sådan kører festen... Og ja, det er to forskellige virkeligheder som mødes. Og nej, ingen skal arbejde gratis. Heller ikke jeg. Og jeg tager fuldt ansvar for hvad jeg har bedt om, Og brugt timer hver dag på at følge op på kode, opsætning etc. – og så få ekstra regning på fejlrettelser. F.eks. MIG: ”Det der står at, det er med i kravssk.- Det er ikke lavet” – ” BingBong: ”Det er fikset og jeg sender lige en regning”. Men efterfølgende at spørge andre programmøre og få at vide” du har købt et IKEA-møbel til ILUM-pris”. Jeg havde tjekket referater inden, jeg har holdt møder, jeg har fa...de gennemgået den kravssepk, så selv jeg blev træt – og nu sidder jeg med et båthorn. Flot - flag til mig, vil I sikkert sige.. |
Hvad gør man med en dårlig programmør..?
|
Selvfølgeligt skal programmører leve op til deres kontrakter, det kan der vel ikke være så meget tvivl om. Men det er jo helle ikke det som denne tråd handler om. Problemet her er at der har været en forventning om en fleksibilitet til en programmør som han, af en eller anden grund ikke kan leve op til. Peder |
Hej Happypie, Jeg vil ikke give dig ret i at tonen er sur på amino.dk, der er nogle der engang imellem får revet lidt af sig i en fart - men det går som regel hurtigt over igen. At du har en ret dårlig oplevelse med i bagagen omkring en opgave der ikke er løst som aftalt, er de lærepenge vi alle kommer til at betale undervejs. Nogle betaler lidt og andre som dig betaler noget mere. Der er kun en vej når du har løst problemet med aftalebryderen - kom videre og vær lidt mere på dupperne næste gang. Med venlig hilsen Lars C |
|
Ud fra mine erfaringer, er det den bedste måde at gøre tingene på. |
Hej Martin E. Jensen Betal ALDRIG en programmør forud! Er systemet stort og strækker sig over lang tid, så kan betaling i rater måske være rimeligt, men Du skal først betale hver rate, når det programmøren har lovet virker som aftalt Det virker på mig som, at Du relativt tidligt i forløbet kunne have opdaget at den pågældende programmør ikke kunne følge opgaven til dørs. Det bør stå i kontrakten at hvis ikke programmøren leverer hver dellevering rettidigt og med den aftalte funktionalitet, så har Du ret til at opsige aftalen og finde en anden programmør. I kontrakten skal der også stå at kunden har rettighederne til kildekoden, også selvom en aftale opsiges underrvejs pga. misligholdelse fra programmørens side.
Hej Niklái En vigtig pointe Du fik med der, jeg er 100% enig, en specifikation består ikke kun af et dokument hvor der står skrevet med ord hvad et special programmeret system skal kunne, der skal også være et komplet sæt af mockups (Prototype skærmbilleder). Designeren og kunden forstår langt bedre hvad systemet ender med at skulle kunne hvis de kan se mockups kombineret med beskrivelserne. Jeg har netop aflevert en større specialløsning til en kunde hvor processen forløb således
mockups i denne situation var et meget stærkt værktøj til at undgå misforståelser. Systemet endte med at være til kundens 100% tilfredshed med hele forløbt og med 98% tilfredshed vedr. systemets funktionalitet. Der var en enkelt detalje, som de først fik øje på, da systemet kom i drift, men det ligger udenfor kontrakten, og er derfor en ny og særskilt opgave. Da det ikke er med i kontrakten, har kunden ikke kunne "påstå", at dette skulle med i den første version af det system de har fået leveret. Ved udvikling af software bør man få lavet en komplet specifikation inkl. mockups og den bør være grundlaget for den aftale som kunde/designer/programmør indgår, så ved kunden hvad han får og programmør/designer ved hvad de skal levere. Ja det er ofte meget meget kedeligt og tungt arbejde, men det er nødvendigt for at komme helt i mål med en tilfreds kunde.
Hej Mikkel Super ide, tak for "tippet", den vil jeg putte i min "værktøjskasse"! /Grosen Friis |
SEO konsulent og partner hos OnlinePartners.dk
|
Tja, nu kender jeg jo hverken den ene eller anden part i denne strid, men rent erfaringsmæssigt, så ligger ansvaret for sådanne problemer meget sjældent ved den ene part alene. Kravsspecifikationer har altid været genstand for mange stridigheder, "religionskrige" m.m. Den grundlæggende årsag er, at to forskellige personer næsten altid læser (forstår) den samme tekst forskelligt. Navnligt hvis parterne har forskellig baggrund, så er der grundlag for misforståelser, fordi det der er helt naturligt / selvfølgeligt for den ene part, ikke er det for den anden. Så hvem er den dumme? Er det ham der ikke formår at udtrykke sig eksplicit, når han fremstiller sine krav/ønsker, eller er det den der spørger til hvad der skal laves, som ikke formår at stille de rigtige spørgsmål? Jeg ikke rigtig at der nogensinde er nogen der har fundet ud af, og det sker nok heller ikke, hvis du spørger mig. Det eneste jeg kan garantere dig er, at dette sker i 99% af alle softwareprojekter - en ringe trøst, jeg ved det. Men.... jeg vil dog sige, at den gode leverandør vil tage højde for, at der vil være mindre tilrettelser undervejs, og indregne dette i prisen. Dog kan ingen tage højde for alt, der er altid noget der bliver glemt. Både af kunde og leverandør. I de tilfælde, hvor det drejer sig om mere omfattende ting, så plejer man at enes om at tilføje opgaven til kravsspecifikationen, imod en merbetaling. Denne betaling behøver ikke nødvendigvis, at være fuld pris, navnligt hvis leverandøreren erkender at have en del af ansvaret for forglemmelsen. Hvis forhandlingens vej ikke fungerer, så er der nok ikke meget andet at gøre end at finde en programmør, som man arbejder bedre sammen med, og helst inden man ender på en økonomisk glidebane a la CSCs "Amanda", og hvad har vi. Men hold dig til at bruge "guleroden" og smid "stokken" væk, den vi ikke bringe dig noget godt, og spiller det ikke, så må du finde dig en anden programmør :-) .... og en hurtig genvej... Hvis du er så "heldig" at have en fejlfri programmør, altså en der aldrig laver fejl eller glemmer noget, så glem alt hvad jeg har skrevet til nu, og find en anden programmør med det samme. (Jeg er selv udvikler så, jeg må godt sige sådan noget :-) ) |
|
Hej David, Har sendt dig en PB og en mail |
|
Hej David Hvis programmøren får betaling for sit arbejde, så er jeg sikker på at han gerne vil lave alle de ændringer du vil have. PS: PHP er ikke kun for nybegyndere, man må ikke undervurdere det kommer man galt afsted med. PHP kan løse meget komplekse opgaver. Det er som regel dem der ikke ved noget der tror at alle andre er dumme. Ralph |
Opret bruger