« Hem

Att jobba som integrationskonsult

BizTalk Server – de 4 största nybörjarmisstagen

Inför inledningen till det här blogginlägget satt jag och googlade på ”mistake quotes”, och jag hittade en hel del om relationer och livet i allmänhet, typ ”Det är mänskligt att göra misstag” och ”gör du inga misstag så har du inte försökt” . Ord som parafraserats alldeles för många gånger, ”memefierats” och helt dränerats på betydelse. Ändå ligger det något korn av sanning i dessa klyschor. Som någon sa: ”Your best teacher is your last mistake”, och visst är det så. Jag gjorde mitt senaste misstag för ungefär två timmar sedan nu, och oj vad jag lärde mig av det…

Det finns ju dock en viss mening i att inte göra alla misstag själv, utan lära sig av andras. Därför tänkte jag dela med mig av de, enligt mig, 4 största nybörjarmisstagen som nästan alla gör i början av BizTalk karriären. Eller ja, alla utom du, eftersom du nu lär dig av mina misstag och kan undvika dem. Förhoppningsvis.

Kolla vad som egentligen händer

Det största felet som nybörjare inom programmering gör generellt är nog att inte läsa felmeddelanden utan sitter och bara kliar sig i huvudet av förvirring när saker inte funkar. Samma gäller inom BizTalk – du måste ta reda på vad som händer när det verkar som att ingenting händer. Min process för att göra detta ser ut som följer:

1. Första steget är alltid att se om det finns några suspenderade meddelanden i BizTalk Group Hub. Meddelanden försvinner inte i tomma intet (även om det ibland känns så!) och vid de flesta felen så fastnar (suspenderas) det meddelande du försökte skicka och du kan kolla på innehållet samt det felmeddelande som.

capture2

2. Hittar du inget där, är nästa steg att ta en titt i eventloggen, där information, varningar och fel från bland annat BizTalk loggas.

capture

3. Om jag inte hittat något fel i eventloggen brukar jag använda tracking för att se om meddelandet tagit den vägen genom integrationen som jag har tänkt. Tracking visar helt enkelt hur meddelandet såg ut när det kom in till porten eller orkestrering och hur det ser ut när det bearbetats och skickats vidare till nästa instans. Ofta kan man på det här sättet spåra vad det är som händer i integrationen.

capture3

Den här processen sviker sällan – och om den gör det så beror det troligtvis på något av kommande vanliga misstag. En bonus för att felsöka orkestreringar är att använda debugviewer, ett verktyg som låter oss läsa meddelanden vi skriver i koden med hjälp av ex. System.Diagnostics.Trace.WriteLine(). Glöm inte heller bort att det går att attacha en debugprocess i Visual Studio till BizTalk, så du kan steppa igenom koden rad för rad, samtidigt som den körs.

Skit in, skit ut

När jag har bankat huvudet mot en vägg gällande ett problem i flera timmar och inte förstår vart i processen felet ligger, är det här ofta orsaken. Anledningen till att jag inte förstår felet är enkel – det finns inget fel. Det är meddelandet som jag försöker skicka igenom integrationen som inte är korrekt.

Bildresultat för shit in shit out

Glöm inte gaccen!

Jag har varit inne på ämnet GAC och att ”gacca” assemblys tidigare, troligtvis var det i samband med *saker som jag önskar att jag lärt mig i skolan*. ”Gaccen” är (mycket förenklat för min egen skull, klockan närmar sig 17 och det är fredag) en folder där alla assemblys måste ligga, för att BizTalk ska kunna komma åt dem. Alla scheman, orkestreringar, pipelines, hjälpklasser – allt måste ligga här för att integrationen ska rulla. Har du gjort en förändring i koden som inte verkar funka? Kolla så den nya versionen av assemblyn är gaccad ordentligt.

Har du startat om host instansen?

Det här är det överlägset största misstaget man gör som nybörjare, och jag kan nog inte ens räkna hur många gånger det hänt mig. En host är en logisk container för BizTalk objekt, och en host instans är dess fysiska representant, återigen väldigt förenklat.

capture4

Bildkälla

Vid varje ny deploy så måste berörda host instanser startas om för att förändringarna ska registreras av BizTalk. Host instanserna kan också vara förklaringen till att en receive location inte plockar upp meddelanden som den ska – är hosten stoppad, så kan inte BizTalk ta in meddeladet. Jag har blivit bättre på att komma ihåg det här numera, men det har tagit tid att få in rutinen att alltid kolla status och starta om dem vid behov.

Med detta önskar jag er alla en trevlig helg!

Så fixar du konsultrollen

Jag vet inte om jag varit inne på detta förut, men något jag inte var beredd på när jag slutade skolan var att jobba som konsult. Eller, jag hade koll på att väldigt många systemutvecklare jobbar som konsulter snarare än anställda på en IT-avdelning, men vad det egentligen innebar hade jag inte tänkt på.

Det finns två huvudtyper av konsulter: antingen sitter du på plats hos kunden, eller så sitter du ”in-house”, dvs. tillsammans med dina konsultkollegor och jobbar på distans mot kunden. Hos oss på Integrationsbolaget har vi en blandning av dessa: vi är ett gäng som alltid sitter in-house här i Örebro och jobbar på distans mot kunderna, och sedan har vi ytterligare ett gäng som sitter ute hos kunder i längre uppdrag. Just nu har vi också några uppdrag där man varvar och sitter in-house ett par dagar i veckan och hos kund resten av tiden.

Som nyexad är det perfekt att sitta inhouse, eftersom du då har nära till dina kollegor och kan enkelt be om hjälp när du funderar på något. Du får långsamt vänja dig vid kundkontakten och hinner bli varm i kläderna innan du åker ut och sitter på plats hos en kund. Det är en ganska speciell känsla att lämna det trygga kontoret och åka på det första kundmötet, och jag kan absolut erkänna att jag var nervös första gången jag gjorde det. Därför tänkte jag dela med mig av mina bästa tips på hur du hanterar konsultrollen som ny på marknaden.

Klä upp dig, klä inte ut dig

En no-brainer för de flesta – i valet mellan luvtröja och kavaj, så välj kavajen, åtminstone till första mötet. Dock så tycker jag det är viktigt att ändå vara sig själv och inte försöka klä dig som någon annan. Har du aldrig kostym tycker inte jag att det finns någon anledning att slänga på sig en sådan ”bara för att”. Inventera garderoben och hitta en kombo som du både känner dig hyfsat bekväm i och som är aningen vardagsuppklädd. Jag kör typ alltid på t-shirt med crazy tryck + bekväm tröja när jag är på vårt eget kontor, och byter till diskret t-shirt och kavaj när jag ska på kundbesök (eller kunden kommer hit).

Var en kameleont, inte en kappvändare

Som konsult behöver du kunna smälta in överallt, likt en hemlig agent läsa av arbetsplatsen, kulturen och människorna, och på nästan ingen tid alls anpassa dig till kunden du arbetar hos för tillfället. Du måste direkt komma in i jargongen och lägga ditt språk och ditt beteende på samma nivå som kunden. Det handlar om att vara flexibel till det yttersta, eftersom du som konsult kommer jobba hos massor av olika kunder, ibland i kortare och ibland i längre uppdrag. Inse detta från början och lär dig att vara lyhörd för klimatet som råder.

Men! Givetvis ska du inte känna att du bryter mot dina grundläggande värderingar. Om jag hamnade hos en kund där det förekom mobbning, diskriminering, sexuella trakasserier eller bara en jävligt taskig attityd så skulle jag inte acceptera detta. Nu har det här inte hänt mig, och jag hoppas det är ovanligt, men om det ändå skulle ske så vill jag vara stark nog att sätta ner foten och säga: det här är inte okej! Inte vara den som blundar för att det är bekvämt, tänker att ”äsch, jag är bara här X veckor, jag behöver inte bry mig”.

Var dig själv, representera ditt företag

”Var dig själv!” Ja, vem skulle jag annars vara? Ett slitet uttryck, men det ligger ändå något i det. I skrivande stund sitter jag med trasiga mjukisbyxor framför datorn, hopsjunken som en säck potatis och kliar mig på magen, och visst är jag precis lika mycket mig själv som när jag tar på mig kavajen, det är bara en annan sida av mig. Skillnaden är att när jag är hemma behöver jag inte tänka på något annat än mig själv: på jobbet, ute hos en kund, så representerar jag inte längre bara mig, utan mitt företag. Om jag missköter mig hos en kund, så är det som att hela Integrationsbolaget missköter sig, i kundens ögon. För att ta exemplet ovan, med att sätta ner foten, så skulle jag i en diskussion utanför jobbet antagligen säga något i stil med ”du är ju helt jäkla dum i huvudet”. Jag skulle inte säga samma sak vid morgonfikat hos kunden, utan välja en strategi för att få fram min åsikt på ett mer proffsigt sätt.

Skapa goda relationer och nya arbetstillfällen

