Archive for the ‘Arbeidsliv’ Category

Dhaka – en usammenhengende reiseskildring

søndag, august 19th, 2012

Dhaka - GulshanJeg var i Dhaka en uke i slutten av mai – det begynner jo å bli en stund siden nå, men jeg har ikke fått somlet meg til  noe særlig blogging.

Før jeg reiste fikk jeg høre fra andre som har vært der at det kom til å være varmt, veldig mye mennesker, og veldig hyggelige mennesker. Alt sammen stemte. For en som er vant med norske forhold, der man selv i sentrale strøk kan tusle seg en tur på butikken tidlig på kvelden og ikke møte en sjel på veien annet enn kassedamen og kanskje en og annen med-handler, er det ganske annerledes å komme til en asiatisk storby. Det er folk over alt, hele tiden. Jeg er imponert over den smidigheten som må til for at det tross alt fungerer ganske greit. Vel er trafikken kaotisk og alle biler bulkete, men trafikkorken blir en levevei og ikke en årsak til høy puls og bannskap.

Dhaka - GulshanJeg ble anbefalt å satse på å kjøpe lokale klær å gå i, men den ideen slo jeg raskt fra meg. Etter å ha sjekket det ganske begrensede utvalget klær i min størrelse, gikk det opp for meg at dersom en bengalsk kvinne trenger en stor klesstørrelse, er det ikke fordi hun er 173 cm høy, men fordi hun er nokså bred. Om klærne passet i lengden, var de størrelse flodhest i bredden, og satt slett ikke flatterende og fjongt over hoftene som på mine lokale kolleger. Jeg kjøpte likevel med meg en shalwar kameez hjem, i naiv tro på at jeg kanskje får tid og ork til å sy den inn en dag.

Som vestlig, og spesielt som vestlig kvinne, er det en del å forholde seg til. På innreisepapirene måtte jeg oppgi navnet til enten min mann eller min far, og det ble presisert at bangladeshiske statsborgere ikke hadde lov til å bringe alkohol inn i landet. Kun vestlige hotellrestauranter serverte alkohol – men det gjorde de til gjengjeld også til bangladeshere, antakelig gjennom et smutthull i loven. Der en vestlig kelner alltid serverer kvinnen først, deretter mannen, var det konsekvent omvendt i Bangladesh – noen steder fikk jeg ikke engang egen meny. Religion er overalt, men samtidig er den ikke politisert på samme måte som i nabolandene India og Pakistan. Som ikke-muslim uten slør følte jeg ofte at jeg stakk meg ut, men aldri at jeg var uvelkommen. Mange menn håndhilste, noen få trakk seg rolig i bakgrunnen for å unngå kroppskontakt.

Dhaka - trafikkJeg levde i en beskyttet boble, naturligvis. En sjåfør plukket opp meg og min kollega om morgenen og kjørte oss til kontoret, og om ettermiddagen tilbake til leiligheten vi bodde i, eller ut på en restaurant. Folk på kontoret ordnet alt, og det var aircondition for å holde varmen borte. Kontrastene fikk jeg bare sett på avstand, men de var ikke så langt borte. Lyktestolpene er en jungel av strømkabler på kryss og tvers og i digre kveiler, og asfalt finnes slett ikke overalt, selv i forretningsstrøkene. Store områder med blikkskur var kun minutters gange unna høye kontorbygg med IT-bedrifter. Noen absurde situasjoner ble det også rom for – som da jeg fant meg selv i en hotellbar sammen med en bengaler, en engelskmann og en taiwaner, og drakk mojitos mens jeg hørte en filipinsk elgitarist spille Edvard Grieg live.

Det blir nok flere turer til Bangladesh framover, og jeg håper å få sett litt mer av landet etterhvert. Neste gang skal jeg passe på å booke hjemreise uten åtte timers layover i Dubai midt på natten. Eller i alle fall bestille meg hotellrom. Men først blir det en svipptur til Amsterdam i september, med oppsett til IBC og påfølgende langhelg!

Jeg er her fremdeles

torsdag, mars 15th, 2012

