SpareBank 1 Utvikling

Et spennende sted å jobbe

Vi er de 14 SpareBank 1-bankenes felles utviklingsselskap. Vår oppgave er å skape de aller beste løsningene og brukeropplevelsene i bransjen – fordi hverdagsøkonomien er viktig for folk. Vi lykkes ved å la kompetanse, læring og frihet definere oss, og fordi vi jobber kompromissløst data- og kundedrevet.

Ledige stillinger - vil du være med på laget?

Et godt sted å være

For å kunne yte på jobb, må vi trives på jobb. Våre medarbeidere får derfor stor tillit og mye ansvar, men også den støtten, veiledningen og opplæringen de trenger for å mestre og like jobben sin. Dessuten passer vi på å le sammen. Mye. Det blir nemlig veldig gode løsninger av god stemning.

@sparebank1-digital på Medium

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

Monorepo med Git och Maven: så fick vi det till!

I SpareBank1 Utvikling har vi tagit i bruk ett monorepo för vår nya generation med appar i digitalbanken. Vi har utgått från verktyg som vi känner gott från tidigare: Git, Maven och Jenkins. Detta är verktyg som i stor grad är mer tillpassade får multirepo än monorepo.Vi har tagit fram ett exempel-githubrepo som visar hur vi har arbetat runt många av de utfordringarna som kommer särskilt från bruk av Maven och Jenkins. Repot visar också hur Bazel-byggsystemet kan användas som ett mer monorepo-native alternativ till Maven.Mer om monorepo kommer på JavaZone 2019: Monorepo med Git og Maven — hvordan lære gamle hunder ny triks, 11 september kl 13:00 i rum 2.Bild av StartupStockPhotos från PixabayMonorepo med Git och Maven: så fick vi det till! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jonas Nordstrand

Torsdag er den nye lørdagen