De mänskliga relationerna är alltid de viktigaste, även om jobbet handlar om teknik: att skapa goda relationer till kunden är det som ger mer jobb till företaget, det är den grund vi använder för att leverera tekniska lösningar. Utan goda relationer får vi inga uppdrag. Även om du som konsult inte jobbar med sälj direkt, är det viktigt att ha med sig – hur du pratar med dina (om än tillfälliga) kollegor skapar relationen till kunden, och är den god, ja då kommer resten att flyta på. En delikat balans är förstås när det finns konsulter från andra bolag ute hos samma kund, men enligt min åsikt ska man se dessa i första hand som kollegor, och i andra hand som konkurrenter. Ingen vinner på att du ser andra konsulter som rivaler, det skapar bara dålig stämning. Även om du såklart, med goda intentioner, ska försöka göra den vassaste leveransen.

För att summera det hela: det är som att gå på lina, där du hela tiden måste avväga din person för att bete dig på ett passande sätt. Varje gång du kommer till en ny kund är det en ny lina att balansera på, och du vet inte på förhand om linan kommer vara slak eller spänd som en stålfjäder. Att känna in situationen och rätta sig efter den är en otroligt viktig egenskap som konsult, och har du koll på det innan du börjar har du halva inne.

En helt vanlig vecka som integrationskonsult

Vafalls, inget blogginlägg förra veckan? Skäms på mig! Till mitt försvar kan jag säga att jag har haft fullt upp, och jag tänkte ägna dagens inlägg till att summera veckan, så ni läsare får en inblick i hur vardagen kan se ut för en integrationskonsult.

Måndag

Vi började veckan med ett förvaltningsmöte, något vi har varje måndag. Då sitter vi i förvaltningsteamet och berättar för varandra hur veckan ser ut för oss, vilka projekt vi sitter med just nu och hur stor arbetsbelastning vi har. Det finns då möjlighet att flagga för om vi har mycket eller lite att göra, och omfördela veckans jobb om det behövs. Vi började med dessa möten i våras och de har verkligen hjälpt till att strukturera upp arbetet och gjort oss mer effektiva.

Efter mötet satte jag mig direkt framför datorn och undersökte hur en integration som vi deployade i fredags mådde, då jag var lite orolig över att något hade gått fel under helgen. För att undersöka statusen på integrationen kollade jag BizTalk och något som kallas ”tracked messages”, vilket helt enkelt är BizTalks sätt att spara all information som skickas genom plattformen. Med hjälp av detta kontrollerade jag vad som skickats från ena systemet, hur det såg ut efter BizTalks bearbetning, vad som skickades till det andra systemet, och sedan vad som skickats tillbaks, för att verifiera att allt såg ut som det skulle.Bildresultat för deploy

Jag kunde tillslut konstatera att integrationen fungerade som tänkt, förutom en liten detalj som inte upptäckts i testmiljön. Jag rapporterade detta till min kollega och han kontaktade i sin tur IT-chefen hos kunden för att få ok på att fixa detta.

Tisdag

Dagen började med att vi fick ok på att göra fixen som upptäcktes på måndagen, men innan jag hann börja med detta fick jag mail om en ticket från en annan kund. En ticket innebär helt enkelt att en kund har ett behov som vi behöver åtgärda, och det kan vara allt från allvarliga incidenter, där produktionsmiljön på något sätt störts, och vi måste agera snabbt för att återställa normalläget, till små förändringar och önskemål. Den här gången var det något mitt emellan: en av våra tjänster som genererar filer hade slutat fungerat i testmiljön, och vi behövde manuellt skapa om dessa filer.

Bildresultat för ticket

Efter att jag åtgärdat detta, var jag tvungen att förbereda mig för nästa dag, eftersom den skulle bli lite annorlunda.

Onsdag

Dagen började med att jag satte mig på tåget klockan 07:00 och begav mig till en närliggande stad för att besöka en kund. De hade gjort en lite annorlunda beställning: de ville ha hjälp med att skapa en integration, men samtidigt använda den som ett case för att deras nya BizTalkansvarige skulle lära sig mer om plattformen. Så, istället för att bara leverera en färdig integration, gjorde jag en testversion av integrationen, sedan kodade vi den tillsammans under dagen.

Bildresultat för workshop icon

Dagen gick faktiskt över förväntan, och vi kom längre än jag trodde med integrationsarbetet. Vi hade en koppling mot en databas, som var lite småbesvärlig att få till, och sedan skulle integrationen skicka information från databasen via mail och sms, och fick till hela flödet under vår workshopsession, även om det inte blev helt klart.

Torsdag

På torsdagen var jag återigen tillbaks på kontoret och det blev en dag där jag gjorde lite av varje:

  • Fixade en incident där ett system saknade filer som skulle ha kommit in under natten
  • Undersökte vad som kan hända med en SQL Server om man byter tidszon på servern
  • Skapade en ny version av ett schema som används i flera av våra integrationer
  • Grejade med ett databasskript då vi behövde byta ut primärnyckeln i en databas

På eftermiddagen hade jag ett möte med HR-Therése, där hon informerade mig om hur det är att vara skyddsombud, ett ansvar jag precis axlat. Vi gjorde också en skyddsrond, vilket gick bra – inga större risker identifierade! Skapade även en ny mailsignatur för rollen som skyddsombud, och den blev jäkligt snygg om jag får säga det själv!

superman

Fredag

När jag vaknade på morgonen undrade jag vart veckan tagit vägen – redan fredag! På förmiddagen utnyttjade jag en av våra bästa jobbförmåner, nämligen att få massage. Otroligt gött, och SÅ lyxigt! Resten av dagen ägnade jag åt att göra den där fixen som upptäcktes på måndagen, vilket var aningen trixigt – men det löste sig till slut och jag kände mig nöjd med arbetsveckan när kollegan Douglas drog igång fredagslåten på eftermiddagen.

Bildresultat för weekend meme

I skrivande stund är det snart fredag igen, och jag ställer mig samma fråga som förra veckan – vart tog måndag till torsdag vägen? Tiden går fort när man har ett roligt jobb!

 

Ta ett steg tillbaks

Igår jobbade jag med en integration där jag hade följande scenario:

  1. En lagrad procedur i SQL Server levererar data till BizTalk
  2. BizTalk tar emot datan som XML via SQL adaptern och debatchar den, dvs. bryter ner datan i olika meddelanden
  3. Baserat på properties i meddelandet olika saker hända i en orkestrering

Jag började med att skapa ett schema för meddelandet i BizTalk, men fick genast problem med att få proceduren att leverera data enligt schemat. Jag testade alla möjliga varianter, men kom ingenstans. Det kändes ungefär som att dunka huvudet mot en betongvägg på olika ställen för att se om den skulle ge vika. Det gjorde den inte.

Till slut gav jag upp och lämnade datorn. Vilket såklart var det bästa jag kunde göra. Lite distans till skärmen och diskussion med kollegor gav mig en ny vinkling på problemet: jag ska såklart inte försöka tvinga in data från SQL i en struktur som jag skapat i BizTalk, utan låta SQL definiera schemat för den data som ska skickas. Jag tog då bort det gamla schemat och genererade ett nytt baserat på proceduren, vilket fungerade fint, och med hjälp av den här guiden lyckades jag få till hela flödet.

Jaha, och vad vill jag säga med detta?

Jo, jag vill påminna er (och kanske framförallt mig själv) om vad en bör göra när en kört fast i ett problem, nämligen att ta ett steg tillbaks. Lämna datorn, ta en promenad, gör något annat en stund. Du får då distans till problemet och kan se bortom det där hörnet som du har målat in dig i. Jag tycker det här gäller alla typer av problem, men det är extra tydligt när det gäller systemutveckling och integration. Ofta fastnar man i fel angreppssätt, som jag gjorde, och inser att problemet inte bör, eller ens kan, lösas på det sätt en tänkt från början, men att det inte alls är lika svårt från en annan infallsvinkel.

Bildresultat för step back

Vad är det bästa med att jobba som integrationskonsult?

Jag har skrivit ett par inlägg om de mer besvärliga delarna i jobbet, som tidsuppskattning och kravhantering, så nu känner jag att det är dags för något mer positivt! Därför har jag knåpat ihop en lista med de topp fem största fördelarna med att jobba som IT-konsult. En del av dessa är generella för jobbet som IT-konsult, andra är mer specifika för just systemintegration och Integrationsbolaget. Enjoy!

5. Lönen

Nej, pengar gör inte en inte lycklig. Men jag kan lova att bristen på pengar gör en olycklig som fasen. Relationen mellan lycka och inkomst ser ut ungefär såhär:

Bildkälla

När vi bara har precis så vi klarar oss är vi inte tillfreds, men pengar i överflöd är inte heller nyckeln till ett bekymmersfritt liv. En stor fördel med yrket som IT-konsult är att löneläget är riktigt bra, och jag skulle säga att min ingångslön ligger ungefär i början på komfortzonen. Om några år tror jag att jag kommer närma mig lyxsektorn, även om det såklart är en definitionsfråga. Kanske kommer jag anse att jag fortfarande ligger i komfortzonen då på grund av ökade utgifter…

4. Variationen

