![Stol aldrig på en udvikler [VIDEO]](https://wernervaleur.com/wp-content/uploads/2018/01/14574.jpg)
I løbet af de 15 år, jeg har arbejdet med softwarefirmaer, har jeg mødt og arbejdet sammen med ufatteligt mange udviklere, og jeg vil i dette blogindlæg beskrive, hvorfor du aldrig skal stole på en udvikler. Det gælder selvfølgelig ikke alle udviklere, men en bestemt type udviklere, der ikke har erfaringer med at kende deres eget og andres domæner og de forskelligheder, der følger med. Blogindlægget og videoen tager altså ikke udgangspunkt i den erfarne og gennemgribende professionelle udvikler, der netop gør det.
Årsagen til, at du ikke uden videre skal stole på alle udviklere, er simpel: Det vil koste dig forsinkelser, du vil tage dårligere beslutninger, og din virksomhed vil potentielt kunne tage skade. Det er hårde ord, så det kræver selvsagt en forklaring. Blogindlægget er primært rettet mod ikke-udviklere, men er du udvikler og allerede nu tænker ”Hold kæft, en arrogant idiot”, så håber jeg, at du læser videre tager en pointe eller to med dig.
Generelt om udviklere
Nogen udviklere ser sig selv som udelukkende rationelle og styret af objektive sandheder, men virkeligheden er, at de i lige så høj grad styres af nysgerrighed og ønsket om at lære noget nyt. Med afsæt i det rationelle kan de derfor have det billede af sig selv og deres beslutninger, at de ved meget om alting, selv på områder, hvor de ikke er eksperter.
Vi stoler grundlæggende på udviklere, fordi de er eksperter, men det er altså ikke ensbetydende med, at de så er eksperter i alt. Det hører til sjældenhederne, at udviklere er eksperter i salg og marketing, ligesom det hører til sjældenhederne, at marketingfolk er eksperter i at kode.
Hvad der er rigtigt og forkert er sjældent entydigt
Man kan argumentere for, at der ikke findes objektive sandheder, hvilket betyder, at ingen af os – heller ikke udviklere – kender det endelige og ”rigtige” svar på tingene. I matematikkens verden kan det godt være, at 1 + 1 = 2, eller at kvadratroden af 3 tilnærmelsesvis er 1.73205080757, men når det kommer til strategiske beslutninger eller satsning på en bestemt målgruppe frem for en anden, bliver billedet sløret. Nogle gange begrænses ens dømmekraft altså af, at man ikke har tilstrækkelige informationer til at træffe en (god) beslutning, og derfor er resultatet behæftet med en høj grad af usikkerhed. Det betyder også, at selvom en udvikler fremlægger verden, som om han var i besiddelse af al tilgængelig information, er det sjældent tilfældet, og det kan marketingafdelingen lære noget af – altså være bevidste om denne sammenhæng; for når en udvikler siger, at det ikke kan lade sig gøre, så er det sjælendt tilfældet.
Grundlæggende har vi stor tiltro til udviklere. De ved noget, som andre ikke ved, ligesom kode er en black box for mange. Derfor er man i en moderne virksomhed dybt afhængig af udviklere, og det fører ofte til, at man tager udviklernes ord for gode varer. Oven i det har man en dyb respekt for deres evne til at kode, hvilket betyder, at man lytter enormt meget til deres inputs og holdninger – for de betyder noget; de tænker over tingene og vil ligesom resten af de ansatte både virksomheden, kollegaerne og kunderne det bedste. Udfordringen ligger i, at udvikling ofte blandes sammen med andre domæner (fx afdelinger eller kompetenceområder) i virksomheden, hvor andre ved bedre. Men udviklernes beslutninger inden for deres felt har enorm betydning for hele virksomheden, hvorfor beslutningerne ikke kun må bero på udviklernes konklusion.
Med ovenstående generelle udfordring i baghovedet kommer her nogle eksempler fra en almindelig hverdag i en it-virksomhed:
Eksempel 1: Vi skal have et nyt kodesprog
Jeg har ofte hørt udviklere sige ”Vi skal bruge et nyt kodesprog”. Dette ønske bunder ofte i to forhold, som dog sjældent er eksplicitte:
– Det interesserer udvikleren at lære noget nyt og dygtiggøre sig inden for nye områder (dette falder ikke nødvendigvis sammen med virksomhedens interesser)
– Udvikleren er god til netop dette sprog (hvilket ikke er ensbetydende med, at det er et godt sprogvalg for virksomheden)
Der er selvsagt også masser af saglige argumenter for at introducere nye sprog (det nye sprog er hurtigere, mere velegnet til at løse problemet eller mere udbredt blandt andre kodere, hvilket fremover gør det lettere at ansætte). Men det understreger blot vigtigheden af at være kritisk, når et nyt sprog skal introduceres. Fx er det ikke sikkert, at det er en god idé at vælge et nyt sprog, som ikke er modent, hvis man skal ansætte udviklere i fremtiden – risikoen er simpelthen for stor, hvis ikke sproget ender med at blive accepteret af andre udviklere bredt og fremadrettet ansættelse derfor bliver svært.
Eksempel 2: Det tager kun en uge
Når en udvikler mener, at det kun tager en uge at omskrive noget kode, så passer det sjældent. Faktisk er det ofte sådan, at du kan gange ethvert tidsestimat med 3. Kodning består nemlig som minimum af både kodning, testning og implementering.
Når først man som udvikler ændrer ét sted, så er risikoen for, at andre ting også skal ændres, meget betydelig. Det betyder, at det, der kun skulle tage en uge, pludselig tager flere måneder eller halve år. Dermed ikke sagt, at beslutningen om ændringen var forkert, selvom det tog langt længere tid, men måske skulle det være sket gradvist. I Billy introducerede vi EmberJS, fordi det kun skulle tage en måned – men det endte med, at vi ændrede mange andre ting sammen med dette nye framework, og dermed tog det faktisk over et år. Om det var en forkert beslutning, vi tog, ved jeg ikke, men hvis jeg havde vidst, at det ville tage så lang tid, ville vi have grebet det anderledes an.
Det er jo ikke i en udviklers interesse ikke at holde, hvad han eller hun lover, men alt for ofte glemmes det (af udvikleren og ikke mindst af andre på teamet), at kodning tager mindst tre gange så lang tid, som man forventer, hvis altså man ikke er en erfaren koder og tager højde for denne faktor tre. Problemet ligger ofte i, at både udvikler og marketingfolk er optimistiske, og ting tager derfor tit langt længere tid, end der lægges op til. Ofte træffes beslutninger efter, hvor lang tid ting tager. Derfor vil prioriteter ofte også ændre sig, hvis noget, der skulle vare en uge, i stedet varer tre uger. Måske ønskede marketingfolkene slet ikke den funktion, eller også ønskede de en helt anden.
Konklusion
Formålet med dette blogindlæg er at sætte fokus på, at selvom udviklere er dygtige, intelligente og kompetente, er deres domæneviden inden for fx marketing begrænset. Den samme begrænsning gælder for mennesker fra andre fagområder. Derfor er det som udvikler og ikke-udvikler vigtigt at anerkende, at man har forskellige roller i en virksomhed, og at respekten for hinandens felter er vigtig. Valg af kodesprog/frameworks kan sjældent besluttes alene af udvikleren, men skal også være en strategisk beslutning for virksomheden. Den gode udvikler kan opstille fordele og ulemper, så en ikke-udvikler kan være med til at træffe det endelige valg.
Der er dog stadig en helt klar opdeling mellem to afdelinger. Marketingafdelingen beslutter, hvordan priserne skal være, eller hvordan kunderne skal tiltrækkes, mens den ikke blander sig i, hvordan kodesproget skal skrives, og hvordan strukturen på koden skal opbygges. Det er selvfølgelig naturligt, at der er input på tværs af afdelinger, men det betyder blot, at der er en større gensidig accept af, at de endelige beslutninger træffes i den afdeling, de vedrører. Hvis beslutningen er på et strategisk plan, er det typisk ledelsen, der har det sidste ord.
Virksomheder bygges af hele teams – ikke kun af marketing eller kun af udviklere: uden marketing intet salg, og intet at sælge uden udvikling. Derfor er mit råd, at du skal lytte og tage udviklerne med på råd, når du har brug for deres input eller medvirken. Træf derefter selv din beslutning efter den viden, som du har.
Når jeg skriver ”Stol aldrig på en udvikler”, gælder det selvfølgelig langtfra altid. Overskriften er derfor på en måde misvisende. Men min pointe er, at du som ikke-udvikler skal være på vagt, når en udvikler fortæller dig det, som du tror er en sandhed, men som ikke er det. Når en udvikler fx vil introducere et nyt sprog eller kode halvdelen af kodebasen om, så vær kritisk og stil oplysende spørgsmål, for det påvirker hele virksomheden og dermed også andet end blot udviklerens eget arbejde.
Er du udvikler, kan du skrive dig op og modtage attraktive jobtilbud:
Mange hilsner
Toke
Indlægget er cool nok, og ret spot on med mange ting.
Men jeg syntes ikke det som sådan er “udvikleren” som den er galt med – det er “typen” af arbejde, der kan være svært at forudsige omfanget af. Det kan sådan set gælde mange typer arbejde, ikke blot udvikling – min erfaring er det sker lige så ofte for eksperter i strategisk foretnings udvikling, iværksætteri osv.
Man kan sådan set kun fuldstændig forudse en process, hvis man har gennemgået den eksakte process før, og har tænkt sig at gennemgå den eksakt samme process igen: men ofte er to processer overhovedet ikke ens selv om man forventer de vil være det (det kan være adskildt af en så lille ting som ‘klienten’ der er forskellig fra projekt til projekt), heller ikke selv om man fra start måske forventer de vil være det.
Sindsyg spændende med forskel på måden en sælger arbejder på, og måden en udvikler arbejde på. Ret spot on.
Overall godt indlæg.
De bedste hilsner,
Dennis O. Madsen
Hej Dennis
Tak for en super god kommentar. For ja, det er svært at estimere noget, som man ikke har prøvet før, eller som man ikke har det fulde overblik over.
Klart nok, at det langt fra er udvikleren, som er skyld i, at tingene tager længere tid. Det er et bånd mellem kunde og udvikler. Eller marketing og udvikler. Det er fælles ansvar, at man sammen får enderne til at mødes.
Fedt at du i øvrigt er enig i blogindlægget.
God weekend.
Toke
Som udvikler ved jeg ikke helt hvordan jeg skal have det med den er post.
Én ting jeg synes du mangler mest er lige præcis pointen med den xkcd du viser (men ikke rigtigt nævner). Noget jeg har oplevet en del, er hvis vi kigger på hvad der sker før det xkcd billede, så har sales and marketing brugt et par måneder på at planlægge, og nogen gange endda allerede reklamere for deres nye geniale koncept. Og når der så er brugt er par måneder på det, så snakker man med udviklerere og beder dem om at lave dén ting. “Oh det lyder som en god ide, og vil måske tage et par uger at lave”, første prototype er klar, “nu skal vi bare lige have lavet den vigtigste del, hjemmeside skal tænke selv og brygge danmarks bedste kaffe ved et simpelt klik” …… Det var så den feature hele konceptet, plan og turnaround projections var baseret på. Og min erfaring er så at det er udvikleren der ender med at være ‘The bad guy’ fordi han bare er idedræber og siger at det ikke kan lade sig gøre, og nu er skyld i at firmaet har spildt så mange penge og tid på at planlægge det hele.
Eller endnu værre, som også ses ofte, ikke-udviklere sætter deadlines uden at konsultere med udviklerne der skal lave den feature. Og hvem får skylden når deadlinen bliver overskredet, selvom der blev sagt fra starten at det meget sikkert ville ske, men… “bare prøv”.
En anden ting, “ændringer”. Jeg har også oplevet alt for meget at folk mangler en forståelse for hvor stor en betydning små ændringer kan have. Så måden ting bliver lavet på er at en feature bliver halvt gennemtænkt, så bliver en udvikler sat igang med opgaven, tager beslutninger der er de bedste for den feature der er bleskrevet. Og så er det ellers bare uger/måneder med “kan vi ikke ændre det her?”, “det var ikke sådan jeg havde i mit hoved at det ville virke”, “vi har ændret lidt taktik så nu…”, “kan du ikke lige prøve at ændre det hele for at se om det her virker bedre?” …… og “hvorfor er du ikke nået længere? Os andre på teamet har knoklet løs for at finde ud af hvordan alt skal virke!”
Sorry, jeg kan godt se hvor du vil hen med den her post, men synes (som ofte med lignende artikler) stadig du er på den ide med at udviklere altid er the bad guys og det er deres skyld deadlines ikke bliver overholdt.
Så, det jeg ser der mangler helt enormt meget er at folk er nødt til at forstå hvor stor en del udvikling er af et projekt. Som sales person har du et “rimelig” klart afgrænset område at beskæftige dig med, og kan nøjes med simple inputs og outputs til og fra andre afdelinger for at have et effektivt teamwork. Det samme gør sig gældende i en del andre områder.
Men ikke udvikling. Hvis jeg som udvikler skal have mulighed for at give bedre estimater, give gode råd, bygge gode systemer, så er jeg nødt til at kende firmaet meget godt, kende til vores salgs strategier og forventinger, kende til vores marketings planer, kende til de længere sigtet planer bestyrelsen har for firmaet. Udviklere kan mere end bare at være nogen aber med en kaffe og et keyboard. Og en ting du også nævner som kan være meget værdifuldt for en forretning: Vi er ofte virkelig nysgerrige og ret hurtige til at lære nye ting, fordi… det er det vores job består af.
Så prøv at forestil dig hvordan det ville være hvis de/den person der står for praktisk at skulle lave det produkt hele din business drejer omkring, ved hvad salgs ideer og forventinger er for de næste 5 år. Vi kan designe systemer med den viden i baghovedet. En ny feature der lyder som en simpel lille test ting, kan let være en langsigtet plan som kun sales kender til, men hvor den viden vil gøre at den feature teknisk skal gribes an på helt anden måde. Og når vi kender til den langsigtede strategi, kan vi komme med meget bedre rådgivning om implementationen af de ideer der skal laves.
Kort sagt så er det min meningen at udviklingsteamet er dem der skal vide mest om forretningen (I firmaet hvor forretningen ér et stykke software i hvert fald). Meget af hvad der bliver lavet rundt omkring i firmaet kommer ned til at en udvikler skal lave noget, ændre noget, fikse noget, svare på spørgsmål om noget teknisk. Hvis vi har den nødvendige baggrundsviden så kan vi gøre vores job meget bedre.
Og hvis folk har bare den mindste interesse i at lære og at blive bedre til deres job, så burde alle også arbejde på at få en bedre ide om det stykke software som firmaet er bygget omkring. Det er lidt nøglen i det her, det stykke software er en så central og vigtig del af firmaet, burde ALLE personer i firmaet ikke have i det mindre bare en ide om hvordan det hænger sammen så de kan tage beslutninger med den viden?
Meget kort sagt: Udviklingsteamet er ofte alt for afskåret fra alle vigtige beslutninger og vigtig viden til overhoved at kunne tage de bedste beslutninger.
Undskyld det blev så langt, men får altså lidt sure opstød når jeg kommer igang med at tænke over hvor skævt det ofte er 😉
Og en anden meget vigtig ting mange skal lære:
Et estimat betyder ikke “fastlagt deadline som jeg basere en masse kritiske beslutninger omkring” 🙂
Et estimat er et gæt fordi der er mange unknown unknowns 🙂
Hej Martin
Super dejligt, at du har taget dig tid til at skrive et så langt svar. Det skal du da ikke undskylde over.
Jeg kan totalt godt følge dig. Jeg har siddet på begge sider af bordet og sidder faktisk mest på udviklersiden. Så selvom jeg i visse dele i indlægget påpeger, at udvikleren kan forbedre sig, så anerkender jeg totalt, at det ikke er her, at problemet ligger. Derfor skriver jeg også afslutningsvis
“Virksomheder bygges af hele teams – ikke kun af marketing eller kun af udviklere: uden marketing intet salg, og intet at sælge uden udvikling. Derfor er mit råd, at du skal lytte og tage udviklerne med på råd, når du har brug for deres input eller medvirken. Træf derefter selv din beslutning efter den viden, som du har.”
Blogindlægget var i højere grad henvist til ikke-tekniske folk, men er selvfølgelig klar over, at udviklere så ønsker at blive hørt.
I forhold til din kommentar, så mener jeg dog godt, at udviklere kan tage et større ansvar og forklare de ikke-tekniske personer, at udvikling er andet end et udstikke nogle løse idéer, for ofte ser jeg, at disse mennesker ikke aner noget som helst omkring et ideelt udviklingsforløb. Så i den henseende er jeg på udviklerens “side”.
I næste uge kommer jeg med et blogindlæg og video, hvor jeg hjælper marketingsfolk med at tale “udviklernes sprog”, som faktisk falder i god tråd med din kommentar. Så glæd dig – forhåbentlig kommer der nogle bedre kunder ud af det i den anden ende, som er lettere at arbejde sammen med 🙂
God weekend.
Mange hilsner
Toke
Hej Toke
Den provokerende overskrift virker og jeg har taget mig selv i ikke blot at læse hele artiklen men også have lyst til at kommentere. Well played 🙂
Jeg er udvikler og har de sidste 15 år arbejdet som freelance webudvikler, konsulent, iværksætter, teammedlem og nu CTO i et startup. Jeg er skyldig i, i mine unge dage, at komme med best-case estimater og har brændt fingrene utallige gange på den bekostning. Estimater er blevet til deadlines (som har kostet nattesøvn) og estimater er blevet til fastprisaftaler (som har kostet på pengepungen). Det tvang mig heldigvis til at dygtiggøre mig i disciplinen at komme med realistiske estimater og til at begynde med var det faktisk ikke så langt fra din regel med at gange med 3. Jeg gangede vist med pi.
“3 reglen” fungerer i øvrigt også i andre discipliner i et startup: når salg forventer at kunne nå målet om 100 nye kunder på 1 måned, så tager det realistisk set 3 måneder. Når marketing forventer at kunne drive en vis trafik ind på websitet så regn med en tredjedel. Eller når vi sætter en forventning om at være break-even efter 1 år, så kan det desværre også være, at der går 3. That’s life. Jeg stoler stadig på både sælgerne og dem i marketing, selvom de ikke rammer plet hver gang.
Jeg er helt enig i – og det er det jeg synes er essensen af dit indlæg – at det er problematisk hvis der tages strategiske beslutninger på baggrund af estimater. Her er et par fif til hvordan du får mere realistiske estimater ud af dine udviklere:
* Lav en “definition of done” som beskriver hvad der er indeholdt i estimatet. Er det “done” hvis det bare er kodet eller er det først “done” når koden er godkendt af en kollega, testet i en browser og deployet i produktion? Er det en større feature er det måske først “done” når support har fået en gennemgang og marketing har annonceret den.
* Afklar om estimatet er ‘effektiv arbejdstid’ eller om det er ‘forventet afleveringsdato’. Altså er der indregnet at den stakkels udvikler også skal være med til diverse møder, rette ‘urgent incidents’, arbejde på andre sideløbende features og spise frokost hver dag. Hvis du får et estimat på estimeret effektiv arbejdstid og oversætter det direkte til en forventet leveringsdato, så bliver du selvfølgelig skuffet.
* Gør det klart, at du ikke er interesseret i at få et ‘lavt estimat’ men at du er interesseret i et realistisk estimat.
Og hvis du tager dig selv i at skulle lave en strategisk beslutning på baggrund af et estimat som udvikleren lavede ‘fra hoften’ mens du stod og ventede, så gå i stedet tilbage til udvikleren og bede ham bruge 15 minutter på at danne sig et overblik over din feature og komme med et estimat og en forventet leveringsdato.
Ovenstående er selvfølgelig bare sund fornuft. Men vigtigt. Og nogle gange glemt. Tak for indlægget 🙂
Jonas for den da! Super gode kommentarer og gode huskeregler. Det nailer netop nogle af de ting, hvor udviklere og marketing taler forbi hinanden. Ingen er forkert på den, men resultatet er blot, at man ikke rammer det, som begge forventer.
Så er helt enig i:
1) Definer, hvad det vil sige at være færdig med noget
2) Hvad beror estimtatet på
3) Definer hvorfor estimatet er vigtigt eller hvad formålet med estimatet er
Fedt og vigtige indspark, du kommer med. Tak for det.
Hej Toke
Godt indlæg set fra den ene side af bordet, salgets – glæder mig til at læse det fra den anden side.
Jeg ser det som to kulture, der mødes; den udadvendte, altid optimistiske, mål og KPI orienteret sælger overfor den introverte, detalje fokuserede og pligtopfyldende udvikler. Det er måske lidt stereotypisk, men det er det billede som jeg som projektmedarbejder gennem flere år har set. Det være sig både i SMV og C20-index virksomheder.
Jeg tror at det er en naturlig udvikling, som en virksomhed gennemgår. Opstarts virksomhederne starter med alle opgaver (udvikling, projektledelse, salg, marketing, bogføring, fundraising) i en eller meget få personer. Her er det ikke vanskeligt at koordinere opgaverne, men som virksomheden få brug for flere ressourcer søges der at ansætte de dygtigste inden for hvert fag: den dygtigste CTO, den dygtigste web designer, den dygtigste business developer, etc.
Men huskes der også at bliver investeret ressourcer til at holde det hele sammen. Hvor er limen, koordinatoren, brobyggeren, katalysatoren (kært barn – mange navne), som kan fordre samarbejdet, sikre retningen og samle op på ting, der falder mellem to stole.
Funderen skal i denne sammenhæng være ærlig over for sig selv, og kende egne kompetencer og passion. Funderen kan let ende med at blive denne katalysator, som holder virksomheden sammen, mens hans passion og kompetence ligger et andet sted, f.eks. som webdesign, networking eller fundraising.
I sagens natur har en katalysator ikke en direkte leverance, hvorfor værdien er vanskelig at mål. Derfor fravælges denne rolle ofter, på trods af det netop kunne fodre et bedre samarbejde mellem udvikling og salg.
Gode inputs, Jesper. Jeg er helt enig. Startups har den udfordring, at de sjælendt ansætter forskellige folk til de samme roller, men derimod giver flere “kasketter” på. Når virksomheden så vokser, skal folk give disse kasketter videre og indse, at opgaver skal fordeles ud på flere hænder.
Med kasketter på flere personer, vil jeg da bestemt anerkende, at der så opstår nye stillinger, som fx projektledere og nogle endnu mere klare linjer mellem afdelingerne.
Tak for input.