Kristjan Wager

  • Jeg bliver lige nødt til at adresserer din kommentar om at han er for dum til at erkende at han er dum. Dunning-Kruger handler på ingen måde om intelligens, kun om færdigheder indenfor et område – man har et for lavt færdighedsniveau til at vurdere sine færdigheder i forhold til andre menneskers færdigheder.

    Hvis man vil læse mere om Dunning-…[Read more]

  • Så er det tid til en boganmeldelse, denne gang af The Expert Beginner af Erik Dietrich, som er en e-bog baseret på en række af Erik Dietrich’s blog posts (startende med denne: How Developers Stop Learning: Rise of […]

    • Jeg bliver lige nødt til at adresserer din kommentar om at han er for dum til at erkende at han er dum. Dunning-Kruger handler på ingen måde om intelligens, kun om færdigheder indenfor et område – man har et for lavt færdighedsniveau til at vurdere sine færdigheder i forhold til andre menneskers færdigheder.

      Hvis man vil læse mere om Dunning-Kruger har jeg skrevet en blogpost på engelsk tilbage i 2009: http://kriswager.blogspot.dk/2009/05/dunning-kruger-effect.html

      Mht. expert beginner, er det rigtigt at det er et udslag af Dunning-Kruger, men ikke kun – man kan råde bod på Dunning-Kruger ved at øge sine færdigheder. Expert beginners vil ofte aktivt undgå at dette, da det jo bringer deres faglige kompetence i tvivl.

  • Lad os tale lidt om arkitekter – her bestemt i en IT-mæssig betydning.

    Det at være en arkitekt er ikke en beskyttet, eller særlig veldefineret for den sags skyld, titel, og det er ofte en titel man får i kra […]

  • Nu er sikkerheden i et offentligt IT-system igen i vælten – denne gang er det til Tingbogen. Ekstra Bladet skrev Kæmpe dansk database lagt ud på nettet: Hemmelige adresser kan let søges frem, hvor de indleder art […]

  • Jeg betvivler ikke et sekund at tvangsdigitaliseringen er den primære grund til anvendelsesgraden, men det er efter min opfattelse ikke hele grunden, hvilket er det jeg prøvede at argumentere for i min oplæg.

    Der var et oplæg vedr. Digital Post og hvordan digitaliseringen var gået på konferencen, og der blev det faktisk sagt at det ikke var s…[Read more]

  • Jeg tilbragte et par dage i sidste uge på Dansk ITs konference Offentlig digitalisering 2015, hvor jeg, og alle de andre fremmødte, kunne høre dels om hvordan det går med den offentlige digitalisering og hvad […]

    • Jeg betvivler ikke et sekund at tvangsdigitaliseringen er den primære grund til anvendelsesgraden, men det er efter min opfattelse ikke hele grunden, hvilket er det jeg prøvede at argumentere for i min oplæg.

      Der var et oplæg vedr. Digital Post og hvordan digitaliseringen var gået på konferencen, og der blev det faktisk sagt at det ikke var så meget de ældre som fravalgte, men lige så meget de unge.

      En anden ting de nævnte var at den store udfordring nu er at få folk til faktisk at læse deres beskeder. Det er her brugervenlighed mv. må stå sin prøve.

  • Hvis man har et Linux device med Bash installeret (og hvem har ikke Bash installeret på deres Linux device?), så er det på tide at få patched den. Det sammen gælder jeres Unix servere.

    Det viser sig at der er […]

  • Når man har arbejdet med at kode igennem nogle år, har man en tendens til at udvikle en slags kode-filosofi, som i høj grad er formet af de projekter man har været involveret i og de roller man har haft i sin karriere.

    I starten af min karriere var jeg ofte involveret i projekter efter de var løbet af sporet i en eller anden forstand, og skulle hjælpe til med at rette op på dem. Nogle gange var det sammen med de personer som var involveret i udviklingen inden jeg kom på projektet, andre gange var det som en del af et nyt team som overtog projektet.

    Uanset hvordan det så ud organisatorisk, bestod en stor del af mit initiale arbejde i at sætte mig ind i koden, og finde ud af hvad der udestod/var problemer med.

    Ofte var koden præget af at udviklerne havde været under pres i noget tid, således der ikke havde været afsat tid til nødvendig refaktorering og nedbringelse af teknisk gæld. Der var også ofte en pukkel af fejl i koden, som var blevet skubbet foran udviklingen (en vane jeg er stærk modstander af), som skulle løses før man kunne komme i gang med at løse de egentlige problemer med koden.

    Jeg har tidligere refereret til udviklingsformen på denne type projekter som error-driven software development, og den er kendetegnet af at være reaktivt snarere end proaktivt.

    Når man tager alt dette i betragtning, er det måske ikke overraskende at jeg har en kode-filosofi som jeg omtaler som ”debug venlig kode”. Det består af en række tiltag som jeg har oparbejdet igennem årene, som gør det nemmere for mig selv, og andre, at debugge koden, hvis man skal lede efter problemer.

    Nedenfor følger en beskrivelse af mine tiltag, som jeg håber kan være til hjælp fra andre. De tager i nogen grad udgangspunkt i at man arbejder med eksisterende kode, og ikke er i gang med at starte helt fra bunden, men selv hvis man er i et greenfield projekt, mener jeg stadigvæk at de kan bruges.

    Ok, nok baggrundssnak, lad os kigge på hvad man kan gøre.

    Begræns scope på metoder
    Alt for ofte oplever man metoder på hundredevis af linjer og med stribevis af ansvarsområder. Disse danner en barriere som er svær at overkomme når man skal danne sig et overblik over koden, særligt når man skal løse et problem.

    I stedet bør man afgrænse metoder til kun at indeholde en funktionalitet. Dvs. at en metode til hentning af data fra en database ikke også bør smide den i en cache og konverterer den til et andet dataobjekt. Vælg i stedet at lave en metode til hver af disse funktionaliteter, som så kan kaldes når de skal benyttes.

    Generaliser metoder
    Dette burde ikke længere være nødvendigt at sige, men det er det desværre.

    Hvis man har implementeret en metode som understøtter en given funktionalitet, og bagefter skal bruge den samme type funktionalitet i en anden sammenhæng, bør man se om man ikke kan generalisere metoden, således man kan nøjes med at bruge den et sted.

    Det giver mindre kode at vedligeholde, og det minimerer antallet af steder man skal kigge efter en given fejl.

    Sigende navngivning
    Metoder, klasser, parametre mv. bør have sigende navne, således man ikke er i tvivl om hvad man arbejder med.

    Hvis man har en Person klasse med et CPR nummer i, så kald den pågældende variabel CPR nummer, og ikke ID nummer. Hvis man på den anden side skal håndtere forskellige typer af ID numre, så lad være med at kalde variablen CPR nummer, selv om det er det mest udbredte ID nummer man støder på i Danmark.

    Som et slags supplement til dette, så bør man også være enige om en fælles navngivningstandard på tværs af systemer som benytter hinanden. Dette gælder især domæne specifikke begreber, hvad enten de er på dansk eller engelsk.

    Hvad man ikke skal gøre er at overdrive. Hvis det er tydeligt fra kontekst hvad en variabel gør, så lad vær med at komme med lange sigende navne, men hold det kort og præcist.

    Brug lokale variable
    Dette er vist et punkt Martin Fowler vil være uenig i, men det er nok sjældent han har debugget andre folks kode.

    Hvis man indsætter et metodekald som parameter i en anden metode, f.eks. methodX(methodY(Z)), kan man ikke umiddelbart se hvilken en metode det er som giver en fejl, uden at gå ind i hver af dem. Hvis man i stedet først kalder den ene metode, og derefter den anden, vil man ved normal debugging kunne se om det er den ene metode eller den anden som giver problemer, uden man skal bruge unødvendig tid.

    Så, i stedet for ovennævnte eksempel, gør følgende
    Var A = methodY(Z)
    methodX(A)

    Kod defensivt
    Dette er nok en af de minde oplagte punkter, men det er faktisk en vigtig del af debug venlig kode.

    Defensiv kode er kode hvor man forventer at koden vil blive brugt forkert, f.eks. ved at den får forkert input data, og koder derefter, bl.a. ved at verificere at input data er korrekt, og smide sigende fejlbeskeder når de ikke er det.

    Ved at man verificerer input data, viser man hvad man forventer, især i forhold til null-værdier, og det er en enorm hjælp for andre som senere skal fejlsøge.

    Ensartet adfærd i koden
    Jeg arbejdede engang på et projekt hvor der var en ToString() metode i noget central kode, som altid påsatte noget tekst for enden af tekststrengen som den dannede ud fra objektet den var tilknyttet. Eller rettere, den påførte variablen som teksten blev dannet ud fra, en tekststreng for enden.

    Det vil sige at resultatet af metode kaldet varierede alt efter hvilken gang metoden var kaldt.

    Dette er problematisk af mange grunde, bl.a. det var en uventet bi-effekt for dem som kaldte metoden, da det ikke er en del af den generelle adfærd for ToString() metoder, men det gjorde det også svært at fejlsøge, da fejlen var afhængig af om den pågældende metode var blevet kaldt før på det pågældende objekt.

    Lad være med at bryd gængse normer for en given metode, i dette tilfælde ToString(), og lad være med at lave metoder som giver forskelligt resultat, selv når anvenderen tror der benyttes samme parameter.

    Test
    Dette burde ikke være nødvendigt at skrive, men unittest og integrationstest er vigtige når man skal debugge og rette fejl.

    Hvis der er gode test, er det muligt at foretage rettelser med en forvisning om at der ikke lige pludseligt kommer uventede bivirkninger, som ødelægger andre dele af koden.
    Såfremt der ikke er test i forvejen, bør man implementere dem i forbindelse med man foretager rettelser til koden. De kan være et vigtigt værktøj til debugging, og de er, som sagt, et godt værktøj til at evaluere bivirkninger af koderettelser og refaktoreringer.

    Kommenter din kode
    Der er mange som mener at kodekommentarer er spild af tid (se f.eks. her), men ikke jeg. Jeg er en varm fortaler for meningsfulde kodekommentater.

    Det vigtige i denne sammenhæng er ordet ”meningsfulde”.

    Der er ikke noget mere ligegyldigt og forstyrrende end kodekommentarer som forklarer hvad koden gør. Det skulle da lige være kodekommentarer som forklarer hvem der har skrevet/rettet koden. Det første kan vi se i koden, det andet kan vi se i vores source control.

    Den slags kommentarer gider jeg med andre ord ikke kigge på.

    Hvad jeg i stedet vil se, er kode kommentarer som forklarer hvad præmisserne for noget kode har været. Hvorfor er der blevet truffet de valg som der er blevet truffet. Det kan være evt. work-arounds som er nødvendige pga. begrænsninger i andre systemer, et hurtig oprids af hvad en given funktion skal gøre, rent forretningsmæssigt (evt. med referencer til hvor man kan læse mere), eller basale antagelser (”vi forventer at folk benytter decimal systemet og ikke imperial units”)

    Løbende, nødvendig refaktorering
    Som jeg skrev i starten er der ofte en del teknisk gæld på projekter som er løbet i problemer, men selv i velfungerende projekter vil der være områder af koden som kan trænge til refaktorering. Når man render ind i sådanne kode, giver det god mening at refaktorere den når man er inde og løse fejl og lignende. Ikke blot giver det god mening, men det kan være nødvendigt for at gennemskue hvor fejlen optræder.

    Hvis man er i sådan en situation, skal man naturligvis refaktorere.

    Pas dog på at man ikke bare begynder at refaktorere unødvendigt. Alt kode kan forbedres, men man skal også sørge for at prioritere opgaverne så de giver mest værdi.

    Og husk lige at indsætte test før du refaktorerer, så du er sikker på koden fungere som den skal bagefter.

  • ThumbnailJeg har igennem min karriere primært arbejdet med større systemer, ofte i form af portaler, hvor der har været en del integrationer til andre systemer. I mange tilfælde har disse andre systemer været under […]

    • Det er nogle rigtig gode pointer du har. En af mine kæpheste mht. system/service afhængigheder er at man bliver nød til både at kigge på hvordan system/service ansvarområderne (boundaries) SAMT ens arkitekturelle tilgang (f.eks. er valget af lagdelt integration – tit med en ESB i midten – virkelig det bedste?) – alt sammen med det mål for øje at skabe så lav kobling mellem services – se f.eks. http://qed.dk/jeppe-cramon/2014/02/01/soa-synkron-kommunikation-data-ejerskab-og-kobling/

      Portaler(ne) er tit der hvor dækket for alvor møder asfalten og der hvor de skæve ansvarsområder og den medfølgende feature envy viser sig. Lige som du, har jeg også set min del af portal projekter og min erfaring er at den klassiske tilgang, hvor et portal team som står i pølseenden og skal integrere X antal services til en sammenhængende helhed, oftest er en kamp der tabes fordi integrationerne altid bliver færdige forsent og oftest ikke matcher med behovene. Resultatet bliver spaghetti integration.

      Et godt gammelt citat fra Einstein siger, at definitionen på galskab er “at blive ved med gøre det samme, men forvente et anderledes udfald”. Så næste gang nogen står overfor at skulle lave en ny “portal” kunne det være en kærkommen anledning til at prøve nogle alternative mønstre/løsninger, så som consumer driven contracts eller composite applications (nogle gange også kaldet Composite UI’s). Jeg planlægger at skrive mere om Composite applications i den næste blogpost i min microservice serie.

  • Jeg er helt enig i dine anbefalinger, selv om jeg dog vil sige at The Mythical Man-Month ikke helt klarer tidens tand så godt som f.eks. The Pragmatic Programmer. Dog er der kapitler/artikler i den som med god grund er blevet klassikere, og som altid vil være sande (her tænker jeg f.eks. på “No Silver Bullet”).

    Clean Code og Clean Coder kan hel…[Read more]

  • Når man arbejder i IT-branchen, oplever man et konstant pres på både at hele tiden holde sig bredt opdateret på sit felt, og at være skarpt fokuseret på det område eller projekt man arbejder med.

    Dette er […]

    • Jeg er helt enig i dine anbefalinger, selv om jeg dog vil sige at The Mythical Man-Month ikke helt klarer tidens tand så godt som f.eks. The Pragmatic Programmer. Dog er der kapitler/artikler i den som med god grund er blevet klassikere, og som altid vil være sande (her tænker jeg f.eks. på “No Silver Bullet”).

      Clean Code og Clean Coder kan helt klart også anbefales. Mit eneste forbehold i den sammenhæng er at man skal have basis på plads før man går igang med dem. Med andre ord, skal man først og fremmest lære at kode, før det giver mening at kaste sig over dem.

    • Ser frem til at følge med i dine bogvalg. Det er begrænset hvor meget tid man har i døgnet, så det vil være værdifuldt at få sorteret de bøger fra som ikke giver udbytte og istedet få anbefalet dem som er tiden værd.

  • Note: Jeg har tidligere skrevet et tilsvarende indlæg på engelsk på min anden, engelsksprogede, IT-blog.

    Det sker regelmæssigt at jeg snakker om konferencer med andre folk i IT-branchen. Samtalen falder naturligvis på de konferencer som de har været til og/eller de konferencer de gerne vil til.

    Alt for ofte oplever jeg, at min samtalepartner fortæller mig at vedkommende ikke regner med at kunne tage på konference, da virksomheden som vedkommende arbejder for, har et begrænset træningsbudget, som også dækker konferencer.

    Når jeg hører dette, kan jeg ikke lade være med at tænke, at den pågældende virksomhed tænker meget kortsigtet.

    Det er forståeligt at en virksomhed, som er økonomisk presset, skal være forsigtig med omkostninger, men fra-valg af konferencer (og øvrige uddannelsesaktiviteter) er noget som vil koste dyrt på lang sigt.

    Min erfaring, og erfaringen fra alle dem jeg har snakket med omkring dette emne, er at de personer som beder om at komme til konferencer, normalt tilhører gruppen af ansatte, som en virksomhed meget gerne vil beholde. Ikke dermed sagt at virksomheden gerne vil af med de folk, som ikke beder om konferencer, men det virker som om innovation indenfor virksomheden har en tendens til at udspringe fra personer, som kan lide at søge inspiration andetsteds, og hvilket bedre sted end konferencer til det? Hele formålet med konferencer er jo, mere eller mindre, at dele viden og inspirere andre (og naturligvis sælge produkter, men lad os ignorere det i denne sammenhæng).

    Med andre ord, så er konferencer en fantastisk måde at introducere nye ideer og metoder til en virksomhed eller afdeling – i hvert fald så længe de personer som gerne vil gå til dem, får lov.

    For de personer som deltager i konferencer, er det ofte en vigtig, nærmest vital, måde at få nye ideer og input på, da de andre deltagere på konferencen er samme type mennesker, som kan tilbyde nye indblik i problemer, ofte som led i en uformel samtale. Jeg tror vi alle har prøvet situationen hvor vi har hørt en fortælle om noget, og din hjerne pludselig siger “KLIK”, og du indser at du har prøvet at løse problemet på den helt forkerte måde. En konference giver deltagerne hundrede, hvis ikke tusinder, af muligheder for at få sådanne “KLIK” oplevelser.

    Så med andre ord, så er min anbefaling at overveje det meget nøje før man siger nej til at en medarbejder går til en konference. Hvem ved hvilke input man misser ved at spærre for muligheden? Og så er der naturligvis det faktum at mange folk i branchen betragter konferencer som noget essentielt for deres faglige udvikling, så man risikerer at miste medarbejderen, hvis denne ikke får lov til at gå til konferencen.

  • Det er lige gået op for mig at mit svar til dig af en eller anden grund aldrig blev publiceret – faktisk kan jeg ikke finde det noget sted. Beklager meget det sene svar.

    Fordele ved at være IT-konsulent er, set med mine øjne, en tæt kundekontakt som man sjældent oplever som fastansat. Dertil kommer det at man i højere grad har skiftede proje…[Read more]

  • Når man snakker med folk i IT branchen, er man, som konsulent, ofte en lidt udskældt størrelse, da der er mange folk som har dårlige erfaringer med dyre konsulenter, som ikke har leveret det som var lovet/forventet, og da slet ikke til den pris som det blev lovet til. Når man spørger ind til erfaringerne lidt bredere, viser det sig dog ofte at de samme personer også har haft positive erfaringer med konsulenter, men at de er blevet overskygget af de negative erfaringer.

    Dette er naturligvis uheldigt, set med mine øjne som IT konsulent, men det vidner også om et bredere problem i konsulent-branchen, hvor det som kunde kan være svært at vide hvad man får for sine penge, før man rent faktisk har brugt dem.

    Vi konsulenter er i virkeligheden ikke meget bedre stillet. Når vi kommer på et projekt med andre konsulenter, ved vi ikke nødvendigvis hvad vi går ind til. Dette er bl.a. fordi der hverken er nogen klar definition af hvad en konsulent er eller nogle eksplicitte krav til hvad en konsulent kan.

    Netop pga. den manglende klare definition, og de manglede krav, er der mange folk som bliver konsulenter, uden at forstå hvad de går ind til, med utilfredse kunder og frustrationer til følge.

    Denne blogpost er en slags reaktion på dette. Det er et forsøg på at opridse hvad der, efter min mening, kan forventes af en konsulent fra kundernes side. Jeg har forsøgt at forklare det på en måde hvor jeg håber det kan hjælpe folk med at se om konsulent-vejen er noget for dem, og at se hvor der er områder de skal gøre en indsats.

    Dette er en blogpost jeg har overvejet at skrive i flere år nu og som jeg flere gange er blevet opfordret til at skrive af andre, da de mener der er behov for en sådan blogpost.

    Som altid, men mere eksplicit nævnt end normalt, må jeg fremhæve at dette er mine personlige holdninger, og på ingen måde repræsenterer nuværende eller tidligere arbejdsgivere eller kunder.

    Definitionen på en konsulent

    Som jeg skrev ovenfor, er der ikke nogen fast definition for en konsulent, men for at man kan skrive en blogpost som denne, bør der alligevel være en definition man taler ud fra.

    Konsulenter er mange ting, inkl. en jobtitel i det offentlige, men i denne blogpost snakker jeg om en person som udlejes til organisation for at løse en IT-mæssig funktion, det værende sig programmering, test eller projektledelse. Personen kan indgå i et team af konsulenter eller være alene.

    Konsulenter kan enten være ansat i et konsulenthus eller være selvstændige (evt. igennem en brooker).

    Konsulenter kan som sagt indgå i et team som har ansvaret for et projekt, men de adskiller sig fra projektdeltagere i projekter solgt af et projekthus. Grænsen mellem disse typer roller er dog ikke klar, og det kan derfor være svært at sige om en person er konsulent eller projektdeltager – min afgrænsning går på hvorvidt kunden eller projektet er i fokus, men mere om det senere.

    Konsulentens egenskaber

    Set med mine øjne er der en række egenskaber som skal være på plads før man kan sige at der er tale om en god konsulent. Jeg vil liste dem nedenfor, og så uddybe dem hver for sig.

    Fundamentet er på plads
    Kompetent
    Udadvendt
    Omstillingsparat
    Lærenem
    Pragmatisk
    Kan på håndtere stress
    Kundeorienteret
    Ærlig
    Politisk forståelse

    Der er sikkert mange flere egenskaber som man kunne ridse op, og jeg kunne da også selv finde på flere, men disse mener jeg er ganske dækkende.

    Fundamentet er på plads

    Når en virksomhed eller organisation hyrer en konsulent, bør de forvente at konsulenten kender de gængse teknologier, metodologier og principper indenfor sit område.

    Hvis en konsulent er hyret til at hjælpe et system, kan kunden med nogen ret forvente at personen kender et eller flere af de gængse udviklingsværktøjer indenfor sit felt, de mest udbredte frameworks, principperne bag unittest og continuous integration osv.

    Når man er grøn konsulent kan det naturligvis være svært at have så bred en viden som det forventes, og man må derfor ty til genveje, så som at holde sig orienteret vha. blogs eller læse bøger om emnerne. Mit forslag vil altid være at man som minimum sørger for at have læst The Pragmatic Programmer.

    Kompetent

    Det er en udbredt misforståelse at konsulenter er eksperter. Det er de ikke nødvendigvis, og da slet ikke på alle områder. I langt de fleste tilfælde er der ikke brug for eksperter, men ”kun” kompetente individer, som kan hjælpe med at skaffe fremdrift/resultater.

    En konsulent har ofte erfaring fra en lang række lignende projekter, og kan derfor hjælpe det nye projekt med at lære fra tidligere fejl og successer, som konsulenten har været del af.

    Dette gør at selv en ikke-ekspert ofte kan flytte et projekt en hel del.

    Dog vil selv nok så meget erfaring ikke hjælpe, hvis konsulenten er inkompetent – derfor kravet om kompetence fra konsulentens side.

    Udadvendt

    Den type roller som konsulenter får, involverer interaktion med andre mennesker, herunder kundens ansatte og evt. slutbrugerne. For at dette skal fungere, er det nødvendigt at konsulenter er udadvendte og socialt velfungerende. I hvert fald hvis der er tale om et kundeforhold som varer mere end et par timer.

    Mange konsulenter har deres daglige gang hos de samme kunder i årevis, og opnår derved en tæt relation til dem. Dette kan naturligvis hjælper samarbejdet, men man skal dog altid huske at der er tale om et kunde/leverandør forhold, og der derfor bør være ting som holdes helt professionelt (f.eks. alt i relation til kontrakter).

    Omstillingsparat

    Er der en ting som kendetegner de roller jeg har haft på kundernes projekter igennem årene, er det at jeg sjældent er endt op med at have den rolle som jeg egentligt var blevet hyret ind til.

    Hvis man som konsulent ikke er klar til at skifte rolle eller arbejdsområde alt efter behov, er det ofte begrænset hvad en kunde kan bruge én til. Ofte vil det behov kunden mener de har, ikke være det reelle behov, og hvis man som konsulent ikke er i stand til at observere dette, og omstille sig til det egentlige behov, vil ofte medføre frustrationer og utilfredshed fra begge sider.

    Det er også nødvendigt at man er klar til at omstille sig mellem projekter, og ikke blot hele tiden bliver ved med at referere tilbage til hvordan man plejede at gøre ting i sit sidste projekt. Man bør naturligvis viderebringe de gode erfaringer, men man skal passe på at man ikke er for bagudskuende.

    Dette leder meget naturligt hen til næste punkt.

    Lærenem

    Som konsulent arbejder man ofte inde for et eller flere overordnede områder. F.eks. arbejder jeg med projekter i den offentlige sektor og i de finansielle brancher. Dette gør at man skulle tro at man hele tiden arbejder med det samme, overordnet set. Dette er langt fra tilfældet.

    Hvert projekt indenfor den offentlige sektor eller i de finansielle brancher har hvert deres domæne – det værende sig lovgivning, processer eller produkter – og det er naturligvis nødvendigt at få en hvis forståelse for dette, når man skal gennemføre et projekt der.

    Derudover bør man som konsulent (og udvikler i øvrigt) holde sig orienteret omkring den teknologiske udvikling indenfor sit område, og sørge for at man forstår de nye frameworks mv.

    Det sidste er et ikke-trivielt arbejde, og kræver en del indsats, især i starten af ens karriere, men det kan svare sig på længere sigt, da man får en langt bedre forståelse for hvad der er af løsningsmuligheder i de forskellige projekter. En effektiv måde at gøre dette på, er at deltage i gå-hjem arrangementer, brugergrupper og naturligvis konferencer og kurser.

    Pragmatisk

    Når man er ude hos en kunde kan man ofte se en lang række ting som der burdes rettes op på.

    I sådanne situationer er det fristende at prøve at rette op på det hele, i stedet for blot at gøre det man er blevet bedt om.

    Det skal man lade være med.

    Som konsulent skal man have en pragmatisk tilgang til ting, og lade være med at prøve at redde hele verdenen på en gang. Man skal sørge for at man får gjort det man er blevet hyret til, samtidig med man sørger for at man ikke bidrager til teknisk gæld, dårlige vaner mv.

    I forbindelse med man gør det man er hyret til, er det ofte muligt at rette op på nogle af de ting som er problematiske (eller i det mindste mindske problemets omfang), og det skal man naturligvis gøre. Når man så er færdig med sin opgave, kan man rejse problemerne man ser, og komme med forslag hvordan de kan håndteres fornuftigt.

    Man vil ofte opleve at kunden er ganske villig til at lytte til en, og gerne vil have at man hjælper dem med problemområderne. Meget mere end hvis man rejste problemerne så straks man kom på projektet, eller hvis man havde prøvet at rette op på alle tingene fra start.

    Det er kunden fordi man har bevist at man er i stand til at udføre opgaverne på en fornuftig måde, og man respekterer prioriteringen af opgaverne.

    Hvis man havde forsøgt at løse alle problemerne fra start, ville man ofte have gjort dem værre, i hvert fald i en periode, og man ville ikke have haft den fremdrift som kunden kunne forvente.

    Kan på håndtere stress

    Dette giver vel egentligt lidt sig selv.

    Når en kunde hyre en konsulent, er det fordi de ikke selv har ressourcerne til at håndtere opgaven. Dette bliver som regel først klart når det er ved at gå galt, og deadlines mv. truer.

    Det er, med andre ord, et stresset miljø man træder ind i som konsulent.

    Det skal man være i stand til at håndtere. Ellers går man selv ned med stress.

    Kundeorienteret

    Som jeg skrev tidligere, kan det være svært at skelne mellem en projektdeltager og en konsulent, da der ofte vil være en del overlap i deres opgaver og kvalifikationer. Jeg mener dog at der er en væsentlig forskel, og det er hvorvidt de er kundeorienteret eller projektorienteret.

    Hvis man er projektorienteret, er det projektet (og dermed projektkontrakten) som går forud for alt andet. Man vil hele tiden fokusere på projektets fremdrift frem for alt andet.

    Hvis man er kundeorienteret, er det kundens behov som er fokus, og som er det man prøver at opfylde fremfor alt andet.

    Der er naturligvis et stort overlap mellem kundens og projektets behov, men der er også situationer hvor projektets behov er i strid med kundens reelle behov.

    Som konsulent bør man være kundeorienteret.

    Hvis man er ansat i et konsulenthus har man naturligvis også en forpligtelse til sin arbejdsgiver, men min erfaring er at man tjener dem bedst som konsulent, ved at sætte kundens behov i fokus. Dette skal naturligvis ske under de rammer kontrakter mv. giver.

    At sætte kundens behov i fokus er også at sørge for at man ikke spilder deres ressourcer. Dvs. man skal sørge for at man ikke længere er hos dem, hvis de ikke længere har behov for en. Faktisk vil jeg gå så vidt at jeg vil sige, at en konsulents fornemmeste opgave i forhold til kunden, er at gøre sig selv redundant, således at de ikke længere har brug for en.

    Hvis man arbejder målrettet mod dette, vil man ofte finde at det medfører andre opgaver hos samme kunde, da de sætter pris på den tilgang, og derfor gerne vil bruge en igen.

    Ærlig

    Med ærlighed kommer man længst siges der, og i konsulentbranchen er det i nogen grad rigtigt.

    Man kan komme langt med uærlighed, f.eks. ved at lyve om ens kvalifikationer, men før eller senere er der nogen som finder ud af det, og så bliver der sat en stopper for det.

    Når man er ærlig omkring sine kvalifikationer mv. undgår man at man skal prøve at bluffe sig igennem situationer eller at nogle afslører sine mangler.

    Så, hvis man ikke kender til en teknologi eller har erfaring indenfor et område, skal man stå ved det.

    Politisk forståelse

    Projekter foregår i organisationer, og i organisationer er der stort set altid politisk spil kørende.

    Som konsulent skal man være opmærksomt på dette.

    Man skal ikke selv deltage i det politiske spil, men man bør prøve at forstå hvad der foregår, og hvad de forskellige fraktioner ønsker at opnå, og hvordan det kan påvirke ens rolle/projekt.

    Hvis man ikke gør det, risikerer man at man pludseligt bliver gidsel i et politisk slagsmål, og ens udtalelser bliver brugt ude af kontekst.

    Dette er særligt vigtigt hvis man har en senior rolle i et projekt eller i kundens organisation.

    Sammenfatning

    Jeg har prøvet at give et oprids af de kvaliteter som jeg synes er vigtigt for konsulenter (baseret på min definition af en konsulent), og jeg håber det åbner lidt op for hvordan jeg, som konsulent, ser IT-verdenen og min rolle i den.

    Er der noget som I mener jeg tager fejl omkring, eller noget som jeg mangler, vil jeg meget gerne høre om det i kommentarerne.

    • Godt blogindlæg. Kan du fortælle lidt om hvilke fordele og ulemper der er ved at være IT-konsulent – i modsætning til at være fastansat i en IT-virksomhed?

    • Det er lige gået op for mig at mit svar til dig af en eller anden grund aldrig blev publiceret – faktisk kan jeg ikke finde det noget sted. Beklager meget det sene svar.

      Fordele ved at være IT-konsulent er, set med mine øjne, en tæt kundekontakt som man sjældent oplever som fastansat. Dertil kommer det at man i højere grad har skiftede projekter. Sidst men ikke mindst, kan man som konsulent ofte mærke at man gør en forskel – der er trods alt en grund til at man er kommet på projektet.

      Ulemper er at der er et højt arbejdspres, mange deadlines og høje forventninger/krav. Derudover er der også en løsere tilknytning til sin arbejdsgiver end hvis man er normal fastansat. Som konsulent sidder man ofte hos kunden fremfor “hjemme” på kontoret.

  • Ja – den faktor du nævner er bestemt vigtig i forståelsen, og er en faktor jeg planlægger at adressere ved en senere lejlighed.

    Og ja, jeg lægger op til diskussion om hvorvidt agil udvikling altid er godt nok, […]

  • Når man, som jeg, arbejder med offentlige IT-projekter, bliver man ofte mødt af spørgsmålet i overskriften, med det implicitte ”i forhold til det private” hægtet på. Det er et spørgsmål som er problematisk af […]

  • Mit problem med bitcoins er at det er et interessant computer-relateret problem som gør at IT-folk elsker det, men det ignorere hvordan valuta faktisk virker. Langt de fleste som har økonomisk indblik betragter […]

  • Det blev i 2012 besluttet at det offentlige grunddata skulle samles, og benyttes på tværs af offentlige systemer, og samtidig blive stillet til rådighed for offentligheden.

    Finansministeriet sagde dengang:

    Når […]

  • Det er ikke det formål som er fremført som argument for at have en IT-havarikommission – her er argument at den skal komme med anbefalinger til ændringer, så man kan undgå gentagelse af fejl/ulykker, helt […]

  • Frank, jeg tror faktisk ikke det har noget at gøre med den offentlige kultur. Jeg tror det er et spørgsmål om at offentlige styrelser mv. ofte er store organisationer, og det er dér skoen trykker. Der er masse af […]

  • Load More