Seriöst – den här veckan har jag jobbat med SQL (oftast trevligt), C# (välbekant), PowerShell (mysigt), bat-skript (kallt, hårt och kort), kryptering (sjukt intressant), BizTalk (nya polaren), WCF (äntligen börjar jag fatta!) och WebSphere MQ (va?). Massor av skilda tekniker, där jag känner att jag behärskar en del av dem, samtidigt som andra är helt nya, och jag tror det är få jobb som kan matcha den här variationen i arbetsuppgifter.

568a3553a0d3ed3657475829471cf07d-networking-technology-iconsTill viss del är det här ganska generellt för IT-konsulter, eftersom branschen helt enkelt är så bred, men det är nog speciellt sant för jobbet som integrationskonsult. Nu har jag ju bara jobbat som just det i  den här branschen, så rätta mig gärna om ni tycker jag har fel, men jag tror att som ”vanlig” IT-konsult blir du betydligt mer nischad, och arbetsuppgifterna är inte lika mångsidiga.

(En parentes här till den som funderar på att börja jobba som IT-konsult är att inte vara rädd för ordet förvaltning! Jag tyckte själv att det lät vansinnigt tråkigt när jag pluggande, men nu sitter jag som en del i en förvaltningsorganisation, och det är faktiskt här det finns mest variation! Fast nu när jag tänker efter gäller det här nog mest integrationsförvaltning, variationen blir säkert mindre när man förvaltar ett specifikt system. Å andra sidan finns det kanske chans att bli riktigt vass på det systemet och göra sig oumbärlig i företaget…)

3. Förmånerna

Det här är förstås väldigt olika beroende på vart du jobbar, men mitt intryck är att som IT-konsult har du ofta bra förmåner på arbetsplatsen. Kompetensen inom systemutveckling är eftertraktad, och företagen måste göra sig själva attraktiva för att locka till sig (och behålla) anställda.

benefits square icon for web-larger

Jag är väldigt nöjd med de förmåner som jag har här på Integrationsbolaget. Det bästa är nog att få gymkortet betalt, och att vi har möjlighet att få massage på arbetstid. Jag kan dessutom använda min jobbtelefon som min privata, och slipper därmed räkningen för mobilabonnemanget varje månad, samt en bra pensionsavsättning. Vi har också möjlighet att leasa bil via företaget, något jag tycker är väldigt smidigt eftersom alla kostnader dras direkt på lönen.

2. Utvecklingen

Det här med att utvecklas på jobbet kan vara svårt inom vissa yrkesroller. Ofta kräver det att man byter arbetsplats, eller roll inom företaget, vilket kan vara tufft att få till, och det kräver en del förändring. Som IT-konsult har jag förändring varje dag, och även om jag är kvar på samma arbetsplats så finns möjligheten att växa och förändras hela tiden där, speciellt i början på karriären.

progress-report_318-35789

Jag känner att jag har utvecklats väldigt mycket sedan jag började här på Integrationsbolaget, mest vad det gäller mitt kunnande teknikmässigt, men också när det gäller konsultrollen. Det går aldrig att bli fullärd i det här yrket, vilket kan vara en frustrerande tanke, men det garanterar också för att du hela tiden kan utvecklas och bli bättre.

1. Friheten!

Det som toppar min lista på fördelar med konsultrollen är friheten i jobbet, och hur lyxigt det är att ha kontroll över sin egen tid. Jag har ju tidigare jobbat som undersköterska, och skillnaderna är enorma. Om du som uska jobbar ett pass mellan 07 – 14, då måste du jobba exakt de timmarna, och (åtminstone om du jobbar i hemtjänsten) så är din dag planerad minut för minut, och du har små möjligheter att ändra detta. Flextid och kompledighet är moderna myter som du hört talas om men aldrig praktiserat.

I jobbet som IT-konsult så är dessa fenomen inte längre myter, utan en del av arbetsdagen. Jag älskar att kunna träna på lunchen, och om det drar ut på tiden så stannar jag bara lite längre på eftermiddagen, eller att kunna jobba senare en dag för att gå tidigare en annan. Möjligheten att jobba från vilken plats som helst så länge jag har min dator och internetuppkoppling är också fantastisk, även om jag är bekväm av mig och helst sitter på kontoret med mina två skärmar och mitt sköna tangentbord. Men bara att möjligheten finns är otroligt upplyftande!

a0278d6ebd9591c39e398b65ed9c5dd9d7d6ea7686578f1088d41908c6b92ca4

För mig, som tidigare varit van vid att någon annan planerar min dag i detalj, så uppskattar jag det här otroligt mycket. Visst blir det svårare om du klättrar i yrkesrollen och får större ansvar, vilket alltid brukar innebära fler möten = fler tider att passa, men förhoppningsvis kan du styra tiderna på dessa, åtminstone till viss del. Och även om det bara handlar om halvtimmar hit eller dit, så har du en känsla av frihet och kontroll över din arbetstid, vilket tror jag är en av de starkaste grundpelarna för att vara tillfreds med jobbet.

 

Det svåra med kravhantering

Jag har ju tidigare skrivit om att det är jäkligt svårt att tidsuppskatta arbetsuppgifter när det gäller IT, och ytterligare ett problem som relaterar till detta är att hantera de krav som finns på den lösning som ska byggas. Till skillnad från  tidsuppskattningen är det här något som faktiskt tas upp i informatikutbildningen, så har du läst systemvetenskapliga programmet är du antagligen medveten om problematiken.

dilbertProblematiken simuleras i åtminstone en kurs där lärare agerar ”kunder” som plötsligt ändrar sig under ett projekt, och jag minns att många studenter blev irriterade på detta. I skolan är man inte van att nya saker dyker upp mitt under ett projekt, allt brukar (och ska enligt regler kring betygssättning) vara specificerat från början, så studenten vet exakt vad som förväntas. I yrkeslivet är läget dock ett annat, vilket lärarna i informatik gör sitt bästa för att förbereda studenterna på.

Jag tycker att de gör ett bra jobb med detta, men det är ändå otroligt stor skillnad att vara med om det i verkligheten. Problemet med att nya krav dyker upp från kunden är dock inte så stort för mig, eftersom jag mest jobbar med mindre, ganska avgränsade uppgifter som redan definierats. Det största bekymret för mig är snarare att förstå de krav som redan finns. För det mesta går processen till såhär:

  1. Jag får en uppgift, ofta specificerad via mail
  2. Jag tänker: jag fattar. Det här fixar jag direkt.
  3. Jag startar Visual Studio, BizTalk eller vad det nu kan vara för programvara som krävs
  4. Och tänker: men vänta här nu. Vad exakt är det som ska hända här egentligen?

Det som verkar så lättfattligt i mailet blir plötsligt betydligt mer oklart när jag ska börja skriva koden, och jag måste ofta gå tillbaks och ställa mer frågor för att kunna lösa uppgiften. Ju mer detaljer jag grottar ner mig i, desto fler blir frågetecknen och ofta visar sig uppgiften vara betydligt större och mer komplicerad än jag trott från början.

Varför är detta så svårt egentligen?

Jag har en teori och det är att IT är så otroligt abstrakt, både för den som ska använda lösningen, men också för den som ska programmera, innan denne har verkligen börjat koda. Ska man bygga en bro är det betydligt enklare: vi ska från punkt A till punkt B och eventuella problem längs vägen är betydligt lättare att förutse. Alla kan direkt se att en promenadbro över en liten bäck kommer vara betydligt enklare än en bro för biltrafik över en stor älv.

1tower-bridge

I IT är det inte lika enkelt: det som från början kan se ut som en promenadbro visar sig vara en klaffbro över ett vattendrag med båttrafik när kraven börjar analyseras. Det som från utsidan, och kanske främst från en användares sida, ser enkelt ut, är bara toppen på ett isberg av kod och komplexa beroenden, som ofta är svåra att förutse. Och framför allt: ingen skulle föreslå att man skulle bygga över Mälaren på ett par veckor, men inom IT händer det ständigt.

Jag har själv försökt mig på det – jag trodde att jag skulle kunna bygga en hemsida med ett eget CMS på några veckor, utan att inse de många timmar som ligger bakom ett administratörsgränssnitt som ex. WordPress. För att göra en lång historia kort: det gick inte alls. Det blev bara en hemsida och administratören fick administrera i HTML istället… Här har vi ett praktexempel på när en inte tillräckligt tydlig kravbild totalt pajar den tidsuppskattning som gjorts, och jag hade egentligen två val: öka tiden eller minska på kraven, och jag valde det senare.

Men, precis som med tidsuppskattning så går det att bli bättre på det här också! Ju mer man jobbar med en viss typ av lösningar, desto mer förförståelse får man för de olika delar som kan bli besvärliga, och man lär sig också att ställa mer och bättre frågor kring vad som ska göras. Man ser helt enkelt tydligare om det är en liten träbro eller en järnvägsbro som ska byggas, och kan anpassa jobbet därefter.

Nu har klockan slagit fem denna fredag, och jag lämnar er med den här klassiska bilden kring kravhantering. Det är möjligt att den är en sliten klyscha i sammanhanget, men den illustrerar ändå problematiken väldigt bra.

business-requirements-management

Trevlig helg på er!

Varför är det så in i h… svårt att estimera?

