Hur upplever ni förståelsen för ert tekniska jobb är med bekanta?

Jag är IT tjänsteägare idag - handlar mycket om att översätta teknisk förmåga till säljbar produkt. Avtalsbilagor, kostnadskalkylering, tidsuppskattning för implementationer, etc. Många möten med både tekniker och säljare, mycket Word, Excel och Powerpoint.

När jag förklarar det på det viset brukar de flesta förstå, men det finns fortfarande många i min bekantskapskrets som tror att jag fortfarande sitter och skruvar i datorer och skriver kod om dagarna, för det gör väl alla i IT-branschen?

Bland det roligaste jag läst på länge

Gör samma sak, så fort man sagt "IT" så brukar det vara färdigpratat om man vad man gör om det inte är någon som är i branschen själv.

Specialistyrken med flera års utbildning/erfarenhet är alltid svårt att förklara på ett lätt sätt. Att få folk utan it-kunskap att fatta min programmering är ungefär lika lätt för en mekaniker att förklara skillnader mellan olika hydrauliska komponenter eller annat. Går såklart att göra liknelser inom IT med men oftast blir det aldrig förståelse på andra sidan, utan man får samma fråga igen nästa gång man ses

Är i liknande situation så det som nämns här i tråden är mycket välbekant.
Men det är egentligen två olika delar som diskuteras:
A. Hur förståelsen för vad man gör är bland bekanta/familj m fl.
B. Hur arbetssituationen är och hanteras, samt hur förståelsen för den är för arbetsgivaren/kollegorna/kunderna.

När det gäller A är det varierat, de flesta frågar inte ens och vet heller inte mycket om det. Det är något med "data" el "teknik" och de nöjer sig med det för att inte verka alltför okunniga.
I den närmaste familjen, för tillfället främst mor och far, är förståelsen olika beroende på vem det är. Där ena dels gått IT-utbildning och dels anstränger sig mer för att förstå, medan den andra också är pensionär sen många år och har betydligt mindre förståelse för såväl området som vad det innebär att arbeta.

B är mer komplicerad.
Som konsult med många olika uppdrag åt olika kunder/användare gäller det att kunna vara flexibel med tider och var man är. Kan inte räkna med att bara sitta på samma ställe hela dagen och ha lunch/fika/slut på dagen på exakta tider. Samtidigt som det gäller att kunna ta ansvar för att saker verkligen blir lösta. Man vet långt ifrån alltid hur länge något kommer att ta. Man jobbar inte utifrån ett schema utan baserat på ärenden/uppdrag, som man debiterar sina timmar för.
Om man dessutom har mycket hög beläggning och man gör saker som få andra vet något om kan det bli påfrestande, man är mycket ensam om sitt.
Att varken konsultchef el de flesta av kollegorna förstår hur det är el knappt vad man gör förbättrar ju inte direkt situationen.
Sen har jag ju även några kollegor som förstår mycket väl hur det är, men inte vågar säga så mycket åt chefen och istället lider i det tysta.

Det är en stor utmaning att rekrytera personal lokalt, då folk inte vill flytta till mindre orter som de inte har anknytning till. Det innebär även att mer erfarna konsulter många gånger behöver göra grundläggande saker som borde kunna skötas av juniorer, om det fanns tillräckligt med sådana. Sen är steget till att göra de mer komplexa sakerna enormt stort och kräver betydligt mer djup. Dvs nya/juniorer kan på sin höjd hjälpa till med en del mer grundläggande saker rätt snabbt, men för att göra mer krävs intresse och många års erfarenhet.
Sen är det också skillnad mellan de som bara tar det som ett jobb, dvs någonstans att vara på dagarna för att få pengar utan att engagera sig desto mer, eller de som gör det med stor passion och plikttrogenhet. En alltför stor del tillhör den förstnämnda kategorin.

Bland kunderna är förståelsen också olika. En del förväntar sig att om man jobbar inom IT ska man veta och kunna lösa absolut allt, andra förstår att det finns olika specialiseringar och folk om sköter olika områden.

