W tym wpisie chciałbym się skupić na faktach i mitach związanych ze współpracą z Indiami. Nie będzie hejtu, tylko suche fakty – jak jest i dlaczego. Zaprezentowane przykłady są studium moich przypadków oraz moich znajomych. Możliwe, że masz inne doświadczenia i odczucia.

Zacznijmy od popularności Indii jako kierunku outsourcingu usług IT – istnieją co najmniej 2 powody (poza kosztami usług) – strefa czasowa, która w miarę pokrywa się z Europą (3,5-5,5 godzin różnicy) oraz angielski jako oficjalny język w dużej grupie ludności. Dodatkowo sporo osób emigrowało do UK czy USA, gdzie dali poznać się jako ludzie przykładający się do pracy i dający dobre efekty. To dodatkowo przekonało wiele firm do otwierania oddziałów w Indiach.

Duża popularność usług IT w Indiach i gigantyczne tempo ekspansji zachodnich firm w Indiach, spowodowała szybki drenaż wykształconych zasobów (ważne! w lokalnej nomenklaturze jesteś tylko zasobem, a nie człowiekiem – przeraża mnie taka perspektywa bycia łatwo zastępowalnym klocuszkiem, zamiast wartościową jednostką!), co spowodowało wciąganie osób bez kwalifikacji. Innym aspektem, który w tym zjawisku należy rozważyć jest niesamowita bieda i system kastowy. Tylko wciągnięcie do dużo lepiej płatnej pracy daje im szansę na godne życie. Niestety, jak już wspomniałem, często są to osoby bez właściwych kwalifikacji technicznych, dla których nawet obsługa komputera potrafi stanowić nowość.

Kolejnym aspektem dostępności ekspertów jest częstotliwość zmian pracy wynikająca z lepszych warunków pracy na wyższych stanowiskach. Hindusi są gotowi zmienić pracę częściej niż Europejczycy czy Amerykanie i dzięki temu przejść z juniora do seniora w 2 lata, a następnie przeskoczyć na managera. A w Indiach manager to osoba dużo bardziej poważana niż u nas i dużo lepiej nagradzana przez pryzmat lokalnych warunków niż programista czy tester.

Ponadto w lokalnej kulturze nie istnieje możliwość odmówienia wykonania polecenia względem przełożonego, nawet jeśli ktoś nie ma pojęcia co i jak ma zrobić, albo z góry zdaje sobie sprawę z tego, że jest to nierealne. Osobiście spotkałem się z tym kilkukrotnie – w pierwszym przypadku nasz dyrektor zobowiązał managera do dostarczenia dużego modułu mimo, że wydawało się to nierealne – manager zaakceptował polecenie, mimo, że w jego głosie słychać było bardzo wyraźnie niepewność i wątpliwość. Kolejne sytuacje dotyczyły współpracy na linii programista – DevOps i programista – tester. Poprosiłem o wykonanie kilku rzeczy, z mojego punktu widzenia prostych. Natomiast były one złożone z punktu widzenia, które miały to wykonać. Początkowo potwierdziły, że zrobią, ale po ponownym pytaniu – usłyszałem, że nie wiedzą co/jak mają zrobić i konieczne było ponowne wytłumaczenie i zebranie potwierdzenia czy zrozumieli i wiedzą. Druga iteracja w tych przypadkach była skuteczna, niestety nie zawsze tak jest i czasem należy powtórzyć kilkukrotnie zmieniając sposób tłumaczenia. Pamiętajmy, że jeśli coś tłumaczymy w sposób, który jest dla nas jasny, niekoniecznie jest jasny dla drugiej strony. Może trzeba wykonać dodatkowy rysunek albo zmienić słownictwo? Przypadki są bardzo indywidualne.

Nie chcę oceniać narodowych możliwości co do twórczości i kreatywności wspomnianego narodu, natomiast osobiście nie współpracowałem jeszcze z bardzo dobrym lub wybitnym programistą .NET z Indii. Zdarzyli się przeciętni i fatalni (np. zadanie, które mi zajęło 2 godziny programistka z Indii robiła 2 tygodnie). Jednakże w takich dziedzinach jak bazy danych i SQL, poznałem takich, którzy potrafią działać cuda. Z testerami, jak już zauważyłem, bywa różnie. W pewnym projekcie przetestowali płatność przelewem płacąc kartą kredytową. Brzmi jak żart? Ale tak naprawdę było…

Biorąc pod uwagę wspomniane już zjawiska, warto wrócić do emigracji. Bardzo dużo utalentowanych ludzi opuściło Indie za lepszą pracą i warunkami dla swojej rodziny. To tylko pogłębiło dysproporcje pomiędzy utalentowanymi ludźmi, którzy zostali “na miejscu”, a “świeżakami”.

Skutkiem tych wszystkich działań są potężne ilości kodu, które mają wątpliwą jakość, stabilność, a jeszcze gorsze bezpieczeństwo. Znam przykład aplikacji, gdzie 100% walidacji danych było zrobione na frontendzie. Aplikacja wystawiona publicznie do internetu. Chyba wszyscy wiemy jak to się mogło skończyć. Na szczęście zostało to dość szybko wyłapane i załatane.

Dodatkowym aspektem kulturowym, na który warto spojrzeć są urlopy. Dość często zdarzała mi się dostać maila, że kogoś dzisiaj nie ma. W Polsce taki urlop na żądanie można wziąć 4 razy do roku (jeśli ktoś jest na etacie), natomiast we tej współpracy zdarza się to średnio 1-2 razy na miesiąc.

Kolejnym aspektem wartym omówienia jest dokładność wykonywania zadań. Tutaj bywa różnie – kiedyś pewna osoba miała skonfigurować serwer SQL wg instrukcji, 2 node’y. Oba były skonfigurowane inaczej. Takich przypadków mógłbym mnożyć dziesiątkami. Niemniej jednak ważnym elementem takiej współpracy jest przygotowywanie bardzo dokładnych instrukcji, w tym zawieranie bardzo dużej ilości screenshotów.

Jak to wszystko rzutuje na współpracę?

Dużo powtarzalnych zadań (np. DevOps, testy manualne) powierza się Indiom, natomiast droższym, “zachodnim” ekspertom powierza się programowanie i architekturę systemów.

Dodatkowym czynnikiem jest zrozumienie kulturowe. Często od nas oczekuję się zrozumienia drugiej strony, ale w drugą stronę to nie działa (tzn. oczekiwanie, żeby osoby w Indiach respektowały naszą kulturę pracy).

Jakość współpracy jest często fatalna, gdyż na samo hasło “Indie” wiele osób w branży dostaje spazmów i niestety nie pochodzi to z mitologii jak wygląda współpraca tylko z osobistych doświadczeń. Niemniej jednak pamiętajmy, że zawsze to ludzie tworzą projekt i atmosferę. Przy odpowiednim szkoleniu, powinno być coraz lepiej.