Hei og velkommen til LØRN - 1500 lærings historier fra de beste fremtids tenkerne og skaperne. På LØRN.tech kan du lytte, lese eller se alt innhold gratis, men registrer deg for å få tilgang til personaliserte læringsstier, sertifikater og mye mer.

Silvija Seres: Hei og velkommen til denne kunnskaps serien, som LØRN lager sammen med konsulentselskapet Bouvet. Gjennom fem samtaler skal vi utforske noen av deres mest spennende prosjekter og kundehistorier innen teknologi, produktutvikling og ledelse. Med meg i dag har jeg Einar Fredriksen, som er konsulent ved Bouvet. Og så får du fortelle oss littegrann flere detaljer om deg selv, Einar. Til å begynne med. Hvem er du? Profesjonelt og privat?

Einar Fredriksen: Begge deler. Ja, jeg er Einar Fredriksen. Jeg jobber nå i Bouvet og det har jeg gjort i fire året og en uke, faktisk. Før det så jobbet jeg som utvikler og avdelingsleder på i Roxar som lager ting for 3D modellerringssystemer for oljeindustrien. Så har jeg en godt skjult del av livet der jeg var fire og et halvt år i militæret. Ganske mange som jeg har kjent i 20 år blir ganske overrasket hvis jeg forteller at jeg er Fenrik. jeg kan glemme det selv. Og før det så hadde jeg et liv på skole og videregående og sånn.

Silvija: Du underviser av og til på Luftforsvarets tekniske skolesenter?

Einar: Jeg gjorde det. Det var jobben min i militæret. For jeg tok utdanningen min der. Jeg tok teknisk fagskole også hadde jeg pliktår i to år der jeg ble instruktør. Det var min vei ut av skogen rett og slett. 

Silvija: Opp i skyene. Fysisk og i overført betydning. Nå i Bouvet, hvorfor Bouvet?

Einar: Ja si det. Jeg jobbet med en som synes det var enormt bra å jobbe i Bouvet. Også prøvde jeg meg der og. Jeg hadde aldri trodd jeg skulle bli konsulent. Med dette å være konsulent har jeg alltid sett for meg at du kommer inn i et team, så skal du komme med hele svaret også skal du hjelpe en bedrift også skal du trekke deg ut igjen. Akkurat der har jeg veldig liten tro på at det fungerer, så har jeg heller aldri jobber som konsulent. Jeg har funnet ut at for å være med på dette med langsiktige ting så må du jobbe langsiktig med kunder som konsulent også. Og når jeg fant ut at det var sant så ble jeg værende. Vi får se hvor lenge det varer. Jeg tror det blir en stund. 

Silvija: Ja, jeg er veldig imponert over Bouvet og hvordan dere jobber med kunder. Digger alt fra navnet til kidsa koder som Simen er så stor drivkraft bak. Men du Einar, har du en eksentrisk hobby som dine kollegaer kan spørre deg om neste gang dere drikker øl sammen? 

Einar: Eksentrisk hobby. Jeg ble spurt om hobby. Jeg synes det er veldig vanskelig med hobby, det er så mange ting jeg vil være med på at jeg har ikke tid til en hobby.

Silvija: Det kan godt være at jobben er en hobby, selv om jeg vet ikke om du finner så mange øl-venner på den. Eller kanskje det er nettopp det i Bouvet? Men spennende, du. Vi skal egentlig snakke faglig. Dette er en samtale, ikke intervju, ikke debatt, ikke foredrag, men en toveis samtale hvor vi driver å dytter hverandre litt i en felles retning og den retningen som jeg tror vi kommer til å gå i. Det er nettopp det du begynte med, og det er langsiktig perspektiver i konsulentbransjen, og særlig når man bygger komplekse systemer for komplekse kunder som ikke helt vet hva de skal ha. Og konsulenter er ikke bare teknologileverandører, men også strateger, produkt, innovatører og kanskje forretningsutviklere for kunden. Og dette starter ofte med ett prosjekt, og jeg tror de beste konsulentselskapene er de som klarer å bygge det der fra et prosjekt til produkt. Kanskje til en hel business som da ofte har en plattform assosiert med seg. Og jeg har lyst å spørre deg litt hvordan. Hva har du lært? Var du tenkt i den retningen? Hvordan går man da fra et prosjekt til et produkt?

