SpareBank 1 Utvikling

Dette er SpareBank 1 Utvikling, og på denne siden kan du bli bedre kjent med hvem vi er, hva vi gjør og hvordan vi jobber – gjennom oss som faktisk jobber her. Så kan du vurdere selv om du også har lyst til å bli en del av det vi mener er det beste og triveligste IT-miljøet i bransjen. Med de flinkeste folka.

Vi skaper en enklere og bedre hverdagsøkonomi

Vi utvikler og forvalter løsninger som brukes av over 1 million kunder. Det er vi skikkelig stolte av! Her kan du bli enda bedre kjent med selskapet, måten vi jobber på, løsningene vi lager, og ikke minst - ukas aller beste dag: Fagdagen.

Miljøbilde fra SpareBank 1

SpareBank 1 Utvikling på Medium @sparebank1-digital

Det er ikke alltid jeg mocker, men når jeg gjør det bruker jeg Troxy!

I SpareBank 1 Utvikling har vi lang erfaring med å teste hvordan våre applikasjoner oppfører seg under last, altså når mange samtidige brukere benytter en applikasjon. Dette skjer som oftest under en test som kalles ytelsestest, loadtest, performancetest, lasttest, ja dere skjønner greia. Når man kjører en av disse testene, så er det ikke alltid greit å også belaste alle bakomliggende systemer. Dette gjelder spesielt når man integrerer mot underleverandører.Så hva gjør man da? Jo da får man simulere kallene mot de eksterne systemene med hjelp av et simulerings- eller mockverktøy.Om vi går tilbake 15 år i tid var det ikke mange verktøy å velge mellom. Valget ble da å utvikle et eget verktøy som fikk navnet Troxy. Troxy ble spesialdesignet for å brukes som en simulator av eksterne systemer og måtte ha høy kapasitet for å kunne svare på forespørsler fra flere applikasjoner samtidig under lasttest.Troxy kan konfigureres for å settes opp mellom en klient og en webservice. Der fungerer Troxy som en proxy og kan lytte på trafikken og ta opp HTTP-request og HTTP-response. Disse opptakene kan deretter brukes til å svare istedenfor den faktiske tjenesten når applikasjonen sender forespørsler til andre systemer.En av hovedstyrkene til Troxy er at man i tillegg kan trekke ut verdier fra en request og deretter bruke de i responsen som sendes tilbake. Dette er spesielt nyttig om man vil bruke den samme mocken for flere forskjellige testbrukere og der, som et eksempel, fødselsnummer er en verdi som sendes med i request og som i tillegg er med i response. Dette gir noe dynamikk i en ellers statisk oppførsel.Troxy kan i tillegg enkelt utvides med små java-klasser der man har full kontroll over request og response, både under opptak og avspilling. Dette gjør at man f.eks. automatisk kan formatere opptak til å tilpasses sine formål, uten manuell redigering i etterkant.All funksjonalitet kan skriptes via et API mot Troxy, men trenger man manuelt å endre ting kan dette gjøres via et fullverdig UI. Her finner vi blant annet funksjonalitet for å endre modus på Troxy (Avspilling, Opptak osv), håndtere og redigere mocker, samt sjekke loggstatistikk for antall kall mot forskjellige endepunkter.Troxy har med årene blitt et fullverdig mockverktøy og SpareBank 1 Utvikling bruker det nå, i tillegg som simulator ved lasttester, innen både funksjonell test, automatisert regresjons- og integrasjonstest og som simulering av backend-systemer i vår Utviklerportal for åpne APIer.Som et konkret eksempel kan nevnes et testoppsett der det er mulig å konvertere automatiserte ende-til-ende tester til å kjøre mocket, helt uten manuell jobb involvert. Oppsettet tar i utgangspunkt i tester som kjører mot et dockerisert testmiljø inneholdende applikasjon under test sammen med Troxy. Testen kjøres først ende-til-ende med Troxy i opptaksmodus. Deretter kan den samme testen kjøres med Troxy i avspillingsmodus, fullstendig mocket, uten at applikasjonen sender kall bakover mot andre tjenester. Mockene blir lagret sammen med testen og øvrig kildekode.Da Troxy er et testverktøy som kan brukes av andre enn bare SpareBank 1 Utvikling, hvorfor ikke dele det som åpen kildekode? Som sagt så gjort, i 2019 ble det tatt en beslutning om å legge ut det kjære mockverktøyet vårt som open source. For å få det til måtte vi rydde litt i kildekoden, og dette ble gjort gjennom et godt samarbeid med våre utviklere på deres fagdag.Så trenger du et fleksibelt og utvidbart mockverktøy som i tillegg tåler høy last og kan brukes i mange ulike type testscenarier? Kanskje trenger du et godt alternativ til mer etablerte mockverktøy som f.eks Wiremock? Eller kanskje trenger du inspirasjon for å lage noe eget? Test ut Troxy da vel!Det er ikke alltid jeg mocker, men når jeg gjør det bruker jeg Troxy! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Robert Hammarström

Start smart med premortem