Bloggen min preges litt av det som kanskje er en for høy terskel for å skrive innlegg. Jeg vil gjerne ha hele, velformulerte resonnementer med begynnelse, midtparti og konklusjon. Dessuten ser jeg aldri poenget med å blogge om noe som noen allerede har sagt bedre enn meg. Dermed utgår alle kommentarer til aktuelle nyheter og debatter. Innen jeg har rukket å tenke ferdig og bestemme meg for hva jeg egentlig mener om saken, er det minst fire andre bloggere som allerede har sagt akkurat det jeg mener. Kombinert med mange baller i luften på jobb og andre fronter, så vips, har det gått fem måneder siden siste bloggpost.

Derfor har jeg tenkt å gi meg selv litt lavere terskel for å blogge. Jeg trenger kanskje ikke fullendte og unike resonnementer? Kanskje jeg ikke trenger å mene så mye om samfunnsdebatten i det hele tatt. Jeg kan for eksempel skrive litt mer om jobben min. Kanskje jeg burde hatt en egen blogg for jobb-temaer, sånn at alle IT-folkene som kunne tenkes å ville følge en fag-blogg ikke belemres med matoppskrifter og bokanmeldelser i ny og ne. På den annen side er det å starte en ny blogg når man allerede sliter med å oppdatere den gamle, dømt til å fisle ut i sanden etter omtrent tre bloggposter. Jeg holder meg her, så får de som er interessert i vilt forskjellige ting finne seg i å hoppe over ting de ikke er interessert i.

Så, bare for å komme ajour: Hva har jeg gjort siden sist? Jo:

I fjor høst gikk jeg inn i rollen som teamleder for QA, andrelinje-support og toolsmith (internutvikling) i Vizrt, der jeg har jobbet siden 2008. Det i seg selv er en ganske lang historie. Jeg må åpenbart ha gjort noe riktig det første halvåret i stillingen, for like etter nyttår ble jeg bedt om å opprette og lede et team i tillegg til dette. Det nye teamet skal befinne seg i Dhaka, Bangladesh, og drive med integrasjonstest av produktene og komponentene som utvikles i de ulike R&D-kontorene vi har rundt omkring i verden.

Akkurat nå sjonglerer jeg altså teamet i Bergen, som er inne i siste testfase av tre produkter som skal ut innen Q1 er over (ja, det er… aldeles ikke lenge til Q1 er over), og forberedelser til teamet i Dhaka, som både skal ansettes, læres opp og settes i gang med jobben. I tillegg skal de helst ha en testlab med hardware, og andre slike detaljer som må på plass. I tillegg er det forberedelser til NAB i Las Vegas i april, et årlig gedigent tradeshow for kringkastingsbransjen. Dit drar jeg like etter påske, forhåpentligvis med nyutgitte produkter i kofferten. Og så bærer det avgårde til Dhaka i mai. Hvor ferden går etter det har jeg ikke begynt å tenke på ennå, men med tanke på at alle disse integrerende produktene skal koordineres, er det nok lett for at det blir en reise eller tre til i løpet av året.

På andre fronter har jeg denne uken blitt ferdig med migreringen av nettbutikken til Te med stor T fra egendriftet Zen-Cart til en SaaS-løsning fra MyStore. En god del arbeid på kort sikt, men det vil spare meg for mange ganger mer arbeid med drifting av den gamle løsningen på lang sikt. Jeg jobber i QA, jeg liker å påpeke feil slik at noen andre kan fikse dem. Jeg liker ikke å fikse feil selv.

Og dessuten har jeg laget ny, fjong WP-basert nettside til Foreningen for fremme av fri programvare i Bergen og omland, der jeg er styremedlem. Den ser kanskje ikke så spennende ut, men den er betydelig vakrere enn den gamle. Og mye, mye lettere å vedlikeholde.

For å få tid til alt dette må jeg selvsagt prioritere. Bloggen, for eksempel, har vært prioritert bort. En del andre hobbyer likeså, og et par sosiale arenaer jeg gjerne skulle ha deltatt mer på. Men jeg prøver å få tid til å klø katten og ungene bak øret i blant, og lese litt skjønnlitteratur og ikke-jobbrelevant sakprosa innimellom. Alt i alt tror jeg ikke jeg har noe å klage over.

Brukertesting – praktisk og upraktisk

fredag, september 16th, 2011

For ordens skyld

