Befri dine kunder for dit ego og dårlige undskyldninger

Åh nej, tænker du sikkert, ikke endnu en “smart-guy”, som prøver at højne sig over os andre med endnu en moral prædiken. Stop!
Dette indlæg handler om, hvorfor jeg ser et lys i standard software frem for systemer og software, som jeg selv har tænkt, lavet og hersker over, som jeg kender bedre end mine bukselommer, og som er så fleksibelt, at jeg kan tilpasse det til ethvert behov på meget kort tid.

Først må jeg lige hæve mine barrikader og kort lige nævne, at der er mange følelser involveret i dette emne, og det er altså ikke dem jeg er ude efter at høvle, men nærmest udelukkende at tilgodese den kundeværdi, som kan gå tabt.

Jeg deltog i en debat omkring, hvor vidt det ville være relevant at se på et udbredt grid-system til frontend udvikling og implementering af webdesign. Debatten røg over i, at det var man som udgangspunkt imod fordi, det ville være meget nemmere at lave det fra bunden, så man vidste, hvad man havde med at gøre. Og så kunne man jo også lave det, efter ens behov og krav til fleksibilitet osv. osv.

Det lød meget som mig selv for ca. 8-10 år siden, hvor jeg helt klart også følte mig meget tryg ved udelukkende, at skulle tage ansvar for noget, som jeg selv havde tænkt fra bunden, og lavet som jeg selv, gerne ville have det hele.
Men hvis der er noget, som, jeg synes, jeg er blevet klogere på siden dengang, så er det helt klart, at der ligger en helt vild stor, ja måske nærmest enorm, værdi i, at det ikke kun er mig, som kan udvikle, ændre, optimere og tilpasse systemet.

Den tryghed som jeg høstede ved, at udvikle systemer, som jeg beherskede, er jo en stor forhindring i dag for kunder, som har fået sådan et system. De har i mit tilfælde i mange omgange fået bygget videre på et system, hvis fundament, jeg som udvikler og som sparringspartner gerne så ændret til noget helt andet for nemt, at kunne modernisere den løsning, så den kan være konkurrence dygtig i dag.

Min overbevisning er, at du får kunderne til at købe sig ind i en falsk tryghed, hvis du selv udvikler systemer til dem, som der er ikke er en kontinuerlig massiv udvikling bag, som kan skubbe til udviklingen og holde den inde i modernisering efter de krav og den efterspørgsel, som kunden får i fremtiden.

Min morale er lidt, at du som udvikler giver kunderne 1000 gange mere værdi i, at deltage i forbedring af eksisterende standard systemer end, hvis du lige løste kundens her-og-nu problem med et eget udviklet system.
Der findes ingen undskyldninger, men der kan selvfølgelig være den situation, at det system, som kunden ønsker ikke findes, så er der sjældent en vej udenom.

Deler du samme erfaring som udvikler eller kunde, eller er du uenig med mig i mine antagelser, så løft endelig sløret for din mening og giv emnet lidt feedback i form af en kommentar nedenfor, tak!

,