Etter å ha gjennomført over 80 post mortemer siden 2017 sitter SpareBank 1 Utvikling igjen med store mengder verdifull læring, og en trygg arena for å ta frem innsikt sammen etter feil og hendelser. Under arbeidet med post mortem ble vi etterhvert også kjent med en beslektet metode - premortem. Formålet med premortem er å skape læring og forbedring uten at noe har gått galt. En besnærende tanke, men hvordan er det egentlig mulig?Bilde: www.theguardian.comHva er premortem?I Harvard Business Review-artikkelen “Performing a Project Premortem” fra 2007 beskriver Gary Klein en metode for å øke muligheten for at prosjekter lykkes. Ved å gjennomføre premortem i starten av prosjektet, eller før viktige beslutninger skal tas, søkes forbedring mens det fortsatt gjenstår tid og rom for endring. En slik tilnærming fremstår langt mer attraktiv enn alternativet der post mortem utføres etter at prosjektet har gått galt.I en premortem forflytter teamet seg mentalt frem i tid til et sted der prosjektet eller organisasjonen har mislykkes. Deretter ser man seg tilbake for å identifisere hva som kunne føre til at det gikk dårlig. Hovedoppgaven til teammedlemmene er å ta frem sannsynlige grunner til at man har feilet og reflektere over funnene.Kort beskrevet inneholder premortem følgende:Teamlederen tar med seg teamet et år frem i tid og informerer om at prosjektet på dette tidspunktet har feilet spektakulært.Teammedlemmene ser seg tilbake og skriver hver for seg ned årsaker til at det gikk så galt.Resultatene deles med gruppen ved at et og et notat leses opp av forfatteren. Når den første årsaken er presentert leser nestemann opp en ny. Slik går runden videre i gruppen helt til alle punktene er dokumentert.Teamet reflekterer over innspillene mtp. hvordan man kan styrke sin plan.Diskusjon om mulige grunner til at rekruttering av utviklere gikk galt i 2020.Hvorfor er premortem en god ide?Gary Klein viser til at effekten av “prospective hindsight” i premortem er betydelig høyere enn det tradisjonelle spørsmålet “Hva kan gå galt?” ved starten av et prosjekt.“Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%.“— Gary KleinVidere peker Klein på at premortem kan bidra til å redusere effekten av overmot ved starten av prosjekter. Teknikken skaper også trygge rammer for å kunne løfte frem og diskutere problemer. Ved at metoden belønner vanskelige innspill, bygger man kultur for å prate om utfordringer.Psykolog og nobelprisvinner i økonomi Daniel Kahneman omtaler premortem i sin anerkjente bok “Thinking, Fast and Slow”. Her er lenke til en kort video hvor Kahneman beskriver metodens positive effekter.“What the premortem technique does, which I think is beautiful, is that it legitimizes dissent. Actually, it turns things around. It rewards people for being imaginative in finding flaws in the current plan.”— Daniel KahnemanTid for eksperimentPå slutten av 2019 grep vi sjansen til å teste ut metoden ifbm. satsing på et nytt produktområde. Erfaringen fra første premortem var positiv, der teamets refleksjon skapte innsikt med betydelig verdi for deres videre arbeid. De positive erfaringene gav mersmak, og vi har nå prøvd ut premortem på følgende områder:Partneres bruk av SpareBank 1 sin finansplattformRekruttering av utviklereOrganisering av utviklingsteam med økt ansvarCovid-19 situasjonen (remote sesjon)Vår gjennomføringI premortemene som er utført til nå har det vært gunstig med en eller to dedikerte personer til å fasilitere sesjonen. Psykologisk trygghet er et viktig premiss for arbeidet som skal finne sted. Tydelig fokus på “blaimfree” dialog med trygge rammer vil være sentralt for en vellykket gjennomføring. Vi har derfor innledet hver premortem med en introduksjon av selve konseptet, inkludert viktigheten av å følge anbefalte retningslinjer. Ut over introduksjonen har det ikke vært behov for at teammedlemmene har forberedt seg særskilt til et premortem.For oss har det viktigste forarbeidet vist seg å være konstruksjonen av caset som har feilet spektakulært. En sterk historie som fremføres med innlevelse og troverdighet er utgangspunktet for å skape engasjement i gruppen. Både kreativitet og fremføring har så langt vært imponerende.Teamet skriver ned grunner til at det gikk galt.Etter at teamet er tatt med frem i tid, og informert om at man har feilet stort, er det dags for å reflektere. I denne delen av premortem har teamet sett seg tilbake og notert hver for seg årsaker til at utfallet ble negativt. Resultatene er så blitt delt i gruppen ved at et og et notat presenteres av skribenten. Årsaken henges deretter opp på veggen etter eventuelle spørsmål og kommentarer. Med første notat ferdig presentert leser nestemann opp en ny lapp. Runden blir avsluttet når alle årsakene er presentert og klistret på veggen.Med gjennomgang av mulige feilkilder sluttført var neste steg å velge ut hva man skulle fokusere på med resterende tilgjengelige tid. Deltagerne grupperte da først sammenfallende punkter og stemte så frem årsakene som var mest interessante å drøfte dypere mtp. rotårsaker og mulige tiltak. Prioriteringen ble gjort vha.“dot-voting”.Når arbeidsmøtet er ferdig og deltagerne har mottatt velfortjent takk for bidrag og innsats gjenstår noe etterarbeid. Dette består i at innspillene oppsummeres og deles med teamet, samt deles med andre som kan ha nytte av resultatet. Noen punkter krever ytterligere refleksjon og analyse, mens andre allerede har resultert i konkrete tiltak.Kan premortem bli for negativt?Et punkt vi var nysgjerrige på var om det kan bli for mye negativt fokus i en premortem? Daniel Kahneman trekker frem en bekymring han har registrert ifbm. at organisasjoner har et grunnleggende ønske om optimisme. Her fryktes handlingslammelse hvis man blir kjent med reell kostnad og risiko, som et resultat av at man kvier seg for initiativ som blir utfordrende. Kahnemans svar til dette er at balansepunktet mellom realisme og optimisme er en reell diskusjon. Samtidig argumenterer han for at å kjenne til feilkilder uansett er nyttig. Vi har så langt ikke opplevd utfordringer knyttet til at fokus på risikopunkter skaper negativ stemning eller frykt for handling. Inntrykket har tvert i mot vært at det skapes energi og et sterkt ønske om tiltak for å forbedre situasjonen.Tilbakemeldinger fra deltagereEt tydelig mønster i tilbakemeldingene etter våre premortemer er at det er positivt å jobbe med problemer før de oppstår. Deltagerne synes det er nyttig å være pro-aktive og reflektere over hva som er viktig. I tillegg liker man selve formatet, der lettbent og enkel gjennomføring skaper en positiv måte å diskutere mulige utfordringer på. Samtidig lar strukturen gruppa fokusere på det de selv ønsker uten negativt press eller stress. Videre vurderes premortem som en lærerik øvelse der det kommer frem punkter man ikke har tenkt på før.Kan vi risikere at historien som fremføres er for negativ? En av tilbakemeldingene fra deltagerne stilte spørsmålstegn ved om historien som ble fortalt i for stor grad var “worst case”. Dette spørsmålet er det verdt å reflektere over. Selv om våre case til nå ser ut til å ha truffet greit mtp. balanse på alvorlig konsekvens og realisme understreker punktet viktigheten av at materialet som presenteres er godt oppbygd og troverdig presentert.OppsummeringI SpareBank 1 Utvikling er post mortem en god følgesvenn for trygg læring når noe har gått galt. Det har vært lærerikt å teste ut en teknikk som søker å redusere behovet for bruk av post mortem. Erfaringene så langt støtter hypotesen om at premortem kan være en bidragsyter til dette. Gjennom refleksjon og innsikt mens det fortsatt er tid og mulighet for forbedring øker sannsynligheten for at det man jobber med blir vellykket.Start smart med premortem was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristoffer Berg

Ikke jobb mens jeg forstyrrer — del to

Ikke jobb mens jeg forstyrrer — del toI del en av denne historien fortalte jeg at jeg var på vei til å bli utbrent.Kombinasjonen av sterkt leveransepress og hyppige avbrudd var i ferd med å spise oss opp. Hvordan skulle vi klare å levere forbedringer raskt og med høy kvalitet, når vi ble avbrutt hele tiden?Gjennom å gjennomføre en A3 identifiserte vi de viktigste typene avbrudd vi ble utsatt for:Møter — både egne og andresElektronisk kommunikasjon — chat, epost, SMS osvSelvpåførte konsentrasjonsavbrudd — tankene spinner avgårde, enten på oppgaver en vet en skal gjøre, eller en kommer på nye oppgaver som trengs å gjøresPirk på skulderen og kapring ved kaffeautomaten — “Har du fem minutter?”Del en beskrev hvilke grep vi gjorde for å håndtere møtene.Men hva har vi gjort for å få kontroll med resten?Foto: Getty Images via IStock.Jeg sendte deg akkurat en epostDet er godt mulig. Det vet jeg ikke noe om. For jeg har skrudd av epostklienten. Jeg prøver så godt jeg kan å ha den lukket gjennom dagen. Helst ønsker jeg å sjekke epost om morgenen, etter lunsj, og før jeg går hjem om ettermiddagen. Har du sendt meg en epost på den private epostadressen min, så sjekker jeg den ikke før på kvelden.Før hadde vi epostklienten oppe, gjerne med pushvarsling aktivert, hele dagen. Dette var en av årsakene til at vi endte opp i den uholdbare situasjonen vi var kommet i. Det er en befrielse å kunne håndtere eposter på bestemte tider på dagen, heller enn å stadig skulle bli avbrutt av mer eller mindre viktige eposter.Ved å håndere epostene på denne måten, får jeg også muligheten til å prioritere arbeidet epostene resulterer i. Når jeg kan se gjennom flere eposter samtidig, kan jeg lettere ta stilling til hvilke som bør følges opp når.Kanskje har du ditt eget system for å håndtere oppgavene dine? For meg fungerer det best med en liste i et enkelt tekstdokument hvor jeg kan notere så mye eller lite jeg trenger om det som skal gjøres.TextEdit oppgavedokumentet mitt ble litt kjedelig, så det ble dette bildet istedet.Når en oppgave er gjort, sletter jeg den fra listen min. Det gir en god følelse. Derfor er det lurt å skrive opp også enkle oppgaver som å svare på en epost. Det lille dopaminkicket du får når du har gjort en oppgave og kan slette den fra listen, det har du fortjent.Det rister i buksaJa, det gjør det. Men det er sjelden. For jeg har skrudd av nesten alle pushvarslene mine. De eneste pushvarslene jeg har igjen er SMS, Facebook Messenger og direktemeldingene på Slack.Før hadde jeg pushvarsler med vibrasjonsvarsling på det meste, inkludert Facebook og private epostvarsler. Det var gøy i starten, men etterhvert som jeg ble mer og mer bevisst på hvordan disse avbruddene påvirket meg, var det en befrielse å skru dem av. Jeg har aldri sett meg tilbake.Jeg kom på en tingDet gjør jeg hele tiden. For å få det ut av hodet og jobbe videre med det jeg holder på med, så må jeg legge til en ny linje i oppgavelisten min. Da får jeg også samtidig prioritert oppgaven i forhold til alt det andre som står der som skal gjøres.Av og til er det utfordringer som er såpass krevende at føles umulig ikke å tenke på det. Tankene blir trukket mot det hele tiden. Da holder det ikke bare å notere det ned i oppgavelisten. Da må jeg også ta meg tid til å finne ut av når jeg skal jobbe med problemstillingen. Deretter booker jeg et møte i kalenderen med meg selv, slik at jeg vet at jeg har god nok tid til å jobbe grundig med det. Først da klarer hodet slippe taket, og jeg kan jobbe videre med det jeg holder på med.Det kan være lurt å sette av tid i kalenderen til å jobbe med krevende utfordringer.Så du Slackmeldingen min?Det kommer an på. For jeg har ofte skrudd av Slackklienten også. Er jeg midt inne i noe, så er det ikke sikkert jeg sjekker mobilen, selv om Slackappen gjør et rist.Jeg prøver å sjekke Slack samtidig som jeg sjekker epost. Da oppnår jeg den samme fordelen som nevnt over: Jeg kan gå gjennom alle meldingene og epostene samtidig, og lage en prioritert liste over hva som skal håndteres når. Er det trivielt å svare på meldingene, så svarer jeg selvfølgelig på dem med en gang.Men hva når noen trenger hjelp med en gang? Er det noen som trenger hjelp eller lurer på noe, så er det som oftest relatert til noe jeg jobber med. Jeg jobber i team. Dermed er det som oftest noen av teammedlemmene som trenger hjelp eller lurer på noe. Da prater vi heldigvis sammen. Det er som oftest alltid mer effektivt enn skriftlig på Slack, og mye hyggeligere.Har du tid til å tenke?Vi som jobber med kunnskapsarbeid, er ansatt for å løse komplekse problemstillinger som ofte aldri er løst før i vår kontekst. Samtidig er det en forventning om at vi skal være tilgjengelig for alle spørsmål, meninger, informasjon og møter i alle kanaler hele tiden. Dette er en situasjon som kan være farlig, og i verste fall føre til utbrenthet og årelange fravær fra arbeidslivet.Det lille dopaminkicket vi får for hver eneste Slackmelding, Facebookpost, møteinnkalling eller epost vi mottar, er godt. Følelsen vi får når vi har løst en komplisert oppgave som ofte kommer mange andre til nytte, er bedre.For å løse flere av de kompliserte oppgavene, må vi gi oss selv tid og rom til å tenke. Vi løser oppgavene best når vi jobber sammenhengende uten forstyrrelser.Ved å ta tilbake kontrollen over tiden min, unngikk jeg trolig å bli utbrent. Jeg håper du også tar tilbake kontrollen over tiden din. Det tror jeg er best for oss alle.Ikke jobb mens jeg forstyrrer — del to was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Når hårete mål for rekruttering gruses på deltid