Einar: Ofte så begynner det med en bestilling på et prosjekt. Det er svært vanlig at noen som egentlig ikke er veldig interessert i data har et ønske om å få et dataprodukt som hjelper de. Også vil du bare få laget dette. Hvor mange timer tar det å lage denne løsningen vil man gjerne vite. Og få laget den. Også skal den fungere i all evig fremtid. Og sånn er det ikke helt lengre. For når du har ting i skyen så beveger jo ting seg hele veien. Så hvis du først får laget en løsning som kjører i skyen så må man være litt forberedt på at denne må kontinuerlig oppdateres. Det må kontinuerlig finnes et team som kan hjelpe deg med å bygge videre på den. Også må du være sikker på at den faktisk løser det problemet som man skal løse. Og det problemet kommer og til å forandre seg over tid. For når du først bestilte den løsningen så hadde du en med arbeidsmetodikk og et behov for å løse. Men de som jobber med det samme problemet nå vil trenge at denne løsningen utvikler seg sammen med oppgavene de har. 

Silvija: Jeg tror du er inne på noe helt sentralt. Jeg har bare lyst å understreke det du sa nå i forhold til at folk kommer IT-konsulenter og andre konsulenter fordi de har opplevd at de har et konkret behov og de ønsker å løse det så fort og så billig som mulig. Men gjennom å løse det opprinnelige problemet så oppdager man ofte at dette problemet er under utvikling. For verden er jo i enorm rask utvikling. Og den utviklingen skaper kanskje veldig spennende nye muligheter. Så denne læringsløypa som man går opp gjerne sammen som konsulent og bestiller. Det er noe av det mest magiske man kan oppleve i konsulentbransjen.

Einar: Og det er nødt å være samarbeid mellom bestiller og utvikler. Og det handler og veldig mye om å få bygd seg opp en tillit til at dette får man til sammen. Hvis en spør om et fast pris prosjekt så er jo det fordi en gjerne kommer første gang til konsulenthuset, også ber om noe og få laget noe. Så ber du gjerne om fastpris fordi du er nødt til å ha noe å forholde deg til og du kjenner ikke konsulenthuset. Du vet ikke hvordan det kommer til å levere, og derfor må du ha noe håndfast av at hva kommer dette til å koste. For ting kan koste uendelig mye, og det må en ikke komme inn i. Men hvis man da har fått opparbeidet seg en tillit og et godt samarbeid med konsulenthuset over lang tid, så vet du at ting begynner å fungere og du kan begynne å eksperimentere på en helt annen måte. 

Silvija: Jeg tror at det jeg har lyst å spørre deg egentlig om er to verktøy. Ikke sånn veldig godt kjente verktøy, men nyttige. Det ene er MVP - Minimum viable product, et sted må man starte. Og hvordan man utvikler denne MVPen til et fullvoksen produkt og kanskje etter hvert en plattform via Scrum metoden. Og det sentrale her er at dette skal ikke skje helt adskilt fra kunder, at man skal utvikle i et lite lukket konsulent team. Kanskje til og med offside, men at dette foregår i god kobling med bestilleren. Og at bestilleren skal være med på reisen og utvikle seg selv underveis også. Så den bestiller rollen i utvikling tror jeg er et kjempeviktig poeng her.

Einar: Og MVP er jo et fantastisk godt konsept. Da jeg leste om det første gang så var det genialt. For de som ikke kjent med en sånn løsning så handler det om at i stedet for å si hva vil du ha, hva er det minste du kan bruke, og få det ut i et brukbart system som ikke virker på utviklerens maskin, men som virker på bestillerens maskin. Så har du den kjente tegningen fra rullebrett til full bil. Også er det også litt viktig å vite at det er Henrik Nyberg som kom opp med den tegningen og har laget en ny bloggpost der han skriver om hvordan du skal make sense of making MVP, der han egentlig anbefaler å ikke bruke en MVP lenger, men kanskje et bedre ord vil være earliest test eller et eller annet. På grunn av at man ser også blant bestillere så har en gjerne gått over til å tenke fossefall med MVP har jeg sett. Jeg har sett fossefalls diagrammer der det står MVP 1, MVP 2, MVP 3 også skal det planlegges og utføres på samme måte som en gjorde med Fossefall. Det er veldig viktig at vi som er inne i dette har en tillit, eller opparbeider en tillit og kjenner godt til hva dette faktisk betyr og da diskutere med kunden om hvordan leverer man dette. Hva var intensjonen og hvorfor snakker man om MVP? Og få de med på utviklingen.

