Jan Sørensen er en af de tunge drenge og har været i IT-branchen de sidste 18 år. Senest har han lavet et projekt for ProData Consult hos GN Store Nord. Han er en tung Microsoft udvikler og designer med styrke i analyse- og opstartsfasen, hvad enten det gælder behovsdækning, systemanalyse eller teknologivalg.
Jans erfaringer med offshore-projekter ligger primært inden for den tekniske del af organisationen og som teknisk projektleder. Han vil i dette interview fortælle om de offshore-erfaringer, han har høstet sammen med IT-folk fra både Indien og Pakistan.
Hvad var dit første offshoring-projekt?
Min første erfaring med udenlandske IT-konsulenter i en outsourcingsammenhæng var på et stort projekt hos en af Danmarks største virksomheder, hvor en stor del af opgaven skulle bemandes med konsulenter fra Indien. Hovedprojektetet var af en varighed på ca. 4 år. En stor del af IT-besætningen sad lokalt i Indien – i Bangalore helt præcist. Så var der et par stykker, som sad onshore i Danmark og fungerede som direkte bindeled mellem den danske virksomhed og offshore-afdelingen. Med hensyn til IT-tekniske ressourcer – altså udviklere — var der vel en ca. 10 mand på i alt, hvor 8 sad i Indien og 2 i Danmark. Jeg fungerede som teknisk projektleder på en afgrænset del af projektet, og en af opgaverne var at koordinere i samarbejde med de indiske ressourcer.
Beskriv din dagligdag på projektet
Fællessproget var engelsk, og det snakker de fleste indere heldigvis rimelig fornuftigt, selvom det er med en sjov accent. De synes nok, vores accent er ligeså mærkelig – men det kommer der bare sjov ud af. Det er i hvert fald ikke nogen barriere. Den direkte daglige kontakt går selvfølgelig nemmest med den konsulent, der sidder onshore i Danmark. Det er der, den direkte kommunikation og koordinering foregår. Og den del forløber sådan set ok. Dér hvor man skal være på vagt, er nok mht. de her kulturelle forskelle. Især det med, at indere ikke siger ”nej”. De vil aldrig indrømme, at de ikke har forstået det eller har spørgsmål eller indrømme, at de ikke er blevet færdige. I stedet går de bare tilbage på deres pind og til deres bagvedliggende ressourcer og sidder og grubler over, hvad pokker det egentlig var, de skulle lave. Eller også får man en lang søforklaring om, hvorfor de ikke er færdige.
Hvad gør man så?
Man skal sørge for at være den udfarende; følge op hele tiden og spørge ind til, hvad der er besluttet, hvor langt de er nået i processen, og hvordan de griber det an. Med danskere er man vant til, at hvis personen ikke forstår det, så råber vedkommende op og spørger om hjælp, så der ikke opstår tvivl. Men indere er bange for at udstille sig som uvidende. Det er sådan set den store forskel, og det kræver en meget stram opfølgning på projektet.
Blev du gjort opmærksom på dette problem, inden du startede på projektet?
Nej! Det var dyrekøbte erfaringer! Det tog mig noget tid, før jeg havde lært teknikken til at følge op på dem.Jeg har for nylig også været med på et projekt, hvor der blev brugt konsulenter fra Pakistan. Der sad 1 onshore og 5-10 stykker offshore. Og danskeren, der var lead-arkitekt på hele opgaven, gik meget minutiøst igennem, hvordan hver ting skulle laves og designes og kørte sådan nogle sessioner mindst én gang om ugen, hvor han forklarede, hvordan tingene skulle gøres. Det projekt blev kørt rigtig rigtig stramt, men det var ikke en succes alligevel. Det lykkedes simpelthen ikke.
Hvad gik der galt?
Jamen – den “bageopskrift” han havde lagt for dagen, og som han hårdt og minutiøst havde gennemgået med dem for at skære ud i pap, hvordan tingene skulle implementeres – den blev gang på gang ikke fulgt; de lavede fejl, og de gjorde ikke, som han helt tydeligt havde sagt. Det holdt for nogle få af de udviklere, som vi brugte, men for størstedelen var det et flop. Og det endte med, at vi stort set lavede det selv. Det er også svært at kommunikere over lange afstande. Det kan godt være virkelig frustrerende, når man sidder i Danmark og skal kommunikere med nogen, der sidder i Pakistan og det, man har til rådighed er et konference-call og en eller anden form for remote desktop, så man kan se, hvad der foregår på skærmen. Men det er bare ikke det samme, som hvis man kan stille sig ved en tavle og stå med en tusch, og alle ligesom kan gå op og sætte nogle streger og indgå i en rigtig dialog.
Jeg har en lille sjov anekdote mht. at sige “ja” eller “nej” til, om man har forstået det: Mine danske kollegaer samt en indisk konsulent, som sad onshore, skulle flytte internt i firmaet. Og det fungerede på den måde, at man hver især fik et vist antal flyttekasser, man skulle samle og pakke sine ting ned i. Det gjorde man om fredagen, og om mandagen ville flyttekasserne stå på ens nye kontor. Men sådan en flyttekasse kan godt være lidt umulig at samle, hvis man aldrig har prøvet det før. Så min kollega viste den indiske konsulent, hvordan man skulle samle sådan en flyttekasse. Og han spurgte ham, om han havde forstået det, og han sagde: “Ja! Ja!” Det viste sig så, at da man løftede den kasse, som den indiske konsulent havde samlet, så stod alt indholdet tilbage på gulvet! Den var overhovedet ikke samlet rigtigt. Her begyndte alarmklokkerne at ringe! Så derfor er det fornuftigt hele tiden at verificere, at de ikke begynder at bevæge sig ud ad en eller anden tangent eller forkert retning, ellers ender man med at have spildt en masse tid.
Er der andre ting, man skal være opmærksom på?
En anden stor forskel er, hvor dygtige de er. Her er det min erfaring, at man kun får én IT-medarbejder, der er rigtig dygtig med mange års erfaring, og som er virkelig kompetent. Det er ligesom den første person, man får og har kontakten til og skal diskutere det hele med. Men så får man desværre også nogle andre med i kølvandet, som man kun lærer at kende ud fra deres CV, hvor det kan være svært at danne sig et overblik over, om det er en dygtig person eller ej. Så hovedregelen er, ifølge min erfaring, at når man har fået en, der er rigtig god, følger der som regel en 4-5-6 stykker med, som er af meget svingende kvalitet.
Hvordan har du opdaget det i et arbejdsforløb?
Det er svært at opdage, for der er jo et par kilometer fra Danmark til Bangalore. Det opdager man ikke, før man begynder at granske i noget af den kode, de har lavet. Eller hvis man har lavet en tidsplan og delt opgaverne ud til person 2, 3 og 4 – og så ser man, at der aldrig kommer noget fra person 2, 3 og 4, og at det ligesom er den samme person, der driver værket. Inderne gør også deres bedste for at skjule nogen, der underperformer eller laver dårligt arbejde. Som helhed vil de gerne levere en vare, der er ok, så det kan være svært at opdage, at man har nogen med på teamet, som er uduelige.
Har du nogen gode råd, hvis man sidder i sådan en klemme?
Man må jo sørge for at være opmærksom på det, inden man starter. Der skal være mulighed for at sige: “Jamen, den her ressource vil jeg simpelthen ikke have med på projektet, og jeg vil ikke betale for en, der ikke lever op til kompetencekravene.” Hvis man har det med i kontrakten, så kan det også være, at begge parter gør sig lidt mere umage for at overholde den del af kontrakten, så man ikke spilder en masse tid. Men det kan måske også være et problem, for konkurrencen er hård. IT-kompetencer er stadig en mangelvare, og det er også blevet en mangelvare i Indien og Pakistan. Så lille Danmark, som kommer og skal have outsourcet, og som har brug for ti mand, der sidder ude i Indien, er altså i skarp konkurrence med både Indiens eget voksende behov for IT og alle mulige andre landes.
Er der andre faktorer, man skal holde øje med?
Når man først begynder at arbejde med indere, og det fungerer, så er de nogle rare og høflige mennesker, og vi får hurtigt lært dem vores skandinaviske sorte humor og ironi, som de hurtigt tager til sig. Der opstår et udmærket arbejdsmiljø, så det er ikke kun dårligt; der er også positive sider. Og de, der er dygtige, ER vitterligt dygtige. Det handler bare om at spotte de rigtige og sørge for at være heldig. Men erfaringsmæssigt så hedder det: 1 god og 4-5 dårlige, desværre.
Efter alt det, du fortæller her, kan det undre, hvorfor man bruger så mange ressourcer og penge på offshoring?
Jamen, det lyder jo attraktivt til at starte med. Du får et CV, hvor der står, at vedkommende er ingeniør, og månedsprisen er 14.000 kr. Og alt andet lige, så er det i hvert fald en faktor 3 i forhold til danske medarbejdere. Man har det bare med at glemme nogle af de omkostninger, der er i forbindelse med outsourcing til eksempelvis Indien eller Pakistan. En anden ulempe er også, at det er klart sværere at kommunikere hen over tidsforskelle. Det er jo sådan, at når vi møder kl. 8 om morgenen i Danmark og går hjem kl.16, så er inderne altså mødt en del timer tidligere og går hjem kl.12 vores tid. Så der er kun nogle få timer, hvor man kan snakke med hinanden. Og det foregår så over telefonen, messenger eller noget tilsvarende. Der er også den fordyrende omkostning, at man pludselig skal have fløjet 3 mand den ene eller den anden vej inklusive hotelophold og alt muligt andet. Og den glemmer man at regne med i prisen. Man regner sikkert heller ikke med, at man får en eller anden, som slet ingen ting laver. Selvom der står ingeniør, så kan det vise sig, at personen er maskiningeniør og aldrig nogen sinde har lavet 2 liniers kode. Det er helt værdiløst, og man kunne lige så godt tage en hvilken som helst akademiker i Danmark og omskole vedkommende til at være programmør.
Hvordan mener du, at vi kan løse de her ulemper mht. offshoring?
Det kunne måske være interessant at kigge på et land, der ikke nødvendigvis lå så langt væk fra Danmark. Det ville jo fjerne den her barriere med, at man ikke bare lige sætter sig ind i en flyver, fordi det tager 10 timer. Polen kunne være en mulighed, og både kulturelt og afstandsmæssigt er de også tættere på os. Men måske også lidt dyrere.
Et kig ind i krystalkuglen for freelance IT-konsulenter, hvad er dit bud?
Jeg tror, krystalkuglen står fuldstændig fast på, at der er masser at lave både for danske freelance-konsulenter og for outsourcing-konsulenter, sådan som pendulet svinger lige nu. Alt tyder på, at jo mere offshoring, der bliver lavet, jo mere arbejde er der også til danske IT-konsulenter. Så der er intet, der tyder på, at offshoring skulle betyde mindre arbejde til danske IT-konsulenter. Snarere tværtimod.