Jon Gunnar Wold, en av forfatterne av boken Praktisk brukertesting, etterlyste bokanmeldere via Twitter. Jeg er interessert i temaet og meldte meg frivillig til å teste boken. Dette er dermed en sponset bloggpost, men jeg har ikke mottatt annen kompensasjon enn selve boken for å skrive om den.

Om meg

Jeg har tidvis skrevet om jobb her på bloggen, men en god del av leserne har antakelig ikke helt klart for seg hva jeg jobber med. Jeg er testleder og teknisk tester i Vizrt, som (blant annet) utvikler kontrollsystemer for tv-grafikk. Vi lager altså ikke selve grafikken, men verktøyene som brukes for å lage den og få den spilt ut på luften. Jeg bruker mye av tiden min på å planlegge test og grave fram nødvendig teknisk informasjon om kommende systemer og funksjonalitet, men får også leke med morsomme duppeditter. Teamet mitt fokuserer mest på funksjonell testing, men har lav terskel for å rapportere om ting som går på ren brukervennlighet. I tillegg har noen utviklere på avdelingen eksperimentert med brukertesting og oppnådd gode resultater med svært enkle midler.

Om boken

Til poenget. Boken heter altså “Praktisk brukertesting”, og den er akkurat det den gir seg ut for å være. Jeg kom meg greit gjennom hele boken på en halv arbeidsdag. For de som har enda mindre tid å avse åpner boken med en presentasjon av ulike roller som kan tenkes å ha nytte av boken, med tips om hvilke kapitler de bør se spesielt på. Det er et gjennomgående fokus på nytteverdi i arbeidslivet, og en god balanse mellom det ideelle og det oppnåelige.

Før jeg åpnet boken hadde jeg en konkret liste av spørsmål jeg håpet å finne forslag til løsninger på:

  1. Hva skjer med resultatene av brukertest når deadline nærmer seg og kunden skal på luften med den nye funksjonaliteten på tirsdag?
  2. Hvordan håndterer man brukertesting med en målgruppe som er vanskelig å definere og ikke minst vanskelig tilgjengelig?
  3. Hvordan kan man praktisk gjennomføre brukertest av svært komplekse systemer?

Min personlige dom over boken blir dermed avhengig av i hvilken grad jeg fikk nyttige svar på disse spørsmålene. Det skal jeg komme tilbake til.

Først litt mer generelt om boken. Dette er ikke den første teksten jeg leser om brukertesting, selv om jeg på ingen måte er ekspert på området. Det de fleste tekster om brukertesting har til felles er at de er fokusert på metode. I så måte ble jeg svært positivt overrasket over Praktisk brukertesting.

Det er riktignok et kapittel om metode, og det kapittelet sier bare en brøkdel av det det kunne ha sagt. Mesteparten av boken dreier seg om andre ting: Ren praktisk gjennomføring av brukertester, ned til detaljnivå med forslag til sjekklister. Hvordan logge og analysere resultatene, og ikke minst – hvordan få gjennomslag for å gjøre endringer basert på resultatene. En fornuftig prioritering, spør du meg. Metodikk finnes det hauger av annen tilgjengelig litteratur på, og den store bøygen er ikke egentlig å finne ut av metodene, men å få noen konkrete resultater av testingen, i form av bedre produkter.

Boken er tydelig skrevet av folk med mye praktisk erfaring, og bruker flittig sitater fra og referanser til andre erfarne kilder. Den er konkret og behagelig kortfattet, men samtidig fleksibel, og fokuserer gjennomgående på praksis framfor teori – learning by doing. Det dukker likevel opp en påminnelse mot slutten om at brukertesting ikke erstatter interaksjonsdesignere.

En ekstra styrke er at boken er skrevet på norsk, med det norske arbeidsmarkedet som utgangspunkt. Du skal ikke forbi mange landegrenser før du finner store forskjeller i bedriftskultur og brukerkultur. Rådene som gis er fornuftige i forhold til norsk kultur, og eksemplene er hovedsakelig fra norske bedrifter. Dermed er de lett omsettelige i praksis, for ferske brukertestere som tester systemer utviklet i Norge for norske brukere.

Dette er som sagt en styrke, men samtidig en svakhet. Jeg savner et avsnitt eller to om det internasjonale aspektet, både med tanke på brukermassen (i hvilken grad kan man generalisere brukertest gjort i ett land til brukere i et annet?) og med tanke på forankring av brukertesting innad i en internasjonal organisasjon med utviklere i mange land. Kanskje i neste utgave?

