Projekt Indie #1 – Wprowadzenie

Jeszcze kilka lat temu co styczeń pisałem podsumowanie roku ubiegłego i plany na rok następny. Od jakiegoś czasu porzuciłem ten pomysł. O ile podsumowanie jest fajną ciekawostką, to plany kompletnie się nie sprawdzają. Czasami w styczniu myślę sobie o kolejnym nudnym dniu w pracy, a w kwietniu jadę do Indii żeby zapoznać się ze swoim nowym zespołem 🙂

Tak, to nie pomyłka. Oficjalnie od kwietnia 2022 jestem „Tech Leadem” zespołu Offshore składającego się z 10 osób i mającego swoją kwaterę główną w Nowym Delhi w Indiach. Nieoficjalnie jestem jego szefem (stąd tak mało pisałem w ciągu roku), a dlaczego tak jest, mam nadzieję wyjdzie w późniejszej części wpisu.

Ten artykuł ma mieć w założeniu dwojaki charakter. Po pierwsze chciałem opowiedzieć trochę o samych Indiach i podróży tamże. Po drugie – o zespole Indusów (nie „Hindusów”) i współpracy z nimi. Takie podejście może sprawić, że artykuł będzie zbyt rozwodniony, albo że będzie ciekawy i dla programistów i dla osób postronnych. Zobaczymy.

Jedna uwaga na początek: ten artykuł powstał wyłącznie z mojej inicjatywy i zawiera wyłącznie moje spostrzeżenia i odczucia. Kładę duży nacisk na nieodkrywanie szczegółów technicznych i biznesowych firmy, która mnie zatrudnia oraz firmy z Indii. Jeżeli zauważysz coś, co może stanowić takie naruszenie, powiadom mnie proszę o tym. Zależy mi, żeby jeszcze trochę tu popracować 🙂

Jedziemy.

W pierwszym kwartale mijającego roku otrzymałem wiadomość, że będziemy zatrudniać zespół z dalekiego Wschodu.

Moje uczucia były mieszane. Z jednej strony wszyscy słyszeli o jakości pracy zespołów Indyjskich czy problemami z komunikacją werbalną i niewerbalną (chociażby ich słynny akcent czy dziwne kiwanie głowami) i to na pewno było coś, czego się obawiałem.

Z drugiej strony jest to jednak wielkie wyzwanie. Odskocznia od udręki codziennego robienia tego samego. Coś nowego, ciekawego. A gdy do tego dołożymy wiadomość, że góra zadecydowała, że z okazji zawiązania zespołu pojedziemy do nich z wizytą, rozumiecie sami, że byłem tym wszystkim bardzo podekscytowany.

Zanim jednak zaczęliśmy współpracować powstał przed nami problem znalezienia im odpowiedniego zadania.

Zadania o odpowiedniej wielkości (projekt miał trwać rok), nie bardzo związanego z domeną (obracamy się w bankowości, mega trudna dziedzina, praktycznie niemożliwa do załapania w rok), które można łatwo dzielić na mniejsze klocki, i tak dalej i tak dalej.

Co ciekawe – szczęśliwie znalazło się takie! Z grubsza, chodziło o wewnętrzne API, które nasz główny system eksponuje i za pomocą których można się z nim komunikować. Metody API (zwane dalej CallApi, bo tak je wewnętrznie nazwaliśmy) mają bardzo ciekawą budowę. Jest ich ponad dwa tysiące i wszystkie kropka w kropkę przyjmują i zwracają łańcuchy znaków. Dane przekazywane są w nich jako pary klucz/wartość.

Z jednej strony mega elastyczne rozwiązanie, które niesamowicie ułatwia dokładanie nowych wartości. Z drugiej, koszmar do utrzymania. A że nasz system jest bardzo dojrzały i stabilny, większy nacisk kładziony jest właśnie na utrzymanie. Wszyscy od dawna marzyliśmy o zamianie stringów na silnie typowane obiekty, więc pomysł przepisania naszych CallApi wydał się idealnym kandydatem na pracę dla zespołu Offshore.

Każda metoda z ponad dwóch tysięcy to jeden „backlog item”, możliwy do wzięcia przez jednego programistę. Średnio przepisanie jednej nie powinno zająć więcej niż dzień samego programowania, nie licząc oczywiście testów. Przy 200 dniach roboczych i 6 programistach daje to 1200 metod w rok. Jako że nie wszystkie z tych 2000 są równie ważne (a niektóre nawet nieużywane), po odpowiedniej priorytetyzacji powinniśmy po roku mieć śliczne nowe CallApi. Tak wtedy w swojej naiwności myśleliśmy.

Co się stało i dlaczego nie było to coś, czego się spodziewaliśmy, już w następnych odcinkach. Ale najpierw uraczę Was opowieścią o wyjeździe do Indii.