"Hvordan får man dygtige udviklere overbevist om, at de skal lave skodkode, når nu kunden ikke vil betale for noget af en ordentlig kvalitet?", spurgte en af mine bekendte, der er projektleder i et konsulenthus.
Jeg blev på foruroligende vis mindet om spørgsmålet, da jeg hørte en nylig episode af P3's glimrende program Harddisken, hvor man diskuterede et emne, der måske nok er lidt fortærsket efter i årevis at have oppe at vende på udviklerkonferencer: At se udvikling som "craftmanship" eller håndværk på dansk, hvor et håndværk bl.a. er karakteriseret ved, at det i en traditionel håndværksetik er stoltheden over produktet i sig selv, der driver værket, mere end det er den tanken om den deraf følgende økonomiske belønning.
At blive tvunget til at levere arbejde af en ringe kvalitet er altså demotiverende for enhver, der ser sig mere som håndværker eller videnarbejder end som lønslave.
Jeg har svært ved at forestille mig, at dygtige udviklere kan stille sig tilfredse med gang på gang at levere ustabil, svært vedligeholdbar brug-og-smid-væk software. Er open source bevægelsen måske udviklernes stille revolution mod kravet om at indfinde sig med betingelser, der dybest set strider mod håndværksetikken?
Jeg ville ønske, at jeg havde et godt svar på min bekendts frustrationer. Jeg troede nemlig, at videnssamfundet indvarslede et opgør med forestillingen om arbejdet som noget, der skulle overstås. Men der er måske lang vej endnu?
Jeg håber da at din ven på et tidspunkt giver op og ser sig efter nogle klogere kunder eller nogle dummere udviklere. Måske kan han finde nogle udviklere et sted i Østen som er ligeglade med produktet hvis bare kunden betaler ;-).
I mellemtiden vil han måske have glæde af at læse Martin Fowlers tanker om emnet: http://martinfowler.com/bliki/TradableQualityHypothesis.html
Klogere kunder er der nok mange, der ønsker sig...
Men min vens dilemma er jo, at hvis han sætter prisen på tilbudet efter, at udviklerne skal have tid til at lave et ordenligt stykke arbejde, så er der en vis risiko for, at kunden vælger et konkurrerende tilbud fra nogen, som ikke har skrupler ved at levere et dårligt produkt, der virker billigt (i hver fald på kort sigt).
Så er det vel også en kunde som ikke har nogen problemer med at købe noget bras, bare det er billigt. B&O laver jo ikke billige højtalere, blot fordi de er bange for at kunderne køber noget andet. De vælger istedet at skille sig ud, ved at levere et produkt som nogen gerne vil betale ekstra for og lever med at de aldrig kommer til at sælge specielt mange højtalere, til gengæld lever de godt i den niche de har opbygget. Hvis de skulle konkurere på prisen, ville de jo også skulle konkurere på at sænke kvaliteten. Og på det marked er konkurrencen hård og kunderne illoyale. Det samme gælder jo også i vores branche. Skulle vi konkurere på pris istedet for andre parametre, vil vi jo tabe hver eneste gang til outsourcing til f.eks. Kina eller lignende. Så din ven må nok gøre op med sig selv, hvad han egentlig gerne vil konkurere på, og så acceptere at de kunder, som ikke er intereserede i de parametre som hans virksomhed skiller sig ud på, simpelthen ikke er hans kunder.
[..]som ikke har skrupler ved at levere et dårligt produkt, der virker billigt (i hver fald på kort sigt).
Nu ved du så, hvorfor offentlige (IT)projekter altid bliver mindst dobbelt så dyre som aftalt, og hvorfor kvaliteten altid er hovedrystende ringe!
Hej Puslinger,
Hvis I har stærke nerver, kan I erkende noget ved at læse Coopers gamle bog.
http://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672326140/...
(Tåbeligt amerikansk! - men underholdene læsning)
Det er vel din ven der er "skyld" i det! Han tager dårlige projekter ind velvidende prisen på dem. Så udsætter han sine udviklere for det efterfølgende. Han bør vel, som tidligere nævnt, få bedre opgaver ind.
Synes det er lidt pudsigt at læse hvordan man kan tage udviklere som gruppe ud af context. Fra min side drejer softwareudvikling sig ikke kun om udviklere, men mindst ligeså meget om alle de andre mennesker der er involveret (regnskab, marketing, projektledere osv.). Jeg tror det er vigtigt for din ven at se virksomheden som en helhed og ikke kunne skille udviklerne ud. Han kunne også spørge: "Hvorfor skulle jeg blive her, når min chef tvinger mig til at tage dårlige projekter ind". Man kan ikke skille en gruppe af medarbejdere ud på den måde, det er et teamarbejde at løse den type opgaver. Specielt hvis det skal være kvalitet, kunden køber typisk en hel pakke: pris, support, design og funktionalitet af systemet.
Der er i øvrigt noget galt med den grundlæggende præmis for din vens problemstilling, nemlig forestillingen om at det ville være billigere at lave dårlig kvalitet. Den forestilling hænger godt sammen med "craftmanship" tankegangen, for der er jo ingen tvivl om at en håndlavet kommode af materialer i høj kvalitet og sirlige udskæringer som pynt er dyrere at fremstille end end Ikea-lignende ting i spånplader. Softwareudvikling adskiller sig bare fra craftmanship på præcis dét område at dårlig kvalitet sjældent er billigere, fordi man lynhurtigt rammer dét punkt, hvor den dårlige kodning (her defineret som dårlig kvalitet) gør det komplet umuligt at rette fejl, lave ekstra features eller bare rette på eksisterende, når kunden opdager at de ikke gør dét som var meningen. Dårlig kodning gør det næsten altid helt vildt sværat at blive HELT færdig med produktet, og derfor er dårlig kvalitet ikke nødvendigvis billigere at fremstille end god. Forslag til relevant læsning: http://martinfowler.com/bliki/TradableQualityHypothesis.html
Hej Puslinger, Hvis I har stærke nerver, kan I erkende noget ved at læse Coopers gamle bog
Jeg kan ikke regne ud om det indlæg er en fornærmelse eller kærligt ment eller om bogen har nogen relevans for emnet eller blot er blog-spam. Den mindste antydning af hvilken holdning bogen eller indlæggets forfatter har til emnet ville være rart.
Selvfølgelig er det chefens ret og pligt, at diktere at en opgave løses på kortere tid, hvis det er det markedet er villig til at betale. Og gøre kunden opmærksom på, at fremtidigt vedligehold kan risikere at blive dyrere, hvis der er behov for det.
Måske der er tale om en applikation, der kun skal bruges af én person eller i kort tid og så kan det simpelthen ikke betale sig at bruge meget tid på, at gøre det klippestabilt, ekstra brugervenligt eller noget lignende.
Selvfølgelig er det chefens ret og pligt, at diktere at en opgave løses på kortere tid, hvis det er det markedet er villig til at betale.
Er det vognmandens ret og pligt at diktere at en lastbilchauffør SKAL køre længere og hurtigere end han må, hvis det er dét markedet er villig til at betale? Chefen har vel også en pligt til at være realistisk? Han kan trods alt ikke diktere at en opgave kan løses hurtigere end hvad hans folk kan arbejde. Men du har naturligvis en pointe, hvis det man definerer som kvalitet, er noget, som rent faktisk medfører besparelser, hvis man skruer på det. Men Anne-Sofies oplæg nævner "skodkode" og det er altså uhyre sjældent at skodkode bringer projektet i mål hurtigere og billigere end god kode.
Kan man få bøder af politiet for at skrive dårlig kode? Nej vel. Dårlig sammenligning at bringe vognmænd ind i historien.
Spørgsmålet er om man bruger f.eks. 10 timer ekstra på projektet, som sparer hver bruger for 1 time. Er der nu kun én bruger, så er de 10 timer dårligt investeret med mindre den ene bruger har en meget høj timepris.
Ligeledes kan man forestille sig, at kunden ikke forventer at skulle bruge applikationen til andet end et her og nu projekt, så vil ekstra investering i vedligeholdelsesvenlig kode være dårligt givet ud.
Hvis man som udvikler kan lave både god og dårlig kode lige hurtigt, ja så er valget selvfølgelig nemt. Det er forhåbentlig ikke den slags selvfølgeligheder vi diskuterer?
Storm P. har en flue, hvor en mand siger: "Det kræver ærlighed at sælge elastik i metermål."
At sælge softwareprojekter er som at sælge elastik i metermål, for der vil altid være åbne parametre, når man indgår aftalen, og netop forståelsen af kvalitetsbegrebet afhænger af øjnene, der ser.
Er det dårlig kvalitet, at designet ikke tillader flere brugere adgang samtidig? Er det dårlig kvalitet, at der ikke er en turingkomplet konfigurationsfil? Er det dårlig kvalitet, at applikationen skal genstartes, hvis man ændrer i visse parametre? De spørgsmål kan ikke besvares uden at vide, hvordan softwaren tænkes anvendt. Det er et stik i hjertet, når man som programmør hellere ville lave den fulde pakke, men hvis kunden aldrig har mere end en bruger på af gangen eller sjældent ændrer i indstillingerne, har han bare fravalgt noget, der ikke giver ham værdi. Det er derfor vigtigt at gøre sig klart, om "lavere kvalitet" her betyder "reduceret funktionalitet" eller "stressforårsaget sjuskefejl".
Ofte er kvalitetsdilemmaet en konsekvens af, at der er gået vandfald i et projekt. Alle er enige om, at vandfaldsmodellen i dag kun har meget begrænset berettigelse, men når en kunde står og siger: "Kan I lave mit projekt her for X kroner?", er det svært at sige nej, især som markedet er lige nu. Men konsekvensen af et ja er jo, at man har rigtigt svært ved at få alle vores gode agile metoder i spil. Vi kan ikke længere justere på indholdet, og kvaliteten bliver elastikken i projektet, fordi den oftest ikke er en del af projektbeskrivelsen. Det er desværre en lose-lose situation, for kunden får et dårligt resultat, og det giver ikke et godt rygte i branchen. Hvis man derimod kan få kunden til at acceptere indledningsvis at købe så lidt som to agile programmører i en uge (afhængig af projektet), får han netop så meget funktionalitet, at han kan vurdere, hvor meget elastik han får pr. løbende meter. Det giver ham en langt bedre platform, hvorfra han kan træffe sine valg.
En del af problemet er også, at vi ikke helt har indset konsekvensen af, at markedet har ændret sig. En programmørtime kan ikke sælges for det, den kunne for 2-3 år siden. Hvis ikke vi har en ærlighed over for os selv om det, bliver vores regnestykker forkerte og urealistiske. Sagt på en anden måde: Hvis vores ærligste estimater siger, at et projekt koster X programmørtimer à Y kroner i timen, men at det kun kan sælges for det halve, er det så X eller Y, der er forkert?
Uanset det nævnte, er det i sidste ende kundens suveræne afgørelse, hvad han vil bruge sine penge på. Vi kan ikke gøre andet end at klargøre, hvad konsekvensen er af de valg, han træffer. Vores integritet ligger i, at vi er ærlige, gør vores bedste og - i yderste instans - siger fra, når kundens forventninger er helt uden for rækkevidde.
Thomas
Hvis vores ærligste estimater siger, at et projekt koster X programmørtimer à Y kroner i timen, men at det kun kan sælges for det halve, er det så X eller Y, der er forkert?
Sandsynligvis hverken eller. Her er nogle mere sandsynlige fejlkilder:
Man forsøger at lave nyudvikling i et marked, hvor den mest kost-effektive løsning er brug af billig [i]shrink-wrap[/i] software.
Man udvikler med forældede/uegnede sprog og værktøjer, så man bruger alt for mange programmørtimer til at løse opgaven.
Programmørerne er for dårlige. Diverse undersøgelser tyder på, at rigtigt gode programmører kan kode mere end 20 gange hurtigere end middelmådige programmører og alligevel (eller måske netop derfor) producere bedre kode. Så det kan sagtens være dine programmører, der fordyrer produktet. Desværre kan det ofte være svært for managers at se forskel på gode og dårlige programmører, specielt hvis de kun har erfaring med de dårlige. Så vil de gode programmører se ud som anarkister, der nægter at følge kodepraksis, og som hele tiden vil lave om på kravspecifikationerne.
Torben skrev:
Sandsynligvis hverken eller. Her er nogle mere sandsynlige fejlkilder:
Man forsøger at lave nyudvikling i et marked, hvor den mest kost-effektive løsning er brug af billig shrink-wrap software.
Man udvikler med forældede/uegnede sprog og værktøjer, så man bruger alt for mange programmørtimer til at løse opgaven.
Programmørerne er for dårlige. Diverse undersøgelser tyder på, at rigtigt gode programmører kan kode mere end 20 gange hurtigere end middelmådige programmører og alligevel (eller måske netop derfor) producere bedre kode. Så det kan sagtens være dine programmører, der fordyrer produktet. Desværre kan det ofte være svært for managers at se forskel på gode og dårlige programmører, specielt hvis de kun har erfaring med de dårlige. Så vil de gode programmører se ud som anarkister, der nægter at følge kodepraksis, og som hele tiden vil lave om på kravspecifikationerne.
Jeg var ved at skrive nogle af de samme pointer i afsnittet over, men indlægget var allerede langt nok i forvejen.
På spørgsmålet om forholdet mellem kvalitet og pris var min pointe, at den forhandlede pris, som projektet ender med at blive solgt for, ikke på magisk vis kan ændre tiden, der går til at implementere løsningen med samme indhold. Om man vil tage opgaven alligevel, afhænger af en række forretningsmæssige faktorer (f.eks. at man har folk stående på græs), men så må man bogføre det som tabsbegrænsende aktivitet.
Prisen på en vare i et givent marked bestemmes af faktorer som udbud, efterspørgsel, præferencer og tilgængelighed. Alt andet lige (herunder egnetheden af værktøj og kvaliteten af egne evner) betyder det, at aktører kan være tvunget til at justere deres priser til de nuværende vilkår. Forhåbentlig har markedet for specialsoftware tilstrækkelig priselasticitet til, at mængden af projekter stiger, når prisen falder. Det er tilfældet, hvis der ligger en bunke skuffeprojekter, der af økonomiske hensyn er skrinlagt. Hvis priselasticiteten derimod er meget lav, så kan prisen falde meget mere.
Hvad man derimod ikke kan, er at bilde sig selv ind, at man kan levere en ringere vare, når priserne generelt er faldende i markedet. At fortælle sine udviklere, at de skal implementere det samme projekt på den halve tid, fordi man kun kunne opnå den halve pris, er misforstået økonomi. Hvis de kan implementere projektet tilfredsstillende på den halve tid, så skulle de kunne gøre det alligevel - uanset pris, og kan de ikke, så har man bare hældt vand i øllet for sine kunder, hvilket de klart ikke vil betale for, når de er stillet noget andet i udsigt.
Det er kun i den situation, hvor den specifikke kunde har ønsket at begrænse sine omkostninger ved at nedsætte sine kvalitetskrav, at man kan hælde vand i øllet.
Thomas
"Hvordan får man dygtige udviklere overbevist om, at de skal lave skodkode, når nu kunden ikke vil betale for noget af en ordentlig kvalitet?", spurgte en af mine bekendte, der er projektleder i et konsulenthus.
Hvordan får man udviklere overbevidst om at de skal skræmme kunderne væk, når sælgerne nu ikke har gjort det?
Et eller andet sted så undre det mig hvorfor din ven insistere på at skubbe lorten ned til udviklerne?
Fordi han ikke kan se at han har et problem. Som andre har nævnt er det en udbredt misforståelse, at man kan justere på "kvaliteten" af software på samme måde, som man kan justere på kvaliteten af stål.
Er der iøvrigt nogen der kender andre kvaliteter ved software end funktionalitet og pålidelighed?
Kan man få bøder af politiet for at skrive dårlig kode? Nej vel. Dårlig sammenligning at bringe vognmænd ind i historien.
Lastbilchauføren kan nu en gang ikke køre en pakke fra Århus til København på 1,5 time uanset om kunden ikke vil betale for mere. Gulvlakken kan ikke tørre på den halve tid og ni kvinder kan ikke lave et barn på en måned. Nogen gange må man altså bare acceptere at tingene ikke kan laves hurtigere end de kan.
Hvis man som udvikler kan lave både god og dårlig kode lige hurtigt, ja så er valget selvfølgelig nemt. Det er forhåbentlig ikke den slags selvfølgeligheder vi diskuterer?
Jo, det er efter min mening PRÆCIS den slags selvfølgelighed vi diskuterer. Det er nemlig så utroligt nemt for projektleder, sælger og kunde at blive enige om at levere det hele til det halve ved at bede udviklerne skrue ned for kvaliteten "så længe det ikke gør noget". Så står man som udvikler foran en uløselig opgave, for hvis man virkelig havde evnen til at lave det samme stykke arbejde på den halve tid, så havde man jo nok gjort det noget før! Problemet er at ledere og kunder ofte tror at kvalitet er noget som kun kan betale sig på den lange bane, hvis et produkt skal videreudvikles og vedligeholdes i årevis. Min erfaring er at jeg kan nyder effektivitetsfordelen ved kvalitetskode efter få uger, ja nogen gange få dage.
Men hvis du slås med udviklere som insisterer på at lave et produkt som f.eks. kan håndtere en million samtidige logins, på trods af at det skal bruges til tidsstyring i en 3-mands virksomhed, så trænger de nok til at få en opsang i at lytte til kundens behov, snarere end en "nedsang" om at begynde at skrive dårlig kode. For så laver de jo bare en system som BURDE kunne håndtere en millions samtidige logins, men crasher 8 gange om dagen blot solen lidt skævt ind af vinduet.
Er der iøvrigt nogen der kender andre kvaliteter ved software end funktionalitet og pålidelighed?
Hvad med skalerbarhed, effektivitet (resourceforbrug), vedligeholdbart (er det er ord?), dokumentationsgrad, ...?
Det kræver som ovenfor anført etik og moral at sælge elastik i metermål og derfor kræve det rygrad af baglandet at holde sælgerne på måtten.
Problemstillingen er ikke unik for EDB-branchen.
Danmark har noget af det elendigste brød, fordi danskerne ikke vil betale hvad det koster at få et ordentligt brød.
Det er også bevist igen og igen at danskerne lader hånt om alt fra dyrevelfærd til cocktailkemikalier, hvis bare prisen er discount nok.
Kvalitet er blevet en luxusvare i de fleste andre brancher, fra håndværksbagere til snedkerfirmaer. De har 1% eller mindre af markedet: Dem der har råd til og er villige til at betale for kvalitet.
Rigmænd, Mærsk, meninghedsråd og den slags.
Resten af markedet er det billigste discount Bilka og Harald Nyborgs indkøbere har kunnet skrabe hjem fra Kina.
Hvis man ikke vil skrive skod-software, skal man uddanne sig til at blive god nok til ikke at gøre det og derefter søge job i et af de softwarehuse der har som politik ikke at levere skodsoftware.
Og man skal indse, at der ikke er nogen hurtige penge at tjene på den måde...
Poul-Henning
Er der iøvrigt nogen der kender andre kvaliteter ved software end funktionalitet og pålidelighed?
Hvad med skalerbarhed, effektivitet (resourceforbrug), vedligeholdbart (er det er ord?), dokumentationsgrad, ...?
Og hvor er det så man kan skære så det bliver billigere at udvikle?
Når først man har fået styr på udviklings-processen, så det der bliver udviklet også svare nogenlunde til det der bliver bedt om, så er der ikke så meget at rafle om. Det tager den tid det tager.
Alternativt lyver man for kunderne (eller sig selv) og lover dem noget man ikke kan levere.
Og hvor er det så man kan skære så det bliver billigere at udvikle?
Er det ikke normalt sådan at man skærer i test? Man sparer den tid test ville tage og da man ikke finder nogen fejl, er der ikke så meget arbejde med at rette fejl inden release. Da softwaren ovenikøbet er i mindst ligesågod kvalitet som grundigt testet software (der er jo ikke flere fejl) så "gør det ikke noget" at man sparede.
Er det ikke normalt sådan at man skærer i test?
Jo, hvis hver aktivitet i udviklings-forløbet (design, implementering, test) kun udføres én gang.
Der er dog nogen der mener, at der er en kortere vej i mål, hvis man udvikler i små skridt og kommer igennem alle aktiviteter flere gange. I det tilfælde er det stort set kun funktionaliteten der kan skæres i.
Et sted det er nemt at spare (og tidmæssigt er meget at hente) er på fejlhåndtering og "robusthed".
"Brugerne skal kunne indlæse deres timeregistreringer".... jeps, det er nemt at lave. Der findes sikkert en Excel reader klasse et eller andet sted man lige kan benytte. Den kan godt nok ikke læse tekster med æøå, men hvor mange skriver tidsregistreringer med de tegn alligevel....
Brugere kan finde på at pege deres musikfiler ud istedet for den tidsregistrering de skulle have klikket på (det hele ligger jo og falder over hinanden på desktoppen alligevel). Skal applikationen nu...
1) prøve om filen evt. er en gl. excel 2003, en csv fil eller en anden afart af tidsregistreringer.
ELLER
2) give en "java.lang.NullPointerException" fordi "første linie" i MP3 filen ikke lige indeholdte et sagsnummer
Jeg ved godt hvad der er nemmest (hurtigst) at kode...
Nogle brugere inddaterer (ja, det hed det i 70'erne så det er vel også brugbart i 2011) kun en gang om måneden. Skal deres indlæsning tage ... få sekunder... eller er det ok at det tager et par minutter ? Det er et webservice kald der opretter tidsregistreringen i systemet, men skal vi bare lave en "kald WS pr. linie i filen" eller skal vi lave "kald WS i batch af 20 registreringer". Jeg ved godt hvad der er nemmest/hurtigst at kode...
Der er masser af tid at spare hist og her. Den kvalitetsbevidste udvikler vil nok lave robust, vedligeholdelsesvenlig, fejltolerant og performancewise gode applikation, men vil kunden betale for det ?
Kundens brugere skriver kun timetallene på deres registreringer - kommentarfeltet bruges næsten ikke så ÆØÅ er faktisk lidt uinteressant...
Kundens laver en brugervejledning der forklarer at "NullPointerException" i forbindelse med indlæsning betyder at man har valgt en fil som ikke indeholder tidsregistreringer så fejlhåndteringen er unødvendig.
De fleste brugere indlæser tidsregistreringer hver morgen så der vil typisk kun være een eller to registreringer at indlæse. Det er derfor ikke noget problem at WS kaldet sker pr. registrering.
Jeg tror ikke kunden vil betale for den kvalitetsbevidste udvikler...
Et sted det er nemt at spare (og tidmæssigt er meget at hente) er på fejlhåndtering og "robusthed".
Ja, hvis man som udgangspunkt udelader det tager det længere tid at indføre det senere.
Jeg deltog engang i et kursus, hvor vi på et tidspunkt i forløbet skulle skrive en funktion, som brugte det her nye API. Vi fik lige lang tid, men der var meget stor spredning på hvor robuste løsningerne var. Et hold havde konsekvent undladt at håndtere retur-værdier, mens et andet havde taget hensyn til samtlige udfald. Og som sagt der var ikke forskel på hvor lang tid vi havde brugt på det.
Det der gør den store forskel er forestillingen om hvad der skal til. Hvis man på forhånd ved hvad der skal gøres tager det ikke længere tid ved tasterne.
"It's all in your head".
Ja, hvis man som udgangspunkt udelader det tager det længere tid at indføre det senere.
Men hvem siger at sælgeren behøver at tage højde for det? Måske er konsulenterne kun solgt ind til at levere første version af systemet. Måske bliver de endda betalt på timebasis for at rette fejl i systemet efterfølgende.
Men hvem siger at sælgeren behøver at tage højde for det? Måske er konsulenterne kun solgt ind til at levere første version af systemet. Måske bliver de endda betalt på timebasis for at rette fejl i systemet efterfølgende.
Det er her at ting som moral og faglig stolthed blander sig i beslutningen...
Vil du have det fint med at levere et ustabilt system og ovenikøbet flå kunden i dyre domme for at rette op på dette bagefter, eller vil du hellere levere en god stabil løsning og så tjene dine penge på nye opgaver/løsninger til kunden?
Jeg vil til hver end tid vælge den sidste løsning - Den første er forbundet med ringe faglig stolthed og en generel dårlig moral.
Vil du have det fint med at levere et ustabilt system og ovenikøbet flå kunden i dyre domme for at rette op på dette bagefter
Naturligvis er det altid federe at lave det ordentligt, men nu påstod andre debattører at det aldrig kan betale sig at slække på kvaliteten. Jeg taler ikke om at tørre kunden, men om en kunde der eksplicit kun vil betale for et ustabilt produkt.
Nu da vi har været godt rundt om værdien af god kode, får jeg lyst til at addressere Anne-Sofies (vens) oprindelige spørgsmål:
Hvordan får man dygtige udviklere overbevist om, at de skal lave skodkode, når nu kunden ikke vil betale for noget af en ordentlig kvalitet?
Mit svar dertil må være: Lad udviklerne selv deltage i et eller flere af de tidlige møder med kunden, hvor man afklarer hvilke behov systemet skal opfylde. Hvis udvkilerne selv går i dialog med kunden om hvilken kvalitet han vil have, BEHØVER projektlederen ikke efterfølgende overbevis udviklerne om hvilken kvalitet de skal levere. De har nemlig selv deltaget i den proces, hvor det blev afklaret. Måske kan de endda komme med konstruktive bud på hvordan besparelserne opnås. Programmører er ikke altid så dumme som ikke-programmører gerne vil gøre dem til.
Spørgsmålet er vel også om man som firma er opsat på at tage en hvilken som helst kunde ind uden begrænsinger eller om man er villig til at erkende at nogle kunder er det bedst at sige nej til - Enten fordi de er for nærige til at betale for et produkt man føler man kan stå ved eller fordi de ganske enkelt er for besværlige til at være en god forretning. Min erfaring siger at kunder der virkelig konstant forsøger at presse prisen i bund ved at acceptere at man springer over hvor gærdet er lavest, oftest ender med at blive en tabs-forretning. For det første fordi de alligevel brokker sig når tingene så ikke fungere ordentligt og fordi de samtidigt har forventninger om at når nu man har "skruet på kvaliteten" så får de meget mere end det egentligt er muligt at levere.
Det bedste man kan gøre er at forsøge at forklare kunden hvordan tingene hænger sammen og hvis de ikke vil forstå, så forslå dem at finde en anden leverandør.
For at bruge en bilanalogi så foreslår man jo typisk heller ikke sin mekaniker at han kun skal spænde hjulene fast med en enkelt møtrik for at spare nogle penge.
At blive tvunget til at levere arbejde af en ringe kvalitet er altså demotiverende for enhver, der ser sig mere som håndværker eller videnarbejder end som lønslave.
Ja. Det handler om perspektiv - der skal være en mening med tingene.
Grunden til de fleste af os ikke gider at lave skodkode er fordi, vi ved der kommer en regning senere. Vi tænker ved os selv: Det er ikke det værd. Det her er for dumt. Vi føler os ansvarlig for det vi skaber og for vores virksomhed. For de fleste er det med modstridende følelser når vores (beordrede) handlinger ikke hænger sammen med vores personlige værdier.
Det handler om for lederen at give arbejdet værdi - også på langt sigt. Om ikke andet kan strategien blot bestå i at få lukket opgaven så hurtigt som muligt - for at at kunne tage den næste værdiskabende (spændende) opgave. Anders Raastrup Kristensen udtrykker meget godt, selv om skalaen er en lidt større:
Som topleder er arbejdsopgaven at skabe en drøm eller en vision, som medarbejderne vil være med til at realisere. Det handler om, hvad man som virksomhed skal bidrage til i et større perspektiv
http://videnskab.dk/kultur-samfund/led-arbejdet-ikke-personen
En anden side af samme sag er IT branchen umodne stade - men det har jeg vist skrevet om så mange gange. Jeg vil sparre gentagelserne.