Historien om hvordan SpareBank 1 Utvikling lykkes med felles strekkmål for rekruttering.Mot slutten av 2018 fikk vi en monumental utfordring: Gode erfaringer med insourcing til utviklingsorganisasjonen over flere år gjorde at SpareBank 1 Utvikling ønsket å øke satsingen på rekruttering ytterligere for 2019. En god tanke, men ikke en vi var alene om. Markedet vi opererer i er krevende, og konkurransen om de flinke folkene er knallhard — med langt større etterspørsel enn tilbudsside. Særlig er dette tydelig i utviklermarkedet, der vårt behov er størst. Rekrutteringsapparatet vårt gikk allerede for full maskin. Det var ikke enkelt å se for seg hvordan vi skulle lykkes med en ambisiøs oppskalering. Strekkmålet som ble satt for 2019 ble imidlertid oppnådd allerede ila. september måned. For året totalt ble måloppnåelsen hele 138%. Hvordan var dette mulig?Tydelige mål hjalp ossFor å hjelpe oss med å holde fokus over tid valgte vi en Objectives and Key Results-tilnærming. Arbeidet med å ta frem mål ble startet tidlig ved å kombinere dialog med ledelsen med input fra de som ville være involvert i rekrutteringen. Vårt objective ble “Leveransekraft i tverrfaglige team med høy andel ansatte utviklere og teamledere”. For å realisere dette kom vi fram til to målbare key results.Det første var et strekkmål på hvor mange vi skulle ansette. Tallet var basert på selskapets overordnede mål, kombinert med at hver enkelt personalleder og teamleder ble utfordret på hva de kunne bidra med. Resultatet av denne “top down/bottom-up”-prosessen ble et key result om å ansette 21 personer ila 2019. Ambisjonen var på grensen til å være ubehagelig høy, og betydelig over resultatet for 2018. Det er verdt å merke seg at 2018 hadde vært vårt beste år for rekruttering noensinne. Vi visste rett og slett ikke helt hvordan vi skulle nå det nye målet. Derfor etablerte vi enda et key result som utfordret oss selv til å teste ut minst én ny måte å drive rekruttering på. For eksempel ved å teste ut en ny måte å treffe kandidater på. På denne måten forsøkte vi å sikre et tydelig spor for læring og videreutvikling av rekrutteringsprosessen vår.Ambisjonen trigget forbedringerVårt strekkmål om 21 ansettelser gjorde at måten vi jobbet med rekruttering på måtte forbedres. Vi var nødt til å se nærmere på hele prosessen. På starten av året ble følgende elementer vurdert som sentrale for videreutvikling:Styrke fokus på hva målgruppen er opptatt av. Her dro vi stor nytte av innsikt og læring fra en rekrutteringsundersøkelse gjennomført av et eksternt firma.Bygge videre på #nofilter-profil i annonser og dialog med kandidater. (#nofilter ble hentet fra en presentasjon av Thimon de Jong under rekrutteringskonferansen “The Hunt” 2018.) En #nofilter-strategi innebærer å være åpen om både styrker og svakheter. Vi økte bl. a. fokuset i stillingsannonsene på utfordringer vi har.Skape engasjement om et felles målbilde. Dette var viktig særlig mtp. at de som står for rekrutteringsarbeidet gjør dette som en “deltidsjobb”, ved siden av det man jobber med i utviklingsteamene til vanlig. Vi var helt avhengige av å skape kraft i en distribuert modell for å skalere godt nok.HR som en integrert del av laget. Nøkkelkompetanse innen HR ble inkludert i organisasjonen, mens den tidligere var plassert lenger unna der rekrutteringsarbeidet foregikk.Være mer synlige i miljøet vi rekrutterer fra. Det ble lagt en konkret plan for hvordan vi skulle løfte oss og bygge kjennskapen til miljøet gjennom deling i artikler, presentasjoner mm.Løpende eksperimenter med hvordan vi rekrutterer. Planen la til grunn et løft av kvaliteten i rekrutteringsarbeidet gjennom kontinuerlig forbedring, bl.a. gjennom å sette spesifikke mål om å teste ut nye måter å rekruttere på.Beskjeden start styrket fokusetÅret startet tregt. Januar og februar måned kom og gikk uten at det resulterte i signeringer. Stemningen var imidlertid god. Takket være OKR-rytmen med tavlemøter for løpende fokus på både status og nødvendige tiltak styrket pipeline for kandidater seg jevnt og trutt. I mars ga arbeidet tydelig uttelling ved signeringer med hele fire ansatte. Vi var kommet skikkelig i gang, og modellen skulle etterhvert vise seg å fungere meget bra.Antall signeringer fordelt på måneder i 2019.Det var flere faktorer som bidro til denne utviklingen. Innføringen av fagdag hver torsdag for utviklere ble etterhvert mer kjent utenfor huset. Dette kom som et resultat av presentasjoner og erfaringsdeling på forskjellige eksterne arenaer, blogginnlegg skrevet av oss selv, artikler i media, samt tradisjonell “word of mouth”. Dette bidro til at flere kandidater var nysgjerrige på hvordan det var å jobbe i SpareBank 1 Utvikling. Videre var det nyttig for oss å kombinere spesialistannonser med mer generelle stillillingsannonser. Kombinasjonen gjorde at vi var var til stede i markedet stort sett hele tiden, samtidig som de fleste utviklerprofiler fant noe som passet for seg. Tilsiget av kandidater økte merkbart i perioden. Til tross for den beskjedne starten ble det ambisiøse målet oppnådd allerede i september. Det stoppet heller ikke der. Totalt endte vi opp med hele 29 ansettelser innen utgangen av året.Viktige elementer for at vi lykkesPå slutten av året gjennomførte vi en retrospektiv for å identifisere styrker og svakheter på rekrutteringsarbeidet. Punktene under ble vurdert som tydelige styrker:Den distribuerte modellen gjør at mange kan bidra etter eget ønske og kapasitet.Hvem som holder i generelle prosesser går på rundgang. Dette førte til at ingen ble sittende med ansvaret for en stillingsannonse og prosess over for lang tid.Vårt fokus på faglig utvikling for våre ansatte begynte å bli kjent utenfor huset.OKR-tilnærmingen hjalp oss å sammen sette et mål og å holde fokus over tid. Den skapte en fast rytme for å snakke om status og behov for tiltak på egne tavlemøter.Bruk av en dedikert flyt-tavle som viste status hver enkelt prosess og kandidat.Egen “OKR-shepherd” for rekruttering som hjalp til med at vi aldri mistet fokus på målet.Datadrevet arbeid basert på kundeinnsikt for målgruppene våre.Tilgjengeliggjøring av praktisk informasjon om rekruttering.Eksperimenter med nye måter å rekruttere på førte til at vi lærte mye, og flere elementer som ble testet ut fungerte så godt at de ble videreført.Strukturert jobbing med sommerjobb åpnet opp et nytt segment for oss i utviklermarkedet.Fokuset på hver enkelt kandidats prosess og opplevelse ble styrket ved at HR kom med på laget. Dette skapte bedre flyt og fart i prosessen.OppsummeringRekruttering hos oss er ikke outsourcet til en egen funksjon. Tvert imot er ekspertene på fagområdene, sammen med sentrale personer i de tverrfaglige teamene, i front — på deltid. Dette gjør at kandidater møter de man vil jobbe sammen med, og som er nærmest arbeidet som skal utføres. Kraften i dette og den distribuerte modellen, kombinert med et OKR-målbilde som ble en naturlig del av det vi fulgte med på i det daglige, skapte en sterk rekrutteringsmuskel. Denne var i stand til å favne over et bredt spekter av prosesser og kandidater. Dette gjorde det mulig å lykkes med et viktig mål for organisasjonen, basert på overkommelig deltidsarbeid hos hver enkelt som var involvert.Vi liker utfordringer og har satt et nytt strekkmål på rekruttering for 2020 som er enda et steg opp fra fjoråret. Satsingen innebærer at arbeidet med å videreutvikle hvordan vi jobber med rekruttering fortsetter. For å lykkes med ytterligere skalering blir løpende forbedring med utgangspunkt i kundefokus sentralt for hvordan vi skal klare å tiltrekke oss de flinke folkene.Skrevet av:Kristoffer BergLars KirkhusNår hårete mål for rekruttering gruses på deltid was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Lars Kirkhus