Så tilbake til utgangspunktet. Spørsmålene mine var ikke enkle, og de har ikke enkle svar. Boken behandler temaet om tidsfrister på realistisk vis. Noen ganger er det rett og slett ikke tid – prøv igjen neste gang, og planlegg bedre fra start av. Det forutsetter riktignok at den som er interessert i å kjøre brukertesting er med ganske tidlig i prosjektet, og ikke minst at prosjektet er veldefinert. Som så mange andre bøker om test og prosess bærer Praktisk brukertesting preg av konsulentbransje og prosjektbasert utvikling, der man har en plan, en kravspesifikasjon, en prosjektleder og en gruppe mennesker som jobber på et bestemt prosjekt i en bestemt periode. I min bedrift er ikke dette alltid (eller ofte) tilfelle. Spørsmål to og tre blir ikke egentlig besvart.

Vil jeg nå hoppe til verket og sette i gang brukertester på jobben?

Tja.

Produktene jeg jobber med har en del aspekter som gjør at brukertesting ikke er helt rett fram. Som nevnt innledningsvis:

  • Målgruppen er vanskelig tilgjengelig. Brukerne er ulike yrkesgrupper hos TV-stasjoner rundt omkring i verden. For de spesifikke produktene jeg har testansvar for er det mest relevant å kjøre brukertest på journalister og operatører – det vil si de som legger informasjonen inn i systemet, og de som sørger for at den blir spilt ut på luften til rett tid. Det er ikke praktisk og ressursmessig mulig å få brukerne til å komme til oss – vi må komme til dem. Selv da kan det være vanskelig å få tilgang til testpersonene vi trenger.
  • Testmiljøet er komplekst og kostbart. En ren oppgavebasert test vil ikke være god nok for oss, ettersom en viktig faktor er hvordan systemet fungerer under tidspress med mange beskjeder som flyr fram og tilbake og ting som må endres på sekunders varsel. TV-seere ville bli overrasket over hvor kaotisk situasjonen i kontrollrommet kan framstå under sending, selv om de som sitter der har full kontroll. Noen sekunders forsinkelse som ingen ville lagt merke til i en veldefinert test i rolig setting vil være et stort problem under sending. Å sette opp en egen, realistisk lab er for dyrt og uansett nesten umulig (se neste punkt), og å få tilgang til tv-selskapenes egne kontrollrom er heller ikke rett fram.
  • Målgruppen er vanskelig å definere. Systemene våre integrerer tett med øvrig programvare og hardware hos kunden, og det er milevise forskjeller i oppsett og konfigurasjon fra kunde til kunde. Det er tildels store forskjeller i både brukergrensesnittet og arbeidsflyten. Dermed er vi på gyngende grunn når vi skal prøve å generalisere testresultater og ikke minst prioritere hva som er viktigst å endre. Endringer gjort for å tilpasse produktet til arbeidsflyten til en kunde fører ikke sjelden til at en annen kunde roper opp i protest fordi det kompliserer arbeidsflyten hos dem. Det betyr ikke at brukertest er umulig, men det betyr at vi trenger et mye bredere datagrunnlag enn de 3-5 testpersonene boken legger opp til – og fra kunder over hele verden.

At brukertesting kunne være nyttig for oss er det liten tvil om. Vi, som alle andre, har utfordringer på brukergrensesnittfronten, og de spede forsøkene som har vært gjort har vist at det er mye å hente. Likevel nøler jeg med å sette i gang brukertest av annet enn enkelte, begrensede prosjekter og funksjoner. For de fleste produktene tror jeg kost/nytte vil være større med andre tiltak, i alle fall der vi er nå. For eksempel:

  • Det er vedkjent at verken utviklerne og testerne har tilgang på nok domenekunnskap. Det kan vi gjøre noe med, på ulike måter. Økt domenekunnskap gir ikke automatisk gode brukergrensesnitt, men det øker sannsynligheten for at man utvikler det kunden egentlig trenger for å utføre arbeidsoppgavene sine.
  • Fattigmanns brukertest: Ren observasjon av brukere i deres eget miljø, mens de utfører sitt vanlige arbeid. Denne metoden har vi i testavdelingen allerede tatt i bruk, men arbeidet kan og bør både systematiseres mer og følges bedre opp – og deretter utvides. Selv om dette ikke kan regnes som en brukertest, har Praktisk brukertesting mange nyttige råd som kan brukes også på denne metoden, spesielt med tanke på analyse og bruk av resultatene