Det finns saker som en önskar att de lärde ut på universitetet, och sedan finns det saker som en inser är omöjliga att lära ut. En av de senare sakerna är estimering, alltså att uppskatta hur lång tid en viss uppgift ska ta. Det kan vara allt från ett stort projekt, till en liten ändring i en kodsnutt någonstans. Oavsett vad det gäller så finns det en sak en lär sig som ny IT-konsult: det är svårt att estimera.

Det är inte bara svårt: det är riktigt svordomssvårt! Jag har gjort en del estimat hittills och vad dessa har gemensamt är: de är felaktiga. Och då menar jag way, waaaay off. Som tur är har jag kollegor som jag kan bolla med och som har styrt in mig i rätt riktning, men även de som är rutinerade håller med om att estimat är bland det svåraste som IT-konsult.

Svårast är det dock när man är ny, och jag har här listat ett gäng tips för att motverka några av de nybörjarmisstag som jag har gjort (och för all del, fortfarande gör):

  • Det är inte bara kodandet som ska estimeras. Du har garanterat inte hela bilden klar för dig, och du kommer behöva tid för att diskutera kraven med kunden, troligtvis genom möten och/eller mail. Detta tar tid. Mer tid än du tror.
  • När du har en lokal version klar, kommer du behöva tid för att deploya din kod i testmiljön, verifiera att den fungerar och sedan installera den i produktion. Beroende på hur miljön ser ut är det här mer eller mindre komplext, så se till att du har koll på den processen och lägger in tid för den i estimatet.
  • Ge inte ett fast estimat utan ha ett intervall av timmar, där den minsta änden är ”om allt går perfekt” och den större ”om det krånglar ordentligt”. Du har större chans att pricka intervallet än att klara ett fast tak.
  • Och det absolut viktigaste för dig som nybörjare: Bolla med dina kollegor innan du ger ett estimat till kunden. De kommer garanterat ställa frågor som visar på aspekter som du inte har tänkt på tidigare, visa på sådant som kan återanvändas från tidigare kod och potentiella risker.

När du tagit de här faktorerna i beräkning så vet du hur lång tid uppgiften kommer ta, och har ett korrekt estimat, right?

Kanske – men tänk på att ett estimat är bara en uppskattning, nya problem kan dyka upp längs vägen och göra uppgiften större än den verkade från början. Då gäller det att se estimatet för vad det är, en uppskattning och inte en deadline. Håll huvudet kallt och rusa inte på i panik för att hinna klart ändå – ta ett steg tillbaks och fundera: hur påverkar det här problemet mitt estimat? Om det gör att du behöver mer tid för uppgiften, flagga då för det direkt och ge kunden en möjlighet att avbryta arbetet.

Med alla dessa problem – är det då ens möjligt att bli bättre på att estimera?

Ja! Det absolut viktigaste är att lära sig av sina misstag: håll koll på dina estimat och bokför sedan hur lång tid det egentligen tog. I takt med att du blir bättre på att programmera och estimera, så kommer estimaten till slut att åtminstone börja närma sig verkligheten.

Bildkälla

Och kom ihåg: var optimist i livet när det gäller allt annat än tidsuppskattning.

 

 

Felsökning med hjälp av en badanka?

Ärligt talat, jag hade aldrig hört talas om uttrycket ”rubber duck debugging” innan jag läste det här inlägget på bloggen Coding Horror för några veckor sedan. Och jag måste säga att jag är ganska frälst i konceptet!

index

Bildkälla

Så vad är då ”rubber duck debugging”?

Idén kommer från boken The pragmatic programmer, och grundtanken är att när du har problem med din kod, så räcker det inte med att sitta och stirra på skärmen och tänka på problemet; det måste formuleras högt. Processen med ankan brukar beskrivas ungefär såhär:

  1. Köp, sno eller låna en badanka och placera ankan bredvid din skärm.
  2. Berätta för ankan om grundproblemet du försöker lösa och vad du vill uppnå.
  3. Gå sedan igenom din kod och berätta för ankan hur du försökt lösa problemet, och förklara rad för rad vad koden gör.
  4. Inse något av följande:
    1. Du hittar felet i koden, eller
    2. Felet ligger inte alls där du trodde, eller
    3. Din kod försöker inte alls lösa det problem du tänkt att den ska göra
  5. Tacka ankan för hjälpen och ändra koden.

Jag tycker det här är en klockren idé, och efter jag hörde talas om metoden har jag tänkt tillbaks på tillfällen då jag skulle ha behövt en badanka till hjälp!

Bildkälla

Jag tyckte det här fenomenet är extremt tydligt under skoltiden: när vi hade handledning räckte det ibland med att förklara för handledaren vad jag behövde hjälp med, för att komma på lösningen själv. Andra gånger var situationen omvänd: jag var handledare och satt bredvid en uppgiven student som suckar: ”Ingenting funkar! Jag blir tokig!”. Nej, då blir det inte lätt för mig att hjälpa dig. Förklara istället för mig vad du försöker göra och exakt vad som inte fungerar.

keep-calm-and-start-debugging-8

Det har även hänt mig nu när jag jobbar, och jag minns för några veckor sedan när jag behövde hjälp att förstå en grej, så jag ringde till en person som hade koll på detta, men under samtalet fick jag motfrågan: ”vad är det exakt du vill veta?”. Och jag insåg att fasen, jag visste inte riktigt vad jag ville veta! I mitt huvud trodde jag att jag hade formulerat mig klart och tydligt, men egentligen var själva grunden för frågan otydlig för mig. Då hade jag behövt en anka att prata med först!

Tanken slog mig igen igår: jag skulle skicka ut en fil till en mapp genom en integration, och det hände absolut ingenting. En superenkel grej, men ändå funkade den inte. Jag stirrade på skärmen och försökte på flera olika sätt, tänkte att vafasen, det här ska inte vara svårt! Till slut ringde jag en kollega och bad om hjälp, och när jag försökte förklara problemet för honom så förstod inte han heller vad problemet var. Han gav lite tips att testa, men när jag lade på luren så slog det uppenbara mig: felet ligger inte i den här enkla grejen. Det är något som går fel innan, vilket gör att exekveringen aldrig når den här punkten och försöker skicka ut filen – det finns ingen fil att skicka ut.

Nu ska jag forska i en incident som precis kom in, därefter drar vi till Stockholm för sommarfest med hela bolaget. Önskar er alla en trevlig fredag!

Integratören == Spindelmannen

God förmiddag!

Kommer ni ihåg att jag skrev att jag hade ett möte med folk från Finland, Indien, Tyskland och Ryssland för ett tag sedan? Då diskuterade vi en integration mellan företagets HR-system, där användaren knappar in data om anställda, och Active Directory, där datan lagras. Jag har utvecklat den här integrationen och implementerat den i testmiljön, så nu sitter jag i ett möte där flödet ska testas från början till slut. Eller möte är egentligen fel ord – vi har en testsession på ca 4h, där någon från varje ansvarsområde är tillgänglig.

Det är väldigt spännande, även om det såklart dyker upp nya problem som vi inte förutspådde innan. Det är ju anledningen till testerna, och jag tror att det är väldigt få IT-lösningar som fungerar perfekt på en gång. Hursomhelst, jag fick en ganska skum känsla när vi började testerna: jag kände mig helt plötsligt jäkligt viktig. Inte så att jag går runt och känner mig försumbar i vanliga fall, men i det här scenariot tyckte jag det blev extra tydligt att integrationen är hjärtat i det dataflöde vi vill skapa, och jag som integratör är en Very Important Person.

Visst, det här är min subjektiva åsikt, och de flesta tycker säkert ens egna område är det viktigaste. Typ som lärare i skolan: nå, det är väl bra att det finns andra ämnen, men det är just mitt ämne som du faktiskt behöver kunna. Men jag tycker ändå jag har en poäng här: utan integrationen kan inte systemen kommunicera med varandra, och då finns det liksom inget flöde, oavsett hur bra övriga system funkar. Integratören är också den som måste ha koll på hur de olika systemen kommunicerar: vilken typ av data skickar HR-systemet ut? Vad är det egentligen AD vill ha för att kunna lagra information om anställda? Vilka konverteringar behöver vi göra? Hur ska responset se ut? För att använda ett slitet uttryck: integratören är spindeln i nätet här. Som den här snubben.

spider-man

Typ.

Uttrycket är klyschigt, men det stämmer. Precis som vi skriver på vår infosida om att driva integrationsprojekt: ”Det är ofta en stor utmaning då [integrations-]projekten av naturen kräver kommunikation mellan fler parter (som ofta inte befinner sig på samma plats). Integratörens roll får alltid inslag av projektledning och kravställning eftersom man nästan alltid får en väldigt central roll i projektorganisationen.”

Nu ska jag inte gå så långt som att säga att jag varit inblandad i projektledningen i det här fallet, eftersom jag bara haft ansvar för just den här integrationen, men jag ser ändå utmaningarna. Som till exempel i den här testsessionen, då vi är folk från totalt sex länder i olika tidszoner. Visst är det lite svettigt med första testet av något jag har byggt, men jag tycker coolhetsfaktorn väger över. Här sitter jag och är internationell liksom!