Silvija: Jeg må komme med noen innrømmelser selv og jeg, data-dame, og jeg kan mye om plattformer i teorien. Også skal jeg bygge min egen plattform her i lille LØRN. Også har jeg gått på alle mulige smell, også får jeg til og med spørsmål fra folk om ja, men Silvija, når skal dere bli ferdig? Og som kunde da som jeg har lært er at du blir ikke ferdig. Men for hver feilet utvikling så kommer du deg nærmere et drømmemål. Det er ikke bortkastet penger, det er ikke bortkastet tid, det er nødvendige evolusjoner. Og det er ikke alltid sånn at du utvider det du hadde. det er godt mulig du må kaste hele skiten ut av vinduet, men du har lært deg noe som du kommer bare til å bruke en uke på å utvikle i neste runde i stedet for et halvt år sånn som forrige gang. For nå skjønner du hvordan den biten henger sammen. Og dette har med at du trenger verktøy som er lette å eksperimentere med. Ikke kjør deg inn i den mest høyskala Azure AWS kybernetes greien, men et eller annet som er lett å eksperimentere med until you get lovable tror jeg at jeg har lært er kjempeviktig.   

Einar: Og ikke minst tror jeg at en del av det produktet du har er også teamet. Det tar litt tid å bygge opp et team som du kan snakke enkelt med. Hvis du hopper fra team til team så må du begynne helt på start. Og selv om du kanskje har feilet med selve produktet så har du bygget opp veldig mye kunnskap hos teamet så det er lettere å forstå hva du egentlig trenger. Så du ikke går på den samme smellen en gang til.  

Silvija: Det er utrolig viktig det du sier nå. Man prøver seg på forskjellige utviklingsteam, og som du sier starter man fra scratch, også blir man stadig mer frustrert for at man gjentar seg. Men du må jo få med flere på den reisen du er med på selv. 

Einar: Og det kan kanskje være litt vanskelig med ordet konsulent. For konsulent ligger litt i forventningen at det er noe du skal bruke i en periode også skal du ut. Jeg vil utfordre mange til å gå litt i seg selv og vite om det er det man egentlig vil. Det er mange andre ekstra fordeler du får med konsulenter. Det er jo at de kanskje har et større miljø med andre kunder som de og får lære av, men ikke vil klare å bygge opp internt. Hvert fall vil jeg tro det er vanskelig for mange bedrifter å skape et godt IT-samarbeid med kunnskapsdeling med andre bedrifter. Selv om det finnes mange gode måter å gjøre det også på. Med hele open source opplegget som er helt fantastisk. Og som vi ikke kan få lært nok av. 

Silvija: Du det som et moteksempel dette med waterfall, hva er problemet med waterfall og hva er alternativet? 

Einar: Det jeg har hørt waterfall kom fra en beskrivelse var et essay som beskrev hva type software utvikling som ikke fungerte. Også begynte han å forklare hvordan den prosessen var, også skrev han det som waterfall. Også beskrev han det på førstesiden. Også lagde de det som en prosess og glemte å lese hvorfor fungerer ikke dette. 

Silvija: Jeg kan ikke definisjonen, men min intensjon bak det er at det er en produktutvikling hvor du drar inn et produkt fra fossefall til fossefall med definert funksjonalitet. Så når du er ferdig med dette så starter du på det neste. Mens det vi opplever er jo at du går jo tilbake til opprinnelsen og du kan ikke ha ting som forsteiner seg. 

Einar: Veldig mye er gjerne at greien er at det er sykt vanskelig å klare å finne ut hva du har lyst til å ha. Og hvis du ser for deg det og klarer å formidle det til noen andre sånn at de ser for seg det samme - og selv om du har klart det så skal det være mulig å lage det på en rimelig måte. Det er noe som et fossefall vil kreve. I mange prosjekter så kreves jo det. Hvis du lager en oljeplattform med betong så må du sikre at det funker første gangen. Med software utvikling så har vi den muligheten at vi kan gå å endre kode på en enormt mye lettere måte. Og da må vi utnytte det til å snakke sammen om hva som er enklest. Lage litt her nå, også ser vi hva vi skal utvikle i neste steg. Og vis meg hva du har. Det er enormt stor forskjell på hva en bestiller klarer å tenke seg av hva vil jeg ha til det neste hvis du får noe å klikke i selv. At en løsning virker hos de. Åja, det er sånn ting henger sammen ja! Det klarer du ikke å se for deg hvis du bare får en tegning.

