Pozwólcie, że opowiem wam nieco o podejściu do lokalizacji w Infobip. Jako globalna platforma komunikacyjna dla firm i programistów nieustannie dążymy do ulepszania naszego procesu lokalizacji, zwłaszcza jeśli chodzi o dostosowanie go do naszej zwinnej struktury organizacyjnej.
Z tego powodu postanowiliśmy niedawno rozpocząć kolejną rundę badań i eksperymentów, które przyniosły interesujące, a nawet zaskakujące wyniki.
Lokalizacja i tworzenie oprogramowania: podstawy
Ale najpierw, czym jest lokalizacja i co ma wspólnego z tworzeniem oprogramowania? Lokalizacja to dostosowanie produktów i treści do konkretnej lokalizacji, którą może być region lub kraj, aby zapewnić ich funkcjonowanie w danym środowisku kulturowym i językowym.
W Infobip skupiamy się na ciągłej lokalizacji. Jest to najnowsza forma lokalizacji, zaprojektowana w celu rozwiązania problemów, z którymi zazwyczaj borykają się firmy programistyczne podczas wdrażania lokalizacji do swoich cykli tworzenia oprogramowania. Jest to niezwykle pomocne dla firm posiadających kilka zespołów inżynierów.
Problem z tradycyjną lokalizacją
W dzisiejszych czasach oprogramowanie jest równoznaczne z elastycznością. Oznacza to krótkie cykle wydawania nowych wersji, czyli programiści często wprowadzają niewielkie dodatki i zmiany do produktów oprogramowania. Te niewielkie, powtarzające się wydania również wymagają lokalizacji, więc wszyscy zaangażowani w proces lokalizacji – niezależnie od tego, czy są to dostawcy usług językowych, firmy tłumaczeniowe czy zespoły wewnętrzne – również powinni być elastyczni.
Niestety, świat lokalizacji nadal pozostaje w tradycyjnym sposobie myślenia – stosuje się powolną, liniową metodę kaskadową, polegającą na wykonywaniu skończonych kroków jeden po drugim, przed przejściem do następnego. Ta stara metoda może nadal działać w niektórych branżach (prawie), ale w przypadku firm produkujących oprogramowanie nie da się uniknąć problemów związanych z wąskimi gardłami – ponieważ wszystko musi być wykonywane znacznie szybciej.
Wyzwanie Infobip
Spójrzmy na przykład na naszą własną sytuację. Nasze produkty (UI) zawierają około 95 000 słów. Może się zdarzyć, że będziemy musieli przetłumaczyć na 11 języków tekst składający się z zaledwie 120 słów w ciągu 48 godzin.
Każdy dostawca usług językowych, z którym się skontaktowaliśmy, musiałby:
wyjaśnić wymagania i zaakceptować projekt
skontaktować się z maksymalnie 11 dostawcami
potwierdzić ich dostępność i znaleźć zastępców dla tych, którzy nie są dostępni lub nie reagują w tak krótkim czasie
nadzorować postępy projektu
odpowiadać na pytania i rozwiązywać problemy
sprawdzać ukończenie tłumaczeń i dostarczać je
wystawiać faktury klientowi i płacić dostawcom
Ze względu na wymagania zazwyczaj napotykaliśmy trzy problemy: minimalne opłaty pobierane przez dostawców usług językowych i ich podwykonawców, napięte terminy oraz obniżona jakość. Należy tu również zauważyć, że dostawcy usług językowych mają oczywiście dużo pracy, co utrudnia im nadążanie za naszym ciągłym napływem małych projektów.
Ciągła lokalizacja zawsze była naszym celem w Infobip, ale biorąc pod uwagę wszystkie powyższe ograniczenia, była ona w najlepszym razie „półciągła”. Dlatego niedawno rozpoczęliśmy eksperyment o niskim ryzyku i wysokich zyskach, aby sprawdzić, czy możemy uczynić nasz proces lokalizacji naprawdę ciągłym. Innymi słowy, chcieliśmy sprawdzić, czy możemy dopasować nasz proces lokalizacji do naszej zwinnej struktury organizacyjnej.
Inspiracja dla Infobip: 12 zasad Manifestu Agile
Kiedy zastanawialiśmy się, dlaczego prawdziwa ciągła lokalizacja jest tak trudna, zdaliśmy sobie sprawę, że musimy całkowicie odejść od sekwencyjnego podejścia do projektów lokalizacyjnych opartego na modelu kaskadowym. Czy było to w ogóle możliwe?
Okazało się, że grupa programistów stanęła przed tym samym wyzwaniem już w 2001 roku. Przeciwstawili się metodzie kaskadowej, proponując swój Manifest Agile, aby tworzyć oprogramowanie w inny sposób. 20 lat temu zrewolucjonizowało to tworzenie oprogramowania i nadal jest aktualne, bardziej niż kiedykolwiek.
Podejście zwinne a podejście kaskadowe
Wprowadzając kilka zmian do oryginalnego Manifestu, opracowaliśmy kilka zasad dotyczących tego, jak sprawić, by lokalizacja również była elastyczna.
Oto nasze 12 wytycznych dotyczących ciągłej lokalizacji:
Publikuj tłumaczenia wcześnie i poprawiaj je później – nie czekaj na idealnie zweryfikowane tłumaczenia.
Bądź gotowy na ciągłe aktualizacje treści – nie proś o wstrzymanie prac programistycznych, ponieważ opóźni to wprowadzenie produktu na rynek.
Nawiąż współpracę w całej firmie – nie izoluj zespołu lokalizacyjnego.
Polegaj na ludziach, zaufaniu i pracy zespołowej – nie stosuj stylu dowodzenia i kontroli w dziale lub programie lokalizacyjnym.
Priorytetowo traktuj bezpośrednie metody komunikacji z tłumaczami i innymi interesariuszami – nie polegaj na pośredniej komunikacji za pośrednictwem dostawcy usług językowych.
Zbieraj opinie od użytkowników końcowych – pokażą Ci one, co naprawdę ma znaczenie, i będą prawdziwą miarą jakości.
Stwórz ciągły, skalowalny proces – proces nie może ulec opóźnieniu, jeśli zespół lokalizacyjny jest niedostępny.
Stale ulepszaj narzędzia i system lokalizacji – nie oczekuj, że jakiekolwiek ogólne oprogramowanie innych firm zaspokoi wszystkie Twoje potrzeby, nadal konieczne jest pewne wewnętrzne opracowanie.
Zautomatyzuj lub zminimalizuj pracę ręczną – nie polegaj na zarządzaniu projektami przez ludzi lub zaangażowaniu ludzi, jeśli można to zautomatyzować.
Pozwól zespołowi lokalizacyjnemu wybrać sposób pracy – nie nalegaj na ściśle określone procedury.
Regularnie dokonuj ponownej oceny procesów i planów – nie pozwól, aby minęły lata bez wprowadzenia niezbędnych zmian.
Eksperyment – niskie ryzyko, wysokie zyski
Chcieliśmy przetestować te zasady, więc przeanalizowaliśmy wszystkie etapy naszego procesu lokalizacji, usunęliśmy kilka z nich, a następnie zastanowiliśmy się, jak zwiększyć efektywność pozostałych. Zasady agile sprawdziły się bez wyjątku.
Jedną z kluczowych zmian w naszym eksperymencie było przeformułowanie roli dostawcy usług językowych – wyobrażaliśmy sobie go jako trzecią jednostkę obok tłumaczy i klienta (nas), a nie jako pośrednika między klientem a tłumaczami.
Kiedy znaleźliśmy odpowiedniego dostawcę usług językowych (Beluga Linguistics), wybraliśmy język szwedzki jako język testowy i stworzyliśmy nasz nowy trójkąt: klient, dostawca usług językowych i dwóch niezależnych tłumaczy. Zrezygnowaliśmy z wszelkich praktyk kaskadowych, korzystając z technologii i komunikując się ze sobą w ramach trójkąta.
Oprócz zmian w strukturze i komunikacji przejęliśmy również umowy i płatności dla freelancerów (obsługiwane za pomocą kilku kliknięć, przy użyciu technologii zewnętrznej) i poprosiliśmy dostawcę usług językowych przede wszystkim o wsparcie w zakresie zarządzania zespołami freelancerów i procesem jakości. Wyeliminowało to wszelkie możliwości konfliktu interesów między nami a dostawcą usług językowych i sprawiło, że wszyscy byliśmy całkowicie zorientowani na ostateczny cel – szybszą i lepszą lokalizację.
Korzyści płynące z rzeczywistej ciągłej lokalizacji
Odkryliśmy, że ta nowa, trójkątna konfiguracja w końcu umożliwiła rzeczywistą ciągłą lokalizację i przyniosła korzyści wszystkim zaangażowanym osobom.
Korzyści dla firm produkujących oprogramowanie:
Brak konieczności opóźniania premiery produktów – gdy były one gotowe pod względem kodu i marketingu, natychmiast wysyłano je do tłumaczenia i wprowadzano na rynek.
Wszelkie problemy językowe można było natychmiast rozwiązać – niezależnie od tego, czy dotyczyły one języka źródłowego, czy tłumaczenia.
Korzyści dla tłumaczy:
Otrzymywali odpowiednie wynagrodzenie, szybko i w całości – bez potrąceń bankowych ani żadnych dodatkowych opłat.
Bezpośrednia komunikacja z klientem – bez konieczności oczekiwania na odpowiedzi lub wyjaśnienia za pośrednictwem dostawcy usług językowych.
Korzyści dla dostawców usług językowych i biur tłumaczeń:
Brak terminów i obowiązków administracyjnych, o które trzeba się martwić.
Gwarantowany stały miesięczny dochód, podobny do wynagrodzenia ryczałtowego.
Warto zauważyć, że biorąc pod uwagę fakt, iż produkty Infobip nie zagrażają życiu, mogliśmy pogodzić się z okazjonalnymi niedoskonałościami tłumaczeń. Pozwoliło nam to przyspieszyć wprowadzenie produktu na rynek, a także umożliwiło lokalnym pracownikom Infobip przeprowadzenie przeglądu interfejsu użytkownika w kraju, a nie w abstrakcyjnym kontekście TMS. Aby to osiągnąć, musieliśmy najpierw rozłożyć nasz proces lokalizacji (z technicznego punktu widzenia) – pozwoliło nam to naprawić wszelkie błędy tłumaczeniowe i opublikować zmiany w produkcji w zaledwie 10 minut, tyle razy, ile było to konieczne w ciągu dnia.
Zalecenia dla firm zajmujących się oprogramowaniem
Podsumowując, nasz eksperyment zakończył się sukcesem i pokazał, jak skuteczna może być ciągła lokalizacja, jeśli jest przeprowadzana prawidłowo.
Trójkąt lokalizacji rozwiązany
Nie ma nic lepszego niż bezpośrednie doświadczenie, aby nauczyć się podstaw i zobaczyć, jak można przeprowadzić lokalizację w Twojej firmie, ale oto kilka wskazówek – opartych na wnioskach wyciągniętych z naszego eksperymentu – które powinny pomóc Ci w tym procesie:
Firmy zajmujące się oprogramowaniem powinny naprawdę pomyśleć o zachowaniu kontroli nad procesem lokalizacji. Żadna osoba z zewnątrz nie zrobi tego lepiej niż Ty.
Pamiętaj, że tłumaczenie to współpraca między ludźmi, a nie anonimowy łańcuch, więc dbaj o wszystkich zaangażowanych i czerp korzyści z efektywnej współpracy.
Określ oczekiwania na wczesnym etapie i zaufaj ludziom, że wykorzystają swoją wiedzę.
Daj tłumaczom przestrzeń i zachęty finansowe, aby mogli poznać Twoją firmę.
Często przeprowadzaj małe kontrole i eksperymenty, aby wszyscy mogli się doskonalić.
Ten ostatni punkt jest jednym z najważniejszych i prawdopodobnie najczęściej pomijanych. Agile polega na iteracjach, testowaniu i dostosowywaniu, więc nie bój się zastosować tego eksperymentalnego podejścia również w procesie lokalizacji, a wkrótce zaczniesz czerpać korzyści z ciągłej lokalizacji w swojej firmie programistycznej.
