Diverse administration hjælp

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

Anders Bruun Rasmussen — Fri, 14 Sep 2018 05:40:54 GMT

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

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

Ralph Rezende Larsen — Fri, 14 Sep 2018 05:12:19 GMT

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

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

MT9 — Fri, 16 Feb 2007 02:01:00 GMT

Hej David,

Har sendt dig en PB og en mail

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

Thomas Skou Hansen — Mon, 12 Feb 2007 14:06:00 GMT

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

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

Grosen Friis — Sat, 10 Feb 2007 09:43:00 GMT

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

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

Niklái — Fri, 09 Feb 2007 10:54:00 GMT

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

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

Lars C — Thu, 08 Feb 2007 22:32:00 GMT

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

www.plbrake.dk

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

Peder TakeTwo.dk — Thu, 08 Feb 2007 22:21:00 GMT

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

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

Happypie — Thu, 08 Feb 2007 22:08:00 GMT

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

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

Martin Lysfelt — Thu, 08 Feb 2007 12:35:00 GMT

Mikkel - he he... du er sgu da sjov! Du har misforstået mit indlæg.... Jeg er ked af, at du er træt af at høre "folk som mig" brokke sig over dårlige programmører. Jeg postede kun et enkelt dårligt tilfælde i en tråd med titlen "Hvad gør man med en dårlig programmør..?" og jeg synes egentlig, at hvis du er træt af at læse om / høre på "folk som mig", der brokker sig, så hold dig da væk fra sådan en tråd... Jeg synes du udstiller din egen mangel på tolerance! Især når du efter mit andet svar, hvor jeg giver dig ret i, at jeg selv var et fjols til at håndtere projektet, stadig kaster med lort efter mig... hmmm... men jeg vil så gerne have lov til at undskylde min egen dumhed i at tro du var programmør... sorry, det var sgu ikke meningen!

Jeg gentager (hvis ikke alle har forstået): det er kun de uduelige programmører, som ikke er værd at handle med... Jeg har intet imod andre programmører. Jeg HADER i øvrigt også dårlige projektledere... (lad os se, om der er nogen af dem, som reagerer ligesom Mikkel...)

Nå, tilbage til arbejdet... det er trods alt det, som betaler huslejen...! Nu gider ikke rigtig at følge op på dette emne mere.

Mange hilsner,
Martin E. Jensen

www.mejensen.dk
- Markedføring og distribution af reklamekort, visitkort og butiksdisplays.

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

Jesper Jørgensen — Thu, 08 Feb 2007 11:34:00 GMT

Projektleder: Jeg skal bruge en løsning der kan X, Y, Z og K, men jeg ved ikke hvordan jeg kommer derhen. Kan du hjælpe mig?

Store projekter kan være svære at definere, hvorfor indkøberen går til en fagmand for råd og vejledning. Hvis fagmanden råder forkert, så er det altså fagmanden, der har spillet fallit. Men hvis indkøberen fatter bjælde, så bør vedkommende måske kigge lidt på sin stilling og eventuelt udvikle sig eller aftræde den.

Uanset om det er IT aktier i .com dagene, IT udviklingsprokter eller noget helt tredje, så viser al erfaring at det kan være MEGET dyrt at investere penge i noget man i bund og grund ikke har forstand på. De virksomheder der vil klare sig bedst på lang sigt er også dem der kender til det de beskæftiger sig med. Hvis man har behov for expertise indenfor et område man ikke kender til, må man betale sig til denne.

De to ovennævnte sitater peger på et grundlæggende problem: Den der skal udvikle løsningen antages også (ukritisk) for at være den der bedst er i stand til at vejlede kunden. Hvis der er tale om et velrenomeret konsulenthus med deraf følgende priser kan du måske med rette forvente en sådan professionel vejledning. Men når der er tale om end mindre udvikler må man altså se i øjnene at kunde og leverandør ofte har modsatrettede interesser. Kunden ønsker det så billigt som muligt, leverandøren så dyrt som muligt. Løsning: konsulter et uvildigt konsulent bureau til at varetage dine interesser. Kvalitet koster.

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

