Når er egentlig riktig tidspunkt å forstyrre sidepersonen?

Hvor mange faglige spørsmål har du i løpet av en dag?

Jeg har hundrevis. “Hvordan skrives en dato i C#?”, “Hva er egentlig dependency injection?”, “Hvorfor er skjermen gul — kodeendringen burde jo ikke ha ført til en feil?”.

Hva gjør du med spørsmålene du har?

Jeg stiller dem ofte til teamet. Selv om jeg alltid blir møtt med tålmodighet og gode svar, tror jeg ikke dette er det første du bør gjøre.

Ta eksempelet med å bli møtt med en nettside som kræsjer. Jeg har flere ganger blitt møtt en mystisk feilmelding, og instinktivt spurt andre teammedlemmer om de har sett feilmeldinga før. Det første de gjør er å gjøre et søk på nett, og løsningen står som første resultat.

Andre ganger kan jeg spørre ting som “hva er egentlig dependency injection?”. Så får jeg en forklaring, men forklaringen går rett over hodet mitt. Vosj.

Om du alltid stiller spørsmål til teamet ditt før du prøver selv, tror jeg du taper både mestring og stjeler tid fra både deg og teamet ditt. Jeg tror du gagner mye på å prøve minst 15 minutter på egenhånd.

15-minuttersregelen

15-minuttersregelen innebærer at du ved et hinder venter minst 15 minutter før du ber om hjelp fra teamet. I disse 15 minuttene prøver du selv å løse problemet. Om du etter 15 minutter ikke har noen retning, kan du spørre.

Grunnen til at jeg tror denne regelen kan være nyttig, er at jeg tar meg selv i å stille spørsmål som er veldig googlebare. Om det er et spørsmål med en enkel fasit, kan det være raskere å bruke en søkemotor enn å spørre en person.

Alle spørsmål er ikke like enkle. Noen ganger kan det du lurer på være uklart, så du vet ikke engang vet hva du skal spørre om. Du vet du skal sette opp dependency injection, men vet ikke hva dependency injection er. Du mangler noen knagger.

Uten knagger kan det være vanskelig å forstå forklaringer eller stille spørsmål. Løsningen kan være å bruke hinderet som en læringsmulighet. Tillat deg hvert fall 15 minutter på å danne noen knagger. Les deg opp på dokumentasjon, bloggposter eller se en YouTube-video på temaet. Det er litt greiere å sparre om oppsett av dependency injection, om du først har funnet ut hva greia med dependency injection er.

15-minuttersregelen innebærer ikke at du må bli ferdig innen 15 minutter. Å sette opp dependency injection, og sjekke om det er rett, kan jo ta timesvis. Det kan også hende at du er på vei mot en løsning etter 15 minutter, men heller ikke da må du be om hjelp. Det viktigste etter 15 minutter er å ha en retning. Om du ikke har det, bruk teamet rundt deg.

Men hvordan ber du om hjelp?

Hvordan ber du om hjelp?

Hvem av disse er det enklest å hjelpe?

Aksel:

Kan du hjelpe meg med å åpne syltetøyglasset?

Bård:

Kan du hjelpe meg med å åpne syltetøyglasset? Jeg har prøvd å holde lokket med en hånd og vri glasset med den andre.

Bård kommer med ting han allerede har prøvd, så jeg vil hvert fall ikke foreslå det. Her sparer vi begge tid. Jeg kan foreslå uprøvde ting, som å sette lokket under varmt vann. Jeg tror det også kan være lettere å sparre med Bård om løsninger, siden han har forsøkt noen løsninger og dermed har noe bakgrunnsinformasjon.

Etter å ha fått til vane å liste opp hva jeg har prøvd, blir 15-minuttersregelen trigget om jeg skriver et ensomt spørsmål på Slacken. Noen ganger glemmer jeg rett og slett å sjekke åpenbare løsninger, som å google en feilmelding. Så om jeg ser meg selv stille et ensomt spørsmål, prøver jeg hvert fall 15 minutter, og ser om jeg får noe retning.

Mange ganger er jeg Aksel.

Jeg ønsker å åpne et syltetøyglass, men vet ikke hvor jeg skal starte. Kan du hjelpe meg med en retning?

Jeg syns også det å spørre om retning kan være et fint spørsmål. Du viser hva du ønsker å løse, og du viser at du er villig til å jobbe mot å finne løsningen. Du trenger bare litt hjelp med å starte.