Silvija: Det å tegne disse frontend greiene. Og en annen viktig læring for meg var hvor forskjellig du tenker når du lager et system som noen andre maskiner skal bruke, eller når du lager et system som mennesker faktisk skal bruke. jeg har alltid tenkt at det vanskelige her er algoritmer og server side og sånn. Skalering og sånn. Men det å forstå brukeropplevelse, brukervennlighet, det har jeg undervurdert fullstendig. Også har jeg alltid tenkt at samme greie som design. Det er noen folk med noen fargestifter og post-it-lapper. Også snakker vi litt om design-thinking og sånn også er vi ferdig. Men det viser seg at det er utrolig vanskelig. Det er nettopp det du sier. For du prøver å forstå hva er kjernen av det jeg leverer som verdi i produktet mitt.

Einar: Der har jeg en liten sånn anekdote. Jeg fikk mitt aha-moment i UX når jeg fant ut at konen min ikke visste hva alt tab gjør. Da hadde vi vært gift i over 10 år. Og det å klare seg i 10 minutter på en pc uten alt-tab klarer jeg ikke å forstå. Så jeg tenkte du er jo helt ute. Også tenkte jeg at jeg hadde en god og morsom historie om konen min som var så ubrukelig på pc, også tenkte jeg å fortelle den historien til folk, så er det enormt mange som da vil svare alt-tab? Hva er det det gjør? Så det er helt på det nivået. Vi tar så utrolig mye for gitt vi som sitter og elsker å trykke på datamaskinen i 20 timer i døgnet.

Silvija: Du kommer fra en verden, ikke sant, hvor den knappen hadde en enormt viktig funksjon for det du skrev og den koden du skrev. Også er vi i en verden hvor den er fortsatt der, men folk gjør noe helt annet med pcene sine i dag. 

Einar: Men alle hadde hatt en mer effektiv dag på pcen hvis de hadde brukt alt-tab i stedet for å klikke rundt med den musen hele tiden. 

Silvija: Men du Einar, hjelp oss nå å oppsummere. Fra prosjekt til produkt, hva er forskjellen?  

Einar: Forskjellen er at når man er i prosjektutvikling så er det veldig mye snakk om hvor lang tid ting tar og når ting er ferdig. Og det bruker man mye tid på i utviklingsmetodikken vår også. Hvis en går all inn med scrum så skal en estimere hver enkelt oppgave. Det tar enormt med tid. Og en ting er at det tar mye tid, men det tar også enormt mye fokus. Kan man ikke heller bruke den tiden på å diskutere hva man skal lage i stedet for hvor lang tid det tar? Også i tillegg lyver man mye for seg selv når vi estimerer. Vi sier hvor lang tid tar det å kode akkurat den? Men du kan ikke ta med den dopausen folk tar når de skal utvikle en ting i estimatet. Men den er der. Og veldig mange ting er med i estimatene for hver enkelt ting som skal lages. Også sitter man på slutten av sprinten og enten får skryt eller negativ tilbakemelding om du oppnår etter sprinten basert på hvor lang tid ting tok. Ikke om du lagde noe bra. Hvis en går videre til å tenke på dyktig i alt så tenker jeg litt langsiktig. Jeg tenker at en har laget et produkt som skal virke og da vil du at det skal fungere i all mulig fremtid og. Jeg synes NAV sjefen sa det så bra nettopp så jeg på nettet. Med en gang du har blitt ferdig med et prosjekt så har du i grunnen et nytt legacy prosjekt. Det var kanskje ikke det som var intensjonen, men vi har lagt enormt mye legacy prosjekter. Som og er veldig farlig nå. For nå ligger disse rundt på nettet og er usikret og masse sårbarheter i. Så det tar masse tid.