Grosen Friis — Thu, 08 Feb 2007 06:57:00 GMT

Hej alle

Dette har udviklet sig til en meget god tråd, programmør versus designer, leverandør versus indkøber/
projektleder.

Hertil har jeg lige et par generelle bemærkninger:

Det med at man som programmør skal være gratis-fleksibel skal man kun gøre i et begrænset omfang,
for det kan hurtigt blive en vane af en tidsrøver, og man skal ikke arbejde gratis. Dermed ikke
sagt at man som programmør ikke skal tilbyde at foretage rettelser efter kundens/designerens ønske
mod ekstra betaling. Kunden skal jo gerne ende med at være tilfreds med sit produkt.

En kommentar til designere!

At flytte en streg 3 px til højre kan faktisk godt tage 1 time fordi det flytter rundt på hele
designet og ikke bare lige stregen. Smårettelser kan godt være simple at se på men en tidsrøver at
implementere fordi rettelser i software ofte kan have sideeffekter som skal testes og måske tilrettes.
Selvom det er nemt at rykke rundt på fx et design i et billedbehandlingsprogram, så kan det godt
være langhåret at få kodet om og dermed en tidsrøver der skal betales for.

En kommentar til Dig der skal finde en programmør

En god programmør sætter sig ned sammen med en kunde og evt. en designer og sætter sig 100% ind i
kundens daglige forretning for at forstå hvad det er han skal hjælpe kunden med at løse. Det tager
tid og det er arbejde som skal honoreres, det er ikke gratis opsøgende salgsarbejde, og bla. en af
årsagerne til at specialudviklet software ofte kan være en dyr fornøjelse. Indgå ALDRIG en aftale
med en programmør, som ikke vil lave dette ofte tunge, detaljerede og tidskrævende arbejde, for han
vil aldrig kunne levere det kunden ønsker. En god, præcis og detaljeret specifikation som en
programmør har arbejdet på at få skrevet vil også indikere at programmøren vil følge opgaven til
dørs og ikke bare stoppe når projektet ikke længere er teknisk spændende.

Jo vigtigere et projekt er desto mindre skal Du vælge fritidsprogrammøren, men derimod fuldtids-
programmøren/softwarehuset.

Stil krav til programmøren, han/hun skal ikke skrive tæt udokumenteret kode, men skal skrive kode
som er adskilt i logiske blokke og som sammen med dokumentationen kan overleveres til en anden
programmør. En god programmær er en parameter validerings freak, han tester hele tiden om de
parametre han arbejder med er til stede, at de er af af den rigtige type og har den rigtige "værdi".
Validerig koster lidt på performance i det færdige system, men det sikrer at man opnår et langt
mere fejlfrit og robust system.

/Grosen Friis

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

Regin Jæger Madsen — Thu, 08 Feb 2007 05:57:00 GMT

Jeg mener der er ret stor forskel på de to eksempler david og mejensen kommer med.

Jeg er uddannet både programmør og grafisk designer, og det er vitterligt to forskellige verdener. Problemet er ofte at hvor man kan måle hvorvidt programmøren har opfyldt kravspecifikationen, kan det ikke måles hvorvidt en designer har nået sit mål på samme måde. Derfor bliver arbejdsprocessen også meget forskelligt. Programmøren kan starte med at krydse af hver gang han opfylder et delmål, mens designeren arbejder mere "frit". Det er klart det kan give problemer hvis ikke BÅDE designer og programmør er klar over den andens arbejdsform. Som programmør er det frustrerende at arbejde med en designer der "bare lige" laver en lille ændring i ny og næ - det kan betyde mange timers arbejde, omvendt er det irriterende for designeren at programmøren har fastsat nogle rammer der SKAL arbejdes indenfor.