Myter om jobbet som IT-konsult

Finns det myter om IT-konsulter? Jag hade ett par förutfattade meningar kring yrket innan jag började, och för att få ytterligare kött på benen ställde jag frågan i facebookforumet ”Kodapor OT” – stort tack till er som svarade! Detta är ett ihopkok av mina tankar och svaren jag fick där, och mina åsikter kring huruvida stereotyperna stämmer.

1. Vi är antisociala killar som gillar Joltcola

Ungefär som Dennis Nedry i Jurassic Park, han som kodat hela parkens IT-system alldeles själv och ser ut såhär:

thumbnailImage

Jag tror att alla rent logiskt fattar att det här inte längre stämmer: du behöver inte vara en lonely gamer som sitter i en källare och spelar WOW hela nätterna för att vara bra på programmering/IT. MEN. Det är fortfarande underskott på kvinnor i branschen och även om utvecklingen går framåt så tar det tid att bryta mansdominansen i yrket. Jag försöker dra mitt strå till stacken genom den här bloggen, där jag vill visa att du inte behöver tillhöra Dennis Nedry-normen för att jobba som IT-konsult.

2. Vi är gifta med våra jobb

Vi som jobbar med programmering/systemutveckling har det som ett kall och något vi gärna gör gratis på fritiden. Du förväntas kunna visa upp egna, spännande projekt som du skapat utanför studier/jobbet, för att bevisa att du inte bara är bra på ditt jobb – du är ett med jobbet, det är ditt jag och din identitet.

Den här är svår, och en av de största förutfattade meningarna jag hade innan jag började jobba, vilket jag nämnt tidigare.

Åh ena sidan: ett jobb är bara ett jobb, och det är faktiskt helt okej att ägna fritiden åt andra saker än programmering. En av de saker som jag hoppas jag har fått fram i den här bloggen är att du inte behöver vara underbarn som monterade datorer vid 3 års ålder för att vara en bra IT-konsult.

Åh andra sidan så kräver jobbet otroligt engagemang i hjärnan, det går inte att programmera och tänka på annat samtidigt. (Åtminstone kan inte jag det…) Det kräver dedikation och en vilja att lösa problem, ett sug efter att leverera lösningar, och den här dedikationen har en tendens att sprida sig utöver de där timmarna mellan åtta och fem. Risken är stor att om du är gift med något annat än jobbet, så kommer jobbet vara ett rätt så krävande vänsterprassel.

Här har jag dock en teori: det är lätt att gifta sig med jobbet, när allt som krävs är en dator och internetuppkoppling. Människor kan garanterat känna samma dedikation i alla yrken, men det är inte lika lätt att leva ut när jobbet kräver aktioner på plats. Till exempel: en undersköterska som stannar kvar efter sitt pass ses som konstig, men den IT-konsult som gör samma sak, det är bara vardag.

3. Vi kan allt.

När jag ställde frågan på facebookforumet om vilka fördomar folk upplevt som kodapor var första kommentaren detta:

Vad jobbar du med då?
 - Jag är programmerare.
 a) Jaha, kan du göra en hemsida åt mig?
 b) Du, min dator är långsam, kan du titta på den?

Med andra ord: många tror att vi kan när det gäller datorer, vare sig det gäller att göra grafik till en hemsida eller en trasig dator.

IT är ett väldigt, väldigt, väldigt stort ämne och för att bli riktigt bra behöver du välja ett område att bli bra inom, annars finns det helt enkelt inte tillräckligt med livstid för att lära sig allt. Dock så blir jag ständigt imponerad över de olika gurus som finns därute och som har samlat på sig så otroligt mycket kunskap kring olika aspekter av vårt jobb – en eloge till er!

4. Vi kan ingenting

Ytterligare en myt är motsatsen till ovanstående, nämligen illusionen av att det vi gör är jättelätt och inget som kräver någon direkt ansträngning. Citat från facebooktråden i Kodapor OT: ”Fan vad skönt att vara programmerare, då kan man bara sitta i en stol vid datorn hela dagen och dricka kaffe istället för att slita och vara stressad på ett riktigt jobb.”

Min fördom kring folk som har den här fördomen är att de har en liten inblick i kodning och hur det fungerar. De kanske har skrivit ett par rader i något programspråk, men har ingen djupare insikt om vilka problem som dyker upp, vilket leder till att de tror att allt är enkelt löst med en if-sats. Ytterligare en situation när den här mentaliteten dyker upp är vid prototypvisningar: för den som tittar ser det ut som att produkten är färdig, men egentligen är den bara ett tomt skal, och de inser inte att det är betydligt svårare att implementera animationer och snygga flöden i kod än att rita upp det i Photoshop.

Sanningen ligger någonstans mittemellan: ja, det är komplext och ingen barnlek att implementera en idé i kod, men det är samtidigt inte magi, och låt inte den här komplexiteten skrämma bort dig. Jag tror att alla som är motiverade till det kan lära sig koda, och när den första tröskeln är överstigen så kommer det kännas lättare. Det svåra är inte att skriva koden utan att veta vad som ska skrivas.

5. Vi hoppar på vilket projekt som helst

Det här är lite sammankopplat med illusionen om att programmering är ett kall som vi gärna gör gratis på fritiden, och jag tycker nedanstående bild illustrerar det här väldigt bra:

13083260_10153542473356981_2475047108041777606_n

Detta har nog hänt många programmerare, och som en i Kodapor OT formulerade det: ”- Du jag har en unik app/spel/webbsideidé som du kan hjälpa mig med! (jag berättar vad jag vill ha och du gör det faktiska jobbet.)” Gärna utan betalt, med motiveringen att ”det är ju något att sätta på CV-t” och att det är idén som är värd något, inte implementationen. Det hänger också ihop med illusionen om att programmering är enkelt. Och visst, att skriva en funktion som tar en en sak och returnerar en annan är enkelt, men det är vägen från ”jag vill ha en app som gör x och y” till enskilda klasser, attribut och funktioner som är det svåra, vilket jag tror många underskattar.

Bubblare

Det verkar också finnas en del myter från andra yrkesroller i branschen, så vi tar ett gäng bubblare också:

  • Att en kodare bara kan koda och inget annat
  • Att kodare bara ska koda och ingenting annat
  • Att konsulter tar överpris och har sjukligt höga löner, helt i onödan
  • Vi har ju nästan byggt ett sånt system, vi kan väl utgå från det och bara ändra lite, det är väl redan modultänk så det är lätt att lägga till och ändra moduler? Så sparar vi tid.
  • Att det är möjligt att följa exakt samma kodstandarder som i tidigare projekt, även om det är i olika språk
  • Att man vill hjälpa alla med deras datamaskin
  • Missuppfattningen att vi bygger bilen när vi i själva verket bygger ritningen till bilen. Datorn bygger bilen (maskinkoden) utifrån ritningen (källkoden).
  • Att man förväntas vara expert på allt som alla avdelningar jobbar och pratar om bara för att det råkar visas på deras skärm
  • Att teknisk skuld är detsamma som buggar.

För att summera: det finns en jäkla massa fördomar och myter kring det här jobbet! Och då har jag ändå begränsat mig i urvalet från svaren i facebookgruppen. Vad tycker du? Har du myter att krossa eller bekräfta? Lämna en kommentar!

 

Distans och skype

När jag pluggade så visste jag ju att mycket arbete sker i team som inte sitter geografiskt tillsammans, men jag tror inte jag anade vidden av det förrän jag började jobba. Idag har jag till exempel ett möte med folk från Finland, Indien, Tyskland och Ryssland (!!!).

Det som gör det möjligt för oss att ha sådana här möten, med folk från flera länder, är såklart tekniken. Skype är det som används mest, enligt min uppfattning, och när allt funkar så är det riktigt bra! Även om nedanstående graf stämmer in på väldigt många möten – tekniken har en tendens att strula när både ljud och bild ska synka, och ofta tar det en stund att komma igång…

skype

Vi använder dock inte Skype bara till möten, utan även som internkommunikation. Jag tycker det är grymt bra, då kan man kontakta alla kollegor snabbt och det syns direkt om någon inte vill bli störd eller sitter i möte. Såhär ser (en del av) min skypelista ut i skrivande stund:

 

Capture

För de som inte är online ser man hur länge de varit borta, och de flesta lägger till information om vart de befinner sig någonstans så det blir lätt att hålla koll på kollegorna.

Oftast använder vi snabbmeddelanden och skriver till varandra, men det är också möjligt att ringa videosamtal via skype. När någon ringer ser det ut såhär:

Capture

Eller ja, det ser ut såhär som Douglas ringer, men ni förstår vad jag menar – det dyker upp en ruta som det står att personen ringer dig. I början förstod jag inte det här, utan trodde att personen skrev ”ringer dig” i ett snabbmeddelande, så jag tänkte ”okej, ja gör det du!” och sen klickade jag på ignore och funderade på varför personen aldrig ringde…

Min dag i bilder.

Idag har jag jobbat hemma, för jag kände att en förkylning var på G. Jag tror att en jobbdag i pyjamas, i kombination med ingefärste och honung, motade bort den ganska effektivt, för nu känner jag mig helt okej! Förutom segheten som kommer av att sitta framför datorn hemma i pyjamas en hel dag då, utan längre promenader än de där fem metrarna in till köket…