Konklusjon

Hvis du snuser på brukertesting og trenger en dytt for å komme i gang, er dette boken for deg. Hvis du allerede har litt erfaring og kunne tenke deg gode tips for å forbedre måten du jobber på, er det også boken for deg.

Verdi for pengene er ikke så relevant som mål, en bedrift som har råd til å kjøre brukertester har uansett råd til de få kronene denne boken koster. Viktigere er at den er verd arbeidstiden som går med til å lese den. Den er både kort nok, tydelig nok og nyttig nok.

Ikke ta deg nær av at jeg er vrang – jeg mener at brukertesting er en verdifull arbeidsmetode og bør brukes overalt der det er praktisk og ressursmessig gjennomførbart. For de aller fleste IT-prosjekter er det det.

Nerdemillionen

mandag, august 8th, 2011

Vi som jobber innen IT-bransjen har generelt helt grei lønn. I det store bildet har vi faktisk helt ufyselig god lønn. Dessuten tilbringer vi store deler av livene våre på internett, og skaper oss ganske store nettverk. En av disse IT-nissene har sett mulighetene i denne kombinasjonen, og startet NerdAid – eller på nerdsk, #nerdaid.

Det dreier seg om Øst-Afrika og sultkatastrofen der. Du har sikkert sett bildene og tenkt at du burde gjøre noe. For de fleste av oss er det ikke så mye mer vi kan gjøre enn å gi penger. Men penger har vi til gjengjeld lassevis av her i landet. Joda, bestemor må kanskje bo på dobbeltrom et år til, men hun får i det minste mat.

Jeg blir flau og nedstemt om vi ikke klarer å hoste opp den millionen #nerdaid har satt seg som mål. Kom igjen, folkens.

Hvordan få suksess i IT-bransjen: Del 4 – De som kan mer enn deg tar feil

fredag, juni 3rd, 2011

De fleste bedrifter og fagfelt har en minst en guru. En person som har vært der så lenge og kan så mye at få, om noen, stiller spørsmål ved avgjørelsene deres. Noen guruer er globale innen et fagfelt eller en metodologi, andre er lokale eksperter på en bestemt applikasjon eller utviklingsområde. Hvis disse hevder at en bestemt metode er den beste for å løse et problem, tar folk det for gitt at de har rett. De har jo tross alt rett stadig vekk.

Kompetente mennesker kan mye, og er viktige ressurser å ha i et prosjekt. Men det at han på nabokontoret kan noe, er ingen unnskyldning for deg til å skru av hjernen.

Man kan selvsagt ikke stille spørsmål ved alt hele tiden, ellers får man ikke gjort særlig mye annet. Ofte er det fornuftig å forholde seg til det noen andre har bestemt eller foreslått. Godt nok er ofte bedre enn perfekt. Men føler du noe skurrer, stopp opp og tenk. Ikke gå ut fra at noen allerede har sett saken fra den vinkelen og allerede tatt hensyn til problemet, selv om de er flinkere enn deg.

Det kan føles som en belastning å komme inn fra sidelinjen og antyde at flinke, erfarne mennesker tar feil. Men også flinke folk gjør feil hver dag, og i en fornuftig bedrift setter smartingene pris på stemmer som kommer med andre forslag og synsvinkler, eller påpeker problemer som andre ikke har lagt merke til ennå.

Jeg har hatt flere aha-opplevelser på dette feltet. Jeg har opplevd prosjekter der alle som har jobbet på prosjektet har sett helt grunnleggende problemer, men ingen har tord å ta opp kampen mot det de har sett på som ekspertisen. Jeg har opplevd å få mailer fra langt mer erfarne kolleger enn meg selv, som har takket meg for å ta opp ting når de selv ikke har våget å stikke ut nakken.