Er du utvikler? Gratulerer med sikkerhetsjobben!

I SpareBank 1 Utvikling legger vi mye innsats i å lage løsninger med riktig sikkerhet innebygd. Noe av det gjøres av oss med “sikkerhet” i stillingstittelen, men den viktige sikkerhetsjobben er det utviklerne som gjør.Av og til er sikkerhet enkelt å se. Det kan være autentisering, kryptering eller validering, eller annen sikkerhetsfunksjonalitet. Det er åpenbart viktig at det virker, men applikasjonssikkerhet er mye mer enn som så. Sikkerhet er summen av hvordan applikasjonen din reagerer når noen med uærlige hensikter pirker borti applikasjonslogikken eller den tekniske stacken. Sikkerhet er en egenskap i applikasjonen, og oppstår eller forsvinner i den daglige utviklingen av helt vanlig kode.Denne er katastrofal. Én ordinær kodelinje, så faller hele korthuset sammen. Ser du hvor?Heldigvis jobber de fleste av oss også mer eller mindre smidig. Et nøkkelkonsept her er at utviklingsteamene har selvstendig ansvar for applikasjonene sine. Det inkluderer sikkerhetsegenskapene, like mye som ytelsen og brukeropplevelsen. Sikkerhetsarbeidet i en utviklingsorganisasjon er selvsagt mer enn å peke på at utviklerne har ansvaret, men man vil aldri lykkes om utviklerne ikke har forutsetningene for selv å oppdage at det kan være fare på ferde i dagens fjerde pull request.Slike endepunkt som spiser JSON har du sikkert tusen av. Payload parses av et rammeverk, og du får et objekt ut. Vakkert. Men er du sikker på hva slags objekter som faktisk blir lagd? Eller at det bare er JSON som godtas?Her har jeg oppdaget at applikasjonen godtar Content-Type satt til YAML! Da kan jeg unytte at rammeverket RESTeasy tillater at man kan lage helt vilkårlige objekter. Her lager jeg et ScriptEngineManager-objekt, som tar inn en URLClassLoader, som laster min javakode fra min server og kjører det på din. Dette er insecure deserialization, som bl.a. Jackson har hatt mye av.Hvordan sørger man for at utviklerne lukter sikkerhetsuglene i kodemosen? At SQL må være parameterisert, eller at serialisering har sine fallgruver? Som mye annet er det øvelse som gjelder, og vi har den tvilsomme fordelen av at vi som bransje gjentar de samme sikkerhetsfeilene om og om igjen. Dermed kan man øve seg på alt som har gått feil før. Her følger noen varianter vi i SpareBank 1 Utvikling har prøvd med stort hell! Først en kort oversikt, så detaljer om hver enkelt, med fordeler og ulemper:Natas: Enkel testing av sårbar appKWASHC: Fiks en rekke sårbarheter i en webappHack yourself first: Strukturert workshopBugbounties: Test andres løsninger på lovlig visOnline trainingTil slutt er det også et avsnitt om nyttige verktøy for sikkerhetstesting.NatasNatas fra Over the wire består av et tredvetalls “capture the flag”-oppgaver (CTF), der man skal utnytte en sårbarhet i oppgaveapplikasjonen for å skaffe seg en nøkkel som man bruker for å få tilgang til neste oppgave.FordelerKrever ikke noe oppsett. Det er bare å starte på oppgave 0 og fortsette derfra.Fungerer godt som gruppearbeid.Dekker svært mange vanlige sårbarhetsklasser, gjerne i flere varianter eller med utilstrekkelige fikser.Går over http og ikke https, så forutsetter ikke at man må sette opp sertifikathåndtering i webproxy (se avsnitt om verktøy).UlemperKommer ikke med noen form for forklaring eller introduksjon til sårbarhetene, så det er nok en del av oppgavene som kan være vanskelige å starte på om man står på bar bakke. Man finner fasit for oppgavene om man søker, men da må man ha litt disiplin for ikke å bare lese hele løsningen.Ikke fokus på hvordan man bør fikse sårbarhetene.Kantega Web Application Security Hero Challenge (KWASHC)KWASHC er i stor grad utviklet av Kantega i Trondheim (si navnet litt fort!). Hovedfokuset er ikke på å finne sårbarhetene, men å fikse dem i koden. Består av en serverkomponent med oppgaver og scoreboard, og en sårbar bloggtjeneste skrevet i Java.Mange røde lys. Her trengs en Security Hero!FordelerFokus på sikker koding, og ikke testing.Forklarer sårbarhetene, så man har et greit grunnlag for å finne løsninger selv om det er nytt stoff.Open source, så du kan tilpasse eller utvide som du vil.Scoreboard gjør det underholdende å kjøre i mild konkurranseform, gjerne mellom grupper.UlemperKrever litt lokalt oppsett.Ikke den aller mest moderne tekniske frontendstacken, med Spring MVC og serverside-rendret jsp. Kanskje du vil modernisere den?Hack yourself firstTroy Hunt, bl.a. kjent for ‘; — have i been pwned?, holder en veldig god applikasjonssikkerhetsworkshop kalt Hack yourself first.https://medium.com/media/27fbf4aad2a99001fe4a10c9369b5cac/hrefSpareBank 1 Utvikling har både leid inn Troy for å holde denne workshopen on-site, og sendt enkeltutviklere på fellesworkshops hos NDC Security. Det er en blanding av undervisning og oppgaver over to dager.Troy har også mye innhold online på Pluralsight, inkludert Hack yourself first i videoform. Det er nok likevel ikke helt det samme som å delta på en workshop.FordelerNøkkelferdig opplegg fra profesjonell kursholder.To fulle dager lar en gå litt i dybden på mange tema. Holder man workshopen internt legger det rette til gode diskusjoner om hvordan man selv bygger løsninger.UlemperKoster en del.BugbountiesI år opprettet vi en applikasjonssikkerhetsgruppe for jobbing sammen på fagdagen. Der har vi blant annet tenkt å jobbe med bugbounties. Bugbounty-program er uorganisert sikkerhetstesting: Firma registrerer løsningene sine hos tilbydere som Bugcrowd eller HackerOne, og så kan hver og en av oss sikkerhetsteste dem fritt innenfor de rammene de spesifiserer. Det er en veldig god øvelse på å få se ting fra angriperens perspektiv. -Hva inneholder denne applikasjonen? Hva slags teknologistack finner vi, og hvordan kan vi prøve å misbruke funksjonalitet eller implementasjon?HackerOne har forøvrig en flott Hacktivity-side, der fulle rapporter på publiserte sårbarheter ligger. Mye fin inspirasjon.FordelerDet blir ikke mer realistisk enn produksjonsløsninger.Man får utforske varierte teknologistacker, og får reflektere litt over likheter og forskjeller, og patterns som legger opp til sårbarheter. Da blir det enklere å gjenkjenne dem i egne systemer.Det er veldig tilfredsstillende når man finner noe!En del av programmene utbetaler penger for funn.UlemperSystemene som er del av slike programmer er typisk ganske modne, og det kan være relativt utfordrende.I motsetning til opplæringsløsninger og CTF’er er man aldri sikker på om det faktisk er en sårbarhet å finne i den delen av løsningen man pirker på.Man må være den første som rapporterer en gitt sårbarhet i en løsning for å bli premiert direkte. Det er likevel tilfredsstillende å finne dem.Programmene krever typisk en form for proof-of-concept-angrep som beviser sårbarheten. Avhengig av sårbarheten kan det være omfattende å lage. Se hacktivity for eksempler.Online trainingFlere leverandører har opplegg for guidet selvopplæring i applikasjonssikkerhet. SpareBank 1 Utvikling har foreløpig ikke valgt å gå for en slik løsning, men det kan være det passer andre utviklingsorganisasjoner bedre. Av de jeg har prøvd selv, virker Adversary som en av de mer komplette. Du kan teste dem selv, med denne gjennomgangen av en feil i autorisasjonskontrollen Facebook hadde i 2018.Portswigger Academy er gratis, og har også noen gode labs det er verdt å ta en kikk på.FordelerLav terskel for å komme i gang.Dekker typisk bredt.UlemperNoe varierende kvalitet og forvirrende plattformer.VerktøySkal man eksperimentere med websikkerhet er det veldig nyttig å bruke en webproxy, som lar en se og endre på trafikken mellom nettleser og server. Noen alternativer:Burp Suite. Industristandarden. Koster litt i full utgave. Verdens eneste fungerende Java Swing-applikasjon!OWASP ZAP. Gratis, open source. Den andre Java Swing-applikasjonen.Charles proxy. Populært på Mac.Fiddler. Populært på Windows.Burp i aksjon. Hva skjer om jeg endrer det som ser ut som en konto-ID, og sender requesten på nytt? Det er enkelt å finne ut med slike verktøy.Heldigvis går de fleste seriøse webløsninger over TLS (https), men det betyr også at webproxyen må terminere TLS-forbindelsen for å klare å lese eller endre på innholdet. For å unngå at nettleseren (med rette) protesterer på sertifikatfeil, forutsetter det at man setter opp nettleseren sin til å stole på CA-sertifikatet som proxyen har generert. De forskjellige proxyleverandørene forklarer hvordan man går fram for å gjøre det, men et konkret tips er å bruke en dedikert nettleser, så slipper man å sende all legitim trafikk gjennom proxyen når man ikke tester. Firefox har sitt eget oppsett av både proxy og sertifikater, mens andre i større grad baserer seg på globale systeminnstillinger.OppsummeringHer var det mye å velge mellom, selv om det ikke er en utfyllende liste. Mange av tilnærmingene utfyller hverandre på en god måte, men hvor skal man begynne? Det kommer mye an på hvor mye man føler man kan, men en mulig rekkefølge å iterere over kan være:Om du kan, dra på Hack yourself first. Den har blitt holdt flere ganger i -Norge, for eksempel på NDC Security i Oslo.Online training om noen tema, enten i de dedikerte løsningene foreslått over, eller på Pluralsight.Når man er klar til å eksperimentere litt selv kan må gå over på NATAS eller KWASHC.Bugbounties er supert når man er klar til å eksperimentere på virkelige systemer!Happy hacking!https://medium.com/media/ccf1ae94a5427c2c844a32ed831b1262/hrefEr du utvikler? Gratulerer med sikkerhetsjobben! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jon Are Rakvåg