Hursomhelst, jag har läst på andra bloggar att temat *min dag i bilder* är rätt populärt, och vem är jag att ifrågasätta andra bloggare?

Så, varsågoda: Min dag i bilder!

Började dagen med att koppla in hemmaskärmen, musen, tangentbordet och jobbdatorn i en liten dockningsstation jag hittade här hemma. Drack en kopp kaffe och kände lyxen i att kunna jobba hemifrån med en rejäl skärm. Lyckan varade dock inte länge, för när jag gick in på den virtuella maskin som jag utvecklar på just nu, så betedde sig allt helt vrickat.

image

Musen klickade liksom tio cm till höger och fem cm ovanför punkten som jag klickade på. Jag blev lite irriterad, men hade fortfarande hoppet kvar. Jag gjorde det alla gör (eller borde göra) vid datorproblem: jag startade om skiten.

72efeacfed77482640cb25816631daa3

Och igen. Och igen. Och… ja ni fattar. Jag gjorde några omstarter. Fortfarande samma fel. Testade att koppla in musen direkt i datorn. Ingen skillnad.

3b4

Funderade lite. Klickade runt lite random på olika ställen. Råkade klicka fel.

1709375

Fick lite panik. Ångrade både val av yrke och VM.

add

Gav upp totalt en stund, och bara stirrade på skärmen.

Då kom insikten:

avpzphd

Jag googlade mitt problem. Insåg att jag inte var ensam om det. Det handlade om att den virtuella maskinen inte hade samma storleksinställningar på skärmen som min ”riktiga” dator, därav offset i klick med musen. Blev jätteglad. Kollade inställningarna och insåg att de visst hade samma. Åkte ner i det mörka hålet igen.

Funny-facepalm-meme-computer

Insåg att det kan kanske var den där gamla dockningsstationens fel och provade att koppla in datorn direkt i skärmen. Då kunde jag se att storleksinställningarna skilde sig åt och när jag fixade detta funkade allt som det skulle igen. Gav givetvis datorn långfingret först, sedan kom den där glädjen av att ha löst ett problem, och jag avslutade dagen ungefär såhär:

images

(PS! Till min chef: nej, det tog inte precis hela dagen – jag hann jobba lite också!)

Scrum 4 real!

Det finns vissa saker vi gör i skolan som man liksom vet görs ute i *verkligheten*, men som det ändå är svårt att föreställa sig nyttan med. En sån sak är daily scrums. (Vet du inte vad detta är? Läs mer till exempel här.) Alla som läst informatik på Örebro universitet är nog mycket välbekanta med begreppet, och i åtminstone en av kurserna är daily scrums en viktig del av det projekt som genomförs. Daily scrums i teorin brukar beskrivas typ såhär:

daily-scrum-meetingBildkälla

Idealbilden är ett team som står framför sin Scrum board tillsammans med Scrummastern och kort går igenom status på sprinten, samma tid varje dag. Det ska inte ta mer än en kvart, därför är det viktigt att man står upp, och fokus ska inte vara på problemlösning. De klassiska frågorna som varje medlem i teamet ska besvara brukar vara:

  • Vad gjorde du igår?
  • Vad ska du göra idag?
  • Är det något som hindrar dig från att göra det du ska?

I den informatikkurs där de här mötena ingår som en obligatorisk del, tyckte åtminstone jag det kändes ganska… krystat.

Jag agerade scrummaster och ledde våra möten, men trots att jag då försökte motivera teamet att vi måste ses varje dag klockan nio, såg jag inte direkt nyttan med det. Vi satt ju liksom tillsammans hela dagen, och jobbade med ett väl avgränsat projekt där vi hade möten med ”kunden”, dvs. läraren en gång i veckan, och det fanns inga andra distraktioner som kunde störa projektet. Vi hade helt enkelt inte så mycket att säga till varandra under den där kvarten. Men under förra veckan fick jag faktiskt vara med på ”riktiga” scrummöten i det här nya projektet vi håller på med, och ärligt talat tycker jag det är superbra!

Hur kommer det sig då, att det helt plötsligt känns väldigt vettigt att köra daily scrums? Jag har funderat lite och jag tror dessa är de viktigaste faktorerna:

Geografiskt avstånd

Alla delar av teamet sitter inte i samma rum, eller ens i samma stad, vilket skapar ett mycket större behov av att synka arbetet regelbundet och se till så alla är på rätt spår och jobbar med rätt saker. Det blir också viktigt i och med att olika delar av projektet är beroende av varandra, och man måste stämma av så att ingen del av teamet sitter och väntar på att någon annan som i sin tur kört fast.

Storleken på projektet

I skolan har de utvecklingsprojekt man gör ett litet och väldigt avgränsat scope. Det handlar om att utveckla mindre applikationer som kan existera för sig själv utan direkta kopplingar till andra system. I verkligheten är projekten ofta mycket större. Projektet som jag sitter med just nu handlar om att plocka ut funktionalitet från ett fakturasystem till ett nytt CRM-system, då fakturasystemet har byggts ut med ytterligare funktioner under en lång tid. Nu ska fakturasystemet bytas ut, vilket gör att vi måste ”rensa” det först. Integrationsbolagets roll är givetvis att ha hand om integrationerna mellan CRM-systemet och andra system, och de dagliga mötena hjälper oss att få överblick över projektet.

Storleken på teamet

Det här hänger såklart ihop med storleken på projektet: för att genomföra ett stort projekt krävs mer resurser, och vad jag vet så har vi konsulter från minst tre olika bolag, förutom de som redan finns hos kunden. Ärligt talat har jag inte koll på exakt hur många vi är – vilket bara i sig skapar ett behov av att regelbundet stämma av med alla parter så vi är på samma spår.

Störningar

I skolan kunde vi sitta hela dagarna och fokusera endast på projektet, utan att andra saker kom i vägen. I verkligheten är det dock inte lika enkelt: de flesta har andra arbetsuppgifter som ibland måste gå före, och för oss som även har förvaltningsuppdrag hos kunden, kan få incidenter som måste fixas omgående, och då måste projektet vänta. De dagliga mötena blir då till hjälp när det gäller att prioritera och kanske framför allt informera om att man har andra saker som måste göras innan en viss uppgift i projektet.

Mentaliteten

Det här är kanske den viktigaste biten: vilken attityd har teamet till mötena? I mitt fall under skoltiden hade vi inga av ovanstående faktorer som påverkade projektet, vilket gjorde att mötena kändes onödiga. Det i sin tur leder såklart till att folk inte tar dem på allvar och börjar komma försent eller helt enkelt inte bry sig. Och det är en mentalitet som jag lovar är mycket svår att vända när den väl har satt sig i skallen hos folk! I vårt nuvarande projekt blir det tvärtom: det finns faktorer som gör att dagliga avstämningar blir viktiga, folk tar mötena på allvar och detta gör dem automatiskt mer givande.

Det var mina tankar om daily scrums och hur välbehövliga de kan vara, trots att de kan kännas mer som ett nödvändigt ont i skolan. Har du några tankar om Scrum? Håller du inte med mig? Dela gärna med dig i kommentarerna, jag är nyfiken på att höra vad du tycker!

Övergödd konsult

Vi brukar inte fika så ofta på kontoret och det är sällan det står godis framme hos oss. Men när det väl kommer fram något gott, då slås det på stort. I måndags morse möttes jag av nedanstående syn:

20160307_095333Sofia, vår fantastiska administratör och alltiallo, höll på att packa typ 10 påskägg fyllda med godis till våra kunder. Och det var ju inga små ägg om en säger så! Här snackar vi mängder mätta i kilo och inte hekto. Som tur är, vilket både jag och diverse kollegor fick erfara, tejpade hon igen alla äggen till kunderna. Antagligen förstod hon vilken risk det är att förvara sådana mängder sötsaker i närheten av ett gäng gottegrisar…

Jag var rätt lättad över att de var igentejpade, då behöver jag inte kämpa emot suget utan vet att det är oåtkomligt. Men så i går visade Sofia att det fanns godis kvar i ett av skåpen! Givetvis smög jag dit och undersökte vad som fanns kvar: en kombo av gräddkola, geisha och mars-bars i tre lådor. Icke ihoptejpade… Ska ta ett kort nästa vecka och se hur mkt som försvunnit.

20160310_080340Imorse visade jag mitt godisfynd för Micke, min skrivbordskollega mittemot, som blev föga imponerad. Han visade istället det enorma ägg som vi ska ha på kontoret, som låg undangömt i ett annat skåp! Jag undersökte såklart även detta med godisexpertens öga och nedan ser ni att jag ger mitt godkännande. Notera också hur liten min hand är jämfört med ägget… Och då är det här kortet ändå taget från kortsidan av det. Hittade även varsitt ägg till oss anställda i en påse på chefens kontor*. Kommer rulla fram efter påsk…

20160310_092902Hmm, hoppas jag inte har förstört nåns överraskning nu… Vi kommer alltså få en del godis till påsk.

