Vi fortsetter artikkelserien om Design Thinking. Test er den femte og siste fasen i Design Thinking. Når prototypen er ferdig så tester vi den på brukere. Vi tester konsepter, løsningsforslag og eksisterende løsninger for å validere antakelser og for å få nye innspill fra brukere.
Hensikten med brukertest
Det finnes flere type tester: brukertest, funksjonell test, teknisk test, sikkerhetstest, akseptansetest. Her skal vi snakke om brukertest. Får å validere prototyper, bekrefte hypoteser, oppdage feil og oppdage muligheter, gjennomfører vi brukertester. Vi lager prototyper for å teste ideer på mennesker: eksisterende brukere eller potensielle brukere.
Testen gir innsikt – kvantitativ eller kvalitativ, avhengig av type test.
Vi kan teste på beta brukere i produksjon før man ruller ut til alle brukere. Hvis vi setter opp A/B test så får vi kvantitativ data på om løsning A eller B var en suksess og velge løsningen som kom bedre ut på testen. Færre klikk for å komme til et resultat kan være en suksesskriterie. Testen viser kvantitativt data på antall klikk i A og B -løsninger. Beta brukere har ofte en mulighet til å sende skriftlige kommentarer på funksjonaliteten de opplevde. Det gir kvalitativt data.
Jeg digger kvalitativt innsikt. Samtaler med brukere gir informasjon om hvem brukere er, hva de foretrekker og hvorfor. Brukere gir oss tilbakemeldinger, kommer med forslag og deler smertepunkter.
Her gjør designer prototypene klare til en brukertest. Bilde: Amelie Mourichon / Unsplash
Metoder
Det finnes flere metoder og teknikker for å teste prototyper.
Man kan teste konseptprototypen på en tjeneste ved å fortelle en historie og få tilbakemeldinger fra brukere på den. Man kan vise frem en mockup på en applikasjon og validere om relevante funksjoner og informasjon er på plass. Man kan vise frem en brukerflyt og validere om den er naturlig for en bruker. Man kan teste en klikkbar prototype for en mobil applikasjon og få tilbakemelding både på brukergrensesnitt og brukeropplevelse. Detaljeringsnivå i prototypen er avhengig hvor langt man har kommet i prosessen og hvilke ressurser man har i teamet.
Hvordan tester man en prototype
For at testen skal være vellykket så bør den gjennomføres på en riktig måte og på relevante brukere. Tommelfingerregel sier at validering på 5 brukere dekker dybden og bredden for innsikt.
For eksempel, vil vi teste en ny bankapplikasjon. Man kan rekruttere brukere via nettbank, avtale tidspunkt, planlegge test på manus, preppe interne deltakere. Så gjennomfører man testen, får innsikt og bearbeider funn. Da kan man utbedre løsningen.
Deltakere i en brukertest er bruker, fasilitator og i mange tilfeller – observatører. Man bør ha en plan for hva som er hensikten med testen. Og man bør lage et manus for testen. Søk i google for “User test template” – så finner du eksempler på manus.
Bruker (til venstre) tester hi fidelity løsning. Fasilitator (til høyre) stiller spørsmål og tar notater. Hun ser prototypen på PCen sin og kan muligens endre innhold i prototypen for å teste en variasjon etter tilbakemelding fra bruker. Bilde: UX Indonesia / Unsplash
Først så opplyser man den som testes hva testen handler om, sannsynligvis signerer man noen samtykker. I tilfelle det gis gavekort eller annen belønning, så signerer man papirer på at gaven er mottatt.
Her prøver damen utstyr. Observatør ser på testen. Bilde: Jannis Blume / Unsplash
Hvordan analyserer man resultater av brukertester
Når testene er ferdige så gjør man ofte justeringer. Det er ofte at sluttløsning har elementer fra flere løsningsforslag. Man kan gjerne teste igjen og igjen frem til man kommer til et ferdig resultat.
Det kan også hende at man til tross for testresultatet likevel kan ta en upopulær beslutning. Det kan være fordi det ikke er mulig å utvikle det brukere etterspør. Det kan også være at prototypen hadde noen mangler som gjør at tilbakemeldingene ikke er gyldige.
Det beste er å kombinere kvalitativ og kvantitativ innsikt, hvis det er mulig.
Stort sett er alle valideringer, til og med kun på en bruker, bedre enn ingen. Start gjerne å validere med folk som er i bygget du jobber, men som ikke jobber på ditt prosjekt. Det er stor sannsynlighet for at de er brukere av denne eller lignende tjenester allerede. Hvis ikke så kan du betrakte de som ny kunde / bruker og sjekke hva som skal til for at de blir kunde. Du bør teste på relevante brukere, det passer seg for eksempel ikke å teste ut pensjonsordninger på barn, men på folk i relevant alder.
Del testresultatet med ditt team, prosjekt og prosjektledelse. Inviter gjerne kolleger inn for å se på en brukertest eller del opptak. Vær obs på at hvis du tar opptak, så må du sørge for at du følger GDPR og sletter opptaket innen rimelig tid. Du bør ha prosessbeskrivelse på denne rutinen også.
Validering med brukere er en viktig del av Design Thinking prosessen. Det er da vi bekrefter eller avkrefter våre hypoteser, utbedrer konsepter og løsninger, forstår hva brukere ønsker. Det å teste er helt essensielt for å levere en god tjeneste eller et godt produkt. Kom i gang med brukertesting uansett i hvilken fase av tjenesteutvikling du er i. Lykke til!
Vi fortsetter artikkelserien om Design Thinking. Nå har vi kommet til fase 4 – Prototype. Prototype er ofte relatert til fase 5 – Test, fordi det er viktig å validere konsepter. For å validere ideer på riktig nivå så må man lage prototyper. Det finnes flere type prototype teknikker.
Hensikten med prototype
Man lager prototype for å verifisere ideer. Det kan være for å visualisere konsepter eller teste UX, innhold, visuell design, lesbarhet, teknologi og funksjon. Prototypen kan testes av kolleger, tilgjengelige mennesker på shoppingsenter, i kontekst der målgruppen oppholder seg eller via tjenester som finner riktige brukersegmenter.
Mindset
I fasen Prototype tenker man praktisk og velger riktig nivå for detaljering. Man velger idé, lager prototype, tester, evaluer resultat og forbedrer prototype. Man ender ofte opp med å kombinere ideer fra flere prototyper. Det er helt normalt å forkaste mindreverdige ideer for å lage en som er bedre, så man skal være forberedt på å bruke noe tid på ting som ikke skal brukes videre.
“Hvis et bilde er verdt tusen ord, er en prototype verdt tusen møter.” IDEO
Metoder
Det finnes flere metoder og teknikker for å lage prototyper som for eksempel: Storyboarding, Papir prototype, Mockup, User flow, Funksjonell prototype, Klikkabar prototype, Trådskisser/wireframes, High fidelity med flere.
Tidlig fase på konseptuell prototype. Bilde: KaleidicoWireframes som viser funksjonalitet. Bilde: UX Indonesia.High fidelity UI/UX prototype. Bilde: Alvaro ReyesPrototype av brukerreise. Bilde: Daria Nepriakhina
Man kan bruke ulike verktøy for å lage prototyper, bl.a. disse:
Ulike formål med prototypen
Marty Cagan, grunnlegger og partner i Silicon Valley Product Group, har laget en fin matrise for å vise ulike prototype-formål.
Bildekilde: Reforge.
1. Feasibility prototype, kan være laget av utviklere for å teste ny algoritme, teste teknologi, teste teknisk risiko med mer.
2. Low-fidelity bruker prototype, kan være en interaktive wireframe som er laget for å teste user flow og oppdage usability utfordringer.
3. High fidelity bruker prototype, ser realistisk ut og er god for å kommunisere fordeler med produkt/tjeneste til de involverte aktører/stakeholders. En slik prototype gir også innsikt på hvor design feiler.
4. Live-data prototype, er en typisk reell tjeneste som man lanserer for en liten brukergruppe, ofte prosjektteam som kan teste tjenesten.
Prototyper kan ha ulik detaljeringsgrad i skala fra low-fidelity (trådskisser) til high fidelity (funksjonell prototype eller pixel perfect UI). Detaljeringsgraden er avhengig av hva man ønsker å teste og til hvilket formål; og hvor mye tid og type ressurser man har på teamet. I start fasen liker jeg low-fidelity prototyper, men når det nærmer seg utvikling så er det lurt med high fidelity slik at den fremsår i test som forventet i produksjon.
I det siste har jeg laget en del prototyper i PowerPoint og Miro. PowerPoint er et fint verktøy – der kan en forretningsutvikler oppdatere innhold. Når PowerPoint ligger i Teams kanal der alle relevante aktører har tilgang, så er det enkelt for alle å jobbe i samme dokument. Jeg har i det siste brukt Miro mye, fordi det er enkelt å dele med ulike stakeholdere. Grafisk designer kan lime inn oppdatert skisse og en utvikler kan lage kommentarer og beskrive hvordan den korrekte UX flowen skal fungere.
Oppsummert – prototype bør være laget på riktig nivå og til riktig formål. Tenk på hvem som skal lage den og hvem som skal teste den. I neste artikkel får du tips om hvordan du tester prototyper!
Tekst: Darija S. Hauge. Korrektur: Kristin Mulleng Sezer.
Darija Sapozenkova-Hauge, UX ekspert og teamleadi Experis
Vi fortsetter artikkelserien om Design Thinking. Nå har vi kommet til fase 3 – Ideate. Ideate er den mest kreative fasen av Design Thinking. Det finnes mange metoder som setter i gang kreative prosesser. Vi har definert problemstillingene i forrige fase (Define) og nå skal vi generere ideer på løsninger. Her går vi i bredden og genererer mange ideer.
Mindset
I fasen Ideate tenker man kreativt og bruker divergent tenkning. Det betyr å tenke i bredt. Kom med mange ideer. Antall telles her. I starten bør man tenke fritt uten sensur, bedømmelse og begrensninger. Men det er viktig å huske og notere alle ideene. Man bør prøve å bygge videre på ideene til andre.
“Creativity involves breaking out of expected patterns in order to look at things in a different way.” Edward de Bono
“You can´t use up creativity. The more you use, the more you have” Maya Angelou
Bilde: Unsplash / Dstudio Bcn
Bilde: Unsplash / Jason Goodman
Metoder
Det finnes mange ulike metoder og teknikker for å slippe kreativiteten løs, som for eksempel:
Association
Analogies
Brainstorm
Braindump
Brainwrite
Brainwalk
Bodystorm
Cheatstorm
Crowdstorm
Co-Creation Workshops
Creative Pause
Challenge Assumptions
Gamestorming
How would Google do it
SCAMPER
Storyboard
Mash-up
Mission impossible
Movement
Mindmap
Sketch / Sketchstorm
Provocation
The worst possible idea
Trigger cards
Unintended Consequences
The worst possible idea
Denne kreative teknikken gjør deltakerne mer avslappet enn ved bruk av mange andre teknikker. Deltakerne åpner opp for mer kreativitet og har det gøy.
Kom opp med så mange horrible ideer som mulig. Dumme ideer. Illegale ideer. Se på alle dårlige ideer.Hva er egenskapene til de dårlige ideene? Hva gjør disse ideene så dårlige? Gjør dårlige ideer til gode ideer. Søk etter motsatte egenskaper. Eller erstatt de verste egenskapene med noe annet. Eller miks dårlige ideer og se hva som skjer. Her kan du finne gullet!
Eksempel: Vi har en appelsin. Hva kan vi gjøre med den for å øke appelsin-salget?
Bilde: Unsplash / davisuko
Dårlig ide: kutte en appelsin og male den blå. Egenskapene (attributtene) – endre fargen. Hva gjør denne ideen så dårlig? Det ser ikke naturlig ut. Det er nesten ekkelt. Hvem skulle ta på en slik appelsin? Det er ikke mulig å spise den lenger. Det tar tid å male en appelsin.
Gode ideer: Hva om vi kan selge appelsiner sammen med spiselige farger som aktivitetssett. Barn kunne male på appelsin som aktivitet under bursdagsfeiring.
Crazy 8s
Crazy 8s er en enkel og rask teknikk for ide generering. Ta ett A4 ark og brett det tre ganger i to slik at du har 8 like firkanter. Del slike ark til alle som skal idegenerere. Oppgaven er å komme med 8 ideer på 8 minutter. Tegn ideer eller bruk stikkord. Man kan legge til en utfordring for å komme med de mest crazy ideene eller å fylle ut alle 8 bokser. Gang 8 ideer med antall deltakere så har du ganske mange ideer å velge mellom! Del ideene med gruppen og velg de du vil gå videre med. Og ikke minst – ha det gøy.
SCAMPER metoden
Denne metoden hjelper å generere mange kreative ideer på nye produkter, tjenester og løsninger på konkrete problemer. Når man har så mange ideer så er sjansen for å finne på noe innovativt mye større. Metoden består av syv forskjellige måter og se på samme problemstilling, tjeneste eller produkt. Navnet SCAMPER er akronym for en rekke verb. Hver bokstav står for et perspektiv som avgjør hvordan man bør se på problemstillingen.
Bilde: Unsplash / Yann Jacobsen
S.C.A.M.P.E.R. akronym står for:
S– Substitute (Erstatte) – Kan vi bytte det til noe annet? C – Combine (Kombinere) – Hva kan vi kombinere? (flere funksjoner, deler, tjenester) A – Adapt (Justere) – Hvordan kan vi justere det? M – Modify, Multiply, Magnify (Endre) – Kan vi endre det? P – Put to another use (Sette til andre bruksområder) – Kan det brukes til noe annet? E – Eliminate (Eliminere) – Er det en grunn til at vi bør eliminere det? Kan deler av det elimineres? R – Rearrange (Omvendt) – Kan vi endre rekkefølgen?
Bilde: Interaction Design Foundation.
Man starter med å definere en konkret problemstilling. For eksempel: Så stiller man et SCAMPER spørsmål. Videre ser man på mengden kreative ideer. Uansett hvor dumt eller irrelevant ideen kan virke, kan det faktisk hjelpe til med å finne en løsning på et problem. Til slutt så velger man de mest relevante ideene.
Eksempel på en problemstilling: Hvordan kan vi bruke suksessen av KitKat sjokolade?
S (Erstatte)– Erstatte med melkesjokolade. C (Kombinere) – Kombinere med frukt og nøtter. A (Justere) – Legge sjokoladen inn i iskrem. M (Endre) – Øke størrelsen på sjokoladen. P (Sette til andre bruksområder) – Gjøre den om til sjokolademelk. E (Eliminere) – Lage sjokolade i en mindre og smal størrelse. R (Omvendt) – Omorganisere utformingen av sjokoladen – dele den i biter.
Bilde: Meetchopz
Et annet eksempel for bruk av SCAMPER: Etter en arbeidsdag ønsker Johannes å feire bursdag på en Michelins restaurant.
S – Kan Johannes feire bursdag på en annen like god restaurant i samme prisklasse? C – Kan Johannes feire bursdag på Michelins restaurant og få en kokebok til gave? A – Kan Johannes feire bursdag hjemme med proff kokk og kokkekurs? M – Kan Johannes bo på et hotell i to dager og spise på Michelins hver dag? P – Kan Johannes feire bursdag på malekurs med ølsmaking? E – Kan Johannes feire på Burger King? Kan Johannes droppe feiringen? R – Kan Johannes ta frokost på Michelins restaurant og så gå på jobb?
Om noen av bokstavene går litt i hverandre – gjør det ikke noe. Det viktigste er å få så mange ideer så mulig. Prøv SCAMPER på noe du ønsker kreative løsninger på!
Nå har man ganske mange ideer. Hva gjør man med dem? I de to neste fasene av Design Thinking – Prototype & Test skal man realisere ideene. Gjøre ideene til virkelighet. I neste artikkel skal vi se på måter å polere ideene, teste de ut og få brukerfeedback.
Bilde: Unsplash / Mika Baumeister
“Everyone who´s ever taken a shower has had an idea. It´s the person who gets out of the shower, dries off and does something about it who makes a difference”. Nolan Bushnell
Tekst: Darija S. Hauge. Korrektur: Kristin Mulleng Sezer.
Darija Sapozenkova-Hauge, UX ekspert og teamleadi Experis
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein
I forrige artikkel skrev jeg om den første fasen i Design Thinking – Empathize, som handler om å forstå menneskene man lager tjenester eller produkter for. Som en naturlig oppfølger handler denne artikkelen om andre fasen i Design Thinking – Define, mindset og metoder.
Mindset i Define
I denne fasen snevrer man innsikten til scope, redefinerer problemstillinger på en brukersentrisk måte eller transformerer latente behov til en konkret design utfordring.
I Define fasen bruker man konvergent tenkning. Denne form for tenking skapes i den venstre hjernehalvdel. Konvergent tenking er målbevisst, logisk og trinnvis. Tenkningen vektlegger hurtighet, nøyaktighet og logikk, samt at man holder seg til åpenbar relevant informasjon og tar analytiske og korrekte beslutninger basert på en systematisk informasjonsprosessering (Cropley 2006).
Double Diamond designmodell brukes ofte i forbindelse med Design Thinking. Define fasen er lik i begge.
Definere problemstilling
La oss ta et eksempel. En kunde i handelsbransjen ønsker å øke antall salg gjennom alternative betalingsløsninger som forbrukskreditt. Forretningen lurer på “hvordan kan vi øke salg av varer på kreditt”. Det betyr at en tjenestedesigner som må se på brukere og smertepunktene deres (Pain Points). Hvorfor velger ikke brukere delbetaling som betalingsalternativ?
Tjenestedesigner ser at det er flere grunner til at brukere ikke søker kreditt. Det kan være at brukeren kjenner til muligheten å betale litt hver måned, men sier nei takk og betaler med kort. Det kan være at brukeren ikke ser muligheten til å delbetale eller ikke kjenner så godt til hva det innebærer. Det kan være at brukeren vil delbetale, men den digitale tjenesten feiler på noen områder som gjør at man mister brukere underveis i prosessen. Tjenestedesigneren omformulerer dette til konkrete problemstillinger – Hvordan kan vi hjelpe brukeren å bli bedre kjent med delbetaling som betalingsalternativ og hva det innebærer, og hvordan kan vi hjelpe brukeren å gjennomføre den type betaling. Det er en konkret problemstilling som et tverrfaglig team kan jobbe videre med i videre faser av Design Thinking – Ideate, Prototype & Test.
Metoder
Det er en rekke metoder som hjelper deg å sortere innsikten og redefinere antatt scope: Design challenge, Customer journey as is, Problem statement, Personas, Dot Voting og Elevator pitch.
Elevator pitch
Jeg pleier å samskape Elevator pitch sammen med prosjektgruppen og eventuelt andre stakeholdere slik at alle har mulighet til å avklare omfang, forventninger til endelig leveranse og forstå dette fra målgruppens perspektiv. Som oftest er jeg nødt til å lage flere pitches, både for gruppens brukere, som er kunder og internt for ansatte og partnere.
Elevator Pitch malen ser slik ut:
Problem Statement
I Define fasen er det ganske vanlig å lage Problem statements. Tradisjonell påstand har tre komponenter: 1) Bruker 2) Behov 3) Mål
Forenklet eksempel på Problem Statement: 1) Janne, tobarnsmor, god på teknologi (ala Personas), 2) trenger å sammenligne opsjoner raskt for å kjøpe korrekt vare 3) for å ha mer kvalitetstid med familien.
Det er lurt å bruke en relevant kundereise for å bygge brukeropplevelsen rundt den. Sjekk om det finnes kundereiser fra før av i bedriften, eller lag kundereiser som passer formålet. Prøv å bruke riktig detaljeringsnivå i kundereisen med tanke på hvordan det skal brukes videre. Det foreligger ofte eksisterende kundereise, og tjenestedesigneren tilpasser denne og analyserer innsikt for å bygge ønskelig fremtidig kundereise.
Arbeid med kundereise – Pain Points er notert på post-its og noen av de kan bli til prioriterte områder til forbedring.
Dot Voting
Det finnes mange gratis templates online, som man kan endre til sine formål. Denne kundereisen er hentet fra https://online.visual-paradigm.com/
Dot Voting er en enkel teknikk for Decision making og prioritering blant mange retninger å velge mellom.
Deltakere får flere alternativer presentert. De får likt antall stemmer (Dots), for eksempel 3 og plasserer alle sine stemmer på ett eller flere alternativer som de mener er mest relevant. Diskusjon er ikke tillatt under votering. Etterpå diskuteres resultatene og oppsummerer veien videre.
1) Start med definering av 3-5 kriterier som valgene bør svare til. 2) Hver person bruker likt antall dots (3-7) som kan brukes fritt på forskjellige idéer eller en idé. 3) Idéer med flest stemmer er noe man bør fokusere videre på.
Ni deltakere har 3 stemmer hver.
Deltakerne har stemt.
Deltakerne har stemt.
Problemstilling er definert – hva nå?
På slutten av analysereisen kommer man forhåpentligvis til en definert problemstilling. Når behovene er konkretisert, problemstillinger er formulert eller reformulert, scope er avklart og satt, så kan vi sette i gang neste fase av Design Thinking – Ideate. Det er den absolutt mest kreative fasen av design thinking. I neste fase av Design Thinking skal vi slippe løs kreativiteten og generere ideer for løsningen. I denne fasen bruker man divergent tenking (som i første fasen – Empathize) og idégenerer. Divergent tenking er vår evne til å tenke kreativt. Ifølge Guilford (1956) det er fire kategorier som måler den divergente tenkingen.
Idérikdom innebærer evnen til å generere mange idéer,
Fleksibilitet er evnen til å generere et bredt utvalg av idéer,
Originalitet innebærer å komme med uvanlige idéer
«Elaboration» viser til evnen om å utvikle eller bygge på andres idéer.
I neste artikkel ser vi på kreative metoder i Ideate!
Forrige gang hadde vi introduksjon til Design Thinking-mindsettet, fasene og noen metoder. Denne artikkelen handler om den første fasen i Design Thinking – Empathize, mindset og metoder. Empathize handler om empati for brukerne.
Design Thinking faser
Mindset i Empathize I denne fasen er det viktig å forstå menneskene vi designer for, forstå problemene deres.
Man skal stille med åpent sinn, ikke vurdere, men stille åpne spørsmål og være utforskende.
Vær utforskende og åpen i observasjoner.Undersøkelse på UX bransjen av Okse: https://okse.no/artikler/ux-i-norge-2019 Ifølge undersøkelsen topper empati listen over «skills» som en UXer bør ha.
Hvordan komme i gang Vi trenger å samle innsikt om dagens situasjon. For å få det kan man jobbe på flere plan:
Sluttbruker Hvorfor oppførte brukerne seg slik de gjorde? Hvordan lærte de? Hvordan kunne vi engasjere dem? Utforsk i dybden, inkludert registrering av følelser, tanker og ideer.
Interessenter Dyp innsikt i hva interessenter virkelig ønsker seg og trenger, deres perspektiver og problemer.
Team Bruk en etnografisk tilnærming for å forstå dine kollegaer og team, og hva som motiverer dem. Hjelp dem til å forstå kundereisen. Gjenta prosessen med dem og skap verdier sammen.
Organisasjonen Hva er kjernekompetansen vår? Hva ligger i vårt «DNA»? Se utover selskapets bransje eller komfortsone.
Metoder
Det er en rekke metoder som bidrar til å få innsikt og vise empati med dem vi kommer til å skape verdi for.
• Oppelve selv Jobber du med å forbedre en mobilbank-app? Last ned appen og prøv forskjellige funksjoner.
• Observasjon/etnografisk researchMøt menneskene der de er, ikke der du vil at de skal være. I naturlige omgivelser.
Ta deg selv ut av situasjonen, vær en observatør, og ikke ta det personlig.
• Dagbok/fotodagbok I noen tilfeller kan det være riktig å grave litt inn i hverdagen og tankene til brukerne. Be dem dokumentere sine opplevelser – både skriftlig eller visuelt.
• Åpen samtale Slå av en prat med folk som bruker tjenestene du lager eller kommer til å lage. Still spørsmål som hjelper deg til å forstå konteksten de er i og å klargjøre behovene deres.
• Semistrukturert intervju Når problemstillingen er mer konkret, er det best å ha en generell plan for samtalen klar. Det er fortsatt OK å gå utenfor rammene, men det er noen punkter man bør få svar på.
• Ordentlig intervju, ofte med observasjon Denne metoden innebærer en del for- og etterarbeid og ikke minst proft opplegg under gjennomføringen. Det er ønskelig med observasjonsmuligheter. Man skal også ha formelle dokumenter klare, som samtykke/taushetsplikt og intervjuguide.
• 5 whys Svarene ligger ofte dypere enn det man tror eller kommuniserer. 5 whys er metoder der man spør Hvorfor cirka 5 ganger for å kommer til bunns i årsaken.
• Projective techniques Det er en del psykologiske teknikker fra feltet som hjelper til å artikulere/formulere meninger og følelser.
Pictorial projective techniques – bildeprojiseringsteknikker: – Rorschach inkblot test – Thematic Apperception Test (TAT) Tematisk projisering
Ekspresive metoder: – Leketeknikker – Tegning og maling – Rollespill
Rorschach inkblot test
• Innsikt via kundeservice Spesielt når vi ikke kan nå brukerne direkte, som for eksempel i B2B-prosjekter, er kundeservice en fin kilde for hva brukerne etterspør, hva som er typiske henvendelser og trender.
• Kvantitative data som ekstra dimensjon Målinger og analytisk data fra en rekke systemer er også en god kilde til innsikt. Det kan for eksempel være antall pålogginger, antall sidevisninger, mest besøkte sider, flest søkte ord eller feilet søk.
• Secondary research / Desctop research Brukes som støtte til brukerinnsikt. Det kan være dokumentasjon fra en forstudie, søk på nett, publikasjoner, årsrapporter. Det kan blir fort mye info, så det er lurt å vurdere relevansen for kunden for å prioritere kilder.
• Undersøkelser Sjekk om det er blitt gjennomført undersøkelser på brukerne dine? Finnes det et fast tilbakemeldingsskjema? Ble det gjennomført markedsundersøkelser på kundesegmenter, markedstrender eller lignende?
• Empathy map canvas En god metode for å mestre empati for brukerne er å lage løsninger for er å kartlegge innenfor denne malen:
DOES-rammeverk En annen måte å strukturere brukerbehov på er å såkalt DOES-rammeverk.
Deltakerne på Design Thinking-skolen i Ciber Experis hadde voteringsøvelse på hvilke metoder de ønsket å lære mer av/gjøre mer av.
Neste steg
Bruk mønstre du finner i dataene for å trekke ut innsikt som bidrar til å identifisere kriterier som din fremtidige løsning må oppfylle. Å oversette innsikt til kriterier betyr at du vil få et pålitelig filter etter hvert som du går inn i idémyldring og konseptutviklingsfasen. Uten designkriterier er det vanskelig å metodisk sortere potensielle ideer og konsepter.
I neste fase av Design Thinking – Define – jobber man med konkretisering av omfanget (scope). Problemstillingene er formulert eller reformulert. Reformulering er et viktig ord her, fordi et opprinnelig trangt eller konvensjonelt omfang av problemer og muligheter kan skjule og hindre de mest kreative løsningene. Ta et steg tilbake fra de «vanlige» spørsmålene, og still andre, bredere spørsmål. Det fører til et mer meningsfylt resultat.
Bli venner med visualiseringsteknikker. Visuelle fremstillinger erspesielt nyttige for å kommunisere ideer som er mindre intuitive, tilgjengelige eller kan få motstand. Bruk tegninger, foto eller andre typer visualisering som videosnutter.
Bruk metaforer. Metafor åpner opp for den kreative siden av hjernen og fremhever uartikulerte perspektiver, følelser, og antagelser. Det hjelper å frigjøre oss fra våre mentale modeller og gjør det enklere å snakke om vanskelige problemstillinger. Når en gruppe velger metafor, gjør de den til sin egen.
Lykke til med Design Thinking!
Bildekilder: Kristin Mulleng Sezer, Ciber Experis, Vectors Market, Wikipedia, Unsplash/Charles Deluvio og Zdeněk Macháček, eventcanvas.com. Korrektur: Kristin Mulleng Sezer.
Darija Sapozenkova-Hauge, UX ekspert og teamlead i Experis Ciber AS
Begrepet Design Thinking har sirkulert i flere år, flere og flere designere har blitt design thinkers samtidig som flere og flere organisasjoner har blitt godt kjent med behovet å rekruttere en eller to tjenestedesignere til prosjektene sine. Vi tar et steg tilbake og tar en reprise på hva Design Thinking er. Vi går gjennom Design Thinking-faser, mindset og verdien av Design Thinking. Vi skal også se på Double Diamonddesignprosessmodel, som er tett relatert til Design Thinking.
«Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.» – Tim Brown, CEO IDEO
En tjenestedesigner skal først og fremst opplyse teamet/prosjektet om brukerens behov og interesser. For å lykkes må en tjenestedesigner ha god forståelse både for teknologi og forretning.
Design Thinking faser
1. Empathize (Innlevelse) Man skal sette seg i brukerens sko, uten å bedømme. I denne fasen samler man innsikt i brukerens situasjon og problemstillinger.
2. Define (Definisjon) Man skal komme frem til konkret definisjon av problem som skal løses.
3. Ideate (Idéer) I denne fasen skal man idégenerere løsninger til problem som er definert.
4. Prototype Her skal man konkretisere løsningen ved å lage prototype/r. Prototyper bør kunne testes områder med størst usikkerhet.
5. Test Man skal teste prototype på brukere, dokumentere funn og justere løsningen.
Hver fase kan avsluttes med beslutning for enten å komme tilbake til forrige steg eller helt til starten. Dette er ikke en lineær prosess.
Google Design Sprint har bokset fem Design Thinking faser i fem dager. Så lager man ny sprint for å prøve på nytt, akkurat som i Design Thinking.
Verdien av Design Thinking
En McKinsey-studie-rapport fra 2018 om 300 virksomheter på tvers av bransjer og land viser hvor viktig Design Thinking er. Ifølge rapporten hadde bedriftene som var ledende på design en årlig vekst som var tre ganger så høy som gjennomsnittet i sin bransje. Over en femårsperiode leverte de beste virksomhetene en avkastning til aksjeeierne som var nesten dobbelt så høy som gjennomsnittet.
Selskap som Apple, Microsoft, IKEA, Lego og Google har integrert design i hjertet av strategiene sine gjennom å bruke Design Thinking. Design Thinking skaper bedre produkter og tjenester, mer fornøyde brukere og høyere inntekter.
Hvorfor har Design Thinking blitt en suksess?
Dyp brukerinnsikt skaper bedre produkter og tjenester for brukerne.
Fornøyde brukere betaler mer og blir lenger.
Tjenesteleverandøreene reduserer risikoen og kostnadene ved tidlig brukerinvolvering og tidlige tilpasninger.
Design Thinking mindset
Design Thinking tilbyr en rekke prosesser, metoder og verktøy. The five Whys, Photojournal, Interview for å nevne noen.
Men nøkkelen til suksess er Mindset. Mindsettet består av følgende prinsipper:
1. Et menneske-sentrert perspektiv Man bør forstå behov, oppførsel, følelser og verdiene til menneskene, forstå perspektivene og de ulike bakgrunnene de har, uten å dømme.
2. Tvertfaglig samarbeid For å forstå komplekse problemstillinger og komme med innovative løsninger trenger man å se på ting fra flere ståsteder. Tverrfaglige team har stort potensiale hvis deltakere har et åpent sinn.
3. Utforskning Dette er en prosess der man bør fordype seg i kontekst og prøve nye ting, prøve på nytt, tilpasse seg ny setting, forbedre resultatene, eksperimentere og tørre å gjøre det om og om igjen.
4. Usikkerhet Man må regne usikkerhet som en naturlig tilstand, og at forstå at endring bør være en ny mulighet, ikke et hinder.
5. Evne å skape Man bør kunne se utover «redesign» og kunne tenke helt nytt produkt og ny tjeneste. Fremtiden kan være noe helt annet nåtiden.
Double Diamond designmodell
Det er ikke mulig snakke om Design Thinking uten å snakke om Double Diamond. Hva er Double Diamond? Double Diamond er en designprosessmodell. Det handler om bruk av divergent-konverngent tenking. Modellen ble foreslått for første gang av lingvist Béla H. Bánáthy i 1996. I 2005 utforsket British Design Council hvordan mennesker prosesserer informasjon når de skaper løsninger. De oppdaget at i jakten på innovasjon går mennesker i alle bransjer går gjennom de samme fire stegene: oppdage, definere, skape og levere. Double Diamond-modellen ble popularisert, og nå assosieres Double Diamond med Design Thinking.
En klassisk Double Diamond designmodell har fire faser: Fase 1: Discover (Oppdage) Fase 2: Define (Definere) Fase 3: Develop (Skape) Fase 4: Deliver (Levere)
Venstre «diamant» handler om «Doing the right thing». Når arbeidet i den venstre «diamanten» er ferdig (fase 1 og fase 2), bør man sitte igjen med en omfangsdefinisjon. Det er her forprosjekter ofte slutter og her prosjekter ofte starter.
Den høyre «diamanten» handler om «Doing the thing right». Når arbeidet i «diamanten» til høyre er ferdig, bør man komme til et definert avslutningspunkt: Løsning/Pilot/Lansering/Proof of Concept.
Disse fasene er et kart for designere for å organisere tankene sine i en kreativt prosess. Fase 1 og fase 3 er faser av såkalt divergent tenking, der man bør jobbe i bredden og komme med mange kreative ideer. I fase 2 og fase 4 bør man tenke analytisk og realistisk for å fokusere og konkretisere.
Det er viktig å poengtere at dette ikke er en lineær prosess. Det er en fordel om man beveger seg frem og tilbake mellom fasene for å forstå hvilket problem man egentlig skal løse og og hvilken løsning som er den beste.
Double Diamond-modellen er universell. Den kan brukes i flere bransjer, ikke bare av designere. Dette er de grunnleggende prinsippene bak Design Thinking, Double Diamond og tjenestedesign. Neste tema blir konkrete metoder i Design Thinking i bruk og veiledning i metodene.
Interessen for sky-tjenester startet for noen år siden, og nå har flere organisasjoner, selskaper og startups valgt å bruke sky-løsninger. Om sky er noe for deg er helt avhengig av hva du har fra før og hva du skal bruke det til. Du må undersøke hvilke sky-avtaler som er der ute og vurdere hvordan din bruk kan bli i praksis.
Roman Castro er en løsningsarkitekt, som har jobbet med sky fra 2012 og utelukkende med Microsoft Azure i 5 år.
– Hva er definisjonen av sky? – Nettskyen/skyen er betegnelsen på alt fra dataprosessering til datalagring på serverparker i eksterne nettverk som gjøres tilgjengelig på internett for konsumering via brukervennlige portaler/skytjenester.
– Et eksempel kan være Microsoft tjenester som Office 365 og SharePoint, som kommer pakketert og kan kjøpes. De hostes (drives) og kjøres fra Microsoft datasenter.
– Hvilke sky-aktører er der ute? – Det finnes ulike sky-modeller og aktører. De tre største sky-leverandører er Amazon Web Services, Google Cloud Services og Microsoft Azure. Det finnes også mange mellomstore, som Oracle, IBM og Alibaba. Så finnes det nisjemarkeds-aktører som Heroku, Rackspace og Digital Ocean. Sky-modellen kan være privat, offentlig, hybrid eller statlig sky. Skyløsninger kan kjøpes via partnere som Visolit og Basefarm. Man kan også kjøpe applikasjonsdrift – Software som tjeneste (SaaS).
Hovedkategorier i skytjenester:
Infrastrukturtjenester (Infrastructure as a service / IaaS) som for eksempel Rackspace, AWS, OpenStack. – Virtuelle maskiner og OS som tjeneste med garantert SLA. – Målrettede tjeneste som filserver og gateways. – Nettverkssikkerhet som tjeneste, DDoS beskyttelse, brannmur.
Plattformtjenester (Platform as a Service / PaaS) som for eksempel Microsoft Azure App Services, Kubernetes, Docker. – Database som tjeneste (DBaaS) – Applikasjonsserver (App Services) – Integrasjonsplattform som tjeneste (iPaaS) som Enterprise Service Bus.
Programvare som tjeneste – (Software as a service / SaaS) som for eksempel Salesforce, MailChimp, CloudBlue, Cloud Scripting, Gmail, Office365. – Identitetsplattform som tjeneste (IDaaS) som Azure Active Directory.
Visualisering av ansvarsområde ved sky avtaler / David Chou
– Hvem bør vurdere sky? – Holder du til i Oslo, Stockholm og Tokyo, må du tenke på hvordan den samme applikasjonen skal leveres til alle de stedene. Hvordan skal folk i Tokyo bruke applikasjonen på samme måte som folk i Oslo? Hvordan sørger man for at alle tre lokasjoner har samme governanceprinsipper og regelsett? Man bør ta en strategisk tilnærming til hvordan applikasjonene skal leveres og brukes.
– Det er flere aspekter og utfordringer man bør vurdere i valg av sky-leverandør og håndtering av det internt:
Styresett. Kontroll på kostnad, policy, informasjonssikkerhet, GDPR.
Tilgangsmekanismer. Hvordan skal brukere og tilganger håndteres? Hvordan skal deployments mot sky gjøres?
Sikkerhet mot cybertrusler (beskyttelse fra DDoS angrep, patching av Zero-day sårbarheter).
Hvordan skal ytelsen/selve leveransen være?
Krav til personvern (Hvem følger handlinger? Hvem har tilgang til data?)
Dataintegritet (Hvor lagres mine backup data?)
Fordeler med sky
Tilgjengelig 24/7 Data blir lagret på store datasentre og disse serverne er koblet sammen i et nettverk – såkalt privat backbone (utenfor internett) og med internett av samme leverandør. Slik funksjonalitet er viktig for selskap som tilbyr kritiske samfunnstjenester som banker og oljeselskap. Og det svarer godt på SLA (service level agreement) og SLO (service level objective).
Fleksibel kapasitet Om det for eksempel er en populær kampanje, kan kapasiteten til serverne økes kjapt for å håndtere pågangen. Når salget er ferdig, kan dette skaleres ned igjen. Den eneste ulempen er at man kan glemme å skalere ned, og det medfører store kostnader. Dette er fordi man betaler for forbruk i skyen.
Markedsandeler av skytjenester / Gartner
– Hvilken sky plan bør man velge? – Nye prosjekter er absolutt beste utgangspunkt for å bruke sky. Bedrifter som har mange ting fra før må gjøre en del tilpasninger og flytting av data. Det kan være veldig komplekst og en arkitekt kan jobbe i ett år bare for å lage en strategi for dette. Ønsker man bare å flytte ting eller bryte opp en monolitt til microtjenester? Det finnes flere måter å komme til skyen:
Det finnes flere måter å komme til sky: – Rehost. Flytte alt fra en server til sky. Det har lite gevinster, bare stor kost. – Refactor: Man endrer kodebase litt. – Rearchitect: Stor jobb. – Rebuild: Innebærer at en arkitekt jobber i 1 år bare for å komme med løsning.
Rammeverk for sky adopsjon – Man bør etablerte retningslinjer for bedrifter som ønsker å ha en kontrollert tilnærming til sky. Eksempler på rammeverk:
Microsoft: aka.ms/cloudadoptionframework
AWS: aws.amazon.com/professional-services/CAF/
Microsoft sin Cloud Adoption Framework
Sky fra utviklerperspektiv
Antony Charles Allen, senior .net utvikler i Experis Ciber AS
Antony Charles Allen, senior .net utvikler deler sky-erfaringer: – Jeg jobber med Azure og Azure har mye out-of-the-box funksjonalitet. Hvis man jobber med web APiene er det veldig enkelt å publisere og teste kode i «live» miljø.
Usman Awan, java utvikler i Experis Ciber AS
Usman Awan, java utvikler deler sky-erfaringer: – Det er lett å komme igang med å eksperimentere med public cloud som AWS. Jeg prøvde ut Elastic Beanstack, EC2 og RDS på mitt hobbyprosjekt da jeg var student. Men jeg gjorde den samme tabben som mange som begyner med å ta i bruk skyen. Jeg glemte å skru av tjenester når jeg ikke brukte dem og plutselig fikk jeg en regning på 148 dollar.
– Nå foretrekker jeg å bruke Digital Ocean. Det er en billig spesialisert IaaS plattform med gode virtual machines som gir akkurat den kontrollen jeg ønsker meg. Digital Ocean kommer nå med støtte for Kubernetes som kan være interessant for mange.
Til ettertanke
Sky er et stort område med veldig mange aktører. Å flytte tjenester du drifter Hos deg selv over til en sky, er en krevende øvelse som forutsetter kunnskap og erfaring om markedet og teknologiene. Men når man lykkes kan det gi en fleksibilitet og smidighet som kan hjelpe din virksomhet å løse målene dine raskere og smidigere.
Tekst: Darija Sapozenkova-Hauge.
Darija Sapozenkova-Hauge, UX ekspert og teamlead i Experis Ciber AS
I disse tider med hjemmekontor er det nyttig å dele erfaring med verktøy for distribuert samhandling. Her er mine favorittverktøy.
Workshops: Jeg har positiv erfaring med av online workshop ved bruk av Miro.com. Verktøy for visuell samskaping. Veldig lett å komme i gang. Mentimeter har jeg også hørt om for workshops og møter.
Interaktivt board på Miro.
Møter: – Statusmøter – gjerne korte og oftere. – Online lunch hvis det passer er fint av og til. – Sosiale aktiviteter med kolleger online. – Bruk kombinasjon av verktøy og vær tilpasningsdyktig.
Samhandlingsverktøy som jeg kan anbefale på det varmeste er Slack og Flowdock. Microsoft Teams er også OK, litt mindre mobilvennlig. Noen bruker Facebook Workplace, også har jeg hørt om men ikke brukt Twist. Jeg har også brukt Teams for 10 min statusmøter for barn i barnehagen, funker best når kan er 4 stk. Deling av ideer: Wake. For å engasjere folk: Kahoot quiz.
Slack er brukervennlig også på mobil.
Video chats og screenshare: Whereby (opptil 4 deltakere i gratis plan, enkel tilgang via åpen url), Zoom (kan ha veldig mange deltakere, brukes i undervisning på universitet), Google hangouts. Jeg har også hørt om Confrere og Webex men har ikke prøvd dem. En del av programmene har kommet med gratis versjoner i korona-tider. Fikk også tips fra folk i Smidialliansen om Discord som er gratis og støtter opp til 9 stk på video. Hopin for online events.
Prosjektstyring: Trello – superenkel (og mye bra gratis). Basecamp kan jeg også anbefale. Andre slike verktøy – Jira, Asana og Monday.
Enkel oppgavestyring med Trello.
Dokumentlagring: Vi bruker Microsoft Teams internt og det er lett å finne frem Recently used documents. I andre sammenhenger og privat bruker jeg Dropbox Paper og Google Drive. Hvis jeg skal sende store filer en gang så bruker jeg: https://wetransfer.com/
Vanligvis drar jeg på konferanser som dette fordi jeg holder foredrag. Denne gangen slappet jeg helt av og koste meg. Det var tre gode dager med foredrag og to dager workshops med temaer fra quantum computing til opplevelser som meditasjon med stearinlys.
Build Stuff er en IT-konferanse i Vilnius (holdes også i Malaga og Ukraina). Det var bra hotell, like ved et shoppingsenter, geeky stands og innholdsrike samtaler om programmering og utviklerlivet. Årets tema var «Software jungle. Join the tribe» og underholdningen var godt knyttet til temaet og til lokalene.
Åpning med trommer og publikums engasjement. Utsikt over sentrum av byen fra speakers frokostbuffet i 22 etasje.
Meditasjonstime mellom hektiske sesjoner. Jeg har lukket øynene og fikk veiledning i å gå på rare ting. Noe føltes som glass. Det var bare pasta og Lego. Så opplevelsen var positiv.
På denne standen fikk jeg gravert sugerør med mitt navn. Litauen er kjent for laserteknologi. Nå for tiden graveres det mest på glass.
Favorittforedragene mine:
Johannes Brodwall med foredraget sitt om OpenID Connect topper listen. Såpass tørt tema som innlogging var forklart og demonstrert på en tydelig og engasjerende måte. Jeg og to andre tilskuere ble trukket opp på scenen og instruert i et lite skuespill for å demonstrere teknologien. Terningkast 6!
OpenID Connect - er en enkel identifikasjonsmekanisme. På sider som støtter OpenID, trenger ikke brukerne å registrere seg med et eget brukernavn og passord for å få tilgang, og dermed få en konto å holde styr på for hver ny side man besøker. I stedet autentiseres man via en side som støtter OpenID som for eksempel Microsoft, Google eller ID-porten.
Kjent TED speaker David Phillips åpnet konferansen med keynote «The magical science of storytelling». Foredraget var underholdning på høyt nivå, godt strukturert og lett å huske. Jeg har lært hvilke elementer i historier som trigger hvilke hormoner og som gjør oss mindre rasjonelle og påvirker våre beslutninger.
Quantum computing er endelig forklart av en ung forsker fra Stanford & Harvard – Jessica Pointing. Hun brukte en smultring som analogi for å forklare qubits, snakket om googles-gjennombruddet med den første oppgaven løst av quantum computing, og gikk gjennom praktiske verktøy (fra IBM, Google og Microsoft) for de som har lyst å prøve seg på det.
Kvandedatamaskin kan i teorien utføre beregninger. For å fungere må kvantedatamaskinen være ekstremt kald, med temperatur ned mot det absolutte nullpunkt. Disse maskinene vil dermed ikke erstatte klassiske datamaskiner, men vil brukes i tillegg for noen få algoritmer som er for tunge til å løse på en klassisk måte.
Lemon med foredraget sitt «I’m going to make you stop hating CSS» leverte det han lovet. For de spesielt interesserte som har lyst å prøve seg på forontend: Besøk Grid Garden http://cssgridgarden.com/ og Flexbox Froggy http://flexboxfroggy.com/. For de med konkurranseinstinkt – CSS Battle på https://cssbattle.dev/
CSS (Cascading Style Sheets) bestemmer utseende på en nettside, for eksempel bakgrunnsfarge, skriftstørrelse, avstander.
HTML (HyperText Markup Language) bestemmer innhold på nettsiden og hvordan det er strukturert.
Favorittunderholdning:
Dylan Beattie and the Linebreakers er kodere som lager coverlåter med IT tekster. Kan du ikke koding? Du kommer til å forstå mer om koding og utviklerlivet etter at du har hørt på musikken.
(..) «There must be a bug in the JavaScript… (..) Cause everything else was built properly, but the front end is a pile of crap» (Cover av Billy Joal «Piano man») >>
(..) «I wrote my «Hello, World»-program in 16 kb of RAM» (..) «Finally came to a conclusion. I’ll do a big rewrite» (..) And it’s gonna compile the first time» (Cover av Don McLean «American Pie»)
(..) «Young man! Back when I was your age it was use net, not a link on a page, alt dot binaries that was where we would go when we wanted things to download» (Cover av «Village People» av YMCA) https://www.youtube.com/watch?v=mQnF1BBBtXs
(..) «We´re gonna build a framework! Cos we wann’a use one, but don’t wann’a choose one» (Cover av Billy Joel «We Didn’t Start the Fire»)
(..) «Your API is a pile of shame You gave Rest a BAD name» (Cover av Bon Jovi «You give love a bad name»)
(…) «We gonna cut them all Features gonna creep (…) Nobody cares if we run on Windows phone» (Cover av Adele’s «Rolling in the Deep») >>
(..) «Be kind to your keys You’ll miss them when they’r gone» (Cover av Luhrmann «Sunscreen») >>
(..) «We can’t deploy things to production (..) All in all it’s just an Enterprise Waterfall» (Cover av Pink Floyd «Another Brick in the Wall») >>
Jeg avslutter her. Uten oppsummering. For jeg leter fortsatt etter en ny sang fra kveldsunderholdningen «Are we coders or web designers» (Cover av The Killers «Human»).
Tekst: Darija Sapozenkova-Hauge. Artikkelen publiseres også i Typografiske Meddelelser (TgM) – et fagblad utgitt av Oslo grafiske fagforening. Takk til Eva-Lill Bekkevad for korrekturlesing. Youtube screenshots fra Dylan Beattie cover musikk.
Darija Sapozenkova-Hauge, sjefskonsulent og teamleder i Experis Ciber AS
Jeg jobber med teknologer i det daglige og ønsker å dele erfaringer om hva UX og bedriften forventer av en god utvikler. I artikkelen kan du lese om hva er en kick-ass utvikler er i mine øyne – og hvordan kommer vi i mål sammen.
#soft-skills #kick-ass utvikler
Hva forventer en designer seg av en utvikler?
Jeg har spurt designfolk rundt omkring om hva kan en utvikler gjøre for å imponere en designer. Svarene jeg fikk var blant annet at utvikler bør: «Komme med sine ideer og tilbakemeldinger»”, «Bli med på brukertest», «Være i kontinuerlig dialog og tettere samarbeid», «Spørre hvis man lurer på noe», «Være med på å definere kravspesifikasjonen». Den røde tråden her er kommunikasjon. Vi vil ha mer dialog med utviklerne.
Hva forventer en designer seg av en utvikler?
Jeg har spurt designfolk rundt omkring om hva kan en utvikler gjøre for å imponere en designer. Svarene jeg fikk var blant annet at utvikler bør: «Komme med sine ideer og tilbakemeldinger»”, «Bli med på brukertest», «Være i kontinuerlig dialog og tettere samarbeid», «Spørre hvis man lurer på noe», «Være med på å definere kravspesifikasjonen». Den røde tråden her er kommunikasjon. Vi vil ha mer dialog med utviklerne.
I mine øyne er de tre tingene som en utvikler imponerer meg med (i tillegg til forventet kunnskap i faget sitt) at:
Jeg kan få rask avklaring
Utvikler tar initiativ til dialog
Dialogen er tidlig og tydelig
Raske avklaringer om forslag fra designer
– For å velge riktig hypotese, trenger en å se på spørsmålet fra flere perspektiver: forretningsmessig, menneskelig, teknologisk og noen ganger, intern-politisk. Teknologiske muligheter avklarer jeg med utviklere. Jeg beskriver eller viser noen varianter til en utvikler og spør hva han/hun synes. «A eller B?» Noen ganger er forslag A enklere å utvikle enn B, noen ganger er det ikke så lett å si, og noen ganger er det ingen betydelig forskjell i utviklingstiden. I det siste tilfellet blir ikke utviklingstimene del av kabalen når jeg skal komme med anbefaling til bedriften.
– Ofte har jeg et konkret og kort spørsmål som starter med «Er det mulig…?» Det er enkelt når jeg får svar enten «ingen problem» eller et klart «nei». Noen ganger får jeg svaret «Jeg må undersøke litt til».
Screenshot fra samtalen på Slack. Utvikler viser at tekst på siste linje tar alt for mye plass på minst størrelse av device som vår native app støtter. Problemet var løst ved å gjøre paddingen og ikoner litt mindre. Screenshot fra samtalen på Slack. Utvikler tar kontakt og foreslår teksten som mangler i web-view header. Sjekker noe og følger opp. Saken blir løst.
«Jeg er veldig fan av at utviklere kommer med innspill til design». Martin G, designer, Gjensidige
Og det er enda mer kult når en utvikler foreslår ny funksjonalitet.
«Programmerere har ofte de beste ideene til tekniske muligheter. For å vite om en ide er gjennomførbar er det ofte avgjørende at en programmerer tar initiativ til å lage en fungerende prototype». Johannes B, utvikler, Sopra Steria
Yurii P, iOS utvikler hos EVRY har foreslått ny funksjonalitet. Ideen falt i smak og Yurii har utviklet en prototype som demonstrere basis-funksjoner. Dette er imponerende og det synes.
Men det som også er veldig viktig er å ikke glemme når utvikler agerer ad-hoc. «Det har oppstått en feil her, kan du fikse det ASAP?». Slik teknisk feil kalles en «bug» og kunden blir rimelig provosert når det oppstår. Her må man agere fort.
Diverse former for kontinuerlig dialog
Når en utvikler er «in the zone», hater han/hun å bli distrahert fra koding. De bør helst ikke bli forstyrret. Men vi på forretningssiden har behov for å avklare. Derfor trenger vi flere måter å samhandle på, avhengig av type problemstilling. Jeg har fast statusmøte med utvikling hver sprint. Min favoritt kanal for raske avklaringer er Slack. Når vi skal løse litt større ting, er det best med møte eller workshop.
Darija viser ideer til utviklere for å avklarer hva det er mulig å gjennomføre, og hvordan. Den gode utvikler kan faget sitt, er tydelig og er tilgjengelig når det trengs.
«Uansett hvilket fagområde man jobber med, er det viktig at man viser interesse for hverandres fagfelt. Nysgjerrighet, initiativ, våge å stille spørsmål – ofte og tidlig (unngå antagelser), tenke utenfor ditt eget fagfelt. Istedenfor å sitte med «design» og så «utvikling», bør man jobbe samtidig med alle deler av oppgaven. Ikke overleveringer, men diskusjoner og spørsmål.» Martin S., designer, Bekk
Vi er helt avhengige av dialog med utvikling for å prioritere riktige ting. For at vi kan sammen skape verdi så bør vi snakke sammen.
For å ha god kommunikasjon må vi snakke sammen ofte. For å få vellykket resultat må vi snakke sammen tidlig. For å få behagelig kommunikasjon må dialogen være tydelig. Et godt digital produkt oppstår gjennom et tverrfaglig team og engasjerte deltakere.
Tekst og bilder: Darija Sapozenkova-Hauge. Artikkelen publiseres også i Typografiske Meddelelser (TgM) – et fagblad utgitt av Oslo grafiske fagforening. Takk til Eva-Lill Bekkevad for korrekturlesing.
Darija Sapozenkova-Hauge, sjefskonsulent og teamleder i Experis Ciber AS
Favorittfilmen min fra 90 tallet er The Matrix. Hovedkarakteren, Neo, jobber som hacker for å tjene ekstra penger og så oppdager han at den verdenen han trodde på bare var en illusjon. Programmerere flytte seg oppover i verdikjeden og det var ekstra kult å kunne data og koding. Det å kunne koding er enda mer relevant i 2019.
Programvare ligger bak alt vi gjør om dagen. Om du sjekker Facebook, slår på lyset, sender blodprøver til laboratoriet eller velger barnehage for barna. For at du skal kunne overføre 100 kroner via en mobilbank-app, ligger mye kompleksitet bak det, som systemer, registre og databaser.
Jeg er teamleder for Javautviklere i konsulentselskapet Ciber og du kommer til å bli kjent med:
Hva er Java
Hvem er en typisk Javautvikler
Hva lages med Java
Hvordan føles det å kode i Java
Artikkel er en blanding av egen research, eksempler fra java-teamet mitt i Ciber og et helt magisk intervju med java-guru Johannes Brodwall.
Johannes Brodwall – Sjefskonsulent i Sopra Steria, Norgeskjent Java-guru og grunnlegger av Mobile Era, Smidigkonferansen og XP meetup. Johannes har vært nominert til årets konsulent av Konsulentguiden 2019. Twitter: @jhannes
Hva er Java?
Java er et programmeringsspråk som kom på 1990-tallet og kom til bli. Det kom som en forbedring av et annet programmeringsspråk som heter C++ men der utviklere kvittet seg med 50 prosent av «bugs».
Java kan «kjøre» på forskjellige plattformer og er objektorientert. Java ble brukt for å lage programvare for små enheter som TV og brødrister. På slutten av 90-tallet var Java det desiderte beste valget da mange norske selskap valgte å utvikle sine tjenester og produkter. Java brukes mye av blant annet NAV, Skatt, Telenor, Norwegian, Sparebank1 og DNB. Litt senere kom C# med Microsoft som offisiell støtte og som kan levere samme funksjonalitet som Java. C#-investeringer kom på 2000-tallet og er brukt for eksempel i Helsedirektoratet, Statkraft, Statnett og mange kommersielle selskap.
– Hvorfor er Java så stor i dag?
Java har en offisiell organisasjon – Oracle, som vedlikeholder språket og stadig kommer med nye oppdateringer, slik at Java er i sync med moderne teknologier.
Java er stort. Det finnes millioner av java kodelinjer som trenger vedlikehold.
Java er et stabil. Serverne krasjer sjelden.
Bra programmeringsopplevelse. Med Java venter programmereren 1 sekund før man kan se effekten av endringene sine, mens du med for eksempel C# fort kan vente i et minutt eller mer.
Java på topp av viktige statistikker:
Nummer en på liste i perioden 1999-2019 ifølge TIOBE index (hits per search query). Det betyr at Java viser seg å være stabilt over tid (20 år).
Første plass (16.005%) på TIOBE index liste i 2019.
41.1% av 90 000 respondenter av Stackoverflow undersøkelsen bruker Java. Stackoverflow er populær teknologi-webside med 500 milioner besøk per måned).
Andre plass (20.25%) på plass på Popularity of programming language index liste. Index-tallene kommer fra mest søkte opplæringsvideoer på Google via Google Trends.
– Hvis Java var mat, hva slags matrett hadde det vært?
Ifølge Johannes Brodwall kan man sammenligne Python med en, JavaScript med fancy bryllupskake, mens Java og C# er catering – serverer mange og fort.
Hva er laget med Java?
Jeg vil dele noen eksempler fra kollegene mine i Ciber.
André
André Sjøvoll jobber som java konsulent hos i forvaltning hos Statens Vegvesen (SVV). Han vedlikeholder flere systemer. Et av systemene heter VegSak. Der kan brukerne søke om tillatelse å kjøre med tung, lang, bred eller høy last og saksbehandler hos SVV kan besvare forespørselen. Transportører får utstedt et løyve for å utføre transporten.
Stikkord: #Java8 #Spring #Hibernate #JSP #Soap Web Services #Stackoverflow #Maintenance
Thao
Thao Le er seniorkonsulent i Ciber, og utvikler på blant annet Meldingsformidleren for Statens Vegvesen. Denne applikasjon brukes så fagsystemer i Statens Vegvesen kan sende digital post til innbyggere og virksomheter. Applikasjonen benytter Altinn og DIFIs SOAP-tjenester for mottak av digital post. Thao beskriver applikasjonen som «Spring Boot-applikasjon som kjører på Java 8 og Tomcat, har database-integrasjon og en frontend».
Stikkord: #Java8 #Tomcat #Spring Boot #Frontend
Sven-Jørgen
Sven-Jørgen Karlsen jobber som senior java konsulent hos NAV. Han lager et system som utveksler sosial sikkerhetsinformasjon mellom NAV og EU. Spør du ham, så sier Sven-Jørgen: «Jeg jobber med EESSI-basis som er et sett av mikrotjenester i Spring Boot som kjører på Kubernetes cluster.» Stikkord:#Agile Automation #Kubernetes #Docker #Microservices #Spring Boot #Jenkins 2 #EESSI
Cato
Cato Eik er Java-fagleder i Ciber og jobber som senior utvikler hos Eika bankene. Cato utvikler et system der brukeren kan søke lån eller kredittkort. Cato, som de fleste Java-utviklere jobber på server-siden (backend). Stikkord: #Java8 #Micro Services #Open Shift #Liquibase #Jersey #Automation #BanID
Hva er en typisk Java-utvikler?
I følge Johannes Brodwall finnes det en stereotypi som er sann: En mannlig backendutvikler er ubarbert, mens en frontend utvikler har fint skjegg eller bart. Kvinnelige frontendutviklere har bluse, mens backendutviklere har genser. Skal utvikleren på jobb og vil unngå å gå i møter, så tar de på seg sort t-skjorte fra utviklerkonferanse eller en hoody. Skal man på møte den dagen, så bruker man farget skjorte. Har en utvikler fine bukser eller jakke – er det et faresignal om at han eller hun har begynt å jobbe alt for mye med management og ikke er så god til å programmere lenger.
– Hva motiverer en utvikler?
Fullføre piece of code
Lære nye ting
Føle mestring
– Hvilke personegenskaper bør en utvikler ha?
1. Forståelsen av at man ikke er dum bare fordi man ikke klarer å løse en oppgave og ikke gi opp. Det kan ofte skje at du sitter med en kode som ikke funker. Og du vet ikke hvorfor. Etter flere timer med frustrasjon finner du ut at det var bare en ekstra parentes som satt i koden. Med tiden lærer man å løse enkle problemer, men man kommer opp i mer komplekse problemstillinger. Derfor er det smart for en utvikler å dele opp oppgavene slik at man kan oppnå noe til tross for at man ikke oppnår alt.
2. En god utvikler trenger oppmerksomhet for detaljer. Maskinen gjør eksakt det den er bedt om å gjøre, selv om det ikke var det man mente å be den om.
3. Tålmodighet til å koble mentale biter sammen.
– Hvordan ser en dårlig kode ut?
Man sier at all kode som man ikke har skrevet selv, er en stygg kode. Og det er ofte sant. Men det finnes noen karakteristiske trekk som gjenspeiler en dårlig kode:
Koden kan være rett og slett slurvete (dårlig formatert).
Det kan være for mange koder der det er ikke nødvending.
Dårlig organisert og dårlig implementert kode.
Slurvete kode er enklere å se og lett å fikse, mens dårlig struktur er veldig tidkrevende.
– Hvordan vet man at noen er en god programmerer?
Johannes kan du ikke vite det hvis du ikke forstår koding. Du kan be noen å parprogrammere, og så høre med vedkommende om hvordan det gikk.
Hva er Java programmeringsopplevelse?
«Backend runs on the servers, frontend runs on the browser. I work on the server side.»
Man sitter ofte foran flere store sorte skjermer, med favoritt-tastaturet. Java er backend og det som lages er ikke direkte synlig for brukere, men når browseren kommer opp i bildet er den hvit. Og det er bedre for øynene å sitte foran hvit skjerm.
Arbeidsverktøy
For å komme i gang med Java, så må man laste ned JDK (Java development kit). JDK kommer med 25 000 classes (extensive libraries). Man bruker ofte IntelliJ for å lage java kode.Eclipse er i følge Johannes et enda bedre editeringsverktøy, men det er ikke så mange som bruker det. Man kan også editere i TextPad, NotePad, Visual Studio, VS Code m.m.
Til venstre ser man Project Explorer i IntelliJ med mappestruktur, til høyre skriver man kode, nede ser man hvordan koden kjøres. Her lages .java filen og konverteres til .class fil.
På PC har man Command Line Window (Terminal på MAC) som kjører .class fil.
Systemet på bildet er brukt til internt vedlikehold i redningssystemer i Norge. Til venstre ser vi JavaScript i en Chrome browser. Det er frontend men det er tydelig ikke berørt av en designer. Til høyre ser man Chrome debugging tools.
Når jeg ber Johannes å utdype hva systemet gjør så sier han: «You can see network requests that are used by the client (written in JavaScript) to fetch data from the server (written in Java)» Han insisterer på at det ikke går an å si dette på en mer allment forståelig måte, så jeg må nøye meg med den forklaringen.
Syntax
Java, som alle programmeringsspråk har sine regler. Blå er såkallte nøkkelord som utgjøre hovedgramatikken. Det finnes også data typer, operators, variable, kommentarer og flere konstruksjoner.
Her ser man et program som søker etter ordet «Cat».
La oss se på elementtypen «Comments». Johannes forteller at det finnes 3 måter å kommentere på i Java.
// Kommentar på en linje. Brukes for korte kommentarer, ofte TODO huskepunkter
/*
Kommentar på flere linjer. Brukes ofte for å beholde en kopi av gammel kode, eller alternativ variant av kode, eller tanker man hadde da man skrev kode.
*/ /**
* Såkalt javadoc. Det er dokumentasjonskommentar
* en linje eller flere. Verktøy omformer kommentaren
* til dokumentasjon på websider
*/
Johannes påpeker at hvis man ikke er flink til å skrive en god kode, så er man like dårlig til å skrive gode kommentarer.
In the zone
Du sitter konsentrert med en kode og er «in the zone». Så kommer det verste som kan skje – distraksjon. Som utvikler så må du enten ha god korttidshukommelse eller bygge en struktur som du lett kan navigere i. For å håndtere distraksjoner bedre, må man dele opp oppgavene i mindre biter.
Parprogrammering
Det eksisterer et ordtak, «Det én programmer kan gjøre på 1 måned, kan to programmere gjøre på 2 måneder». Det kan være sant, men unntaket er parprogrammering. Parprogrammering er en teknikk der to programmerere sitter ved siden av hverandre og jobber med en kode sammen på samme maskin. Men hvorfor er to som parprogrammerer bedre enn to som sitter og koder separat? Det er enklere å håndtere distraksjoner når man jobber sammen på den måten – man må tenke høyt når man koder og man lager en slags mental «tråd» som hjelper en å komme tilbake til kontekst. Dessuten, når man har praprogrammert så har man to personer som kan endre kode eller fikse problemer når noe går galt.
Fira Code Font
Visste du at det finnes font for programmerere? Fonten er ikke Java-spesifikk, men er likevel en morsom severdighet. Fira Code Font brukes for å formatere «operators» til å være av mer lesbare og hjelper utviklere å navigere i koden.
For å forstå en programmerer må man kunne programmere. Vet du hva det egentlig betyr når en utvikler sier «We need to rewrite the monolith with Spring Boot in Kafka in order to support Microservice architecture on Kubernetes with event streams»? Det kan bety «Vi leter etter passende moderne teknologier for å løse kundens problem, men det kan også bety «Vi vet ikke hva brukeren trenger, så vi skal leke med teknologien og bygge opp CV-ene våre istedenfor». Du må forstå både teknologi og brukerbehov for å vite hvilken tolkning som er riktig.
En du ikke så god på design, kan du klare å gjøre en design-jobb uten mye opplæring. Men kan du ikke kode, så har du ingen sjanse å lage noe som helst. Du bare sitter og stirrer på skjermen foran deg. Ifølge Johannes, tar det en livstid å lære seg Java. Så det er bare å begynne nå. Java er spennende og gøy.
«I didn’t say it would be easy. Just said it would be the truth.» Morpheus, The Matrix
Tekst: Darija Sapozenkova-Hauge. Bilder: Darija Sapozenkova-Hauge & web, matbilder: Unsplash: Alex Munsell, Jay Wennington, Saile Ilyas. Artikkelen publiseres også i Typografiske Meddelelser (TgM) – et fagblad utgitt av Oslo grafiske fagforening. Takk til Eva-Lill Bekkevad for korrekturlesing.
Darija Sapozenkova-Hauge, sjefskonsulent og teamleder i Experis Ciber AS
Ønsker du å se selskapet ditt fra fugleperspektiv, se hvordan ting henger sammen og lære fra de beste? Prøv deg på lederskygging – en dag med lederen din.
Jeg har skygget flere ledere. Det startet med at jeg hadde en dag sammen med Espen, administrerende direktør i selskapet mitt, Ciber. Det var gøy og lærerikt. Jeg har skrevet guide i skygging for nybegynnere på: http://blog.darijasart.com/a-skygge-en-leder/. Lederen i Ciber har også skygget meg og fortalt litt om erfaringene sine. Video: https://www.youtube.com/watch?v=mrB-THWr1E4&t=950s
Nedenfor forteller jeg om min skygging av Trygve Solem, direktør i Experis Norway og Sølvi Spilde Monsen, administrerende direktør for Manpower Norge. Dette er en slags dagbok over hva vi gjorde, hva jeg synes var interessant og hva jeg tar med meg videre.
1. Skygging av Trygve
Trygve Solem er administrerende direktør i Experis Norway, morselskap til Ciber, selskapet jeg jobber i.
Jeg kom først, slik jeg ofte gjør. Vi skulle i et kundemøte hos kunden og gjengen var fem karer i nesten like blå dresser. At jeg også hadde blå klær, var flaks. Jeg tror ikke de andre skjønte helt hva jeg gjorde der. – Darija skygger meg i dag, forklarte Trygve, og alle satt i gang med siste planlegging før møtet. Jeg fikk crash-course for dummies fra Trygve om formålet med møtet og hørte på guttenes småprat. KAMer fra forskjellige regioner skulle presentere bemanningskapasitet og ønske å betjene kunde på best mulig måte. Experis leverer ingeniør-, IT- og økonomiressurser til kundene sine.
Vi kom inn i et stort møterom med mange deltakere fra kunden. De viste en Powerpoint-presentasjon om selskapet sitt og om behovene sine. Så presenterte Trygve Experis. En annen fra oss snakket om hvordan vi jobber, og vektla at 80 prosent av de største kundene i Norge har en eller annen form for samarbeid med oss. Vi måler kundetilfredshet og kandidater. En nøkkelperson, Rune, fortalte om et allerede vellykket samarbeid, som kunden ønsker å utvide til flere regioner. Det var en del viktige avklaringer på detaljnivå. Ikke overraskende, for å få kundens ønsker oppfylt, konkluderte kunden med at også de må gjøre litt jobb på sin side. Jeg satt uvanlig stille hele møtet og observerte. Jeg var nysgjerrig på en annen person som også satt veldig stille – hva tenker vedkommende? På vei ut av rommet spurte jeg hva hun tenkte. Det viste seg at hun var positiv og nysgjerrig, og ønsket å komme i gang. Det var jo godt å høre for gjengen vår. Trygve sa at det var bra at jeg spurte.
Etter en liten oppsummering på parkeringsplassen, sa vi farvel til de som skulle ta fly tilbake og dro tilbake til kontorene våre i Lakkegata.
Der gikk vi rett til et video-statusmøte om digital driftsmodell. Jeg husker ikke hvem som var på den andre enden, men jeg husker et Excel ark med en del beige farger. Nytt system for search & match ble diskutert. Jeg likte tilnærmingen (jeg praktiserer ofte en slik tilnærming selv) «Vi må tilpasse oss system, ikke motsatt» (ellers så blir det veldig dyrt). Det er fint å være trygg på valg ledelsen gjør.
Lunsjen husker jeg ikke. Men jeg husker veldig godt Forecast møte med Avan (datterselskap til Experis) om konsulentomsetning. Det var mye tall! «Q3, Q4 må klargjøres mer». Trygve påpekte at det er viktig å ha riktig info til månedsmøtet med Nordisk ledelse. Det var interessant å se hvordan søsterselskapet til Ciber rapporterer konsulentomsetning, de gjør det annerledes enn vi gjør i Ciber.
Trygve, Jorunn, Richard og Bodil på telefon.
Observasjon: Trygve er beslutningsdyktig og tydelig. Det jeg vil lære mer av ham, er kunsten å drive “butikken”.
Take-away:
Det mest interessante for meg var såklart kundemøtet – der jeg kunne se «produktet» Experis leverer og selger inn i praksis. Det var lett og interessant å observere forskjellige karakterer som var på møte, lese hva som er sagt og hva de tenker. Erfaringen min fra å høre og observere folk under brukertest-intervjuer hjalp meg å forstå nyansene i samlingen. Hoved-takeaway – mennesker med spisskompetanse og skalering av tilbudet er en hot vare.
Jeg lærte hvordan morselskapet er organisert og hvordan vi i Ciber relaterer til det hele.
Det var kult å se Trygve «in action» på diverse møter. Han er dyktig og inkluderende.
2. Skygging av Sølvi
Jeg ønsket å skygge en kvinnelig leder. Hvem kan være forbilde? Sølvi er administrerende direktør for Manpower Norge og LinkedIn sier at hun er flink. Jeg tok kontakt via Linkedin og vi avtalte å møtes.
Sølvi kom fra Bergen til Oslo-kontoret og vi hadde et stort program den dagen.
Det var bra at Sølvi hadde røde klær på seg den dagen, så det var lett å finne henne flyende rundt i lokalene. Jeg pleier ikke å ha noen forventninger til den jeg skygger, men Sølvi var godt forberedt. Vi startet med en introrunde. Sølvi har vært mye involvert i styrearbeid og nettverksfora gjennom karrieren sin. Det bærer frukter.
Vi har sett litt på innboksen til Sølvi. En mail var interessant fordi den handlet om nye lover rundt stillingsbrøk, som gir konsekvens for selskap som jobber med bemanning. Kort fortalt – kravene til fast ansettelse er skjerpet og fortrinnsretten for deltidsansatte er styrket.
Sølvi tok meg gjennom organisasjonskartene for Manpower Norway og ManpowerGroup Norway. En hyggelig kar – Lars – kom innom, og vi hilste.
Sølvi skriver julekort og vi tar en hilse-/klemmerunde i huset med blant annet Vigdis fra Bid team, Lise, Maalfrid og National sales teams representant.
Sølvi stråler av varme og man ser at hun bryr seg om folk. Hun passer godt som leder i et selskap som jobber med nettopp dette – bemanning.
Sølvi har masse energi og nysgjerrighet og det er premissene for å lykkes.
Vi tok et jenteselfy med Maalfrid Brath – administrerende direktør for det hele (ManpowerGroup Nordic & Baltic).
Jeg observerer mye aktiv lytting som Sølvi gjør i hverdagen sin. Det er en viktig suksessfaktor for samarbeid og beslutninger. Mer aktiv lytting er noe jeg har på to do lista mi.
KAM Syver kom innom og presenterte kunden Tradebroker, som han har ansvar for. Hvorfor? Fordi vi skal til lunch med Tradebroker på Sudost! TIPS: Lederskygging i juletida er alltid litt mer hyggelig 😉
Observasjon: Sølvi har vesker til alle anledninger (stor til pc-en og liten til restaurant-besøk). På to do listen min: Vurdere et liv uten ryggsekk.
Etter lunch fortsetter vi med vår Inbox-«safari». Sølvi ringer opp en kollega og de diskuterer avtaleutkast fra Bullhorn/Volcanic. Hun tenker høyt og det er interessant hvilke områder i dokumentet som tiltrekker seg hennes oppmerksomhet og hvorfor.
Vi går til status med salg/convenience team ved Marco. Litt annerledes modell, beregninger og presentasjon enn hos oss i Ciber. Det var bra stemning.
Avslutningsvis tok vi en kjapp wrap-up med Sølvi og jeg løp til Luciadagen i barnehagen.
Det er spennende å følge flinke ledere og se hva de gjør en vanlig dag på jobben. Nå vet jeg mer om vår bransje, konkurrenter, historisk utvikling. Hva som er viktig, og hvordan min organisasjon fungerer og hva som er viktig for oss. Det er givende både for ledere og medarbeidere å delta på lederskygging. Både jeg og de jeg skygget fikk utvidet perspektiv og en arbeidsdag som var litt annerledes på en hyggelig måte.
Skygg en leder du også.
Tekst og bilder: Darija Sapozenkova-Hauge. Artikkelen publiseres i medlemsblad Norsk Forening for Prosjektledelse “Prosjektledelse”; også i “Typografiske Meddelelser” (TgM) – et fagblad utgitt av Oslo grafiske fagforening. Takk til Eva-Lill Bekkevad for korrekturlesing.
Darija Sapozenkova-Hauge, sjefskonsulent og teamleder i Experis Ciber AS