Og det aller viktigste: Når jeg har tatt opp saker, har jeg opplevd en fantastisk respons fra ekspertisen, som har imøtekommet kritikken, begrunnet sine synspunkter godt og grundig, og vært villige til å gjøre endringer der endringer er nødvendige eller hensiktsmessige. Det er en grunn til at ekspertene er eksperter – de er ofte veldig flinke til å lære av feilene sine. Feilene kommer jo som regel for en dag til slutt uansett, men for prosjektet er det langt bedre at de kommer før enn etter release. Og ikke minst er det mye mer motiverende å arbeide på et prosjekt man har tro på.

Dette burde være åpenbart for de fleste, men likevel – noen tips for god kritikk:

Vær ydmyk. Selv om du er sikker på at du har rett og at alle andre tar feil, er det lite hensiktsmessig å komme brasende inn og slå i bordet. Kom med spørsmål og forslag, ikke ferdige løsninger. Som regel er den beste løsningen ikke nøyaktig hva du hadde tenkt – mer om akkurat det i en senere bloggpost.

Vær direkte. Hinting og mumling i bisetninger er bare irriterende. Send gjerne en ryddig og gjennomtenkt epost til alle relevante parter og gjør det klart nøyaktig hva det er du prøver å si. Forklar hva du mener ikke fungerer, og hvorfor.

Fokuser på målet. Målet er (fortrinnsvis) et godt prosjekt. Målet er (helst) ikke å henge ut andres inkompetanse eller fremheve egen genialitet. Vi er alle inkompetente, og gode prosjekter kommer av samarbeid og bruk av sterke sider, ikke av å lage politikk ut av svake sider.

Om jeg noen gang synder mot alle de gode tankene i denne bloggposten? Stadig vekk, mer enn jeg liker. Men det er en fin ting å øve på.

Hvordan få suksess i IT-bransjen: Del 3 – Drikk mye kaffe

onsdag, mai 18th, 2011

Kaffetrakterens symbolske rolle i arbeidslivet til tross: Det jeg var aller minst forberedt på som ny arbeidstaker var viktigheten av å drikke kaffe. Mye kaffe. Hvis du ikke liker kaffe kan du selvsagt gjerne drikke te eller vann, så lenge du henter den i nærheten av kaffetrakteren.

Så godt som alle de spennende faglige og avdelingspolitiske diskusjonene starter rundt kaffetrakteren. Og det viktige er: Ingen kommer til å invitere deg! Hvis du vil være med å påvirke hva som skjer må du delta i de uformelle foraene, stoppe opp når du går forbi noen som snakker sammen i korridorene, spisse ørene når noen kommer inn på noe interessant i lunsjen.

Alle arbeidsplasser har noen monomane arbeidsjern som henter sin kaffe og forsvinner inn på kontoret, der de sitter og koder fram til en sen lunsj, etterfulgt av mer intens koding. Disse arbeidsjernene er ekstremt verdifulle, og hvis du er en slik kommer noen til å sette stor pris på arbeidet du gjør. (I alle fall hvis du gjør det bra). Men ikke tro, som nyutdannet, at å kode mest mulig, eller å prosessere flest mulig supportsaker, eller kjøre flest mulig testcaser, er den eneste måten å oppnå suksess. Dersom du bare forholder deg til formelle informasjonskanaler går du glipp av 70% av den verdifulle kommunikasjonen på arbeidsplassen.

Man kan mene at dette er en uting, og at alle bør inkluderes formelt i alle interessante diskusjoner, men faktum er at hjerner tenker mest kreativt når de står og henger rundt kaffetrakteren. (Andre gode tenkeplasser er i dusjen, på sykkelen på vei til jobb, og i sengen ved leggetid – men det er en annen diskusjon.) Gode ideer blir mer formaliserte etter hvert hvis noen følger opp og gjør dem til virkelighet, men starten er alltid uformell og skjer blant de som tilfeldigvis er der akkurat da. Å kalle inn til et brainstorming-møte er litt som å be noen fortelle en vits på stående fot. Du får kanskje høre en vits, men den er aldri like brølende fantastisk som de vitsene som kommer trillende på assosiasjonsrekkefølge eller situasjonskomikk i løpet av nachspielet.