*OBS – inte så att jag snokade! Men vrider jag huvudet ca 120 grader åt vänster så ser jag rakt in i ena hörnet på chefens kontor, och där stod påsarna helt öppet. Vrider jag mig 180 grader ser jag hela kontoret. (Det är glasväggar..)

Börja jobba som IT-konsult

Ah, nu är jag frisk och tillbaks på jobbet, vilket innebär att bloggen är back in business! Något jag har tänkt skriva om ett bra tag är det här med att börja jobba som IT-konsult direkt efter examen. Jag har varit inne på det en del, men jag vet att jag tänkte väldigt mycket på det under utbildningen: hur kommer det kännas att börja jobba? Hur kommer det vara, rent konkret? Vad kommer folk förvänta sig av mig?

Därför tänkte jag sammanställa en liten lista som svarar på just detta. Visserligen är det här  mina specifika erfarenheter från de första månaderna på Integrationsbolaget, men jag tror mycket kan appliceras även på andra konsultbolag. Håll till godo!

Du är sämst…

Det här låter hårt, men det är bara att vara beredd på. Hur bra du än är i skolan, och hur länge du än har pluggat, så kommer du ändå att vara längst ner i näringskedjan när du börjar jobba. Du är total nybörjare och kommer behöva börja lära dig saker från grunden, mycket kommer att vara helt nytt och annorlunda mot hur det var i skolan, även om det i grunden handlar om samma plattformar och programmeringsspråk. Var beredd på att vara ödmjuk inför dina kollegors kunnande och tro inte att du kan allt bara för att du är klar med utbildningen.

…Men det är helt okej!

Ja, det är det faktiskt – man får vara nybörjare när man börjar jobba! Det här tycker jag även kännetecknar en bra arbetsplats, att de tillåter dig att vara ny och ger dig utrymme för att sätta dig in i arbetsuppgifterna. Om arbetsgivaren förväntar sig att du ska generera pengar åt dem på en gång, så kommer båda parter bli besvikna, för du kommer vara en förlustaffär första tiden. Det här kommer dock att vända snart! Du kommer lära dig massor de första veckorna, och det kommer inte dröja förrän du självständigt kan ta dig an nya uppgifter.

Mitt tips under den här första tiden är att våga fråga, men tänk på att alltid googla först. Jag tror också de flesta företag har någon typ av internkommunikation, ex Skype, vilket är toppen. Då kan du sprida frågorna bland dina kollegor på ett enkelt sätt, även om ni inte sitter på samma kontor, och du kan direkt se om någon är upptagen eller i möte.

Du kommer antagligen jobba ”inhouse” till en början

”Inhouse consulting” innebär att du sitter tillsammans med dina konsultkollegor på ert kontor, och jobbar mot kunder som sitter på andra platser. Det här sättet att arbeta är perfekt för den nyexade, eftersom du har nära till kollegorna och kan ställa alla dumma frågor i världen utan att kunden märker det. Motsatsen till inhouse heter inte ”outhouse”, som jag trodde, utan man säger oftast att du sitter ”hos kund”, och du blir då delaktig i kundens organisation på ett helt annat sätt. Vi på IB har både och: vi är några konsulter (däribland jag) som sitter på kontoret i Örebro, men större delen av styrkan är ute hos våra kunder.

Du kommer tycka det är rörigt

Du har under skoltiden lärt dig olika tekniker kring programmering och systemutvecklingsmetoder och vet vilka principer som är viktiga att följa för att ha struktur både i programkod och i ett projekt i stort. Sedan kommer du ut i ett riktigt projekt och inser att det är betydligt lättare i teorin än i praktiken, där projekten är mycket större, massor av utvecklare har varit inne och pillat på koden och nya moduler har lagts till allt eftersom. Det tar tid att lära sig hur de här stora projekten hänger ihop, men när du rättat ett par buggar kommer du snart vara varm i kläderna och inse att det finns en logik bakom det som tidigare framstått som kaos!

Du kommer få vänta…

Kanske är det här extra tydligt inom just systemintegration, där vi jobbar med många olika system, men den första veckan kommer du att få vänta på behörighet till de olika system du behöver komma åt och installation av de programvaror du behöver. Troligtvis kommer du behöva sätta upp en del projekt lokalt i en dev-miljö, och det här kan ge många dagars huvudvärk, det kan jag garantera. Men det är skönt när det är gjort!

Tidsrapportering, kundkontakt och resor

Det här är tre saker som du med största sannolikhet kommer stöta på när du jobbar som konsult. Tidsrapportering är grunden för kundens fakturering, men ibland också för din lön, så var beredd på att hålla koll på hur många timmar du lägger på varje uppgift under dagen. Kundkontakten kommer till en början troligtvis ske främst via mail och telefon, men längre fram kommer det bli en del möten, och med tanke på att många kunder sitter på annan ort så kan det bli en del resor.

Lönen då?

Det här givetvis en av de största frågorna många ställer sig, och det finns inget generellt svar här; allt beror på hur länge du har pluggat, till viss del vilka kurser du har läst, vad du jobbat med tidigare och vilka andra erfarenheter du har. Mitt bästa tips här är att gå med i ett fackförbund, till exempel Jusek, och använda deras lönesökfunktion, eller helt enkelt ringa dem och fråga.

Vaddå deploy?

I skolans värld jobbar man mycket med de små detaljerna. Det handlar om att få enskilda metoder att fungera, och att sätta ihop dem till ett program som förhoppningsvis både kompilerar och sedan fungerar som tänkt vid körning. Jag minns när vi gjorde vårt allra första projekt i Java och hur stora problem det blev med de hårdkodade sökvägarna till databasen och hjälpfilerna i programmet. Vid inlämning skulle programmet zippas ihop och skickas till lärare och opponenter, och i åtta fall av tio fungerade det inte att köra på någon annan dator, vilket var frustrerande för alla parter.

I det skedet av utbildningen var det ingen lärare som pratade om det (antagligen för att inte överhetta våra redan kokande hjärnor) men det här var egentligen den första, lilla erfarenheten som vi hade av det som kallas deploy. Jag har försökt leta efter ett bra svenskt ord för det, men jag hittar inget klockrent. Enligt google translate är sprida, gruppera eller ”utveckla på bred front” lämpliga översättningar men om man ser till engelska definitioner av begreppet så säger Merriam-Webster att deploy är ”to organize and send out (people or things) to be used for a particular purpose”. Produktionssättning eller driftsättning är svenska ord som kommer rätt nära, men de täcker inte riktigt in hela begreppet. Det behöver inte handla om att lägga in något i produktionsmiljö, eller göra stora förändringar, utan deploy kan även handla om små saker eller förändringar som ska implementeras i en ny miljö. Uttrycket har även blivit försvenskat och vi pratar om att ”deploya” kod eller att den här ”deployen” inte gick som den skulle

Varför sitter jag och funderar på det här med deploy då? Jo, jag ska nämligen deploya en del kodändringar i en integration som jag utvecklat lokalt till vår testmiljö – och det är inte helt enkelt! Att deploya till test är visserligen inte lika kritiskt som att göra det i produktion, men man vill ändå inte störa dataflödet och definitivt inte deploya något som visar sig inte funka.

Vad är viktigt att tänka på när det gäller en deploy?

Tja, det beror såklart helt på hur processen ser ut. I mitt fall handlar det om att uppdatera dll-er som ligger på testservern med de nya versionerna som jag har byggt ihop lokalt, men oavsett hur det ska göras är nyckelordet alltid: backup. Vi har en metod som vi använder för detta:

  1. Se till att det finns en dedikerad backup-mapp på servern
  2. Skapa en ny folder i den med dagens datum
  3. Inuti den nya foldern skapar du ytterligare två mappar, en som heter IN och en som heter OUT.
  4. I IN-mappen lägger du in de nya ändringarna som du gjort, och i OUT-mappen lägger du en kopia på den befintliga, fungerande miljön.

Sen är det bara att lägga in ändringarna i testmiljön, och om något går snett så kan man göra en rollback genom den backup man har i OUT-mappen.

 

Nej, jag har inte dött!

Nu drog ni en lättnadens suck, eller hur? Jag förstår att ni har varit oroliga över att jag inte skrivit på över en vecka, men ni kan vara lugna! Jag har inte dött, jag har bara haft väldigt mycket att göra. Det har ramlat in lite incidenter som jag varit med och löst, och allt annat arbete har helt enkelt fått vänta, inklusive bloggen.

Jag hann dock vara med på kommunfullmäktiges sammanträde i onsdags, och anledningen kan ni se i den suddiga bilden nedan. Rickard (som jag pluggade mastern med) och jag skrev vår masteruppsats om hemvårdens mobila planeringssystem och fick ett trevligt stipendium från Örebro kommun för detta. Det tackar vi för!

20160127_184139

Tyvärr hann jag inte med fikat efter att vi tagit emot diplom så jag hoppas att Rickard åt för oss båda!

