![\"\"](\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2013\/03\/img_block-hedgefund-150x150.jpg\" "\\"offshore")
A few weeks back I wrote an article about What makes global teamwork, offshoring, nearshoring and remote cooperations so interesting<\/a>. I have a critical father in law who told me that I described some pitfalls that I walked into and asked me ‘but what did you learn from the mistakes you made?’ So I devote this article to that question, because I believe it could prevent others from making the same mistakes. I will go through the points that I described one by one (the italics are from my previous article)<\/p>\nIk vond het niet leuk om zo veel fouten te moeten maken. De eerste jaren had ik geen idee over wat men moet doen om samen te werken met iemand in India of Oost-Europa. Ik maakte alle fouten die je maar kunt bedenken: het huren van de verkeerde mensen, het werken zonder proces, zonder hulp van een online project management tool werken, het communiceren via chat alleen, werken met leveranciers die niet betrouwbaar waren, vast komen te zitten tussen klant en leverancier, en niet in staat zij om een \u200b\u200bproject te leveren aan een klant. En dan nog een berg met fouten gepaard gaande met de opening van een kantoor in India zonder enige voorafgaande ervaring of Indiase contacten.<\/em><\/p>\n >Het huren van de verkeerde mensen >Het werken zonder proces >Zonder hulp van een online project management tool werken > Alleen communiceren via chat > Werken met leveranciers die niet te vertrouwen zijn > Noodgedwongen tussen klant en leverancier komen <\/p>\n F\u00f6r ett par veckor sedan skrev jag en artikel om \u201cVad g\u00f6r globala samarbeten, offshoring och nearshoring s\u00e5 intressant?\u201d<\/a> Jag har en kritisk sv\u00e4rfar som p\u00e5pekade att jag beskrev en del fallgropar jag har ramlat i och fr\u00e5gade mig \u201dvad l\u00e4rde du dig av de misstag du gjorde?\u201d. S\u00e5 jag till\u00e4gnar denna artikel \u00e5t den fr\u00e5gan, f\u00f6r jag tror att det skulle kunna f\u00f6rhindra att andra g\u00f6r samma misstag. Jag ska g\u00e5 igenom de huvudsakerna som jag beskrev, en efter en (kursiveringen \u00e4r fr\u00e5n min tidigare artikel).<\/p>\n <\/p>\n Vor ein paar Wochen schrieb ich ein Artikel \u00fcber \u201eWas macht globales Teamworking, Offshoring, Nearshoring und Kooperationen aus der Ferne so interessant?\u201c<\/a> Ich habe einen kritischen Schwiegervater, der mir sagte, ich h\u00e4tte einige Fallstricke beschrieben, und er fragte mich \u201eaber was hast du aus deinen Fehlern gelernt?\u201c Somit widme ich diesen Artikel genau dieser Frage, weil ich denke es kann anderen helfen nicht die gleichen Fehler zu begehen. Ich werde jeden Punkt einzeln durch gehen. (Das Kursive ist von meinen vorhergehenden Artikel)<\/p>\n Das was ich nicht mag, sind die vielen Fehler, die ich machen musste. In den ersten Jahren wusste ich nicht was man tun muss, um mit jemanden aus Osteuropa oder Indien zusammenzuarbeiten. Ich machte alle Fehler, die man sich vorstellen kann: Stelle die falschen Leute ein, arbeitete ohne Fortschritt, nutze gar keine Online-Projekt-Managment-Systeme, kommunizierte nur durch Chat, arbeitete mit Lieferanten, die nicht vertrauensw\u00fcrdig waren, blieb in der Mitte zwischen Kunde und Lieferant stecken und war auch nicht in der Lage ein Projekt an einen Kunden zu liefern. Und dann noch einen Eimer voll Fehler bei der Er\u00f6ffnung eines B\u00fcros in Indien ohne Vorkenntnisse und indische Kontakte.<\/em><\/p>\n \u00d8 Die falschen Leute einstellen<\/p>\n Obwohl es einfach scheint gute Programmierer einzustellen, weil man objektiv die Qualit\u00e4t eines Codes beurteilen kann und die analytischen F\u00e4higkeiten vern\u00fcnftigerweise beurteilen kann, ist es in der Realit\u00e4t nicht so leicht. F\u00fcr eine Zusammenarbeit auf Distanz sind technologische oder analytische F\u00e4higkeiten nur ein Teil der Gleichung. Kommunikation ist der wichtigste Aspekt dabei und nach dieser F\u00e4higkeit sollte auch rekrutiert werden. Ich habe auch gelernt, dass es wichtig ist gemeinsame Werte bei der Auswahl zu ber\u00fccksichtigen. Offenheiten und Verantwortung sind zwei unserer Unternehmenswerte, die den gr\u00f6\u00dften Einfluss auf den Erfolg bei unserer vertrauten Arbeit mit unseren Kunden haben. Ich habe einen fr\u00fcheren Artikel <\/a>diesem Thema gewidmet.<\/p>\n \u00d8 Ohne einen Prozess zu arbeiten<\/p>\n Die menschliche Natur will immer \u201egleich loslegen\u201c. Wir finden einen Programmier oder ein ganzes Team in der Ferne und schicken unsere Anforderungen und erwarten, dass einfach alles automatisch funktioniert. Ich habe gelernt, dass es bei der Arbeit auf Distanz und zwischen Kulturen und Sprachenr\u00e4umen ein gemeinsames Verst\u00e4ndnis wie gearbeitet wird sehr wichtig ist. Wenn man sich vorher nicht darauf verst\u00e4ndigt und die Angestellten tun nur das wie sie es gewohnt sind, es sei denn, dass sie zuf\u00e4llig die richtigen Routinen herausbilden, entstehen falsche Routinen und das Offshore-Projekt wird scheitern.<\/p>\n \u00d8 Keine Online-Projekt-Managment-Systeme benutzen<\/p>\n Technologische Fortschritte haben hier viel geholfen. Heute benutzen die meisten Leute Jira, Pivotaltracker, Github und Bitbucket, aber sieben bis acht Jahre zuvor hat man gerade erst angefangen bei der Arbeit aus der Ferne mit E-Mails und Skype zu arbeiten. Wenn Sie sich keinen \u00dcberblick mittels Online-Anwendungen, die die Kommunikation, den Status, die Fehler und Fragen verfolgen verschaffen, wird Ihr Projekt im Laufe der Zeit entgleisen.<\/p>\n \u00d8 Kommunikation nur mittels Chat<\/p>\n Das Auffallende ist, dass es auch funktionieren kann. Wir haben einige Kunden die nur \u00fcber Chat arbeiten und zufrieden sind. Aber was Sie vermissen ist die pers\u00f6nliche Beziehung und die verbale Kommunikation. Es braucht auch mehr Zeit als zu reden. Es ist sicher f\u00fcr den Programmier in der Ferne hinter dem PC zu sein. Aber es ist auch wichtig diese Beziehung aufzubauen und effizient zu arbeiten. Scrum ist eines der Instrumente, das der gemeinsamen Arbeit auf Distanz am meisten hilft. Und Scrum funktioniert nur mittels Audio und Video, nicht mit Chat.<\/p>\n \u00d8 Zusammenarbeit mit nicht vertrauensw\u00fcrdigen Lieferanten<\/p>\n Als ich mit Bridge startete, hatte ich nur Zulieferer mit denen ich arbeitete. Diese haben sich jedoch schnell gezeigt, dass sie zu wenige Programmierer hatten um die Arbeit weiter auszuf\u00fchren. Deshalb verzweigt man sich mit anderen Partnern. Es ist schwer den richtigen Partner zu finden und es braucht Zeit. Aber ich habe gelernt, dass man sich die Zeit nehmen sollte. Au\u00dferdem habe ich gelernt, dass es besser ist seine eigenen Leute zu haben, da wir selbst entscheiden k\u00f6nnen wen wir einstellen (bez\u00fcglich F\u00e4higkeiten, Wissen aber auch in Bezug auf Werte), wie sie arbeiten, wie wir unseren Teamgeist aufbauen und wie wir Komfort und Freude unter unserem Team aufbauen. Ich schrieb im letzten Jahr einen Artikel <\/a>\u00fcber dieses Thema.<\/p>\n \u00d8 In der Mitte zwischen Kunde und Lieferant stecken zubleiben<\/p>\n Ich habe auch eine andere wichtige Lektion gelernt: F\u00fcr erfolgreiche Offshore-Kooperationen sollten ein paar Manager zwischen dem Kunden und dem Programmierern geschalten sein. Wir sind es gewohnt Projekte zu haben bei denen ein Endkunde einen Webshop haben wollte und engagiert daf\u00fcr eine Agentur. Die gibt den Auftrag an eine Webagentur weiter und diese wiederum gibt uns den Auftrag und wir stellen ein Nearshore-Team ein. In jeder Firma war ein Projektmanager involviert, das bedeutet mindestens f\u00fcnf Projektmanager. Wenn einer dabei schl\u00e4ft, scheitert das Projekt. So die beste Version ist, wenn der Endkunde direkt mit dem Programmierer spricht und wenn er nicht die F\u00e4higkeiten dazu mitbringt, kann er eine Web-Agentur engagieren, welche mit dem Programmier in der Ferne kommuniziert. Ein Nebeneffekt ist, dass man sich einige Kosten auf dem Weg sparen kann!<\/p>\n <\/p>\n The thing I disliked was having to go through so many mistakes. The first years, I was in the dark as to what one needs to do in order to cooperate with someone in India or Eastern Europe. I made all the mistakes you can imagine: hire the wrong people, work without any process, not using any online project management tools, communicating through chat only, work with suppliers that were not trustworthy, get stuck in the middle between client and supplier, not being able to deliver a project to a customer. And then another bucket of mistakes opening an office in India without any prior experience or Indian contacts.<\/em><\/p>\n > Hiring the wrong people<\/strong> > Work without any process > Not using any online project management tools > Communicating through chat only<\/strong> > Work with suppliers that were not trustworthy > Get stuck in the middle between client and supplier <\/p>\n Det jag ogillade var att vara tvungen att g\u00e5 igenom s\u00e5 m\u00e5nga misstag. De f\u00f6rsta \u00e5ren kunde jag inte se vad som beh\u00f6vdes g\u00f6ras f\u00f6r att m\u00f6jligg\u00f6ra samarbete med n\u00e5gon i Indien eller \u00d6steuropa. Jag gjorde alla misstag du kan t\u00e4nka dig: anst\u00e4llde fel m\u00e4nniskor, jobbade utan processer, anv\u00e4nde inte n\u00e5gra projektledningsverktyg online, kommunicerade enbart genom chat, jobbade med leverant\u00f6rer som inte var p\u00e5litliga, blev fast mellan klienter och leverant\u00f6rer och hamnade i situationer d\u00e5 jag inte kunde leverera projekt till kunderna. Och ovanp\u00e5 det, en till lista med misstag d\u00e5 jag \u00f6ppnade ett kontor i Indien utan n\u00e5gra tidigare erfarenheter eller indiska kontakter.<\/em><\/p>\n > Anst\u00e4lla fel m\u00e4nniskor<\/strong><\/p>\n \u00c4ven om det verkar enkelt att anst\u00e4lla bra programmerare, f\u00f6r att du objektivt kan bed\u00f6ma kvaliteten p\u00e5 kodningen och du kan rimligen bed\u00f6ma den analytiska f\u00f6rm\u00e5gan, s\u00e5 \u00e4r det inte s\u00e5 enkelt i verkligheten. F\u00f6r att ha goda, distanserade samarbeten \u00e4r teknologiska eller analytiska f\u00f6rm\u00e5gor bara en del av ekvationen. Kommunikation \u00e4r den viktigaste aspekten och det \u00e4r viktigt att rekrytera utefter den f\u00f6rm\u00e5gan. Jag l\u00e4rde mig ocks\u00e5 att rekrytera efter v\u00e4rden \u00e4r avg\u00f6rande. Tv\u00e5 av v\u00e5ra k\u00e4rnv\u00e4rden som har den st\u00f6rsta p\u00e5verkan p\u00e5 framg\u00e5ngen f\u00f6r v\u00e5ra intima arbeten med v\u00e5ra kunder \u00e4r \u201d\u00f6ppenhet\u201d och \u201dansvar\u201d. Jag har dedikerat en annan artikel<\/a> till dessa tv\u00e5 tidigare.<\/p>\n > Arbete utan n\u00e5gon process<\/strong><\/p>\n Den m\u00e4nskliga andan \u00e4r \u201cforts\u00e4tt bara\u201d. Vi hittar en bra, avl\u00e4gsen programmerare eller team och skickar krav och f\u00f6rv\u00e4ntar oss att det ska fungera, bara s\u00e5d\u00e4r. Jag har l\u00e4rt mig att det \u00e4r avg\u00f6rande n\u00e4r du jobbar p\u00e5 distans, mellan olika kulturer och spr\u00e5k, att ha en gemensam f\u00f6rst\u00e5else f\u00f6r \u201dhur det kommer att fungera\u201d. Om du inte t\u00e4nker p\u00e5 det h\u00e4r direkt och m\u00e4nniskor bara g\u00f6r vad de \u00e4r vana att g\u00f6ra, s\u00e5 kommer du att bygga upp fel rutiner och dina offshore-projekt kommer att misslyckas.<\/p>\n > Att inte anv\u00e4nda n\u00e5gra projektledningsverktyg online<\/strong><\/p>\n Teknologiska framsteg har hj\u00e4lpt till mycket h\u00e4r; de flesta m\u00e4nniskorna anv\u00e4nder verktyg som Jira, pivotaltracker, github och bitbucket, men f\u00f6r 7-8 \u00e5r sedan startade de flesta arbeten p\u00e5 distans endast med email och skype. Om du inte skapar en \u00f6verblick ifr\u00e5n b\u00f6rjan genom att anv\u00e4nda n\u00e5gra onlineverktyg som sp\u00e5rar kommunikation, status, buggar, fr\u00e5gor, etc., kommer ditt projekt med tiden att sp\u00e5ra ur.<\/p>\n > Att enbart kommunicera via chat<\/strong><\/p>\n Den f\u00f6rv\u00e5nansv\u00e4rda saken \u00e4r att det h\u00e4r absolut kan fungera; vi har flera klienter som jobbar enbart med chat och \u00e4r n\u00f6jda. Men vad du missar \u00e4r den personliga relationen och den verbala kommunikationen. Det kr\u00e4vs ocks\u00e5 mer tid \u00e4n att prata. Det \u00e4r tryggt bakom en dator, s\u00e4rskilt f\u00f6r distanserade programmerare. Men det \u00e4r ocks\u00e5 viktigt att bygga upp en relation och att jobba effektivt. Scrum \u00e4r ett av de instrumenten som hj\u00e4lper avl\u00e4gset arbete allra mest och scrum fungerar genom videosamtal, inte chatta.<\/p>\n > Jobba med leverant\u00f6rer som inte \u00e4r p\u00e5litliga<\/strong><\/p>\n N\u00e4r jag startade Bridge hade jag bara leverant\u00f6rer att jobba med. De jag jobbade med visade sig ha f\u00f6r f\u00e5 programmerare till att behandla arbetet. S\u00e5 ist\u00e4llet r\u00e4cker du ut handen till andra partners. Det \u00e4r sv\u00e5rt att hitta r\u00e4tt partner och det tar tid. Men jag har l\u00e4rt mig att man b\u00f6r ta sig den tiden. Jag har ocks\u00e5 l\u00e4rt mig att f\u00f6r oss s\u00e5 fungerar det b\u00e4ttre att ha v\u00e5ra egna personer, f\u00f6r att vi kan best\u00e4mma vem vi anst\u00e4ller (efter f\u00f6rm\u00e5ga och kunskap, men ocks\u00e5 efter v\u00e4rderingar), hur de jobbar, hur vi bygger teamspirit, hur vi skapar komfort och lycka i teamet. Jag skrev en artikel<\/a> om detta \u00e4mne, f\u00f6rra \u00e5ret.<\/p>\n > Att fastna mittemellan klient och leverant\u00f6r<\/strong><\/p>\n H\u00e4r har jag ocks\u00e5 l\u00e4rt mig en viktig l\u00e4xa: f\u00f6r att offshore-samarbeten ska bli lyckade, b\u00f6r det vara s\u00e5 f\u00e5 ledare mellan personen som efterfr\u00e5gat en programvara och personen som bygger den. Vi brukade ha projekt d\u00e4r klienten ville ha en webshop, anst\u00e4llde en publishing agency till detta, som i sin tur anst\u00e4llde en webagency, som anst\u00e4llde oss och vi anst\u00e4llde ett nearshore-team. I varje f\u00f6retag var en projektledare involverad, vilket betyder minst fem projektledare. Om en sover, misslyckas projektet. S\u00e5 den b\u00e4sta versionen \u00e4r att kunden pratar med programmeraren och om han inte har kompetens att g\u00f6ra det, s\u00e5 kan han anst\u00e4lla en webagency som pratar med den avl\u00e4gsna programmeraren. En sidoeffekt \u00e4r att du kan spara ett par extrakostnader p\u00e5 v\u00e4gen!<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" A few weeks back I wrote an article about What makes global teamwork, offshoring, nearshoring and remote cooperations so interesting. I have a critical father in law who told me that I described some pitfalls that I walked into and asked …<\/p>\n","protected":false},"author":4,"featured_media":44072,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45,14,5],"tags":[],"class_list":["post-5206","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nearshoring","category-offshoring","category-outsourcing"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2013\/03\/build.jpg","author_info":{"display_name":"Hugo Messer","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/hugomesser\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5206","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=5206"}],"version-history":[{"count":6,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5206\/revisions"}],"predecessor-version":[{"id":54661,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5206\/revisions\/54661"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/44072"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=5206"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=5206"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=5206"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2013\/03\/img_block-hedgefund-150x150.jpg\" "\\"offshore")
<\/a>Een aantal weken geleden heb ik een artikel geschreven over Wat maakt wereldwijd werken met teams, offshoring, nearshoring en samenwerken op afstand zo interessant?<\/a> Ik heb een kritische schoonvader die me vertelde dat ik een aantal valkuilen had beschreven waarin ik was gevallen en hij vroeg me \u2018maar wat heb je geleerd van de fouten die gemaakt hebt?\u2019 Aan deze vraag wil ik graag dit artikel wijden, want ik geloof dat het kan voorkomen dat anderen dezelfde fouten begaan. Ik zal stapsgewijs door de volgende beschreven punten heen gaan (de schuingedrukte tekst komt uit mijn vorige artikel)<\/p>\n
\n<\/strong>Hoewel het gemakkelijk leek om goede programmeurs te huren, je kunt immers objectief de kwaliteit van iemands code beoordelen en redelijkerwijs analytische skills beoordelen, maar dit bleek in werkelijkheid tegen te vallen. Voor het hebben van een goede samenwerking op afstand zijn technologische en analytische skills slechts deel van de vergelijking. Communicatie is het meest cruciale aspect en het is belangrijk om juist voor die skill te recruiten. Ik heb ook geleerd dat het huren van waarden belangrijk is. Twee van onze kernwaarden die de grootste impact hebben op het succes van ons persoonlijk werk met klanten zijn \u2018openheid\u2019 en \u2018verantwoordelijkheid\u2019. Ik heb daar eerder ook een artikel<\/a> aan besteedt.<\/p>\n
\n<\/strong>De menselijke spirit is van \u2018gewoon door blijven gaan\u2019. We vinden een goede programmeur of team op afstand en sturen de eisen op en verwachten dat het op die manier goed uitpakt. Ik heb geleerd dat het cruciaal is wanneer je werkt met mensen op afstand, cultuurverschillen of een andere taal, dat je afspraken maakt over \u2018hoe je te werk gaat\u2019. Als je hier van te voren niet over nadenkt en mensen op dezelfde manier werken zoals ze gewend zijn, tenzij ze bij toeval de juiste routines hebben ontwikkeld, zal je offshore project falen.<\/p>\n
\n<\/strong>Technologische ontwikkelingen hebben hierbij veel geholpen. Veel mensen gebruiken tools zoals Jira, pivotaltracker, github en bitbucket, maar 7-8 jaar geleden werd er vooral met email en skype gewerkt. Als je niet vanaf het begin een overzicht maakt, gebruik makende van een online tool dat communicatie, status, bugs, vragen, etc. bijhoudt; zal je project na de tijdje ontsporen.<\/p>\n
\n<\/strong>Het opvallende is dat deze methode absoluut kan werken, we hebben een aantal klanten die alleen via chat werken, die tevreden zijn. Maar wat dat je mist is de persoonlijke relatie en de verbale communicatie. Ook neemt het meer tijd in beslag dan praten. Het is veilig om achter je pc te zitten, dat geldt zeker voor programmeurs op afstand. Maar het is belangrijk dat je een relatie opbouwt en effici\u00ebnt kan werken daardoor. Scrum is een van de instrumenten die je helpt bij het werken op afstand. Scrum werkt alleen via praten en video en niet met chat.<\/p>\n
\n<\/strong>Toen ik begonnen was met Bridge, werkte ik alleen maar met leveranciers. Degene waar ik mee werkte kregen problemen met het aantal programmeurs dat ze hadden om de hoeveelheden werk te verwerken. Waardoor je uitbreidt naar andere partners. Het is moeilijk om de juiste partner te vinden en dat kost ook tijd. Maar ik heb geleerd dat daar ook de tijd voor moet nemen. Ik heb ook geleerd dat het voor ons beter werkt om onze eigen mensen te hebben, want zo kunnen we zelf beslissen wie we aannemen. Gebaseerd op skills en kennis, maar ook op waarden, hoe ze werken, hoe we een team spirit op kunnen bouwen en hoe we comfort en geluk cre\u00ebren in ons team. Daarover heb ik vorig jaar een artikel<\/a> over geschreven.<\/p>\n
\n<\/strong>Hier heb ik ook een belangrijke les geleerd: om offshore co\u00f6peraties succesvol te maken, moeten er zo min mogelijk managers tussen de klant, die vraagt om de creatie van een software programma, en de persoon die het programma creeert, zitten. We hebben projecten gehad waarin een eindklant een webshop wilde, hiervoor een uitgever inhuurde, die op hun beurt een web agency inhuurde, die vervolgens ons inhuurde, en wij huurden uiteindelijk een nearshore team. Vanuit ieder bedrijf was een project manager betrokken, dat betekent op zijn minst 5 project managers. Als \u00e9\u00e9n slaapt, faalt het project. Het beste scenario voor een succesvol project is wanneer de eindklant direct met de programmeur praat. Wanneer de skills hiervoor ontbreken, kan een web agentschap ingehuurd worden om op afstand te praten met de programmeur. Een positieve bijkomstigheid van deze methodiek is het besparen van kosten!<\/p>\n<\/p>\n<\/p>\n
\nAlthough it seems easy to hire good programmers, because you can objectively judge the quality of ones code and you can reasonably judge the analytical skills, it’s less easy in reality. For having good remote collaboration, technological or analytical skills are only part of the equation. Communication is the most crucial aspect and it’s important to recruit for that skill. I also learned that hiring for values is crucial. Two of our core values that have the biggest impact on the success of our intimate work with customers are ‘openness’ and ‘responsibility’. I have dedicated another article <\/a>to these too earlier.<\/p>\n
\n<\/strong>The human spirit is to ‘just get going’. We find a good remote programmer or team and send requirements and expect it to work out just like that. I have learned that it’s crucial when you work across distance, cultures and language to have a common understanding of ‘how you are going to work’. If you don’t think about this upfront and people just do what they are used to, unless they by accident build the right routines, you’ll build the wrong ones and your offshore project will fail.<\/p>\n
\n<\/strong>Technological advancements have helped a lot here, most people use tools like Jira, pivotaltracker, github and bitbucket, but 7-8 years back most remote work was just started by email and skype. If you don’t create an overview from the beginning using some online tool that tracks communication, status, bugs, questions, etc; your project will over time derail.<\/p>\n
\nThe striking thing is that this can absolutely work, we have several clients that work only through chat and are satisfied. But what you miss is the personal relationship and the verbal communication. It also takes more time than talking. It’s safe to be behind the pc, certainly for remote programmers. But it’s also important to build that relationship and to work efficiently. Scrum is one of the instruments that helps remote work most and scrum goes with talking and video, not chat.<\/p>\n
\n<\/strong>When I started Bridge I had only suppliers to work with. The ones I worked with soon appeared to be having too little programmers to process the work. So you branch out to other partners. It is hard to find the right partner and it takes time. But I have learned that you should take the time. I have also learned that for us it works better to have our own people, because we can decide whom we hire (on skills and knowledge, but also on values), how they work, how we build a team spirit, how we create some comfort and happiness among our team. I wrote an article<\/a> last year about this topic.<\/p>\n
\n<\/strong>Here I also learned an important lesson: for offshore cooperations to be successful, there should be as few managers in between the person asking to create a software application and the person building it. We used to have projects in which an end client wanted a webshop, hired a publishing agency for this, who hired a web agency, who hired us and we hired a nearshore team. In each company there was a project manager involved, which means at least 5 project managers. If one is sleeping, the project fails. So the best version is the end customer talking to the programmer and if he doesn’t possess the skills for that, he can hire a web agency who talks to the remote programmer. A side effect is that you save some extra costs along the way!<\/p>\n![\"\"](\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2013\/03\/031.jpg\" "\\"03\\"")
<\/a><\/p>\n