Silvija: Einar? Forrige IT-direktøren i NAV, Lars Torbjørn Larsen er en av mine virkelig store forbilder innenfor styring av store prosjekter, og en av sitatene hans som jeg bruker hele tiden. Offentlig sektor bekymrer seg ofte for dette med konsulentbruk, også skal man kutte ned. Men de kommer alltid til å trenge konsulenter. Jeg mener at en statsviter burde være god på statsvitenskap og ikke på IT-plattformer. Men også en statsviter må bli en god bestiller. Så det Thorbjørn pleide å si er at du må ha peiling for å kunne kjøpe peiling. Og denne rollen eller relasjonen nærmest mellom gode konsulenter og gode bestillere tror jeg det er noe gull som ikke er forstått godt nok. Hva tenker du om en god langsiktig relasjon mellom dyktige bestillere som forstår problemet og dyktige konsulenter som jobber med løsningen på problemet på en langsiktig måte også blander inn litt DevOps i dette her? 

Einar: Du hadde satt av 24 timer, var det det du sa? Det går litt tilbake på forsvinningen. Hvis bestiller blir flinkere til å bestille som at vi har lyst til å ha noe langsiktig, også bygd det opp med noe smått også ser man hva det blir på sikt. Nå snakker vi om fra prosjekter over i produkter. Hvis vi kommer videre på plattform etter hvert så vil vi lage noe som kan bygges videre på. Det er en helt fantastisk rant på nettet fra 2011 av Steve Yegge som jeg vil anbefale alle å finne frem. La han fortelle om hvordan han kom fra Amazon og over i Google der det aller meste fungerer mye bedre i Google, men noe var mye bedre bedre i Amazon. Og det er hvordan de produktene du lager fungerer mot hverandre. Hvordan systemer skal snakke sammen, og da hovedsakelig via APIer og at du kan bygge en plattform over på det. Så kort fortalt så sa han at alle som går å snakker med regnskapsavdelingen i stedet for å kalle APIet til software avdelingen, de får sparken. Hva fører det til? Og tanken sånn som jeg forstår det da er at det er det som førte videre til AWS. Denne lille bok butikken klarte å bli AWS med å tenke plattform tidlig. 

Silvija: Og her betyr rett og slett et system hvor ting er plugget sammen. Det må være noe grunnlag med noen prinsipper. Der kommer kanskje Amazon sine utviklingsprinsipper og ledelsesprinsipper inn. Også er alt pluggbart, eller?

Einar: Ofte så tenker vi gjerne at en har lyst å lage gjenbrukbare komponenter. Det er kjempevanskelig å lage gjenbrukbare komponenter for neste gang den komponenten trengs så trenger du kanskje noe nytt, og da må du oppdatere den hele veien. Og det går, og det er veldig lurt å lage gjenbrukbare komponenter, men hvis du i stedet for klarer å gå neste, neste steg og tilby denne gjenbrukbare komponenten som en plattform med et team som hjelper deg litt med hvordan det kan brukes, så har du både i dette plattform teamet noen som har som jobb og tenkesett å videreutvikle og gjøre denne plattformen stabil og lett å bruke. Også har du og en stabilt team som vil hjelpe deg litt i gang med hvordan den kan brukes. Og derfor sitter folk å spiller spill på Facebook fordi Facebook har blitt en plattform som bare ikke løser plattform, men Facebook sin egen klient er vel bare det vi tenker som Facebook. Men de ligger oppå en plattform som alle utviklere kan bruke til å lage masse greier på. Og hvis vi kommer dertil så lager vi noe som vil fungere veldig lenge til helt andre ting enn vi først hadde tenkt med den samme koden.  

Silvija: Og det er veldig viktig her. Jeg tenker også det er noe med data og dataanalyse og evnen til å utvikle ting på toppen av de dataene på tvers av disse tjenestene som er greien med plattformen også. Men når du kommer dit at du har en greie som er åpen for fremtidig vekst og utvikling kanskje med tjenester du ikke tenker på i dag, men skal tenke på om et år. Da begynner du å ha et system som skalerer på helt nye måter enn bare antall transaksjoner eller et eller annet som vi måler i dag. Og det er kjempespennende hvis IT-konsulenter kan være med på å utvikle dette. For dette er jo fremtidig business for de fleste kunder. 

Einar: Og hvis du klarer å få ut en plattform når du er som en bestiller så har du laget noe du kan bruke videre i neste omgang selv om det viste seg at den første bestillingen din kanskje var noe du ikke hadde lyst til å ha. Eller det viste seg at det var feil tenkt. Også gjør du det rent menneskelig sett mye lettere for utviklere i sin daglige jobb. Det er en bok nå som heter Team Topologies som snakker om hvordan en bør organisere en hel organisasjon. Topologies.

Silvija: Topologies. For en matematiker er typologi veldig gøy. Jeg liker grafer. Men det er veldig gøy. Vi trenger 24 timer, men det har vi ikke. Da blir noen veldig strenge på oss begge to. Men jeg har lyst å legge inn et par bøker. Så min gave tilbake til deg - og det er godt mulig du har vært borti dem, jeg vet ikke. Men jeg er teknolog og jeg sliter veldig med å være god leder. Og det å forstå effektiv ledelse særlig av disse plattform selskaper og den nye businessen. Der har jeg hatt stor glede av to Silicon Valley bøker - vanligvis blir jeg helt sliten av dem, og det ble jeg her og. Men likevel, alle bør lese dem. og den ene heter Working Backwards, og det er to stykker som har vært i ledelsen i Amazon som skriver ikke noe bittert, men veldig kunnskapsrikt om disse 9 ledelsesprinsippene til Jeff Bezos og hvordan de egentlig oppstod og hva var effekten og læringspunkter underveis. Utrolig interessant lesing. Og den andre - enda mer usannsynlig heter No Rules eller noe sånt fra Netflix sjefen og hans HR direktør som snakker om en helt annerledes måte å bygge opp disse teamene. Hvis du gjør jobben din til alle forventninger så får du sparken. Med en god sluttpakke. Men hvis du leverer over forventning - de går etter toppen av markedet. Det er forferdelig konkurranse fokusert og amerikansk, men de betaler langt over markedsprisen til folk. Tar bare de beste og sørger for at de fortsetter. Men samtidig masse friheter de gir folk, og masse ansvar som følger med på dette her. Veldig interessant. Jeg vet ikke hvordan man gjennomfører dette i praksis, men interessante ledelsesbøker. 

Einar: Gjorde de det i Norge?

Silvija: Ja nettopp, passer ikke så veldig bra med våre kulturelle verdier. Men kjære Einar, jeg vil spørre deg om to ting til før jeg slipper deg. Og det er to ting som du har nevnt før vi begynte å snakke og jeg synes det er veldig spennende temaer. Nå har vi snakket litt om dette fra prosjekt til produkt til plattform. Og poenget her er å tenke på en måte som skaper fleksibilitet, åpenhet og kanskje også gjensidig forretningsforståelse og teknisk forståelse mellom bestiller og leverandør. Tema to som du har to minutter på dreier seg om strukturkapital mellom prosjekter. Et av de problemene vi har som konsulenter er at vi leverer et prosjekt, går til neste også blir det så mye som forsvinner i løse luften i den overgangen. Hva kan man gjøre? 

Einar: Det vi har holdt på med veldig mye i mitt team er når man alltid har laget noe nytt så har vi prøvd å tenke på hvordan kan vi gjøre dette sånn at det vi lager akkurat nå blir lettere neste gang vi gjør noe tilsvarende? Hvis man skal lage en nettside så vet man at den nettsiden skal opp å kjøre og ha en blank side. Kanskje med en påloggingsboks. Også skal en kjøre på den skyløsningen som våre kunder har. Da kan en veldig lett gå rett inn å lage det fra denne også neste gang man skal gjøre det samme en gang til så begynner man fra scratch. Men samtidig er det laget noe - når du er kommet dit at du tenker nå er vi ferdige med det generelle, da tar du en kopi av det eller sier hvor du har versjonshistorikken så du er klar til å bruke den igjen neste gang. Også deler du den med andre. Det tenker jeg er enormt viktig. Det har vi sett utrolig mye nytte av. Og få dokumentasjon. Vi har en veldig enkel onboarding greie i GitHub hos oss der første oppgave er når du begynner som ny i teamet så må du gå gjennom den og oppgaven din er å forbedre den. Så du får aldri et ark der det står hva du må gjøre. Din oppgave er å se hvor langt du kommer med denne og legg til det som mangler. Og det kan vi gjøre i prosjektene også. Alltid legg til hos den du henter hos og på den måten får du delt kunnskap der og da. Også kan andre bruke den hvis de har behov for det. 

Silvija: Kjempespennende. Du snakket om noe som heter dox code? Hva er det for noe? 

Einar: Det høres så teknisk ut, men det er veldig, veldig enkelt. Det er veldig ofte når du skrive dokumenter så skriver vi dokumenter i Word også legger vi det i Sharepoint og der blir de liggende. Og hvis du er heldig så finner du dine egne dokumenter. Og hvis du får dine egne dokumenter så vil du aldri endre det. Behandler du dokumenter akkurat som du gjør med kildekode og får det inn i versjonshistorikk, da må det gjerne være et tekstformat som passer med versjonshistorikk. Det kan ta veldig veldig kort tid å lære. Og da har du pull requester der du kan lage forslag til endring på dokumentasjonen din også få noen andre til å se på om det sånn det skal være også tar du det inn så det blir den nyere versjonen. 

Silvija: Du vet du hva? Det var akkurat dette vi mangler i LØRN. For vi har et veldig god Google Workplace, men det har blitt et sort hull etter hvert. Det er så mye der. Og det er der. Men det er noe med å forstå logikken til den som har plassert ting og hvor det er. Så vi har noen linker som vi bruker alle sammen hele tiden. Men det er masse gull som forsvinner fordi det er mangel på felles forståelse i strukturen. Så hvis vi hadde litt streng holdning til at dette er strukturen, dette er eierskapet, sånn håndterer vi det, sånn har du ansvar for å jobbe med. Akkurat som med kode, så ville dette vært mye bedre. Så der har jeg lært noe kjempenyttig i dag også. 

Einar: Det har gitt meg sånn posttraumatiske vedlegg på mail syndrom. Jeg blir helt gåen når jeg får et vedlegg på mail i stedet for. Kan ikke vi bare endre det i en master? 

Silvija: La oss ikke gå i mail og vedlegg. Men det siste, og det er også et utrolig fint poeng, vi tar det fort. Innpakning av IT-prosjekter. Og det henger på en måte litt sammen med akkurat det du snakket om nå. Jeg tror vi IT-folka er flinke til å levere kode, også er noen av oss mer opptatt enn andre om hvor ryddig det er og hvor forståelig det er for andre. Hvor elegant er det? Men det å lære litt fra marketing bransjen om å formidle på en vakker måte hvilken verdi det er du får fra oss kjære kunde. Litt sånn champagne faktor. 

Einar: Og der er litt fy fy til oss utviklere. For vi får en bestilling vi skal lage. Du skal lage noe også lager du akkurat det som kun er produktet. Så glemmer man at det skal være forståelig og delikat å ta i bruk. Hvis butikken bare var full av sjokolader uten innpakning så hadde det sikkert ikke vært veldig bra for folk sin helse. Det blir mer innbydende hvis du får noe som er gjennomført. Hvis du går på GitHub og inn på alt for mange repo, så kommer du inn til en README der som forklarer deg egentlig ingenting om denne løsningen. Det skal være helt kort, og hvem er det for? Det er veldig nyttig det. Å bruke dokumentasjonen både for sluttbruker og for utvikles teamet selv. Behandle det som en del av produktet. Gjør det fint og lettlest. Lett søkbart, lett forståelig.  

Silvija: Dette her tror jeg vi alle må tenke på, også vi som lager plattform. Det er litt sånn don't make me think. Og forstå verdien ved første øyekast. Der er det mye psykologi som vi ikke har lært altså. 

Einar: Jeg skylder litt på prosjekter her og for dette er sånne ting som blir skrelt bort med prosjekt tankegang. Hvis vi kutter ut det og det så går det bra. 

Silvija: Ja, ikke sant. Du Einar, tusen takk for en veldig fin samtale. Jeg har lært mye om dette med å tenke langsiktig som konsulenter og ta for seg litt DevOps i forhold til forretningsutvikling også. Ikke bare operations. Strukturkapital mellom prosjekter og evne til å pakke inn ting sånn at vi både finner dokumenter og ser verdien i IT-prosjekter og klarer kanskje å få kundene våre til å være med på en vekst sammen med oss. Tusen takk. 

Einar: Selv takk, det var veldig kjekt. 

Silvija: Takk for at du lærte med LØRN. Husk at du må registrere deg på Lorn.tech for å få personaliserte læringsstier, sertifikater og mye mer.

Takk for at du lærte med LØRN. Husk at du må registrere deg på LORN.tech for å få personaliserte læringsstier, sertifikater og mye mer.