Jag möter för övrigt många olika yrkesgrupper på olika nivåer, inser hur svårt det är att förstå vad folk egentligen gör.

Fast det stämmer inte alltid, kunden vill inte alltid betala det som det skulle kosta med någon premiumlösning, de vill oftast ha så billigt som möjligt, även om man berättar vad det innebär.

Hänt flera gånger:
"Finns det något sätt vi kan göra detta billigare?"
"Visst, vi kan t.ex ta bort X,Y och Z"
"Men då gör vi det!"

6 månader senare:

"Detta är inte det vi beställde"
"Vad menar ni?"
"Skulle inte X, Y och Z ingå?"

Säger jämt att jag jobbar med tunnelbanan och alla tror att jag kör tunneltåg, men icke sa nicke.

Ad-hoc, fast med en god dos av "expection management", framförhållning och vettiga chefer och kunder. Samt att det underlättar för flexibiliteten att inte ha familj.

Jag känner igen mig i att vara den enda som har koll på en lösning (enpersonersprojekt) eller vara den enda som har full koll på helheten och därmed kunna felsöka effektivt (flerpersonersprojekt). Det är i konsultbranchen en naturlig del av att kunden vill ha maximal funktionalitet för minimalt pris, det blir inte mycket redundans vad gäller personal. Just första driftsättningen till produktion är ju lite speciell eftersom det handlar om en miljö som man troligen aldrig kört i förut, men man bör med åren bli bättre på att förbereda driftsättningar redan under utveckling och test, man dokumenterar när man förutser problemen eller stöter på dem i testmiljön (en produktionslik testmiljö har man, alltid). Man ska se risken för problem och planera efter det, men om man tror att man kommer få problem i en driftsättning har man gjort något fel.

Tydlig, tidig kommunikation mot alla inblandade hjälper. Projektledare, chefer och kunder behöver uppfostras och när man ska göra det hjälper det att ha ryktet att alltid vara engagerad och hårt arbetande.

Om man i tidigt skede kommunicerat att "driftsättningen blir när vi är så säkra vi kan vara på att det kommer fungera, inte förr, troligen vecka X eller Y", så brukar det gå bra att skapa luft i tidplanen. Vad ska dom göra, ta in någon annan som det tar två veckor för att sätta sig in i systemet och bli försenade på det viset i stället? I vissa fall krävs koordination med andra intressenter, men ovanstående taktik brukar ändå fungera för att köpa flexibilitet. Naturligtvis är det du som ska driftsätta som bestämmer, inte någon projektledare, kund eller säljare - de är för kassa för att åstadkomma något själva och det ska de förstå, även om man kanske ska uttrycka det lite diplomatiskt. Och som sagt, de har inget val, eftersom de valt att inte betala för redundans, antingen gör du det på dina villkor eller så gör ingen det.

Hur bekanta ska förstå vad jag gör? Ingen aning, jag vet ofta inte själv vad jag faktiskt kommer göra när jag kommer till jobbet på morgonen. Jag tänker på mig själv som "IT-hora", jag gör vad kunden behöver/vill ha för pengar. Att kalla sig "IT-arkitekt" ger dock mer pengar, även om det jag helst vill syssla med nog skulle kunna kallas "systemutvecklare" - ibland känner jag att jag lyckas vara just det.

För familj och bekanta brukar jag mest förklara vad kunden sysslar med och hur det jag gör passar in i kundens affär.

Hm, mitt problem jag har är även hur jag förklarar för kollegor på företaget världen över vad jag jobbar med. Tjänsteägare? Chef? Projektledare? T.om min titel är helt åt h*e. Har super problem att hitta en beskrivning när jag skall löneförhandla.

Att beskriva mitt jobb för vänner, blir alltid "jag jobbar med IT".

Ungefär samma som att säga SSD-disk eller andra felaktiga teknikaliteter. Alla förstår vad som menas, sen om man säger jobbar med devops eller jobbar som devops-operatör eller vad man nu vill säga spelar mindre roll i min värld