Avsluttende ord

Mitt mål med å formidle 15-minuttersregelen er todelt:
1) å oppfordre de som spør ved første hinder til å se etter en løsning selv først.
2) å oppfordre de som jobber for lenge på egenhånd, å ta kontakt med den store ressursen teamet deres er.

15-minuttersregelen har hjulpet meg med å finne svar på ting jeg lurer på. Jeg tillater meg mer tid på å forstå rundt problemet, så jeg får mer helhetsforståelse. Det gir meg mestring å oftere finne svaret på egenhånd, selv når det bare innebærer å google en feilmelding. Jeg får også mestring av å være en aktiv part i sparringen.

For 15-minuttersregelen handler ikke om å slutte å spørre om hjelp. For all del, utnytt kompetansen teamet ditt sitter med. De har møtt på lignende problemer, så de kan hjelpe deg. Og når du finner løsningen, er andre interessert i svaret. Kunnskapsdeling er bra for et team.

Det er noen scenarioer hvor 15-minuttersregelen ikke er relevant, som når du sitter og jobber tett sammen med en annen. Du trenger heller ikke å vente 15 minutter om du parprogrammerer med en annen. Eller at du vet at en annen nettopp har løst samme problem. Teamarbeid handler ikke om å bare gi svar til hverandre, men også å diskutere løsninger.

Jeg håper denne posten kan hjelpe deg å ta et hinder som en utfordring. Jeg håper du først prøver å løse problemet på egenhånd og tar deg tid til å lese deg opp om temaet rundt problemet. Også håper jeg du ikke venter for lenge med å spørre om hjelp når du står fast.

Når syns du at man bør be om hjelp fra teamet?

Når bør du be om hjelp fra teamet ditt?

How are different teams facilitating their Monday and Friday meetings? I have sought inspiration for my own team by talking to colleagues working in different teams and organizations. I hope this can also inspire some of you!

If you work in a digital product team in 2022 you may have heard of the OKR framework. With OKRs often comes "Monday Commitments" and "Friday Wins". Meetings that are meant to set goals for the week on Monday, and celebrate your achievements on Friday.

As teams and organizations can be organized in different ways, I’ve been curious about all the different ways these meetings are facilitated. So I talked to a couple of colleagues to find out how they have made them work out for their team. Why do they have them? What works and what doesn't? Maybe these experiences can spark some ideas as to how you can adapt these methods to your own unique team.


Lars Andreas and Markus from Spink

Our Product Owner works remotely, so we do our Monday and Friday meetings digitally. It is a truly important gathering point for our team. Our Monday Commitment meeting agenda is written as a Trello task, readily available and right next to our backlog. Though sometimes, we’ll admit, we forget to look at it. Every week we rotate on having the responsibility to make sure we are working towards those commitments. 


The way we write our commitments is more “big picture”, not concrete tasks. For example: Our goal is to get this in production – not all the steps it takes to get there.

Making commitments for the week does, to a certain extent, help us keep focused and prioritize what we should do throughout the week. Although by the end of the week we often haven’t done all the tasks we committed to, mostly due to unexpected new tasks that are more urgent.

Though we usually don’t get to everything we would like to, we like doing the Monday Commitments because of two things:

It really sets a focus for the week. “This is what we are focusing on – and this other thing we will put aside this week.”

We check our commitments each week to see what we should work on next. It is a good to-do-list (better than our backlog), because it is always up to date.



Markus from Möller Digital

Our team rituals consist of Monday Commitments, daily standups, and Friday Wins.

For our Monday Commitment meetings we close our Jira board completely, and enter a little corner in our Miro board instead. Here we set common goals for the team to accomplish this week, without tagging specific people to a task. Some of the goals are "low hanging fruits" – others more of a stretch goal. These meetings work well to frame our Jira-tasks. The Jira-tasks are often so specific that it’s hard to see the bigger picture. As a designer, I get more invested in what we are making than I would have been if I was just focused on the concrete Jira-tasks. In the long run, we should get better at linking our commitments to our OKRs.  We do have a way to go there. The OKRs at Möller have up until recently only been on a higher level in the organization. A few weeks back we sat down with the team and made OKRs on a team-level. So in the weeks to come we will hopefully get better at linking our commitments with our teams  OKRs.