I davids tilfælde er der som allerede nævnt vist ingen tvivl om at programmøren har gjort sit hjemmearbejde godt. Han har lavet en god præcis kravspecifikation, og har udført sit arbejde...At designeren så sidenhen mener at der er nogle ting der skulle være lavet på en anden måde, er kundens ansvar - JA havde programmøren haft bedre indsigt eller bedre evner var det MÅSKE aldrig blevet et problem. Hvis programmøren derimod vælger at rette tingene risikerer han en masse ballade hvis det ikke fungerer som ønsket, for hvem skal betale for de ekstra rettelser?

I mejensens tilfælde har jeg faktisk lidt ondt af dig... At en programmør syntes det er sjovere at sidde og hygge sig med egne projekter, og lære nye ting på din regning er helt til grin - kravspecifikation eller ej. Om det var fornuftigt af dig overhovedet at lave en kontrakt kan jeg ikke kommentere da jeg jo ikke ved hvordan jeres møder er spændt af...Jeg har selv lavet tilbud med løse kravspecifikationer, og mener sagtens det kan lade sig gøre i visse tilfælde...

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

Lars C — Thu, 08 Feb 2007 03:55:00 GMT

Hej Peter og Mikkel,

Kan I ikke finde en skolegård og bokse i? Selve debatten i denne tråd er rigtig god at lære af, men jeres fnidder ødelægger det lidt. Og så vil jeg vende tilbage til emnet!

Jeg står tit i den situation at skulle definerer en udviklingsopgave fra scratch og frem til det endelig produkt - alt inclusive. Noget at det sværeste er at afstemme alle aktørers virkelighed eller forståelse af opgavens enkeltelementer. Her mener jeg det er både projektleder, idemager (kunde) samt alle aktører der hver især kommer med deres input til en fælles godkendt kravspec. Først herefter er det muligt at få lavet en plan for hvem gør hvad hvornår - således at ændringer ikke blot opfattes som "det ville være smart hvis vi lige gjorde..." men at enhver ændring har betydning for det samlede projekt. Måske lyder det som skudt forbi med en sådan beskrivelse af et udviklingsprojekt, men det er ligegyldigt om det er et stort eller et lille projekt eller blot en website - alle ændringer har konsekvenser og en manglende forståelse af hinandens værdi for projektet, vil kun skyde det isænk undervejs. Derfor få virkeligheden til at passe sammen - ellers går det galt.

Med venlig hilsen

Lars C

www.plbrake.dk

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

pbtryk.dk — Wed, 07 Feb 2007 23:20:00 GMT

Mikkel-> jeg angriber ikke dine argumenter, hvilket jeg også slog fast i første og sidste del af mit indlæg. Til gengæld angriber dit angreb, og det ser ud til at du i langt højere grad end jeg forventede besvarer angreb med modangreb i stedet for at tage en saglig debat.

Jeg kan ikke andet end være enig i, at det er indkøberens ansvar at være indkøber. Men det er i lige så høj grad sælgerens ansvar at være sælger. Hvis en kunde kommer til mig og ønsker en udefinerbar løsning, og vi sammen bevæger os hen i retning af noget, som vi umiddelbart begge forstår, så er det mit ansvar at levere netop dette - og kundens (indkøberens) ansvar at slå alarmklokkerne i, når der er anledning hertil.

Store projekter kan være svære at definere, hvorfor indkøberen går til en fagmand for råd og vejledning. Hvis fagmanden råder forkert, så er det altså fagmanden, der har spillet fallit. Men hvis indkøberen fatter bjælde, så bør vedkommende måske kigge lidt på sin stilling og eventuelt udvikle sig eller aftræde den.

Så principielt er vi ikke uenige i fakta. Men jeg mener stadig, at du er urimelig i dit angreb på meJensen. Dit svar til min kommentar gør mig desværre opmærksom på, at der er lang vej igen, før du respekterer hvad jeg skriver. Og det er jeg ked af. Lommefilosofi eller ej.

Vh
Peter