Ikke dermed sagt at uformell brainstorming og diskusjon er problemfritt. Det finnes mange utfordringer knyttet til å holde folk oppdatert, spesielt i organisasjoner der folk er fordelt på flere fysiske kontorer. Det endrer ikke på det faktum at de uformelle kanalene eksisterer og er viktige. Man er nødt å forholde seg til dem. Selv valgte jeg å skifte jobb for en del år siden nettopp fordi oversettelsen fra uformell til formell ikke fungerte, og jeg satt i en annen by.

Du kan selv gjøre mye for å holde loopen i gang – send en mail med oppsummering når du har deltatt i en fruktbar samtale, både til de som var tilstede og til andre som potensielt kan være interesserte. Da får du informasjonen ut, samtidig som du hjelper til å få saken videre til neste steg i stedet for å la den renne ut i sanden. Om ingenting kommer videre blir det som skjer rundt kaffetrakteren bare meningsløst småprat – kanskje ikke direkte bortkastet tid, men heller ingen stor gevinst for bedriften.

Men før du installerer kontorstolen i kjøkkenkroken og hekter opp intravenøsen: Det går an å overdrive. Du må kanskje gjøre litt kjedelig rutinearbeid sånn innimellom, også. Heldigvis er oppgavene raske å få unna med all koffeinen du har innabords.

Som et apropos: Det finnes mange sjefer som gjemmer seg bort på store, fine hjørnekontorer litt utenfor allfarvei i forhold til der de ansatte kravler rundt. Og så finnes det sjefer som har kontoret sitt midt i kaffegryten. De blir forstyrret stadig vekk og har sjelden særlig god utsikt, men de får med seg mye mer av det som skjer på avdelingen. Blir du sjef noen gang og får velge kontor, sats på det kjipe og trange like ved siden av kjøkkenkroken.

Hvordan få suksess i IT-bransjen: Del 2 – Mas på folk

mandag, mai 9th, 2011

En yrkesfaglærer jeg kjenner gir elevene sine et råd med på veien ut i arbeidslivet: Det beste verktøyet du har for å gjøre en jobb er telefonnummeret til han som har gjort den før.

Som nyutdannet kan og bør du mase på folk. Selvsagt bør du prøve å finne ut ting selv før du går rundt og stiller spørsmål, men det lønner seg aldri å være redd for å være til bry. Du er langt mer til bry hvis du ikke gjør jobben din så godt som du kunne gjort den fordi du var redd for å stille de dumme spørsmålene som skulle til. Men noen triks finnes det:

Fordel spørsmålene. Ikke spør den samme hver gang. Merk deg hvem som ser ut til å kunne noe om ulike temaer, og spør en av de andre neste gang. Det gjør ikke noe at du ikke kjenner vedkommende. Stikk hodet innom kontoret, eller send en mail, og si “Jeg hører rykter om at du kan noe om dette her, har du tid til å svare på et par spørsmål?”

Samle opp spørsmålene.  Den mest tålmodige person kan bli irritabel av nybegynneren som kommer flere ganger for dagen for å spørre om noe. Noter heller ned spørsmål over tid, sorter dem, og spør en som kan det du trenger å lære om hun har tid til å sette seg ned en halvtimes tid og gå gjennom noen ting med deg. Neste gang velger du en annen person. Slik maser du på samme person kanskje bare en gang i måneden eller en gang i kvartalet.

Så langt om konkrete spørsmål. Vel så viktig er den faglige oppdateringen og videreutviklingen. Om arbeidsgiveren din betaler kurs og konferanser er det bra, men du bør ikke begrense deg til det. Medmindre du bor i Ytre Langtpokkerivold finnes det et utall gode fagfora. Start et selv hvis du ikke finner det du leter etter. Noen må du betale medlemsskap for å være med i, mange er gratis og alle setter stor pris på folk som engasjerer seg. De fleste er gjørokratier der du kan få gjennomført mye etter eget hjerte hvis du stiller opp med litt organisasjonsvilje.

Internett er vel og bra, altså, og det er mange gode grunner til å delta på diskusjonsfora og epostlister på nett. Men ulempen med nettet er at du stort sett finner det du leter etter. Du finner ikke like ofte det du ikke leter etter. Gå ut og treff folk, så kommer du på sporet av de tingene du ikke visste at du burde kunne noe om.

Dessuten lærer du aller best av å lære bort. Hold et gratis foredrag om noe du kan godt, så rekker noen opp hånden og stiller et vrient spørsmål om en usecase du ikke hadde tenkt over. I pausen kommer noen og opplyser deg om en detalj du har misforstått. Over ølen etterpå kommer noen trekkende med en helt annen måte å oppnå samme resultat på. Du får til og med en bonus med på kjøpet: Norge et lite land, og sjansen er stor for at den neste som skal ansette deg har vært tilstede på et foredrag du har holdt, eller lurket på en epostliste der du har kommet med konstruktive svar eller stilt interessante spørsmål.

De siste årene har IT-bedrifter blitt ganske flinke til intern kunnskapsutveksling. Noen arrangerer Lightning Talks, andre satser på litt lengre presentasjoner som går på rundgang mellom de ansatte. Om det ikke finnes noe sånt i din bedrift, sett i gang. Det eneste du trenger er et stort nok møterom og velsignelse fra ledelsen. Mangler det første finnes det alltid en løsning. Mangler det siste, bytt jobb.

Å mase på dine fagfeller bør du øve på så lenge du er ny i arbeidslivet. Når du så begynner å få litt yrkeserfaring har du innarbeidet gode mase-vaner, som du bør fortsette med resten av livet. Du blir aldri for erfaren til å stille dumme spørsmål!

Hvordan få suksess i IT-bransjen: Del 1 – Gjør mange feil

fredag, mai 6th, 2011

Velkommen til min nye miniserie, der jeg vil gå gjennom noen tema som til sammen burde danne en solid oppskrift for å oppnå suksess i IT-bransjen. Serien er løst basert på et foredrag forberedt for IT-studenter.

Første del dreier seg, som overskriften antyder, om viktigheten av å gjøre feil.

Som student er det meste lagt opp til at du skal gjøre alt rett, og helst på første forsøk. Dette er en uvane du bør legge fra deg så snart du kommer ut i arbeidslivet.

På alle arbeidsplasser finnes det en del områder som ingen egentlig har lyst eller kompetanse til å ta i. Hvis du tar mot til deg og hopper i disse oppgavene med begge beina oppnår du en rekke fordeler.

For det første lærer du mye. Du kan lære en hel del av å lese bøker og å jobbe mer med ting du kan ganske godt fra før, men det er når du må fikse ett eller annet som du ikke helt forsto hvorfor gikk til helvete i utgangspunktet, du virkelig skjønner hvordan det er satt sammen. Mange gode aha-opplevelser er gjemt i google-søk etter obskure feilmeldinger.

For det andre oppnår du å få respekt for din ståpåvilje, entusiasme og allsidighet. Dette forutsetter riktignok at du er påpasselig med å gjøre andre oppmerksomme på at det er du som har brukket Oracle-serveren eller fått Vmware-serveren til å havarere. Send ut en mail på felleslisten. Og naturligvis fikser du det selv etterpå. Be gjerne om innspill fra mer kompetente mennesker om du har slike tilgjengelig (mer om det i neste del av serien), men gjør drittarbeidet selv.

For det tredje gir det en enorm mestringsfølelse å få til å fikse noe som var vanskelig å finne ut av og enda vanskeligere å forstå.

For alle de tre punktene over gjelder hovedregelen om at jo mer intrikat feilen er, jo bedre er det. Ikke gjør slurvefeil. Slurvefeil er kjedelige og uimponerende. En erfaren feiler feiler spektakulært.

Kompetanse og respekt er vel og bra, men det viktigste i arbeidslivet er tross alt å holde på med interessante arbeidsoppgaver. Hvis jobben er kjedelig, kan det være det samme med alt det andre. Og her er det kompetansen på å gjøre feil virkelig kommer til sin rett.

Folk merker seg nemlig raskt hvem det er som står med ett bein i databasen, hodet i byggserveren og albuen i den livsviktige koden som ingen tør å ta i, og som alltid ser ut til å vite ett eller annet om et hvilket som helst halvveis relevant tema man kommer trekkende med. Det kan godt være kollegaen din på nabokontoret er flinkere enn deg, men hvis du har rykte på deg for å hoppe i nye oppgaver med liv og lyst er det deg de kommer til med de morsomme tingene. Den flinke kollegaen blir sittende der med rutineoppgavene sine.

For det fjerde, altså: Morsomme oppgaver kommer til de som gjør gode feil, ikke til de som gjør alt rett.