For Friday Wins, we put up our Miro board and look at what we have accomplished, color code it, and celebrate that. If there is something we haven't done, we bring it with us for the next week.



Citona from SpareBank 1

Right now we are in a phase where we are trying to figure out what works for us and what doesn’t. We are a big team and have recently divided ourselves into three sub-teams with three different focus areas. We are responsible for a lot of different functionality, so it is quite hard to set goals that everyone can gather around. The three sub-teams make it possible for everyone to have ownership and focus on a specific goal. Our hope is that the sub-teams manage to make goals that contribute towards the “main goal”, so that they become visible to everyone.

We previously used the OKR system with Monday Commitments and Friday Wins. Most teams in our organizations were doing it, and we initially wanted to take part in this thing that seemed to be working so well for everyone. For our team, though, using the methodology felt a bit forced. However, I do not believe there's anything wrong with the framework itself. We are just not quite rigged for OKRs as we have a wide variety of functionality, a lot of maintenance, and legislations that have to be taken into account. So we stopped, took a step back and asked ourselves: What does our team need to find focus and make progress? What we need is a simple meeting on Mondays where we gather and talk about what we are going to do this week.

Although we dropped the classical Friday Wins format as well, we do believe it is important to celebrate our achievements. Every Friday became a bit too often though, as we didn't necessarily achieve that much within a week. Also, after Covid a lot of people continued to work remotely on Fridays, and frankly celebrating in a hybrid meeting or on zoom just isn’t the same.

So this is what we are doing right now: Every ⁠M⁠onday ⁠the whole team get together in the office. One representative from each sub-team shares something that they are proud of from the previous week, and then what the sub-team plan on doing this week. So in a way we have combined some celebration and some planning in the same meeting. We also try to celebrate along the way. We do that by continuously following numbers and measurements, and when we have bigger launches we of course have cake!

So.. Was the fuss worth fussing about?

To have a clear focus and be able to acknowledge and celebrate your achievements, big or small, is undeniably important for personal motivation and for your team to succeed. Monday Commitments and Friday Wins are nice ways to really put it on the agenda. Though, it is important to remember why you do it, and keep reflecting with your team on what works. Do the tweaks needed for your unique team to feel ownership and motivation! I hope reading about my colleagues experiences could inspire you to do just that.

Monday Commitments and Friday Wins. What’s the fuss?

Det er mye som er vanskelig med programmering, navngivning kommer høyt opp på lista. Hvorfor er det vanskelig, og hva kan du gjøre med det? Her er et hendig flytdiagram som kan hjelpe deg.

Det er et kjent sitat i IT-bransjen du som programmerer sikkert har hørt før: “Det er bare to ting som er vanskelig i informatikk: cache invalidering og navngivning” [1]. Likt alt annet på internett er det folk som ikke er enig i denne påstanden, og ønsker å bidra med sin egen variant. Min personlige favoritt er: “Det er bare to ting som er vanskelig i informatikk: cache invalidering, navngivning og bomme-med-én-feil” [2]. I andre varianter av denne vitsen, blir cache invalidering gjerne byttet ut med teknologien forfatteren liker best, og bomme-med-én-feil med et forsøk på en morsommere punchline.

Men navngivning er alltid med.

For navngivning er både en viktig og vanskelig del av profesjonen vår. Det er viktig fordi det er her du som utvikler har muligheten til å gjøre problemet forstått av fremtidige lesere, en leser som kan være alt fra deg selv som har glemt mye siden sist, til en kollega som ikke lenger har tilgang til å spørre deg hva du egentlig tenkte da du skrev koden. Det er også viktig fordi ordene du bruker i koden sprer seg til resten av teamet når du snakker om problemet du løser. Hvis brukerne dine benytter andre ord for de samme tingene, da har du rigget deg opp for mange misforståelser.

Navngivning er vanskelig fordi det ikke finnes noe entydig rett svar, og det som fungerer i dag ikke nødvendigvis fungerer i morgen. Det er vanskelig fordi du har en helt annen forståelse når du allerede har løst problemet og navngir, enn når du ikke vet noe og skal bruke navnet til å orientere deg og skjønne hva som egentlig er greia. Og ikke minst er det vanskelig fordi det er mulig å ha forskjellig oppfatning av samme ord eller begrep.

Du har muligheten til å formidle på alle steder der tekst brukes: variabler, funksjoner, tester, topics, apier, filer, applikasjonsnavn osv. Her kan du kommunisere intensjon, skape en forståelse av problemet du løser, og bidra til å styrke et felles språk i teamet som dere kan bruke til å fortsette å bygge og videreutvikle produktet dere lager.

Etter rundt to tiår med diskusjoner, feilskjær og dyrekjøpte erfaringer har jeg samlet opp tips og triks som er nyttige å ha når du sliter med å navngi tingen din. Jeg har komprimert de ned i et gøy flytdiagram slik at du kan få hjelp til å skrive lesbar kode, og kanskje kjenne deg igjen i situasjonene og le litt av smerten som ligger i det å navngi.

Vær så god!



[1] Internett er stort sett enige om at Phil Karlton sa dette først.

[2] Leon Bambrick hevder han la til “bomme-med-én”




Navngivning

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på og runder av med et godt tips 💡

Hvem er jeg?

Linn Harbo Dahle

Kommer fra Sandnes

Studerte Industriell design på NTNU 

Hvorfor jeg ble designer? Jeg har alltid hatt et engasjement for å skape. Øverst på ønskelista da jeg var liten sto det alltid "lage-ting". Alt en kunne lage noe av eller med. Perler, strikkepinner, lego, hammer, tusjer, teip, papir...

Prosessen med å lage noe synes jeg er skikkelig givende. At det går fra en tanke i hodet, som en så bruker tid på og så ser en etterhvert at det blir til noe som kan brukes av andre. 

Noe av det beste med å være UX-designer er at jobben går ut på å dykke dypt inn i det området man skal jobbe innen. Å prøve å forstå menneskene som opplever tjenesten. Der finnes det alltid noe nytt å lære. Det er motiverende og gir meg mye!

Hva gjør jeg? (Og hvordan?)

Jeg jobber i et team hos NAV. Det vi egentlig gjør er å migrere ut av et gammelt datasystem, men på veien skal vi lage tjenester som fungerer for alle aktørene. Nå lager vi et verktøy for samarbeidspartnere til NAV, slik at de skal slippe å sende brevpost i kommunikasjonen med NAV. 

Det å huske på hva vi oppnår for innbyggere og samfunnet gir meg skikkelig motivasjon i hverdagen. Å huske på hva målet vårt er. 

Vi jobber innenfor et komplekst domene med fem ulike aktører som målgruppe, og det gjør at vi ofte vurderer og prioriterer ulike behov opp mot hverandre. Dette kan være utfordrende. I prioriteringene har det vært essensielt at alle som er med i diskusjonene kjenner godt til dagens tjeneste og hvordan den oppleves. Alle i teamet er med på innsiktsarbeid gjennom intervjuer med de ulike aktørene og andre kartleggingsøvelser. 

Gjennom arbeid i dette teamet har jeg fått kjent på hvor viktig det er å virkelig grave dypt i problemet. At vi sammen som team finner det virkelige problemet og det riktige problemet å løse først. Når vi virkelig forstår problemstillingen, så kommer løsningen ganske enkelt. Hver gang vi klarer å grave dypt, så ender vi ofte opp med en annen løsning enn den vi først tenkte på, og ofte er løsningen enklere og mer elegant. 

Hvilket tips ville jeg gitt meg selv i starten av oppdraget?

Start tidlig med kartlegging av brukerens reise. Dere trenger ikke kunne noe om domenet for å gjøre det, bare begynn i en ende, inkluder de som kan noe om tjenesten og begynn å lære med en gang!

Dagens designtips

Med prinsippene fra Clean Architecture oppnår vi en applikasjon med løse koblinger mellom avhengighetene og økt testbarhet.

Uansett hva vi utvikler er det nødvendig med ulike retningslinjer og prinsipper for at vi skal jobbe sammen og utvikle den stabile, robuste og pålitelige løsningen alle ønsker seg (til jul). Det kan være alt fra hvordan man skriver brukerhistorier, fast tidspunkt for standup, kaffepauser, testbarhet, kodekvalitet og mye mer. Et av disse settene med prinsipper finner vi i Clean Architecture - det er teknikker for å organisere koden din slik at den blir lettere å teste, lettere å utvide og vedlikeholde, med løse koblinger til avhengigheter og grensesnitt.

Dette er på ingen måte noe nytt og man må faktisk over 10 år tilbake for å finne frem da det først ble omtalt av Robert C. Martin (Uncle Bob). 

Utfordringen

Mange kjenner til den tradisjonelle 3-lags arkitekturen som består av 1) Grensesnitt, 2) Forretningslogikk og 3) Database, slik som figuren under illustrerer. En svakhet med denne arkitekturen er at det ikke er et tydelig skille mellom kjernen til applikasjonen (domenet og forretningsregler) og "alt annet". Dette kan føre til at man får sterke koblinger mellom ulike deler av applikasjonen og ikke minst mellom avhengigheter inn og ut av applikasjonen som database, eksterne apier og annen infrastruktur. 

Pilene i tegningen viser at avhengighetene ofte peker "nedover" mot databasen og strukturen på dataene i databasen og ikke minst måten man aksesserer dataene på kan bli gjenspeilet i flere deler av applikasjonen - som er unødvendig og skaper kompleksitet - spesielt med tanke på testbarhet.

Ettersom det ble utviklet løsninger med 3-lags arkitekturen, vokste det frem ønsker om en bedre måter å organisere koden på. Gjennom flere år ble det definert ulike arkitekturer (Hexagonal arkitektur, Onion Architecture, Screaming Architecture m.fl.) der fellesnevneren var å oppnå være løsere kobling mellom eksterne rammeverk, grensesnitt og økt testbarhet. 

Løkringer

Tilbake i 2008 ble Onion Architecture definert av Jeffrey Palermo og på samme måte som en løk er satt sammen av ringer, er arkitekturen basert på at hver av de ulike ringene representerer lagene i arkitekturen. Det viktigste her er at avhengighetene peker innover i "løken" på en sånn måte at det som er innerst i løken er tilgjengelig for alle lag utenfor, mens et lag innover aldri kan vite om noe annet enn de lagene som er lenger inn. Det man oppnår er at de innerste lagene (som typisk er domenemodellen) ikke har noen avhengigheter. 

Denne løkmodellen er også den mest brukte modellen for Clean Architecture og ble illustrert av Robert C. Martin slik:

Den største forskjellen fra 3-lags arkitekturen er at alle avhengigheter ligger i ytterste lag av løken. Hovedfokuset blir på logikken og ikke på hvordan dataene lagres (database) eller hvor de kommer fra (api etc). For å ta et konkret eksempel kan man se for seg at man har applikasjonslogikk som ligger i Use Case-laget som skal lagre data. Da vil man i Use Case laget definere et grensesnitt med de metodene man forventer å kunne kalle for å få lagret dataene. Selve implementasjonen av det grensesnittet ligger dermed lenger ut og typisk i det blå laget i figuren til Robert C. Martin. 

Vis meg kode!

Det er fint med bokser (løkringer) og piler, men vi trenger å omsette dette til kode. Et par raske søk på internett gir oss flere eksempler på ulike tilnærminger til denne arkitekturen i forskjellige programmeringsspråk. Eksempelet jeg har satt sammen, ligger her, og du kan bruke det som utgangspunkt dersom du ønsker å lære mer om Clean Architecture - det er selvfølgelig ingen fasit - "it depends".

Eksempelet er skrevet i C# og er et veldig enkelt API med funksjonalitet for å:

legge til en pakke

hente ut en liste med alle pakker

hente ut en pakke på en gitt id

Løsningen inneholder fire lag (Web, Infrastructure, Application. Domain) som har avhengighet til hverandre slik som figuren under viser. 

Ansvaret til de fire lagene kan oppsummeres slik: 

Domain
Domeneobjekter; det innerste delen av arkitekturen og skal derfor ikke referere til noe annet lag.

Application
Applikasjonslogikk, query og command handlere; kan bare referere til Domain

Infrastructure
Repsitory; kan referere til Application og Domain.

Web
Controllere, dependency injection setup ++ ; er ytterst og kan dermed kjenne til alle lag.

I applikasjonslaget er det behov for å hente ut og lagre pakker. Applikasjonslaget skal derimot ikke ha noe forhold til hvordan disse pakkene er lagret, det eneste som gjøres i applikasjonslaget er derfor å definere grensesnittet for å få utført disse operasjonene:

Hvordan dette implementeres er opptil Infrastructure-laget og dermed kan man starte som i dette eksempelet med en in-memory liste uten at det påvirker applikasjonslogikken. Når man på et senere tidspunkt er klar for å implementere en faktisk database er det bare en ny implementasjon av dette grensesnittet.

Et viktig poeng her er at selve implementasjonen av grensesnittet ligger i et annet lag (Infrastructure) og har private accessor, dermed er det umulig å dra inn den faktiske implementasjonen i applikasjonslaget som sikrer at man kun forholder seg til grensesnittet og ikke blir fristet til å dra inn avhengigheter fra andre, utenforliggende lag i arkitekturen. 

Hvor kan jeg lese mer om dette?

Det er som sagt masse ressurser om dette, men jeg vil anbefale at man leser gjennom den originale posten fra Robert C. Martin som finnes her. I tillegg så har Microsoft en artikkel som beskriver flere arkitekturer deriblant Clean Architectures - den finnes her.

God jul!

Hva er Clean Architecture?

I Bekk har vi en faggruppe vi kaller Bærekraftslab. Her møtes vi på tvers av fagmiljøene teknologi, design og forretning for å jobbe med konkrete problemstillinger innenfor bærekraftsdomenet. Vi valgte i den forbindelse å utforske metodikken livssyklusanalyse - LCA for en start-up som jobber med emballasje. I det videre ønsker vi å dele tre refleksjoner fra å utforske LCA-metodikk.

Kort intro til LCA

På godt norsk kalles LCA livssyklusanalyse eller livsløpsvurdering. Livssyklusanalyse er en kartlegging av den totale miljøpåvirkningen til et produkt eller en tjeneste gjennom livsløpet. For hvert enkelt steg i verdikjeden, for en produksjonsbedrift typisk råvareutvinning, produksjon, distribusjon/transport, bruk og avhending, undersøkes og måles miljøpåvirkningen produktet har. Kartleggingen omfatter alt fra forbruk av energi, vann og naturressurser, til vann-, luft- og jordforurensning/miljøgifter og avfall.



1. Tydeliggjør formålet med analysen