Ikke jobb mens jeg forstyrrer!

Våren 2015 var jeg på vei til å bli utbrent.Vi hadde laget ny nettbankplattform som stadig flere av teamene våre tok i bruk. Samtidig var ikke plattformen ferdig. Det var kode vi måtte forbedre, samtidig som nye krav dukket opp.Selv om mye var likt den gamle plattformen, var også mye annerledes. Teamene trengte hjelp til å forstå detaljene. Det gjorde at utviklingsarbeidet stadig ble avbrutt av pirk på skulderen, meldinger, eposter og møter.Kombinasjonen av sterkt leveransepress og hyppige avbrudd var i ferd med å spise oss opp. Hvordan skulle vi klare å levere forbedringer raskt og med høy kvalitet, når vi ble avbrutt hele tiden?Foto: Getty ImagesAvbruddene gjorde at vi følte at vi fikk gjort svært lite. Situasjonen var uholdbar. Samtidig visste vi at flere av avbruddene var verdifulle for systemet som helhet: Hvorfor skulle folk bruke tid på å finne ut av hvordan detaljene fungerte, eller regne ut hva som ville være beste tilnærming til en ny utfordring i den nye arkitekturen, når vi ofte satt med svaret?I SpareBank 1 Utvikling bruker vi ofte A3-metoden når vi har vanskelige problemer vi skal løse. Vi valgte å kjøre en A3 på avbruddsproblemet. Hvordan kunne vi hjelpe de rundt oss, og samtidig gjøre utvikling på en bærekraftig måte?Hvorfor er avbrudd så krevende for utviklere?Dette er et lurespørsmål.Avbrudd er ikke spesielt krevende for utviklere. Avbrudd er spesielt krevende for alle som driver med problemløsning.Alle som jobber med problemløsning bygger mentale modeller av problemdomenet i hodet. Disse modellene har flere abstraksjonsnivåer, som en må ha i hodet samtidig for å klare å resonere rundt problemet, og forhåpentligvis også nærme seg en løsning.https://www.monkeyuser.com/assets/images/2018/79-focus.pngAvbrudd som omhandler andre tema enn akkurat det en jobber med, river ned den mentale modellen. Den må bygges opp igjen, før en kan fortsette med arbeidsoppgaven. Denne kontekstbyttingen er mentalt krevende, og den tar tid. I arbeidet med A3-en, målte vi på de forskjellige typene avbrudd, og lengden på dem. Vi fant forskjellig byttekost for forskjellige typer avbrudd, med i snitt tre minutter for chat, opp til femten minutter for møter.Hvis det i tillegg er systemutvikling en driver med, og en er midt i en debuggingssesjon for å forstå mer av problemdomenet, så kan byttekosten gå vesentlig opp, siden en i tillegg til å bygge opp den mentale modellen igjen, også må få systemet tilbake i tilstanden en var i, som før en ble avbrutt.Alle har en begrenset mengde kognitiv kapasitet, som vi kan bruke av hver dag. Gjennom dagen blir den brukt opp. Avbruddene, og tiden det tar å komme seg tilbake til oppgaven en holdt på med, spiser av denne kapasiteten.Forskjellige typer avbruddVi så at vi trengte håndtere avbruddene forskjellig. Vi har delt dem inn i fire typer:Møter — både egne og andresElektronisk kommunikasjon — chat, epost, SMS osvSelvpåførte konsentrasjonsavbrudd — tankene spinner avgårde, enten på oppgaver en vet en skal gjøre, eller en kommer på nye oppgaver som trengs å gjøresPirk på skulderen og kapring ved kaffeautomaten — “Har du fem minutter?”Ta tilbake kontrollen over tiden dinEn fin dag for en leder. En trist dag for en utvikler.For mange prosjekt- eller teamledere er kalenderen over en drømmedag.For en utvikler er denne dagen ødelagt før den har begynt. Hun vet at med denne kalenderen kommer hun nesten ikke til å få gjort noe som helst:Hun kommer på jobb åtte-halv niSjekker epost, Slack og nye Pull RequesterRekker akkurat starte på utviklingsoppgaven før retroenForbereder seg litt til retroenGjennomfører retroenGjør litt etterarbeid etter retroenRekker kanskje akkurat komme igang igjen med utviklingen før hun skal spise lunsj i elleve-halv tolv tidenKommer tilbake fra lunsj og sjekker epost, Slack og nye Pull RequesterRekker akkurat komme igang igjen med utviklingen før hun må forberede seg litt til workshopenGjennomfører workshopenLitt etterarbeid etter workshopenRekker kanskje fortsette litt på utviklingsoppgaven før hun går hjem i fire-halv fem tidenMer sannsynlig er hun såpass sliten etter totimers workshop, at det heller blir en ekstra kaffekopp og en ny sjekk av epost og Slack før hun går hjem igjen, frustrert over nesten ikke å ha produsert noen ting på en hel dag.Paul Graham har skrevet en fantastisk artikkel om disse utfordringene. Den heter Maker’s Schedule, Manager’s Schedule.Slik kunne vi ikke ha det.Løsningen for oss ble å innføre en fast blokk i kalenderen hver dag:Fast blokk i kalenderen hver dag for å kunne jobbe effektivtVi kan nå bare kalles inn til møter fra 13 og utover. Med denne blokken i kalenderen har vi fått tilbake kontrollen over vår egen tid. Folk kan velge å kalle oss inn til møter også mellom åtte og 13, men da er det vi som bestemmer om vi skal prioritere møtet eller ikke. Er det et viktig møte, ber vi som oftest om at møtet flyttes til etter 13.Når på dagen bør en ha møter?Vi har valgt å blokke ut første del av dagen, fordi det er da vi er mest opplagt og jobber best. Det er da det er viktigst å ha sammenhengende tid til å drive med utvikling for oss. Noen jobber best på kveld og natt, men for oss er det de første timene av arbeidsdagen som gjelder.Møter som krever høy grad av interaksjon og meddeltakelse bør legges så tidlig på ettermiddagen som mulig. Møter som er av typen informasjonsmøter, for eksempel allmøter og demoer, kan gjerne legges mot slutten av dagen.Hvordan vi har håndtert de andre avbruddstypene går vi nærmere inn på i del to av denne bloggposten.Takk til Børge Lund for hans humoristiske betraktninger rundt dette temaet, og for tittelen til denne artikkelen.Ikke jobb mens jeg forstyrrer! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Vaner, uvaner og abonnement

Hvor mange har ikke inngått et abonnement, bare for innse at det etter kort tid gir deg dårlig økonomi og samvittighet? Selv den mest viljesterke har vel inngått et treningsabonnement i januar for så å bli et passivt støttemedlem, som sørger for at de få som holder ut gjennom året, opplever blanke speil, skinnende vekter og dundrende musikk. Dette er historien om hvordan vi i SpareBank 1 bruker maskinlæring for å hjelpe kundene våre til å få oversikt over abonnementene sine.Men la oss starte fra begynnelsen. I SpareBank 1 bruker vi maskinlæring for å klassifisere banktransaksjoner. Vi ser på om du f.eks har vært i matbutikken, eller om du har vært på kafé. Tanken er at du med et filter kan få oversikt over hvor mye du bruker på f.eks mat i måneden, eller hvor mye du bruker på moro og fjas. Det vi derimot manglet, var et filter for faste utgifter og abonnement. Mange kunder har større nytte av å kunne kategorisere hva som er faste utgifter og ikke, eller rett og slett få oversikt over hvilke abonnement en har. I tillegg inngikk vi en avtale med en tredjepartsleverandør om abonnementshåndtering. Denne tredjeparten tilbyr kansellering av abonnement og endring av abonnement (f.eks endring til et billigere mobilabonnement med de samme vilkårene).Som så mange andre modeller, fikk vår første modell en høy bias (partiskhet). Den fungerte veldig godt for de som lagde modellen. Kort fortalt ble det en regex lignende modell som sa at Netflix-, HBO- og Spotify-transaksjonene dine er abonnement. Vi fikk forsåvidt gode tilbakemeldinger fra våre kolleger da de også stort sett kun har en eller flere av disse 3. Alt så rosenrødt ut og vi kunne sole oss i glansen og flotte oss med vanskelige maskinlæringutrykk for å fremheve vår egen fortreffelighet.Alle elsker NetflixHvor mange forskjellige abonnement tror du kundene til SpareBank 1 har? Jeg kan gi deg et hint: vi har rundt en million kunder. Og jeg skal gi deg enda et hint: svaret er større enn 3. For det viste seg ganske fort at det finnes mange abonnement. Mange, mange abonnement…Det var bare en ting å gjøre, brette opp ermene.For å forstå løsningen må man skjønne problemet. Klientene våre sitter på transaksjoner som spenner over flere måneder og år. Transaksjonene har begrenset informasjon, men vi valgte å benytte oss av dato, beløp, transaksjonskode (unik kode som spesifiserer hva slags type transaksjon det er) og transaksjonstekst.Eksempel på transaksjonMaskinlæringsalgoritmene trenger tall for å fungere, så det første steget er vektorisering. Som så mange andre bruker vi Pandas for å lese og manipulere store datasett.DatoDet første vi gjør, er å endre dato til dag i måneden (i eksemplet blir 22.12.2019 til 22) for så å bruke sci-kit learns StandardScaler på den. Rammeverket beregner gjennomsnittet og variansen for oss, basert på hele treningsdatasettet. Da kan vi senere (når vi skal beregne nye abonnement) vektorisere ved å bruke ligningen under.Standardscalerens ligningBeløpDen neste featuren (egenskapen) er beløp, som vi bruker sci-kit learns RobustScaler på. Grunnen er at vi har noen veldig store beløp som gjør at denne fungerer bedre enn Standardscaleren.Men hvorfor gjør vi om tall til tall, jeg sa jo nettopp at maskinlæringsalgoritmene trenger tall for å fungere? Forklaringen ligger i at tallene bør være i noenlunde samme størrelsesorden og at de bør ligge over og under 0 for å fungere optimalt. Tenk på dag i måneden. Her har vi: Min(dag_i_mnd) = 1 og Max(dag_i_mnd) = 31.Hva med beløpet? Siden vi har alt fra lønnstransaksjoner og boligsalg til store innkjøp kan Min(beløp)=mange hundre tusen i minus og Max(beløp)=mange hundre tusen i pluss. Dag i måneden og beløp er altså på helt forskjellige skalaer når det gjelder nominelle tall. Ved å normalisere de, får vi begge featurene rundt null og på samme skala.TranskasjonskodeTransaksjonskodene er av type kategori (categorical features) og bør one-hot-encodes. I praksis har vi noen hundre transaksjonstyper i bruk og hver transaksjon vektoriseres da til ca. 200 dimensjoner, der 1 dimensjon har lengde 1 og de øvrige har lengde 0.La meg forklare med et litt enklere eksempel. La oss si at vi har 3 transaksjonskoder (i stedet for 200): R_013 (Lønn), R_714 (Visakjøp) og R_718 (Minibank). En transaksjon har en av disse 3, men aldri flere. “Vanlig” normalisering gir ingen mening her. R_718 er på ingen måte “større enn” R_714, på samme måte som at R_710 ikke er “mindre enn” R_714. Det er bare forskjellige transaksjonskoder som er tilfeldig nummerert og som har forskjellig mening.Eksempel på one-hot-encodingTransaksjonstekstTransaksjonsteksten er den siste og kanskje vanskeligste. Det finnes mange måter å represente tekst på, men vi har valgt å gå for word embeddinger ved bruk av fastText. fastText er et rammeverk fra Facebook som gir oss 100-dimensjonale word embeddings. Hvert unike ord er altså representert ved 100 floats og vi vektoriserer opp til 7 ord per transaksjonstekst. Dette kan virke merkelig, men disse embeddingene har visse egenskaper som vi benytter oss av. Syntaktisk og semantisk like ord vil f.eks ligge nære hverandre i vektorrommet. Vi benytter transfer learning når vi trener våre egne word embeddinger (vi baserer oss på pre-trente embeddinger fra Language Technology Group).Til sammen gir dette oss en 902 dimensjonal feature vector:Når disse featurene er vektorisert, clustrer vi de ved hjelp av dbscan. dbscan er en unsupervised clustringsalgoritme som er flink til å finne clustre med lik tetthet og tilfeldig form. Det viktigste argumentet til dbscan er epsilon og min_samples. min_samples bestemmer hvor mange punkter som minst må være innenfor epsilon avstand fra hverandre for å kalles kjerneelementer. Oppfyller man dette kriteriet har man et cluster. Når man har dette minimumet av kjerneelementer, kan man se på grenseelementer som må være innenfor epsilon avstand fra minst et kjernepunkt. Disse vil også bli medlemmer av clusteret. Vi hadde størst suksess med en epsilon rundt 0.3 og min_samples ≥ 3 når vi skulle finne de faste utgiftene. Altså, minst 3 punkter som er innenfor 0.3 avstand fra hverandre + et tilfeldig antall grenseelementer som er innenfor 0.3 avstand fra minst et av disse kjernepunktene.1,2 og 3 er mindre enn epsilon avstand fra hverandre og er derfor kjerneelementer. 4 er kun mindre enn epsilon avstand fra 2 og kalles da et grenseelement. 5 er mer enn epsilon avstand fra alle og kalles støy.Et par observasjoner (hopp over disse hvis du synes dette avsnittet var vanskelig).Vi benytter euclidian distance i clustringen. Det finnes flere måter å måle avstand på (se scipy spatial distance), men det viste seg at euclidian distance ga best resultat. Med word embeddings benytter vi oss ofte av cosine similarity, for å finne likheter mellom ord. Hvordan passer dette inn med euclidian clustring? Løsningen ligger blant annet i det som kalles monotonic transformations. Når cosine similarity øker, minsker euclidian distance (når unit vector length er lik), altså akkurat det vi ønsker. Den komplette forklaringen er mer kompleks og krever en egen bloggpost.Et annet punkt er at dag i måneden gir månedlige abonnement. Vi har også kvartalsvise, halvårs og årsabonnement, løst ved å lage en ekstra feature basert på modulusfunksjoner.Du kan også oppleve noen problemer ved å bruke dag i måneden i månedslutten hvis du får helg/helligdag på en sen dato.Den siste utfordringen er at du vil ha markert Netflix abonnementet ditt allerede den første måneden du får opp transaksjonen, ikke vente til du har 3 Netflix transaksjoner. Hvordan dette ble løst ligger utenfor scopet til denne bloggen, men ta gjerne kontakt så deler vi gjerne.ResultaterHer er et typisk mobilabonnement. Kunden har variable summer (brukt mer mobildata f.eks) og variable datoer (lørdag-/søndag-/helligdag-problematikk, bankene prosesserer ikke betalingen til abonnementet før første bankdag). Ved å ha en passe epsilon under clustringen vil disse variasjonene være små nok til å bli naboer i det 902 dimensjonale vektorrommet.Et annet problem vi hadde med vår første regex versjon, er de firmaene som både har abonnement og selger enkeltprodukter. Et eksempel er Viaplay, en strømmetjeneste som har både abonnement og muligheten for å leie enkeltfilmer. I dette tilfellet markerer clustringen kun de som faktisk er abonnementer (markert som grønne).Ikke alle abonnement kan finnes med regex’er. Mange bedrifter bruker kundenummer og faktureringsnummer som transaksjonstekst.Noen bedrifter endrer transaksjonsteksten fra måned til måned.Noen ganger er navneendringene store. Hvordan er det mulig for algoritmen å skjønne at CanalDigital plutselig heter Telenor? I vanlig språk er god, bra og fantastisk semantisk like ord. På samme måte viser våre word embeddinger at CanalDigital er det ordet som er mest likt Telenor.Disse eksemplene er noen få eksempler på hvordan algoritmen fungerer. De viser dog ikke det store volumet vi fant. Hos kundene våre finner vi hundrevis, om ikke tusenvis av abonnement. Det er alt fra aviser og treningssentre til datingtjenester og japanske tegneserier. Det er norske, amerikanske, polske og rumenske abonnement. Abonnement som du nå kan filtrere og håndtere i SpareBank 1 sin mobilbank.Vaner, uvaner og abonnement was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Inge Johnsen