På tal om mat så inträffade veckans höjdpunkt på fredagen. Jag hade inte hunnit förbereda matlåda och när vår HR-administratör Sofia hörde av sig till mig på torsdagskvällen och frågade om jag kunde slänga hennes matlåda som hon glömt i kylskåpet, var jag inte sen med att fråga: 1. vad den innehöll och 2. om den var ätbar. På fråga 1 svarade Sofia korv stroganoff och på nummer 2 ett garanterat ja, men den håller inte till måndagen. Eller okej, det där att den inte håller till måndagen lade jag till i huvudet, men det var liksom underförstått. Runt lunchtid öppnade jag lådan, inspekterade innehållet, luktade lite försiktigt och slukade den sedan på två röda. Ni ser här hur nöjd jag var efteråt – stor tumme upp för Sofias korv stroganoff!

20160129_141449

Jag var riktigt nöjd med min bedrift efter detta – god, gratis mat är den bästa maten, speciellt när man dessutom slipper laga den själv. Tack Sofia! Det är bara du hör av dig om du glömmer matlådor i kylen fler gånger, jag hjälper gärna till!

Såhär kan en integration se ut

God eftermiddag! Återigen känns det som att veckan bara har flugit förbi och det är redan fredag. Den här veckan har jag haft fullt upp med att utöka en integration med ett nytt flöde, något jag tror jag nämnde i förra inlägget. Det första jag behövde göra var att förstå hur integrationen faktiskt fungerade, och jag tänkte använda det jag tagit reda på som ett exempel på hur ett integrationsflöde kan se ut.

Här kan ni se en översikt av flödet, och jag tänkte gå igenom steg för steg vad det är som händer.

integrationexempel1. XML och FTP

Vi har ett system som samlar in väderdata, till exempel temperaturen över en viss tidsperiod eller hur mycket nederbörd det kommit. Den här informationen lagras sedan i XML-format och sparas på en FTP-server, och det är genom att hämta XML-filerna på FTP-n som vi kommer åt informationen. Informationen från filerna kallas generellt för meddelanden när de går genom en integration.

2. BizTalk-port

BizTalk är den integrationsplattform som används i den här integrationen, och när filerna har lagts på FTP-n, så finns det portar i BizTalk som hämtar in dem. I dessa portar finns det sedan ”mappningar” som översätter de inkommande XML-filerna till ett internt XML-format. Detta är för att man ska kunna lägga till nya dataformat in i integrationen, utan att behöva ändra logiken internt. Allt man behöver göra är då att mappa över den nya filen till det interna formatet, sedan kan den behandlas på samma sätt som alla andra meddelanden. I porten finns även en mekanism som arkiverar all data som skickas in och lagrar den för senare användning, till exempel analys.

3. Inuti BizTalk

Här ska jag inte fördjupa mig i några detaljer, men kort sagt kan man säga att BizTalk använder något som heter orkestreringar för att styra processen. I det här flödet så valideras värdena i meddelanden, och beroende på resultatet av valideringen, så tar meddelandet olika vägar.

4. WCF-tjänst

Oavsett vilken väg meddelandet tagit, så kommer det i slutänden till en port i BizTalk, som skickar det vidare till en extern WCF-tjänst. Även på den här porten sker det mappningar, nu från det interna XML-formatet till en XML-fil som tjänsten kan hantera.

5. Ner i databasen

WCF-tjänsten anropar i sin tur en lagrad procedur i en SQL Server databas, som översätter meddelandet från XML till SQL och sparar ner informationen i databasen. Sedan kan det finnas andra system som prenumererar på de här värdena, då skickas en notifiering (via BizTalk) till dessa system och berättar att nu finns det nya värden att hämta.

Det här blev väldigt kortfattat, men jag tror vi nöjer oss så för den här gången! Min uppgift i det här är att utöka integrationen vid punkt 1, så vi kan ta in ytterligare ett filformat via vår FTP. Här ser man direkt fördelarna med att ha ett internt format att översätta till – jag behöver bara göra förändringen vid punkt 1, inuti BizTalk kan allt fortsätta funka som förut.

En helt vanlig dag.

Mina dagar börjar alltid med att jag sätter på kaffe så fort jag kommer till kontoret, om ingen annan har gjort det. Som så många andra i det här landet har jag utvecklat ett beroende till den bruna drycken, och jag behöver tre koppar på morgonen för att komma igång. Jag sveper dessa innan klockan 10, sedan är min koffeinkvot uppfylld för dagen och jag dricker inget mer. Möjligen att jag tar en kopp på eftermiddagen, men det är mer bonus och inget jag behöver.

Steg två är alltid att kolla mailen. Hur dagen utvecklar sig beror nästan alltid på hur inkorgen ser ut. Idag fick jag en förfrågan från en kund om att plocka fram exempelfiler från en integration, samt undersöka om integrationens logik kan återanvändas i ett annat flöde. Eftersom detta var en ganska liten uppgift tog jag mig an den på en gång och hämtade filerna från ett filarkiv där de sparas, och började sedan analysera integrationen. Den består av ett SSIS-paket (SQL Server Integration Services) som exekverar bat-filer och genom att läsa dessa blev min slutsats att de inte går att återanvända, men för säkerhets skull har jag dubbelkollat det med Douglas, så vi får se om jag hade rätt eller fel gällande det…

Efter att jag skickat svar på mailet var det dags att fortsätta med den lite större uppgiften jag har just nu, nämligen att utöka en integration med ett nytt flöde så att vi kan ta hand in filer i ytterligare ett format för en annan kund. Jag håller nu på att sätta upp miljön jag ska använda lokalt, och det krånglade en del i fredags. Vi har virtuella miljöer som vi arbetar i för det mesta, och någonting har hänt med min miljö – den har segat ihop totalt och ger mig kryptiska felmeddelanden. Jag hade förhoppningar om att det skulle lösa sig av sig själv under helgen, men det gjorde det såklart inte… Så istället för att fortsätta jobba har jag googlat felmeddelanden, ändrat lite inställningar och väntar just nu på att miljön ska starta om sig. Jag hoppas verkligen den fungerar som den ska nu, annars måste jag ringa till supporten och få hjälp.

I det här yrket är man väldigt beroende av sin dator, milt uttryckt. Utan fungerande dator är det i princip omöjligt att jobba, vilket gör sådana här problem jäkligt irriterande.. Det är visserligen bara en virtuell miljö som krånglar och inte hela datorn, så det kunde definitivt vara värre, men det är ändå frustrerande. Nu ska jag prova att starta upp miljön igen, fick en precis en idé om hur detta kan lösas, måste testa direkt…

Min vardag

Egentligen vet jag inte, men jag har vissa aningar om vilka mina läsare är. Jag tror många är studenter som ännu inte börjat arbeta med IT, en del som jobbar med systemutveckling på olika sätt, samt ett par stycken som inte har just någon koll alls på branschen (hej mamma!). Gemensamt tror jag i alla fall är att de flesta inte har någon koll på vad en integrationskonsult gör alls om dagarna och därför tänkte jag ägna en serie inlägg åt min vardag här på IB.

På ett sätt tycker jag det är lite egoistiskt att tänka att alla är intresserade av vad jag gör hela dagarna, men samtidigt minns jag den där känslan när man var student och hur nyfiken man var på vardagen som IT-konsult. Jag tror vissa delar kommer vara ganska generella för branschen i allmänhet, och andra är väldigt specifika för just arbete med systemintegration och Integrationsbolaget.

Dagen idag har dock varit ganska icke-typisk för min del. Vi började med gemensam frukost och jag tror hela Örebrokontoret var här på morgonen och käkade tillsammans, tillsammans med ett par kollegor från Integrationsteamet på CAB. Att alla från Örebrokontoret var på plats på just Örebrokontoret låter kanske inte så imponerande, men till vardags sitter hälften av styrkan på CAB och övriga jobbar ett par dagar i veckan från andra orter, hos våra kunder. Eftersom jag är orutinerad som bloggare glömde jag såklart att ta kort på tillställningen…

Därefter hade jag, Douglas och Stefan ett gemensamt möte med en student som ska göra ”SUPen” hos oss. Ni som läst informatik vet vad jag menar, ni andra funderar säkert på alkoholrelaterade saker, men det står för kursen Systemutvecklingsprojekt, som är en del av informatikämnet och systemvetenskapliga programmet, och som går under hela vårterminen. Mötet gick fint och på måndag säger vi hej till studenten Jonas Boyd, som ska göra ett projekt kring molnintegration. Hej Jonas, välkommen! Tror du kommer få en rolig, lärorik och utmanande termin, och det ska bli kul att ha dig här!

Jag återkommer nästa vecka med ett nytt inlägg kring hur en mer typisk arbetsdag ser ut för mig – även om det i det här jobbet kan variera ganska mycket kring vad man gör. Just nu känns det att helgen är på ingång. Kolla bara på den här bilden:

douglas kör rally

Ja, vi har alltså nån slags racerbil simulator på kontoret just nu. Jag vet inte riktigt vart den kommer ifrån eller hur länge den ska bo här, men Douglas trivs bra bakom ratten! I skrivande stund skryter han ganska öppet om hur bra han är och jag hörde nåt hojtande om ”pole position”. Nästan så jag blir lite sugen på att smygköra den när han har gått för dagen och sedan krossa honom nästa vecka…

Language: