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.
Som rektor ved BAS, Marianne Skjulhaug sa til oss når vi tok bachelor: Go and do marvelous mistakes!
Godt råd, flink rektor!
Gjør man ikke feil, så lærer man ikke. Gjør mange feil (og rett dem) så lærer du fort. Gjør skikkelige brølere så lærer du enda fortere. Godt jungelord. 🙂
Akkurat! Jeg prøver å sørge for en jevn tralt av brølere selv.
Tror kanskje hvorvidt det er lurt å hoppe i ting du ikke kan avhenger at hvilken primærfunksjon bedriften din har. Om 5000 sykepleiere og leger ikke får gjort jobben sin fordi du har brukket Oracle-basen journalsystemet kjører på, blir du neppe så veldig pop..
Joda, ser den. Man bør selvsagt følge rutinene for backup, testkjøringer og alt sånt der det fins, og se an brekkingen i forhold til krav til oppetid.
Øh, jeg stiller meg nok litt tvilende til at man alltid skal hoppe ut i det med begge beina uten å forberede seg først, man blir som det påpekes raskt upopulær dersom du “brekker” kritiske produksjonsmiljøer bare fordi man har lekt seg for mye.
Og man MÅ skille mellom produksjon og test i miljøer der oppetid er viktig. Man prøver IKKE ny kode i produksjon, eller prøver en ny gpo i AD på produksjon, men man går på testmiljøet prøver der, feilsøker om nødvendig og deretter gjør man det samme på produksjon. Og selv om man ikke alltid greier å hindre feil ved å teste først fordi det ikke alltid er mulig å gjenskape samme forhold i testmiljø som i produksjon, så reduserer man hvertfall sannsynligheten for at noe går galt betydelig.
Jeg syntes faktisk ikke det å bygge kompetanse ved å krasje viktige driftsmiljøer er veien og gå, og jeg tviler sterkt på at du blir så veldig mye mer attraktiv av den grunn. Seriøse firmaer opptrer hvertfall ikke slik. Som drifter er noe av det viktigste du bidrar til et så stabilt og robust miljø som mulig, for det kan være alt fra et par stykker til flere hundretusen som får avbrudd i hverdagen sin, med de kostnader det medfører dersom man leker seg for mye.
Nei, skill mye heller på test og produksjon. Der kan man leke seg så mye man vil, og så ta de gode erfaringene derfra over i prod.
Etter å ha jobbet med IT i forskjellige kapasiteter i 15-18 år nå, så er denne antakelsen om at bedrifter har et skille på prod, test, utvikling og slikt noe som er ganske sjelden vare.
Halvparten av tiden jeg bruker hos kunder er for å begynne å rydde mellom hva som er “dårlig vedlikheoldt produksjon” ispedd “mindre viktig produksjon” og litt “test”, det er ofte når man rører i denne suppen man finner ut (og kunden finner ut) hva som henger sammen. Sånn er det bare.
De bedriftene som har produksjon som er faktisk så livsviktig at den “ikke må ryke til”, de har og såpass orden at de stedene man hopper uti er avgrenset nok til at det ikke er så farlig. De som ikke er avgrenset nok, er dekket i forrige avsnitt.
De som jeg har sett rundtom her i byen som er blitt skikkelig flinke er ikke de som følger ITIL og tror at det finnes en ryddig verden med ISO900x-prosesser for alt, det er de som har lært at man kan hoppe uti den dype enden, og etter hvert lære å se ting som er farligere å riste i en andre ting. Og en og annen gang innimellom lærer man at adrenalin er brunt. Sånn er det bare. 😉
Nå tror jeg du leser inn mer enn det jeg prøvde å si, selv om jeg spissformulerer. For det første bør man selvsagt ikke la være å forberede seg. Forberedelse er jo mye av poenget.
Som jeg også svarte til Silje: Jeg oppfordrer selvsagt ikke til å brekke kritiske produksjonsmiljøer. Jeg tenkte hovedsakelig på interne miljøer, selv om jeg ser at det kanskje ikke kom klart nok fram i bloggposten.
Poenget mitt er at man ikke bør være redd for å dumme seg ut ved å ikke få til ting på første forsøk, ikke at man skal få kred ved å ta ned systemer som mange kunder/brukere er avhengige av. Selv om man nok lærer en hel del av det også 🙂
Stemmer ganske godt overens med mine egne erfaringer.
men hvem sa du skulle gjøre det på systemet som er i produksjon? Forøvrig er det ingen så jobber så fort som når det står en oversykepleier å freser.
Uansett får leger og sykepleiere gjort jobben sin. De får kanskje ikke gjort alt av jobben sin så fort, side de da må snakke med hver enkelt pasient, men de klarer fint å titte inni ører, sy magesekker og gjennomføre bandageskift, også på brannskadde pasienter, ta i mot barn, og ikke minst sjekke pulsen på uhorvelig mengder av mennesker.
Man har som regel en nødjournal å falle tilbake på om EPJ skulle være nede over lengre tid, men disse systemene regnes som virksomhetskritiske av en grunn. Man vil nok ikke forstyrre øyeblikkelig hjelp så veldig mye, men mye planlagt aktivitet vil nok bli avlyst. Og så vil det bli et h******* opprydningsarbeid etterpå. 🙂
Joda Alexadner, jeg ser jo den, og jeg har sett mye av det samme selv i mange sammenhenger i min egen karriere. Men at mange ikke har klare nok skiller og at dette for noen bedrifter nesten er normen betyr ikke at dette er det optimale. Når saueflokken velger en tilnærming til drift som fører til flere driftsavbrudd enn det som hadde vært nødvendig – som kunne til dels ha blitt løst ved innføring av klarere skiller mellom forskjellige miljøer – så er det et tegn på at man kanskje bør dytte litt hardere på it ledelsen i bedriften, for man kan stabilisere en del hvis man er bedre på å skille ulike miljøer.
Og nei, jeg vet jo veldig godt at å snakke med enkelte ledere i forhold til informasjonteknologiske behov kan være som å snakke med en vegg, men noe av jobben som konsulent er jo også å forsøke å “løfte” organisasjonens infrastruktur i mange sammenhenger. Og da må man bare prøve å gjøre sitt beste, og komme med anbefalinger som man mener kan føre til et mest mulig stabilt driftsmiljø.
Og det er jo heller ikke meningen at de som ikke har behov for deg skal forholde seg til tunge iso rammeverk, men man behøver jo ikke det for å ha greie skiller mellom test og produksjon.
Det ideelle er fint og flott, men i praksis må man jo forholde seg til virkeligheten. Og i prosessen med å komme til den perfekte strukturen må man nødvendigvis røske litt i slike ting som mange ikke tør å ta i i frykt for at de skal falle sammen. Hvis man ikke tør å ta fatt på ting man er usikker på blir det ikke mulig å rydde opp. Min kollega Rudolf Brunner skal forøvrig snakke litt om akkurat det på Roots i år: http://rootsconf.no/talks/24
(Ok, nå ser ikke bloggsystemet ut til å støtte flere nivåer med “replies”, så jeg svarer rett under min egen forrige kommentar)
Som sagt, skjønner hva dere mener og er enig at man ikke kan være redd for å skitne til fingrene for å oppnå en mer ideell struktur. Men har man en grei struktur allerede, så er det liten vits i å eksperimentere på produksjonsmiljø bare for eksperimentets skyld når man i mange sammenhenger fint kan finne ut like mye på et testmiljø. Jeg vet jo selvsagt at man ikke alltid kan teste alle aspekter, som f. eks skalerbarhet, belastning o.l., men som oftest kan man teste om “refaktorisert” kode kjører greit, og det hjelper faktisk en hel del når man feilsøker på produksjon.
For øvrig er et ikke bare evnen og viljen til å ta utfordringer på strak arm som indikerer en suksessfull konsulent, det er også evnen til å formidle behov og erfaringer oppover. Det hjelper ikke det dønn med god kunnskap og erfaring dersom ledelsen ikke er villig til å implementere forslag. Jeg tror mye av forklaringen ligger i hvordan it folk og andre teknisk orienterte forklarer ting. Setninger som “jeg tror at” og “vi bør kanskje” er ofte ikke tydelig nok og kan fort tolkes som at behovene ikke er viktige nok. Når sjefen spør en om man virkelig -må- bytte ut bladet i bladserverracket eller om man virkelig må kjøpe flere ekstra disker til raidsettet så må man svare at “ja, vi må”, gjerne med en liten konsekvensforklaring av å ikke gjøre det.
Dette med tydelighet i kommunikasjon med ledelsen er jo også erfaringsmessig ofte knyttet opp mot nettopp måten infrastrukturen er satt opp på. I bedriftsmiljøer man finner en hasteløsning, så er ofte en del av forklaringen at den/de som har jobbet der ikke har greid å få satt god nok fokus på robust infrastruktur. Og tilsvarende finner man gjerne de beste og mest robuste miljøene der det jobber folk som i tillegg til å være teknisk flinker er “ledertyper” som er tydelige med ledelsen. Det er hvertfall min erfaring.
Jeg har da aldri påstått at man skal eksperimentere på produksjonsmiljø hvis man kan oppnå akkurat det samme på et testmiljø.
Ellers er det å være tydelige i forhold til ledelse et veldig viktig poeng, som jeg også kommenterer på under http://epistel.no/blog/2011/05/hvordan-fa-suksess-i-it-bransjen-del-2-mas-pa-folk/comment-page-1/#comment-18880.