“Ikke nok et jævla statusmøte!”

Vi ville for mye, og fant oss selv i det ene statusmøtet etter det andre. Backloggen økte for hver eneste dag, men målene var like langt unna. Vi måtte endre måten vi jobbet på — og det fort!Seks måneder tidligere: Team Oversikt — et av utviklingsteamene som lager mobilbanken til SpareBank 1 hadde såvidt begynt å jobbe med OKR’er, og alle var begeistret over å endre fokus fra oppgaver til mål. Ved inngangen av kvartalet hadde vi samlet hele teamet, og hamret ut våre “objectives”. Vi satte noen få, ambisiøse “key results”, som føltes akkurat passe komfortable å sikte mot. Alt etter boken. Vi oppdaterte Trello, syncet med Jira og Slack, kalte inn til regelmessige backlogmøter, teammøter og stand ups.Noe gikk galt på veien…Kvartalet var over, alle hadde gjort sitt beste. Vi hadde riktignok nådd et par av målene, men vi var milevis fra andre. Noen hadde vi ikke jobbet med i det hele tatt. Vi klarte ikke å holde fokus gjennom kvartalet, og teamet var lei av hyppige koordineringsmøter. Det var ingen tvil om at OKRer var riktig for oss, men vi måtte finne en mer effektiv måte å jobbe med de på.Monday commitments and friday winsInspirasjon fant vi hos den amerikanske forfatteren Christina Wodtke. I boken ‘Radical Focus” beskriver hun en elegant og enkel måte å sikre fokus på de riktige tingene, samtidig som man tar vare på kvaliteten, teamet og kunden. Essensen er at det du gjør hver dag, må ha en direkte kobling til de målene du har satt deg. Det så ut til å være akkurat hva vi trengte.Bilde: OKR eksempel fra Radical FocusVi skisset opp den nye tavla,og erstattet møtene våre med monday commitments, og friday wins:Monday commitments kickstarter uken. Hele teamet er samlet foran tavla. “Hvordan ligger vi an i forhold til målene vi har satt oss” og “hva må vi ha fokus på denne uken for å nå målet?” Vi blir enige om de viktigste oppgavene og det er kun de som havner på tavla. Dette er de oppgavene vi forplikter oss til i felleskap, og som vi strekker oss for å levere innen fredag. Vi har satt av 15 minutter til møtet.Fridays wins er for vinnere, og handler om å feire hva vi har fått til og dele hva vi har lært. Vi setter av minst 30 min i kalenderen, og setter oss i kaffekroken. Helst har noen på teamet bakt eller kjøpt med noe godt å spise. Resultatet er alltid stolthet over det vi har fått til sammen. Og her skal alt frem — det er mye som fortjener oppmerksomhet, uten at det nødvendigvis har flyttet nøkkeltall.“You don’t have to do it perfectly, but you do have to commit!”- Christina WodtkeMandag 6 uker senereDet er stort engasjement fra hele teamet. Tallene fra forrige uke er kommet opp på tavla, og alle har ideer til hvordan vi skal komme enda nærmere målet. Nye kamper skal kjempes — og vinnes. Vi gjør en team-helsesjekk, og scorer 4,7 av 5 på spørsmål om det er tydelig for alle hvilke mål de jobber mot.Ved å endre måten vi jobber på har vi fått en sterkere kobling mellom de aktivitetene vi gjør hver dag og målene vi har satt oss. Radikalt fokus gir energi til teamet og bygger kultur og samhold. Og de jævla statusmøtene? De er ikke lenger en kilde til frustrasjon, men noe som gir teamet økt fokus og energi. Og når vi lykkes, feirer vi alle seire sammen!Skrevet av:Marthe SlaatsveenThomas Allan NygaardReferanser:Christina Wodtke (2015) Radical Focus. Cucina Media, LLCJohn Doerr (2018) Measure what matters. PortfolioLes mer…om hvordan egen fagdag radikalt forbedret tilfredsheten i organisasjonenhttps://medium.com/sparebank1-digital/torsdag-er-den-nye-l%C3%B8rdagen-f547e55aadd3og Endelig et statusmøte vi utviklere liker“Ikke nok et jævla statusmøte!” was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Thomas Allan Nygaard

Velkommen til Bankbokklubben

En hel klokketime dedikert til et spennende tema, med ivrig diskusjon blant vennlige og motiverte folk på søken etter innsikt og læring, i kombinasjon med en god kopp kaffe. Kan man egentlig starte dagen på en bedre måte?Hver onsdag morgen møtes Bankbokklubben i SpareBank 1 Utvikling på en kafe i nærheten av kontoret for å prate om det siste kapittelet i en bok vi leser sammen. Hvorfor gjør vi dette?Formålet med klubben er læring med en felles rytme gjennom fordypning i utvalgte bøker innen vårt interessefelt. Fremgangsmåten følger gjerne et slikt mønster:Gruppen blir enige om valg av ny bok. Kandidatlisten inneholder som regel en rekke godbiter, og det smerter å måtte velge bort de fleste.En avtalt del av boken leses på egenhånd, f. eks. et kapittel eller to.På det ukentlige klubbmøtet diskuteres hovedpunktene i kapittelet. Hva betyr dette for oss i SpareBank 1 Utvikling, og hvordan kan vi teste ut elementer vi har lyst til å undersøke nærmere?Rett som det er gjennomfører vi små eksperimenter og diskutere betydningen av funnene.Bankbokklubben i SpareBank 1 Utvikling tar en pause i diskusjonen av hva boken Deep Work byr på av innsikt, muligheter og utfordringer.Hvorfor fungerer dette for oss?Vi jobber med utrolig mange flinke folk, og det er interessant og nyttig med bredden i perspektiv dette skaper.Man kommer dypere i materialet gjennom diskusjon og repetisjon.Innsatsen som legges ned gjøres overkommelig ved å dele opp en bok i mindre bolker.Det blir enklere å lese ved en positiv forpliktelse i det å møtes for å jobbe videre med materialet sammen.Man kommer i kontakt med interessante temaer og tilegner seg innsikt man trolig ellers ikke ville oppnådd på egenhånd.Vi pleier en felles interesse i det å fordype seg i fag og læring innen vårt fagområde.Det er hyggelig å være sammen. Vi styrker samholdet i gruppa og lærer hverandre å kjenne enda bedre. Dette skjer på tvers av grupperingene vi jobber mest i.Med mange sterke kandidater er nåløyet trangt for å bli valgt som felles bok i Bankbokklubben.Bankbokklubbens opprinnelse kan spores tilbake til da det interne utviklingsmiljøet i selskapet ble etablert. I løpet av denne perioden ble en lesesirkel benyttet for å gå gjennom og jobbe med innholdet i boken The Toyota Way. Hver enkelt leste først et kapittel for seg, som så ble diskutert i gruppen med fokus på hva innholdet betydde for miljøet vårt. Dette skapte en felles plattform, og ga mye energi, til arbeidet med hvordan arbeidsprosesser og -miljø ble etablert og videreutviklet. Da siste kapittel var avsluttet, og boken lagt til side, var det flere oss som kjente på den samme følelsen. Den positive dynamikken fra lesesirkelen ville vi svært gjerne beholde. Dermed gikk det ikke lang tid før Bankbokklubben var etablert.Her er et utvalgt av våre favorittbøker:Culture codeThis is LeanLoonshotsAccelerateGood to GreatLean EnterpriseThe Phoenix ProjectFor tiden leser klubben boken Deep Work og diskuterer ting som: Hva er et godt mønster for bruk av tiden vår, for hver enkelt og for gruppene man er del av? Hva er gode strategier for å oppnå en slik tilstand for kunnskapsarbeidere? Hvordan bør vi måle bruk av egen tid, og hvilke eksperimenter kan vi enkelt gjennomføre for å etablere data og innsikt?Plutselig er en time over. Tiden formelig fløy avgårde, og vi er klare for å gyve løs på resten av dagen. Vel vitende om at nok et spennende kapittel venter for Bankbokklubbens medlemmer i uken som kommer.Velkommen til Bankbokklubben was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristoffer Berg