8 Kommentarer

  • Daniel siger:

    Det virker umiddelbart lidt som sort snak for mig det dér – og jeg er 100% overbevist om at hvis du giver sådan en tale til en kunde – så vil vedkommende føle præcis det samme.

    Du skal overbevise din kunde om at det kun er dig de skal have udviklet deres site hos. At lave det åbent for dem så andre kan møffe sig ind i det er bare ikke optimalt, hverken for dig, dem eller den udefrakommende udvikler. Det vil endvidere virke useriøst for kunden da de vil forvente at der er udviklet noget unikt til dem i første omgang.

    Som du selv nævner så er det nemmere at lave hvis du kender det som du kender din egen bukselomme – en udefrakommende vil have det ligeså, med mindre du kan arbejde strengt ud fra en standard fremsat af andre. Som fx W3C eller en fremsat ISO standard af en tredjepart. Det er en fed ting at kunne, men som udvikler skal man være fleksibel og forudsigende.

    Kan du fx i begyndelsesfasen mærke af kunden at de gerne vil have opdateringer ofte og et site der konstant ændrer sig, så laver man sit arbejde ud fra det. Inkluder din kunde i design fasen og sæt strenge kår til hvordan ting bliver udarbejdet. Laver du fx et CMS så lad dem kun se indholds felter til præcis det de skal have mulighed for at ændre. At gøre det så nemt som overhovedet muligt for kunden og dig selv skaber en tryghed for jer begge der er til at føle på.

    Tryghed for kunden er at vide at det virker som det skal og føle at det er lavet præcist sådan for deres skyld. Tryghed for dig, håber jeg, er at vide at det her det kan jeg, det fungerer som jeg vil have det og jeg ved hvad der skal til for at gøre det endnu bedre.

    En lille notits, hvis du benytter et open source CMS som framework kan du naturligvis ikke kræve at andre ikke må udvikle på det med mindre du også hoster det for kunden. Men laver du et system fra bunden og op skal du på ingen måde have det dårligt med det. Faktisk så skal du være på dupperne og specificere hvad præcis du sælger til kunden. For vil du have andre får fingrene i din kildekode? Vil du have de kan distribuere det andetsteds? Er det DIN kode eller er det kundens kode? Laver du et færdigt system fra bunden og op, host det selv, hold kilden for dig selv.

    Det er dine overvejelser, derfor din beslutning.

  • Marcus Wendt siger:

    Kevin, det du skriver giver glimrende mening.

    Hvis der findes noget standard-software der løser xx% af opgaven på en god måde og tillader dig at custumisere dig resten af vejen til de 100% uden hack-to-hack, så sparer du en hulens masse tid og hvis du valgte noget godt standard-software så får kunden langt mere værdi og du giver dem en system der kan vedligeholdes og bedre vokse med kundens behov.

    Dit valg af standard-software er rigtigt vigtigt her – du skal vælge et som du tror på mht. teknik og fremtid. Vælger du det du tror mest på og som har de rette features ifht. opgaven, så vil du give kunden den bedst tænkelige professionelle vejledning og du har nogle glimrende salgs-argumenter på hånden: her er den mest sikre løsning, nu og fremover.

    Hvis dit standard-software ellers er godt og du er godt hjemme i dét og de udviklings-værktøjer der skal bruges ved customerisering, så vil du måske opdage at du bliver meget meget mere effektiv, end dengang du selv styrede hele kodebasen.

    Jeg tror den tankegang er ret let at sælge til kunder. Måske skal du slås med lidt vanetænkning omkring hvilket standard-system man skal vælge, om open source er “farligt” etc.

    … du som udvikler giver kunderne 1000 gange mere værdi i, at deltage i forbedring af eksisterende standard systemer

    Tænker du på open source her?

  • Marcus Wendt siger:

    @Daniel: du skriver

    For vil du have andre får fingrene i din kildekode? Vil du have de kan distribuere det andetsteds? Er det DIN kode eller er det kundens kode?

    Nu kommer jeg fra et open source projekt og så skær ovenstående unægteligt lidt i øjnene.

    Ved mindre du bruger noget open source software licenseret under “ortodoks GPL”, så er svarerne på de spørgsmål er ikke én tøddel forskellig fra alm. kommercielt software: Al kode du laver ‘oven på’, ‘uden om’ og al den konfiguration du laver er din eller kundens ejendom (det aftaler I bare selv) og du er ikke tvunget til at dele din kildekode med nogen.

    Composite C1 som jeg arbejder på er frigivet under MPL (red.: ikke GPL som Marcus først skrev men rettede i en senere kommentar) – og den giver dig disse friheder. Hvis du vil lave dine udvidelser om til moduler og sælge dem som kommerciel close source, så gør du bare det.

    Eneste undtagelse: Hvis du vælger at downloade kildekoden til det pågældende open source software, laver ændringer i selve systemets kildekode og sætter kunden til at køre på din helt egen version, så skal du publicere dine ændringer.

    Sidstnævnte – at tage et standard-system og så pille inde i dets inderste dele – er dog i sig selv en dårlig idé. Det er et vedligeholdes-mareridt i al fremtid, ved mindre kunden accepterer at vinke farvel til opgraderinger i standard-softwaren. Så problemet er ikke at man skal publicere sin kildekode, men at man valgte det forkerte system (den feature man så kritisk ønskede eksisterede ikke, og kunne ikke tilføjes ‘udefra’ == ikke det rette system).

    I et closed source system havde du end ikke denne mulighed – i open source har du den, men det er generelt en skidt idé at ændre ting i maven på standard systemer.

    Hvorfor er det så overhovedet interessant at standard-systemet er open source, og kildekoden let at downloade?

    – hvis producenten går konkurs eller begynder at producere møg kan et nyt open source projekt tage over og overtage føringen. Frihed er et godt salgs-argument.
    – hvis man har et problem er det langt lettere at se hvad der foregår, hvis man har kildekoden – du bliver mere effektiv som udvikler
    – man kan meget meget lettere finde evt. fejl i standard-systemet og sende info eller ligefrem rettelser til producenten, og herved få løst tingene hurtigere
    – der er ingen fare for at man bliver låst til én producent

    “Open source” vs. “Closed source” vs. “custom coded” beslutningen bør efter min mening tage således:

    Findes der et open source system, med en licens med kan li, der har alle de ønskede features, og let og kønt kan tilpasses hvor det kræves?
    JA: brug det.
    NEJ: Findes der et closed source der opfylder kravene og er prisen rimelig?
    JA: brug det.
    NEJ: Kod det selv.

  • […] This post was mentioned on Twitter by ʇpuǝʍ snɔɹɐɯ, Kevin Steffer. Kevin Steffer said: Blog: Standard system vs. special udvikling, hvorfor standard giver mere kundeværdi læs http://bit.ly/9XJzce […]

  • Kevin Steffer siger:

    @Daniel, dejligt med klare holdning, tak! Dog er jeg noget uenig med dig i at kunder ikke forstår værdien i standard-software som er tilpasset kontra special udviklet software af den simple årsag at hvordan er standard-software egentlig blevet standard, det må jo have haft et udgangspunkt i at være et projekt, som kunne løse specifikke behov.

    Tilmed tror jeg, at din tankegang om, at man som udvikler skal holde koden for sig selv er ved at forældes. Jeg har flere gange stødt på kunder som jeg har lavet et website til uden standard-software, at de simpelthen ikke kan forstå, at det skal koste penge, hvergang de skal have lavet en ny type information på deres site – de kan jo se og høre andre kunder og konkurrenter selv kan i deres systemer.
    I sådan en situation er ens eget udviklet software bare bagud for den udvikling der drives af kræfterne bag standard-software. Og der har mistet konkurrence dygtighed.

  • Kevin Steffer siger:

    @Marcus, jeg tænker ikke specifikt på Open Source software, når det gælder at deltage i forbedring af eksisterende systemer, men jo, klart, det jo noget nemmere, at bidrage til Open Source systemer.

    Hvis man bidrager til closed-source systemer, så er der et noget andet “mindset” bag, hvorfor man overhoved skulle bruge tid på det, bl.a. har jeg flere gange været med til at stille nogle krav til standard systemer, som system-leverandøren har været villig til at udvikle, fordi kunden havde nogle helt konkrete behov, som vi ikke kunne løse på andre måder.
    Det er jo dér at kunden for alvor føler sig specielt særlig godt behandlet.

    Helt konkret kan jeg også nævne, at jeg har fået startet et projekt, som egentlig var tænkt som et ISV modul i Dynamicweb CMS, men har foræret modulet til Dynamicweb på den betingelse, at det blive et gratis modul.

    Hvorfor overhovedet forære sådan noget væk tænker man sikkert.
    Tankegangen bag er ret simpel, jo stærkere og rigere et system er på standard funktionalitet jo flere kundebehov kan systemet dække over og jo flere løsninger kan der sælges.

    Hvis jeg sad på dette modul (et beskedent modul) og kunder skulle købe det, og jeg skulle vedligeholde det med support og videreudvikling, så ville prisen for modulet gøre modulet værdiløst. Det ville blive for dyrt. Modulet har ikke potentiale til en så stor volumen, at licens for modulet kan finansiere udviklingen – men det kan være en dør-åbner for salg af helt nye løsninger.

    Kan du se idéen i det?

  • Når kunden har valgt en til at levere deres webløsning, så er det fordi de har tiltro til at denne leverandør løser opgaven bedst muligt. Vi ved alle at det man udvikler i dag er forældet i morgen, så derfor er jeg også stor tilhænger af at man så vidt muligt baserer en løsning på standardsoftware, som løbende vil blive vedligeholdt.

    Hvis man kan nå 80% af vejen med standardsoftware, så bør man overveje nøje om de sidste 20% nu også er så uundværlige. Ofte kan man ikke undgå at der skal specialudvikling til, men jo mere der udvikles, jo mere er der at vedligeholde.

    Det er muligt at nogle kunder sætter stor pris på at få udviklet helt unik funktionalitet til deres løsning, men sådan er det nu ikke med de kunder jeg har kontakt med. De vil som regel gerne have sikkerhed for, at det de investerer i, det er noget der virker – også om et år, så hvis der i forvejen er andre der anvender det, så kan de sove mere trygt om natten.

    Som udvikler er jeg heller ikke interesseret i at implementere et unødvendigt komplekst system til en enkelt kunde. Jeg mener heller ikke at en kunde på nogen måde skal føle sig bundet til en leverandør af denne grund. Kunden skal fortsætte samarbejdet, fordi man har leveret gode løsninger, ikke fordi man har leveret dårlige løsninger.

    Keep it simple :)

  • Jeg synes, Kevins indlæg gi’r rigtig fin mening, og afspejler en bevægelsen som mange programmører/webudviklere igennem tiden har gennemgået.

    Jeg kan også godt forstå Daniels protektionistiske pointe, men jeg ved også godt, hvem af de to, jeg ville lægge min ordre hos.

    Mange programmører elsker at udvikle fra bunden — og det er simpelthen bare spild af tid, penge og ressourcer i 9 ud af 10 tilfælde.

    Alt godt,

    Kasper

Skriv et svar

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>