For en utvikler i SpareBank 1 Utvikling er hver torsdag dedikert til fag. Vi kaller det enkelt og greit Fagdag. Denne dagen brukes til å ta kurs, teste ut nye teknologier, lage helt nye løsninger eller gjøre forbedringer på felles kode.Vi ønsker å dele det vi jobber med. Derfor bruker vi også Fagdagen til å lage artikler som denne, og til å forberede foredrag.Som utvikler i SpareBank 1 er du medlem av et kryssfunksjonelt team. Organisatorisk og faglig er du en del av Utvikleravdelingen. Utviklere, testere og designere jobber sammen i de tverrfaglige teamene, men hver torsdag forlater utviklerne teamet sitt. Denne dagen finner utviklerne sammen for å jobbe med fag. Vi forsøker på denne må å skape en felles utviklerkultur i SpareBank 1 Utvikling.Utvikling kan være så mangt! Her presenteres Hjernebank 1Kultur spiser strategi til frokostPeter Drucker skal ha sagt at “Culture eats strategy for breakfast”. Kort fortalt mente Drucker at kultur alltid vil vinne over struktur. Vi trenger struktur, men kulturen må underbygge strukturen. På QCon i mars var jeg på et foredrag med Randy Shoup. Han påstår at “Kultur spiser strategi og organisering og teknologi og prosess og … til frokost”.Vi tror på en kultur der deling, åpenhet og psykologisk trygghet er fundamentene. Med basis i denne kulturen bygger vi en organisasjon som støtter opp under disse verdiene. Når vi møtes hver torsdag er vi med på bygge denne kulturen. Vi deler kunnskap . Vi lærer og feiler sammen. Vi sosialiserer og vi blir bedre kjent. På denne måten blir vi tryggere på hverandre. Dette gjør det igjen enklere å kommunisere på tvers av teamene. Vi tror også at en god kultur gjør at våre dyktige utviklere ønsker å fortsette å være en del av SpareBank 1 over tid. Fakta er at siden vi startet med fagdagen har ingen utviklere avsluttet hos oss. Samtidig har vi blitt 13 nye utviklere i avdelingen.FlerkulturNår man har en kultur i teamet og en kultur i fagavdelingen, får man flerkulturelle utviklere. Om avstanden mellom “team-kultur” og “fag-kultur” er for stor, vil det kunne skape utfordringer. Resultatet kan bli at man ikke kjenner seg hjemme i fagavdelingen. Utvikleravdelingen i SpareBank 1 Utvikling er en ny avdeling. Når vi nå lager en felles kultur for denne avdelingen, må alle få være med å lage den. Fagdagen er en bra arena for dette. Vi har etablert to arbeidsgrupper. Den ene gruppen fokuserer på sosiale tiltak, mens den andre fokuserer på faglige tiltak. Dette har resultert i felles utflukter, middager og kodekata.Sterke fagmiljø kan også være en utfordring. I en matriseorganiasjon kan det bli konflikt mellom teamene og fagavdelingene. Teamene er tett på kunden og har fokus på levere løsninger på en effektiv måte. For at et team skal bli effektivt jobbes det hele tiden teamkulturen. Stabilitet er et viktig element for effektive team. Endrer man sammensettning av personer i et team viser forskning at det tar tid å bygge effektiviteten opp igjen. Mye av grunnen er at endringer av denne typen påvirker den psykologiske tryggheten i teamet. Denne tryggheten er ikke bare nødvendig for å være effektiv, men også for innvoasjon (Edmondson, 2008). På bakgrunn av dette er det derfor veldig viktig at teamene er tett innvolvert når fagavdelingen ansetter nye utviklere. Teamtilhørighet bør være avklart før ansettelsesprosessen starter og en representant fra teamet bør være med på intervjuene. På denne måten tror vi at vi skal klare å ansette utviklere som passer kulturen i både teamet og fagavdelingen.Snakk om kollegaFor å bli enda bedre kjent, har vi hver torsdag en quiz som vi kaller for Snakk om kollega. Alle har delt noen hemmeligheter med vår quiz master Jan Erik Modal. På bakgrunn av hemmelighetens vanskelighetsgrad får man poeng for riktig svar, og ikke minst minuspoeng om man svarer feil. Dette er en artig måte å bli kjent på og et fint avbrudd fra fagfokuset.Utviklerne gir tilbakeFor en leder er det ingen enkel avgjørelse å la utviklerne bruke 20% av sin tid utenfor teamet. Det er derfor viktig å vise resten av organisasjonen hva man gir tilbake. Vi har valgt å forløpende publisere alle aktiviteter som kommer fellesskapet til gode på en delt liste.Hva fagdagen brukes tilMålingFra første fagdag 13. desember i fjor, har vi målt tilfredshet med det sosiale og det faglige blant oss utviklere i SpareBank 1. Vi har brukt en skala fra 1 til 5, hvor 1 betyr svært lite tilfreds, og 5 betyr veldig tilfreds. Like før sommeren var det eksamen. Den ble gjennomført anonymt. Etter ett halvår med fagdag ønsket å måle hvor godt vi nå kjenner hverandre. Resultatet ble et gjennomsnitt på underkant av 80% riktige. Vi har dessverre ingen historiske resultater å måle mot. Vi vet derfor ikke om dette er et bra resultat, men magefølelsen tilsier at 80% riktige er bra.Utviklingen på bare 5 måneder har vært formidabel. Vi startet med en lite tilfredstillende måling i desember med en gjennomsnitlig tilferdshet på 2.41 for det sosiale, og 2.91 for det faglige. Utover vinteren og våren har gjennomsnittet beveget seg opp på 3 tallet, både for det faglige og det sosiale. Vår siste måling, utført 16. mai, ga oss 4.16 for det sosiale. En økning på hele 79%! Den faglige tilfredsheten ble målt til 4.37. En økning på imponerende 44%.Dette er tall vi er utrolig fornøyde med. Spesielt glad er vi for den høye scoren på det sosiale. Fagdagen må ta mye av æren for dette. Men også aktiviteter som vennegrupper og fagsamling med overnatting har hatt en innvirkning. Vennegruppene er en ren kopi av barneskolens opplegg, men i stedet for å hoppe på en trampoline sammen, så spiller vi dart eller spiser god mat.Veien videreFagdagen var er et halvårlig eksperiment. Det er nå besluttet at dette er en fast aktivitet, og at vi skal bruke en dag i uken på fag. Det faktum at vi ikke har noen turnover og at vi i år skal ha fire bidrag på JavaZone, har vært med på å gjøre det enklere å ta denne avgjørelsen.Synes du dette var interessant, så pratet jeg mye mer om dette teamet på JavaZone 2019. Foredraget finner du her.Anbefalt litteraturJeg elsker å lese om kultur og organisasjon, og hver onsdag morgen møtes bankbokklubben for en kaffe og en bokprat. Av de bøkene vi har lest det siste året vil jeg spesielt trekke frem disse:The Culture Code: The Secrets of Highly Successful Groups, Daniel CoyleLoonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries, Safi BahcallAccelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, Nicole Forsgren, Jez Humble, Gene KimTorsdag er den nye lørdagen was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Stian Conradsen

@sparebank1design og @sparebank1utvikler på Instagram