Før du går i gang med en livssyklusanalyse bør du tydeliggjøre formålet med analysen. Har du behov for å kartlegge total miljøpåvirkning av din virksomhet? Eller har du først og fremst behov for å sammenligne ulike produksjonsmetoder eller materialvalg for å kunne gjøre forbedringer der utslippene er størst? Det kan være mange grunner til at man ønsker å gjennomføre en LCA, men hovedmotivasjonen for de fleste vil være å ta mer bærekraftige valg eller redusere risiko. Likevel anbefaler vi at formålet med analysen konkretiseres ytterligere, dette for å bistå til å scope analysen og gi retning i datainnhentingen (se læringspunkt #2 og #3)

Noen ganger vil formålet være å danne et helhetsbilde av verdikjeden for å identifisere vesentlige forbedringsområder. Andre vil kanskje være mest opptatt av å dokumentere miljøpåvirkning opp mot finansielle institusjoner for å sikre gode utlånsvilkår og tiltrekke kapital. Noen ganger er behovet å danne et grunnlag for sammenligning av produkter eller alternative teknologier. Dette kan være for å identifisere bedre alternativer i egen verdikjede eller for å tydeliggjøre bærekraftig posisjonering vis-à-vis eksisterende løsninger i markedet. Eksempelvis for start-ups vil en slik sammenligning kunne utgjøre et viktig salgsargument, samt kunne belyse sentrale valg i etableringen av en ny forretningsmodell.

En livssyklusanalyse fokuserer på helheten fremfor enkeltområder, og kan derfor være et kraftfullt verktøy for en data- og innsiktsdrevet tilnærming til bærekraft. Bedrifter som har foretatt en LCA vil ha mer innsikt i- og kontroll over verdikjeden. De vil slik være bedre rigget for å tilpasse seg krav til utslippsdokumentasjon- og reduksjon i møte med nye strengere reguleringer. Videre vil de kunne drive proaktiv risikostyring i verdikjeden i møte med økt geopolitisk usikkerhet og økende klimarisiko.



2. Scope analysen i bredden og dybden

Livssyklusanalyse er i sin natur svært komplekst. Når du har klart for deg hva du ønsker å oppnå med analysen, vil neste steg være å avgrense hvor omfattende du trenger å gjøre analysen. Det handler om å scope analysen i bredden og dybden.

Med bredden mener vi hvor langt ut i verdikjeden du vil gå, samt hvilken variasjon du inkluderer. Si at du for eksempel skal i gang med en livssyklusanalyse av en bil. Bilen har sin verdikjede, men det har også hver enkelt skrue, felg, dekk og setetrekk. Disse kan hver for seg produseres, fraktes og avhendes på ulike måter. Noen av skruene kan komme fra resirkulert materiale hos en produsent i Sør-Amerika, andre kan bestå av jomfruelige ressurser fra en leverandør i Asia. Noen av skruene kan løsne på veien og ende opp i naturen, mens noen leveres til gjenvinning og blir til nye skruer. Å vurdere ulike utfall og variasjon vil berike analysen, men samtidig øke kompleksiteten betraktelig.

Med scoping i dybden mener vi å gjøre en vurdering av hvilke typer utslippsparametere du inkluderer i analysen. Trenger du beregninger på utslipp av kjemikalier og gassutslipp til vann og luft, eller er hovedformålet ditt å avdekke det totale CO2-avtrykket? Kanskje er det viktigste å få en oversikt over hvilken miljøpåvirkning din verdikjede har, men ikke nødvendigvis å finregne på alle utslippsparametere.

LCA kan med andre ord gjøres tilnærmet uendelig komplekst. Spørsmålet man derfor bør stille seg er om det er noen verdikjedesteg som er mer kritiske å kartlegge, samt hvor det kan være hensiktsmessig å gjøre antakelser eller estimater for å ta ned kompleksitet.



3. Datainnhenting er komplekst og tidkrevende

Når du har avklart hvilke parametere du skal inkludere i livssyklusanalysen, er neste steg å finne tall og informasjon – data - som inngår i analysen. Å gjøre en livssyklusanalyse vil kreve detaljerte, verifiserbare data fra alle ledd i verdikjeden tilknyttet produktet eller tjenesten.

Hvilke kjemikalier brukes for å utvinne materiale som inngår og hvor mye? Hvilke energikilder bruker fabrikken som produserer råstoffet og det ferdige produktet, eller datasenteret du bruker? Hvilket drivstoff bruker bilene som frakter produktet ditt til fabrikk, til butikk eller hjem til kunder, og hvordan er kjørestilen til sjåføren? Dette er bare noen av datapunktene du behøver for å gjennomføre en fullstendig livssyklusanalyse.

De fleste virksomheter utgjør kun ett ledd i en lengre verdikjede. En viktig del av en LCA er derfor å kartlegge og forstå hvilke data du behøver fra partnere eller eksterne kilder, samt hvordan disse dataene kan innhentes og anvendes. Det er også høy risiko for at kilden ikke har nødvendige data i god nok kvalitet eller i tilstrekkelig oppløsning for å brukes direkte inn i LCA-analysen.

For noen datapunkter vil det være vanskelig å innhente konkrete tall eller sette opp målinger, for andre kan variasjonen i datapunktene være stor. Start da med å sette et estimert realistisk mulighetsrom, fra offentlig tilgjengelige tall eller tidligere gjennomførte LCA-er på tilsvarende produkter. Det kan også være hensiktsmessig å foreta en sensitivitetsanalyse for å forstå hvordan variasjon i datapunktet påvirker LCA-en din som helhet.

Kompleksiteten i datainnsamling har medført at det vokser frem verktøy, programvare og spesialiserte tjenestetilbydere som tilgjengeliggjør databaser for tall og beregninger av miljøpåvirkning. EU tilbyr også en plattform som forsøker å tette noe av dette gapet, European Platform on Life Cycle Assessment, for erfaringsutveksling og standardisering av metodikk og data knyttet til LCA.



Er LCA like relevant for digitale produkter?

Bekk jobber med digital produkt- og tjenesteutvikling. Hvordan går man da i gang med en LCA? Benytt gjerne kundereisen som et verktøy for å se hvilke fysiske komponenter som understøtter tjenesten. Alle digitale tjenester har en fysisk komponent - det påvirker hvordan kundene interagerer med den fysiske verden og det gir direkte miljøavtrykk i form av energiforbruk. Ønsker du å lære mer om bærekraftig digital produkt- og tjenesteutvikling så anbefales luke 9 fra julekalenderen.



23-Dec

Today's posts

Når bør du be om hjelp fra teamet ditt?

Monday Commitments and Friday Wins. What’s the fuss?

Navngivning

Dagens designtips

Hva er Clean Architecture?

Hvordan starte med LCA? Våre 3 refleksjoner