Hvad gør man med en dårlig programmør..? - Side 4 - Amino.dk
på Amino
Bliv gratis medlem på Amino
 

Køb et Amino Sponsorlink

 

Nye ekspertblog-indlæg
om  Administration & Finansiering

Læs flere ekspertindlæg
 

Top karmaliste (30 dage)

De flinkeste Amino’er der hjælper mest med "Diverse administration hjælp "

 

Hvad gør man med en dårlig programmør..?

Side 4 ud af 4 (39 indlæg) < Forrige 1 2 3 4
Amino-karma 153
Tilmeldt 6. apr 05
Indlæg ialt: 40

Happypie
Skrevet 08-02-2007 kl. 23:08
Jeg har været med fra starten herinde – og er daglig læser, men ikke så meget for at skrive, fordi jeg oplever så sur en tone herinde. Uanset hvad folk skriver herinde - af deres tanker. meninger og overvejelser.

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..


Amino-karma 5.944
Fra Klostertorvet 6, 2. tv 8000 Århus C
Tilmeldt 31. maj 06
Indlæg ialt: 1.541

Peder TakeTwo.dk
Skrevet 08-02-2007 kl. 23:21
Selvfølgeligt er der også dårlige programmører, og når du nu har en kravsspecifikation (og en kontrakt, vel?) og du ikke har fået den aftalte ydelse. Så må man jo bare tage sagen gennem de dertilrettede kanaler, tilbageholdning af betaling, domstole eller hvad der nu lige er.
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

Amino-karma 2.155
Tilmeldt 17. aug 05
Indlæg ialt: 577

Lars C
Skrevet 08-02-2007 kl. 23:32
Dato: 08-02-2007 23:07:35 Forfatter: Happypie Jeg har været med fra starten herinde – og er daglig læser, men ikke så meget for at skrive, fordi jeg oplever så sur en tone herinde. Uanset hvad folk skriver herinde - af deres tanker. meninger og overvejelser. (snip)
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..



 

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


Amino-karma 1.581
Tilmeldt 28. mar 05
Indlæg ialt: 410

Niklái
Skrevet 09-02-2007 kl. 11:54
Før en programmør starter, skal hele designet være lavet. Hvis designeren er i tvivl om tekniske ting under design processen, taler han med programmøren, for at høre hvad der er muligt osv. Når designeren er færdig og kunden og programmøren har godkendt designet, starter pogrammøren.

Ud fra mine erfaringer, er det den bedste måde at gøre tingene på.



Amino-karma 2.896
Fra Esbjerg
Tilmeldt 14. dec 05
Indlæg ialt: 629

Grosen Friis
Skrevet 10-02-2007 kl. 10:43
Betaling aftaltes som 1/3 ved opstart og 2/3 ved levering.

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.



Før en programmør starter, skal hele designet være lavet.

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
  • mange indl. møder med kunden og kundens personnale for at lære at forstå deres forretning og dermed
    det behov de skulle have løst

  • udarbejdelse af mockups som igen blev drøftet med og til sidst godkendt af kunden

  • udarbejde en detaljeret specifikation hvor hver lille funktionalitet blev beskrevet.
    Specifikationen blev brugt som grundlaget for kontrakten imellem min virksomhed og kunden.

  • kode systemet og undervejs præsentere og få godkendt delleveringer. (Det skaber stor tryghed
    hos kunden at de kan se at der sker noget at at det man når frem til er det der er aftalt

  • endelig levering og godkendelse
Jeg tager dette med for at beskrive et forløb der har virket utrolig godt og for igen at sige, at
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.



bruge en meget god teknik, hvor de ved de planlæggende møder, tegnede skærmbilleder af alt der skulle
laves på store plancher, med pile, streger og kommentarer til, og når de så var enige om projektets udforming,
tog de et digitalkamerak frem og affotograferede det hele. Dette blev så brugt som grundlag for aftalen. Det
syntes jeg var en fin løsning

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

Amino-karma 30
Tilmeldt 14. nov 06
Indlæg ialt: 8

Thomas Skou Hansen
Skrevet 12-02-2007 kl. 15:06
Hej David.

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 :-) )


Amino-karma 279
Fra Tune
Tilmeldt 11. jan 07
Indlæg ialt: 77

MT9
Fra Whisky Tastings and Tours
Skrevet 16-02-2007 kl. 03:01
Hej David,

 

Har sendt dig en PB og en mail

Amino-karma 38
Fra Ballerup
Tilmeldt 12. apr 09
Indlæg ialt: 11

Ralph Rezende Larsen
Skrevet 14-09-2018 kl. 07:12

Hej David

Jeg er selv programmør og ved hvordan man pludselig havne i overarbejde til over begge ører.

Du skal ikke snakke med programmøren, men gå til hovedet, altså ham der betaler og høre om han vil betale for de ændringer der skal laves.

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

Amino-karma 2.549
Fra Horsens
Tilmeldt 31. jan 11
Indlæg ialt: 474

Anders Bruun Rasmussen
Fra De skøre kugler
Skrevet 14-09-2018 kl. 07:40

Det bliver en dyr hjemmeside hvis den ikke er færdig her 11,5 år efter :-) 

Side 4 ud af 4 (39 indlæg) < Forrige 1 2 3 4

RSS-feed
 
Administration & Finansiering er venligst sponseret af:

Diverse administration hjælp
Besøg vores andre hjemmesider :