Utvikleravdelingen er død! Lenge leve utvikleravdelingen!

Vi har vært på reisen med kryssfunksjonelle team hver dag siden 2014. Vi jobber så svetten siler med å gi teamene våre best mulig forutsetninger for å løse oppgavene sine.Plutselig en dag oppdaget vi at vi hadde kastet ut babyen med badevannet. Vi hadde optimalisert vekk utviklerkulturen vår.Hva var det egentlig som hadde skjedd?Foto fra BigStockBakteppetVi kan takke Frederick Taylor (1856–1915) for mye. Han populariserte standardisering av arbeidsmetoder. Dette gav oss massiv økning i produksjonsvolum for fabrikker over hele verden. Med på lasset fikk vi også med oss ledelsesprinsipper for å maksimalisere effektiviteten:Finn beste måte å gjøre en oppgave påDokumenter beste måte å gjøre oppgaven påTren opp medarbeiderne til å gjøre oppgavene på beste måteLedere og medarbeidere deler ansvaret for løsning av oppgavene. Lederne skal løse oppgavene de er bedre egnet til, heller enn medarbeiderneEn av utfordringene med disse, er at de har større fokus på å optimalisere enkeltroller heller enn systemet. I tillegg er ledelsesprinsippene er ofte blitt mistolket, eller brukt i feil kontekst. Mange mistolker dem fortsatt, over hundre år etterpå:en bruker rammeverket på arbeidsoppgaver det aldri var ment for å løseen ser bort i fra de kontinuerlige treningsaspektet, dvs. dropper kontinuerlig forbedringTa dette og bland det med tradisjonell avdelingsorganisering i underavdelinger som hver for seg er optimalisert for å være så effektive som mulig, dvs at alle i avdelingen til en hver tid jobber opp mot 100 prosent kapasitet, så har vi en standard bedrift. Deler av utfordringene med tradisjonell avdelingsorganisering har vi også erfart i SpareBank 1 IT.Avdelingsdrevet utviklingVi hadde konseptavdeling, arkitektavdeling, prosjektavdeling, forvaltningsavdeling og driftsavdeling. Nye løsninger ble tatt fram i midlertidige prosjektteam, hvor utviklere var leid inn kun med tanke på å utvikle den ene løsningen. Arkitekter støttet opp om prosjektteamet. Arkitektenes utfordring var mange. De var gjerne booket opp i flere prosjekter samtidig , de var få, og de var fullt ut prosjektfinanisert. Dermed fikk de sjelden mulighet til å dykke dypt ned i utviklingen — de måtte løpe til neste prosjekt.Avdelinger med forskjellige mål — et system optimalisert for konfliktNår løsningen var ferdig kodet og testet, ble den overlevert til forvaltningsteamet. Dette tok gjerne flere uker, siden koden sjelden var i henhold til standard, og måtte rettes og retestes før handoveren ble godkjent.Denne måten å jobbe på førte til lav tillit mellom avdelingene, og fremmedgjøring for de som jobbet i dem med de aktuelle løsningene.Mikrotjenestene gav oss teamSom så mange andre, hadde også vi en stor monolitt som alle de nye løsningene ble merget inn i. Vi fikk større og større utfordringer med å levere i monolitten, og dette medførte at vi startet et arkitekturprosjekt i 2012 for å bryte den opp i flere mindre tjenester — la oss kalle dem mikrotjenester. Da vi gjorde dette, bestemte vi oss for å bruke verdikjedeinngangen for å finne fornuftige deler å dele monolitten opp i. Da ble det også naturlig å lage team rundt verdikjedene. Dette var starten på de kryssfunksjonelle teamene våre. Med stabile team organisert rundt verdikjedene, fant vi svar på mange av utfordringene vi hadde hatt med den avdelingsdrevne utviklingen.Egne utviklereVi hadde hatt 100 prosent konsulentdrevet utvikling fram til 2012. Vi startet reisen med egne utviklere omtrent samtidig som vi startet reisen med microtjenester. I starten var vi totalt omtrent 50 personer som jobbet sammen i et fåtall team og omtrent ti av oss var ansatte utviklere og testere. Vi jobbet sammen, og hadde hyppige avdelingsmøter sammen.Entusiasmen var høy. I tillegg til å få en mer moderne arkitektur, hadde vi skapt oss et rammeverk som gjorde at vi kunne skalere opp til å støtte flere verdikjeder — og dermed også flere team. Det gjorde vi. I 2017 var vi blitt 15 team.Samtidig hadde vi ikke evnet å rekruttere egne utviklere i et like høyt tempo. i 2017 var vi gått fra omtrent 10 til omtrent 25 fast ansatte utviklere. Brorparten av skaleringen var gjort med konsulenter.OppsigelserI løpet av seks måneder vinteren 2017–2018 sa seks av utviklerne våre opp.Hva var det som hadde skjedd?Det viste seg at vi hadde jobbet så mye med å skape optimale arbeidsforhold for de kryssfunksjonelle teamene våre, at vi hadde kastet ut babyen med badevannet.I reisen fra et fåtall til da 15 team, ble utviklerne våre spredd tynnere og tynnere utover teamene. Med 25 utviklere på 15 team, så vil de fleste utviklerne enten være ensom som fast ansatt utvikler på teamet sitt, eller i beste fall har en utviklerkollega til i teamet. Den gangen vi var 10 stykker og et fåtall team, så vi hverandre og delte kaffemaskin hver dag. I 2017 var vi blitt 15 team spredd over tre etasjer. Vi traff ikke hverandre lenger. Utviklerkulturen vår var blitt anonym. Tilhørigheten var borte.Utviklerne går sammenOppsigelsene gav oss en skikkelig vekker. Sluttsamtalene var entydige. De som sluttet, følte liten tilhørighet til SpareBank 1 og var ikke fornøyd med den faglige utviklingen sin.Sommeren og høsten 2018 la vi opp til en rekke grep for å snu dette helt om. Vi ville skape et skikkelig bra fagmiljø med mye sosial trygghet og mye humør. Et sted det er godt å være.Vi gjorde to fundamentale grep:Vi satte opp utviklerne som en egen fagavdeling. Vi hadde tidligere vært organisert sammen med flere andre disiplinerVi innførte ukentlig fagdag. Du kan lese mer om fagdagen vår herFagavdelinger + kryssfunksjonelle team = santFor å bygge sosial trygghet og sosial tilhørighet i en hverdag hvor en jobber i kryssfunksjonelle team, er fagavdelingene våre blitt viktigere enn noen gang. I fagavdelingen har vi et fast møtepunkt. Der bygger vi kulturen vår, jobber sammen og blir bedre utviklere sammen. Vi mener dette er så viktig at vi bruker en hel dag hver uke på dette. Dette gir oss muligheten til å jobbe sammen på arkitekturutfordringer, ta kurs sammen, jobbe aktivt med blogg- og konferanseinnlegg, og jobbe med personal, rekrutterings- og brandingsaktiviteter. Ved å være sammen og jobbe sammen med disse aktivitetene, skaper vi også sosial tilhørighet og trygghet. Vi skaper utviklerkulturen vår.Fra standen vår på JavaZone.Faggruppene våreI tillegg til det strategiske kompetansearbeidet som foregår i fagavdelingene, gjør vi taktisk og operativt kompetansearbeid i faggruppene våre. Her er også konsulentene med, og de går gjerne på tvers av fagavdelinger. Vi har faggrupper for en rekke fagområder. Eksempler er teamledelse, applikasjonsarkitektur og sikkerhet.Shift left holder ikkeShift left er en trend som peker på at en skal flytte en rekke aktiviteter som tidligere typisk dukket opp sent i utviklingsprosessen, for eksempel test og sikkerhetsarbeid, tidligere i prosessen. Vi mener at dette på langt nær er nok for å skape en effektiv utviklingsprosess.Du skal ikke bare “shift left” — du skal “rotate left”. Du skal bevege deg fra en horisonal avdelingsstruktur med handovers og ressursoptimalisering, til en vertikal verdikjedeorientert struktur, med kryssfunksjonelle team som jobber flytoptimalisert.Vi må dyrke kulturen og den faglige tilhørigheten. Dette gjør vi i fagavdelingene og faggruppene våre. Samtidig er det i verdikjedene forretningsverdiene skapes. Da er de vi må optimalisere, og i de vi må jobbe.Synes du dette var interessant, så pratet Jostein Emmerhoff og jeg mye mer om dette teamet på JavaZone 2019. Foredraget finner du her.Utvikleravdelingen er død! Lenge leve utvikleravdelingen! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

SpareBank 1 Utvikling på Instagram @sparebank1design / @sparebank1utvikler