„Zarządzanie projektami lokalizacyjnymi”

Sponsorzy konferencji:

Patronat konferencji:

:

Organizator:

:Partnerzy konferencji:

„Zarządzanie projektami lokalizacyjnymi”

Prowadzący: dr inż. Agenor Hofmann-DelborLSP Software, Moravia [email protected]

2/46„Rynek tłumaczeń i lokalizacji w Polsce”, Kraków, 27-28 marca 2010

Plan prelekcji

• Kiedy „zarządzamy projektami”?

• Z czym wiąże się wybór metodyki zarządzania projektami

• Cykl prac/zadań przy projekcie lokalizacyjnym

• Cel projektu, sytuacje awaryjne

• Zarządzanie zasobami

• Metoda „leniwego kierownika projektu”

• Komunikacja w projekcie

• Konsekwencje podziału projektu

• Terminy a zmiany w projekcie

• Techniczne uwarunkowania projektów


Ile jest tłumaczenia w lokalizacji?

50%Wydatki ponoszone na:•zarządzanie projektem•przygotowanie plików•kontrola wersji•identyfikacja plików•obróbka końcowa•dostawa

35%Łączne wydatki na przetłumaczeniei sprawdzenie treści

15%Koszty wytworzenia zasobów językowych do ponownego wykorzystania w kolejnych projektach


Zarządzanie projektami od podstaw

Prosta zasada – osiągnięcie celu przy określonych zasobach

Obecnie funkcjonują dziesiątki różnych metodologii zarządzania projektami.

Najpopularniejsze to: Six Sigma, Prince2, The Ten Steps etc.

Większość z nich funkcjonuje na rynku od kilku dziesięcioleci.

Wszystkie sprowadzają się do wykonania dwóch podstawowych czynności:

1. Budowania planu

2. Czuwania nad realizacją planu

Misje ratunkowe a specjaliści od zarządzania projektami

Zarządzanie projektem lokalizacyjnym może być realizowane dzięki klasycznym technikom i metodom zarządzania projektami.


Dwa główne etapy zarządzania projektami

Waga Lp Zadanie

20 1 Określenie celu projektu

20 2 Sporządzenie listy zadań

10 3 Określenie kierownika projektu ("Project must have one leader")

10 4 Znalezienie osób do wykonania zadań

10 5 Zabezpieczenie ryzyka projektowego, zarządzanie "oczekiwaniami"

Waga Lp Zadanie

10 6 Odpowiednie zarządzanie projektami

10 7 Orientacja w bieżącej sytuacji

10 8 Przekazywanie informacji o bieżącej sytuacji

0 9 Powtarzanie kroków od 1 do 8 aż do końca projektu

0 10 Wykonanie tzw. „post mortem” - podsumowanie projektu

Planowanie projektu

Realizowanie projektu


Określanie celu projektu

Projekty najczęściej kończą się niepowodzeniem, gdy od początku nie jest możliwe ich zrealizowanie. Każdy projekt uwarunkowany jest trzema czynnikami:

Czasem, pieniędzmi i zasobami

Bardzo istotne jest określenie granic projektu – co należy do zadań kierownika projektu (a co nie) i reagowanie na ewentualne zmiany zakresu zadań. Określenie celu projektu przynosi odpowiedź na pytanie – skąd będę wiedzieć, że projekt się zakończył? Co i kiedy określa ów koniec?

Lista uczestników projektu – dla każdego odpowiedź na powyższe pytanie będzie inna. Podobnie z listą „warunków sukcesu”. Każdy uczestnik różnie je określi.

Przykładowi uczestnicy projektu: my, nasz szef, inni pracownicy, potencjalni pracownicy, nasi klienci, klienci naszych klientów itd.


Problem prognozowania przyszłości jest podstawowym problemem związanym z zarządzaniem projektami. Wszelkie błędy popełnione na tym etapie mają poważne konsekwencje w przyszłości, dlatego istotne jest zminimalizowanie ich liczby.

Najczęściej pomocne jest odwołanie się do już ukończonych, podobnych projektów i przejrzenie listy zadań, czasu ich przetwarzania etc. W przypadku nowych projektów kluczowe jest rozbicie zadań na możliwie najmniejsze składniki tak, aby nie pominąć żadnej z istotnych czynności mających wpływ na projekt.

Należy wyróżnić dwa pojęcia:

Czas trwania – mierzony w jednostkach czasu, np. mecz piłki nożnej – 90 minut

Nakład pracy – ile jest pracy do wykonania na określonym stanowisku w ramach projektu. Mierzony zwykle w roboczogodzinach, dniach roboczych itp. W przypadku meczu to czas pracy 22 zawodników, sędziego, dwóch liniowych, jednego technicznego, co daje 26x90 minut, około 39 godzin roboczych.

Obie informacje umożliwiają ocenę – jak długo potrwa projekt i ile będzie kosztować.

Sporządzanie listy zadań [1/2]


Schemat rozłożenia pracy – przykład

Projekt X

1. Wymagania

2. Projektowanie

3. Budowa systemu

4. Testowanie systemu w dziale IT

5. Testowanie systemu przez użytkowników

5.1. Pierwsza runda testów 3 dni [to jedynie przypuszczenie]

5.2. Dział IT poprawia błędy 2 dni [tak samo jak 2 dni]

5.3. Druga runda testów 3 dni [zakładając, że powtarza się wszystkie testy]

5.4. Dział IT poprawia błędy 1 dzień [zakładając, że znaleziono mniej błędów]

5.5. Ostatnia runda testów 3 dni [zakładając, że nie zostaną wykryte kolejne błędy]

W rzeczywistości rund testowych jest znacznie więcej

Sporządzanie listy zadań [2/2]


Każdy projekt musi mieć jednego nadzorcę, który na każdym etapie upewni się, iż wykonywane są

wszystkie zadania, które zdefiniowano na liście zadań.

Wiąże się to z licznymi obowiązkami i przede wszystkim – z odpowiedzialnością. To kierownik

projektu jest na pierwszej linii ognia w przypadku problemów z projektem.

Skąd wiedzieć ile czasu powinien spędzić kierownik projektu przy nadzorowaniu projektu?

Oczywiście nie ma zasady, ale zwyczajowo przyjmuje się, iż jest to ok. 10% całej wartości „pracy”

w projekcie, zwykle w odniesieniu do roboczogodzin.

Przykład: 4 osoby pracują na cały etat przez 10 tygodni. Nakład pracy to: 4x10=40 tygodni,

czyli 200 dni roboczych. Kierownik projektu powinien zatem poświęcić minimum 20 dni roboczych,

rozłożonych na cały czas trwania projektu, czyli 2 dni w tygodniu.

Ile jest zarządzania w… zarządzaniu


Jednym z najważniejszych zdań kierownika projektu jest utrzymywanie sprawnej komunikacji bieżącej w projekcie. Nie jest tajemnicą, że organizacje, w której przepływ informacji jest płynny, funkcjonują bardziej efektywnie.

Kluczową cechą będzie jest zapewnienie dostępności i szybkiej reakcji na zgłaszane problemy.

W trakcie projektu istotne jest przekazywanie informacji zespołowi, aby każdy miał informacje o bieżącym stanie projektu. Jest to także kluczowe na wypadek chorób, zdarzeń losowych itp.

Bardzo istotne jest zapewnienie przepływu informacji z feedbackiem dotyczącym wykonanej pracy.

Komunikacja w projekcie


Znalezienie osób, które wykonają dane zadanie to kwestia popytu i podaży. Popyt to efekt zbudowania planu razem z rozłożeniem zadań. Z planu wynika, iż potrzebna będzie określona liczba osób w danym czasie. Podaż w tym wypadku to liczba osób dostępnych w danym czasie.

Problemem zarządzania projektami jest to, iż z reguły w takim ujęciu popyt przewyższa podaż. Ludzie wykonują różne zadania, są często „współdzieleni” w ramach różnych projektów. Przy współpracy z freelancerami trudno liczyć na pełną dostępność (i wydajność) danej osoby.

Zarządzanie zasobami [1/3]


Zadaniem kierownika projektów jest zatem zapewnienie płynności pracy przy wykorzystaniu zasobów na miarę ich możliwości i dostępności. Odbywa się to w kilku etapach:

1) Określenie listy osób dostępnych w danym projekcie

2) Określenie stopnia dostępności danej osoby do wykonywania danej pracy. Jeśli dany pracownik jest 1 dzień w tygodniu, to wykonanie zadania na 10 dni potrwa 10 tygodni.

3) Umieszczenie wszystkich informacji na wykresie Gantt’a, który uwidoczni słabe i mocne strony planu

4) Zapewnienie bezpieczeństwa projektu….



Przykład wykresów Gantta’a

Powiązane z zadaniem Powiązane z konkretną osobą



Każdy plan bez mechanizmów zarządzania bezpieczeństwem jest narażony na porażkę. Praca zawsze narażona jest na działanie czynników losowych, które zgodnie z prawami Murphy’ego mają tendencję do nasilania się przy szczególnie istotnych momentach. Są dwa sposoby zminimalizowania tego problemu:

1) Uwzględnienie marginesu bezpieczeństwa w planie projektowym (Contigency)

2) Wykonanie pełnej analizy ryzyka w ramach projektu

Zapewnianie bezpieczeństwa projektu [1/2]


Analiza ryzyka składa się z kilku etapów:

•Identyfikacji czynników ryzyka

•Ocena prawdopodobieństwa wystąpienia danego czynnika (w skali 1-3)

•Ocena wpływu wystąpienia danego czynnika (w skali 1-3)

•Mnożąc wpływ przez prawdopodobieństwo otrzymamy stopień narażenia projektu

•Czynniki ze stopniem 6 – 9 wymagają działań w ramach projektu, które trzeba umieścić w planie tak jak każde inne zadanie projektowe

Zapewnianie bezpieczeństwa projektu [2/2]

Nie ma ogólnej zasady jak duży powinien być owy margines błędu. Z reguły stosuje się jednak przynajmniej 15% rezerwę. Bufor bezpieczeństwa poniżej tej wartości stwarza zagrożenie dla projektu.


Analiza ryzyka - przykład


Dowolny projekt narażony jest na liczne zmiany w trakcie trwania. Wpływają one także pośrednio na wszystkich uczestników projektu, kluczowe jest zatem, aby informacje przekazywane były bez opóźnień. Z reguły dyskusja ze zleceniodawcą odbywa się w sytuacji, w której brak jest zasobów i czasu na wykonanie projektu.

Są wówczas możliwości przeniesienia ustaleń na inny poziom: tego co jest dostarczane (zawężenie podmiotu dostawy), kiedy (rozbicie dostaw na kilka etapów), rezygnacja z niektórych etapów pracy (budżet / jakość).

Ogólna zasada brzmi:

Lepiej odmówić przyjęcia projektu niż deklarować się podjęcia misji, która jest niemożliwa do spełnienia

A jak Państwo uważają?

Zmiany w trakcie trwania projektu


Powodem wielu problemów jest sama natura człowieka. Jeden kierownik będzie przywiązywać wagę do każdego szczegółu projektu i stosować tzw. micro-management, inny z kolei będzie zostawiać ludzi samych z ich pracą i polegać na nich. Stosowanie odpowiedniego podejścia zależy od typu pracownika:

Superstar (Pewniak)

-> Solid Citizen (Pewna firma)

-> Dogdy (Cwaniak)

-> Trainee (Żółtodziób)

-> Goner (Umarlak)

Nieoficjalna klasyfikacja współpracowników…


Upewniwszy się, że rozumiemy projekt, zagwarantowaliśmy w nim funkcjonowanie mechanizmów bezpieczeństwa i plan jest realny do wykonania, wystarczy już tylko kontrola jego wykonania.

Najprostszym sposobem jest codzienne wyodrębnianie z planu zadań wymagających jakichkolwiek działań ze strony kierownika projektu i ich wykonanie, ewentualne uzupełnienie planu na kolejne dni. To tzw. metoda „leniwego kierownika projektów”. Istotne jest także odnotowywanie wszelkich odstępstw od planu (opóźnień, zmian w dostępności zasobów, awarii). Konieczne jest także odnotowywanie wystąpienia zdarzeń losowych. Notatki tego typu są niezmiernie istotne na wypadek wznowienia projektu po dłuższej przerwie, bądź na wypadek podjęcia się nowego projektu, który wykazuje podobieństwo do już zrealizowanego.

W tym momencie wystarczy już tylko powtarzać podjęte działania aż do zakończenia projektu. Po jego zakończeniu bardzo istotne jest wykonanie podsumowania, tzw. post mortem projektu. Umożliwi to wskazanie słabych punktów i uniknięcie ich w przyszłości.

Zarządzanie w trakcie i po projekcie


HOMODU

ŁPaczka

Type

TRA Lus

PRF Lus

Total words

Tłumacz

Pobr.

Deadline Przydział Oddanie

Czas TRA

5 14188,2513716,6

523504 Przydz.: 5 TRA: 5 62,4

HO200708 P2

HO200708_P2_p0_both UA 976,6 1667,1 3361 Tłum1 18.09 2007-09-18 2007-09-19 6

HO200708 P2 HO200708_P2_p1 UA 4529,1 4968,4 5662 Tłum2 20.09 2007-09-18 2007-09-23 25

HO200708 P2

HO200708_P2_p2_both UA 2950,6 1640,0 3843 Tłum3 26.09 2007-09-25 2007-09-27 12

HO200708 P2

HO200708_P2_p3_both UA 3416,1 3917,1 4743 Tłum4 n/a 19.09 2007-09-18 2007-09-19 10,4

HO200708 P2

HO200708_P2_p4_both UA 2315,9 1524,1 5895 Tłum5 28.09 12:00 2007-09-26 2007-09-28 9

Przykład


Zarządzanie projektami w niektórych projektach wykracza poza klasyczne czynności kierownika projektu. Często kierownik projektu musi w zakresie swoich obowiązków uwzględnić następujące czynności:

• Wyodrębnianie materiału do tłumaczenia

• Transmisja danych, weryfikacja projektu

• Przygotowanie projektu

• Analiza projektu i jej przetwarzanie

• Tłumaczenie automatyczne

• Zarządzanie podzielonym materiałem

• Konsolidacja materiału i jego weryfikacja

• Testy QA, dostarczenie materiału zleceniodawcy

Project management a inżynieria lokalizacji


Po podjęciu decyzji o lokalizacji następują kolejne etapy:

1) Wyodrębnienie materiału

2) Analiza materiału w oparciu o istniejące pamięci tłumaczeń

Przygotowanie do lokalizacji nie obejmuje jednak tylko fizycznego przygotowania plików. Wymagane jest także:

- Ustalenie podstawowej terminologii

- Ustalenie osoby odpowiedzialnej za rozstrzyganie wątpliwości językowych

- Zapewnienie dostępu do nowych buildów aplikacji (lub przynajmniej próba… )

- Wybór optymalnej technologii lokalizacyjnej (oprogramowanie, standardy etc.)

Przygotowanie do lokalizacji


Istnieje wiele możliwości wyodrębniania materiału do lokalizacji, w zależności od formatu danych. Najczęściej mamy do czynienia z następującymi sytuacjami:

1) Plik PDF. Optymalnym sposobem jest uzyskanie źródła dokumentu: z reguły pliki w formatach Quark, InDesign lub FrameMaker, okazjonalnie doc. W skrajnym przypadku wykonuje się konwersję pdf -> doc ze wszelkimi jej konsekwencjami

2) Pliki UI – wybór zasobów do lokalizacji. Określenie, które moduły i biblioteki zostały zaktualizowane. Wybór określonych elementów. Przygotowanie metodyki lokalizacji / aktualizacji kolejnych wersji – w trakcie trwania procesu lokalizacji z całą pewnością będą generowane kolejne wersje buildu

3) Dokumentacja – wybór zbioru dokumentów (x)html lub chm, zrzut listy plików z systemu CMS

Wyodrębnianie materiału do lokalizacji


Eksport tysięcy plików z systemów zarządzania treścią jest powszechną praktyką. Najczęściej materiał jest w postaci fragmentarycznej, a nazwy plików wyglądają np. tak:Xzrg-0934-xcsz-oppazsdas-katastrofa.xml

Eksport i import z systemów CMS


Uwaga: nie za wszelką cenę, standardy mają nam pomagać, a nie przeszkadzać…

Standardy…


Okazjonalnie stosowane są systemy z własnymi protokołami transmisji lub specjalne aplikacje do transmisji danych między serwerami np. Microsoft Rainbow. Ich użycie było często konsekwencją prędkości transmisji, która była dostępna kilka lat temu – niezbędne było utrzymanie transmisji także w nocy przy zachowaniu szyfrowania danych. Duże projekty lokalizacyjne były przesyłane kilkanaście godzin.

Obecnie najczęściej stosuje się serwery FTP lub sFTP, bądź transmisję z wykorzystaniem protokołu SCP. Kluczowe są trzy kryteria:

Prędkość transmisji, bezpieczeństwo oraz poprawność danych.

Dane najczęściej kompresowane są do archiwum zip (z plikiem CRC). Dopiero po dotarciu do celu pliki są wyodrębniane i następuje porównanie zawartości archiwum z deklarowaną listą plików (liczba, wielkość w kb itp.)

Problem praktycznie przestaje już istnieć.

Transmisja danych, weryfikacja poprawności plików


Blokowanie tekstu do edycji

Przykład zablokowania części tekstu do edycji stylem TW4WinExternal

Tekst możliwy do edycji, wychwytywany przez funkcję analizy dokumentu

Nowoczesne formaty bilingwalne umożliwiają blokowanie tekstu do edycji w bardziej cywilizowany sposób, głównie oparty na konfigurowaniu ustawień dla konkretnych tagów.


Po wyodrębnieniu plików należy poczynić szereg czynności, które umożliwią realizację projektu. Na tym etapie najczęściej nie jest jeszcze możliwe bezpieczne rozpoczęcie pracy.

Część narzędzi wymaga przetworzenia przesłanych plików, by rozpocząć tłumaczenie lub nawet analizę. Pierwszym etapem będzie zatem zapewnienie możliwości lokalizowania określonego formatu. Gdy nie jest możliwa lokalizacja danego formatu pliku, zwykle realizuje się ją przez format pośredni (najczęściej tekstowy oparty na XML). Po zakończeniu tłumaczenia wykonywana jest konwersja zwrotna do formatu źródłowego.

Upewniwszy się, iż materiał jest możliwy do edycji, wykonywana jest analiza projektu. Analiza zawsze odnosi się do konkretnej pamięci tłumaczeń, kluczowe jest zatem wybranie właściwej bazy, a także określenie reguł segmentacji, minimalnego progu zgodności i punktów karnych

Przygotowanie projektu do realizacji


Analiza wykonywana jest z zachowaniem wybranych dla danej pamięci tłumaczeń reguł segmentacji oraz punktów karnych. Jej wyniki zapisywane są w postaci pliku raportu, który może być podstawą tzw. systemu śledzenia projektu.

Analiza dotyczy zwykle całości materiału, klient końcowy najczęściej nie ma wglądu w liczbę tłumaczy zaangażowanych w projekt - traktowany jest jako całość.

Analiza pozwala raz jeszcze potwierdzić wielkość plików (od strony liczby słów) oraz ich liczbę w projekcie.

Należy pamiętać, że powtórzenia obliczane w odniesieniu do całości projektu najczęściej różnią się od realnej ich liczby w dowolnym wybranym jego fragmencie. Z tego względu analiza wykonywana jest osobno na każdej „paczce” wybranej z projektu. Wyniki analizy z jej rozbiciem na poszczególne pliki są umieszczane w specjalnym arkuszu lub systemie śledzenia projektu.

Analiza projektu i jej przetwarzanie


Powtórzenia - przykład

Przykład 1 – pojedynczy plikTego tekstu nie ma w bazie

Ten tekst jest w bazie.

Tego tekstu nie ma w bazie

Ten tekst jest w bazie

Analiza: Match Types Segments Words Percent Placeables Context TM 0 0 0 0 Repetitions 1 6 27 0 100% 1 5 23 0 95% - 99% 1 5 23 0 85% - 94% 0 0 0 0 75% - 84% 0 0 0 0 50% - 74% 0 0 0 0 No Match 1 6 27 0 Total 4 22 100 0

Przykład 2 – osobne plikiPlik 1: Tego tekstu nie ma w bazie


Plik 2:Tego tekstu nie ma w bazie


Analiza wykaże po jednym segmencie

100% match oraz No Match


Kolejnym etapem po przygotowaniu analizy projektu jest wykonanie automatycznego tłumaczenia całości materiału. Ma ono na celu wstawienie wszystkich segmentów o 100% zgodności do dokumentów, aby zmniejszyć nakład pracy tłumaczy oraz aby rozróżnić segmenty pierwotnie umieszczone w bazie od tych, które zostały utworzone w trakcie pracy nad projektem (na przykład na podstawie koloru).

Tłumaczenie automatyczne możliwe jest także dla segmentów o częściowej zgodności, ale stosowane jest niezmiernie rzadko.

W ramach tłumaczenia automatycznego możliwe jest także umieszczenie terminologii w segmentach pochodzących z pretranslacji (tłumaczenia automatycznego wykonywanego przed rozpoczęciem rzeczywistego tłumaczenia). Uwaga: ważne jest włączenie opcji „segment unknown sentences”.

Tłumacz zwykle pomija segmenty 100%, ale możliwa jest także ich weryfikacja na etapie tłumaczenia

Tłumaczenie automatyczne (nie mylić z MT!)


Postępy prac nad projektem zwykle wizualizowane i śledzone są w dwóch kategoriach:

na poziomie pliku – systemy bądź arkusze wskazujące, który plik przynależy do której paczki wraz z jego pełną ścieżką, miejscem w strukturze projektu itp.

na poziomie paczki - jednoznacznie identyfikowalny w systemie zbiór plików o określonej nazwie. Z reguły materiał logicznie pogrupowany np. na podstawie modułu bądź struktury. Na tym poziomie śledzenie wizualizuje termin przydzielenia danej paczki konkretnej osoby, otrzymanie materiału, czas pracy. Pozwala to reagować na wszelkie przesunięcia planu widocznego na wykresie Gantt’a

Zarządzanie podzielonym materiałem


Dzieląc materiał na paczki powodujemy powstanie dodatkowych kroków w projekcie związanych z konsolidacją i weryfikacją podzielonego materiału. Ogólna zasada jest prosta – po konsolidacji materiału z paczek liczba plików i ich struktura powinna odpowiadać materiałowi sprzed podziału.

Weryfikacja może odbywać się na poziomie paczek lub po ich skonsolidowaniu w jedną, całościową strukturę. Weryfikacja na poziomie paczek zapewnia większe bezpieczeństwo projektu, gdyż etap konsolidacji końcowej z reguły jest jednym z ostatnich etapów przetwarzania projektu i nie umożliwia odpowiedniego reagowania na sytuacje „zniknięcia” plików.

Oprócz weryfikacji na poziomie struktury projektu, konieczna jest także weryfikacja na poziomie konkretnych plików.

Można też zastosować automatyczny system, który sprawdzi to w momencie zwracania paczki (oszczędza dużo nerwów).

Konsolidacja i weryfikacja podzielonego materiału


Testy na poziomie konkretnych plików to kluczowy etap przygotowania projektu do dostarczenia klientowi. Testy te mają charakter:

Językowy – na przykład analizowane jest użycie „zabronionych” słów lub istnienie wykrywalnych literówek, niespójności

Techniczny – analizowane są błędy związane ze znakami przestankowymi, kodowaniem znaków, tagami

Testy te są najczęściej realizowane przez inżynierów lokalizacji i korektorów/specjalistów językowych. Powoli jednak zasadą staje się także ich wykonywanie już na etapie tłumaczenia dokumentu przez tłumaczy indywidualnych (zależnie od narzędzia CAT i formatu danych)

Kontrola jakości


Testy QA - przykład


Podobnie jak przy odbieraniu materiału kluczowe jest zapewnienie terminowej i bezpiecznej wysyłki plików. W większości przypadków projektu dostarczane są w formie elektronicznej za pomocą jednej z popularnych metod przesyłania plików. Zawsze jednak należy wybrać metodę sugerowaną przez klienta.

Jeszcze przed przesłaniem materiału konieczne jest upewnienie się, że struktura archiwum odpowiada dokładnie otrzymanemu pierwotnie projektowi a wszystkie pliki przygotowane są w ostatecznej wersji (w trakcie trwania projektu może pojawiać się nawet 8 wersji plików).

Dostarczanie materiału do zleceniodawcy

Uwaga: niejeden fantastycznie zlokalizowany projekt poległ na tym etapie.


•Tłumaczenie maszynowe

Część narzędzi umożliwia wstawienie do dokumentów tekstu pochodzącego z tłumaczenia maszynowego. Najczęściej wykonuje się najpierw takie tłumaczenie, a następnie nadpisuje się segmenty wszystkimi pochodzącymi z „rzeczywistej” pamięci tłumaczeń. W ten sposób tłumacz otrzymuje więcej podpowiedzi niż przy klasycznym sposobie lokalizacji projektów, nawet jeśli tylko niewielki odsetek segmentów z tłumaczenia maszynowego nadaje się do modyfikacji/użycia.

•Odnośniki do niezlokalizowanych plików

Pliki projektów pomocy wielu producentów zawierają z reguły liczne odnośniki do innych plików. Jednym ze stosowanych kroków przy przetwarzaniu projektów jest identyfikacja, czy plik do którego wskazuje łącze jest zlokalizowany. Możliwe jest dodanie dodatkowej frazy, np. In English lub usunięcie odnośnika, w zależności od decyzji producenta/językoznawcy

Niestandardowe kroki w cyklu projektowym


Każdy projekt lokalizacyjny narażony jest na liczne niespodziewane sytuacje, które z reguły powodują mniejsze lub większe utrudnienia w jego realizacji. Można podzielić je na kilka kategorii:

Problemy techniczne

Na przykład: kodowanie znaków, działanie narzędzi, struktura plików, złe przygotowanie

Problemy związane z terminem prac

Na przykład: choroba, przesunięcia projektowe, urlopy, nagłe skrócenie terminu projektu, złe zaplanowanie projektu…

Inne losowe wypadki – awaria systemów, Internet, backup, wszelkie możliwe wystąpienia „praw Murphyego”.

Wiele firm, które forsują określoną metodykę zarządzania projektami, większość zysków czerpie z tzw. misji ratunkowych.

Sytuacje awaryjne


Otrzymanie materiału od podwykonawcy nie oznacza końca procesu. Również jego poprawne wyodrębnienie i porównanie liczby plików i ich struktury nie jest końcem testów i nie oznacza jeszcze akceptacji projektu.

Po otrzymaniu projektu firma wykonuje wewnętrzne testy techniczne i językowe, które lokalizowany projekt musi przejść, aby zakończyć się sukcesem. Podwykonawca z reguły niezwłocznie stara się wprowadzać wszelkie znalezione uchybienia, ale idealną i pożądaną sytuacją jest dostarczenie projektu, który od razu spełnia wszelkie wymogi klienta.

Projekt przechodzi szczegółową analizę językową, tzw. Linguistic review. Lista uwag wraca do firmy, która wykonała lokalizację. Należy zauważyć, że część błędów nie musi wynikać z winy firmy lokalizującej projekt i stąd uwagi te są komentowane przez specjalistów językowej firmy przez ich implementacją. Testy językowe i ogólna ocena są najczęściej wyrażane procentowo. Bardzo dobrze wykonane projekty lokalizacyjne uzyskują noty powyżej 95%. Powszechną praktyką jest sprawdzanie gotowego projektu przez konkurencję danej firmy.

Akceptacja projektu po stronie zleceniodawcy


Większość projektów lokalizacyjnych cechuje się dużą powtarzalnością. Wynika to z faktu, iż producenci co kilka lat aktualizują swoje produkty, bądź wprowadzają ulepszenia, które w mniejszym lub większym stopniu bazują na dotychczasowych technologiach.

W przypadku niektórych grup językowych (do których należy j. polski) nie jest powiedziane, że każda aktualizacja będzie wymagała lokalizacji. Zakładając jednak, iż decyzja zapadnie realizowany jest podobny proces. Różnica polega na tym, iż analiza odbywa się w odniesieniu do już nasyconej pamięci tłumaczeń, przez co projekt powinien być zrealizowany szybciej i taniej.

Dochodzi do tego możliwość tłumaczenia kontekstowego. Mając starszą wersję plików oraz pamięć tłumaczeń możliwe jest zablokowanie części segmentów i ich bezpieczne przetłumaczenie kontekstowe (sprawdzane są sąsiadujące segmenty oraz pamięć tłumaczeń). W ten sposób całe fragmenty plików mogą w ogóle nie być częścią nowego projektu lokalizacyjnego.

Aktualizacje


Zapewnienie poprawnego backupu w obrębie projektu nie sprowadza się do jednego elementu przepływu danych. W trakcie przetwarzania projektu lokalizacyjnego powstaje przynajmniej 7 różnych wersji plików. Backup nie tylko zabezpiecza przed utratą danych, ale także umożliwia powrót do poprzedniej wersji pliku w razie pomyłki. Może być to realizowane przez system wersjonowania CVS lub poprzez klasyczną strukturę z folderami i backupowaniem zawartości dysków sieciowych.

Backup musi także dotyczyć pamięci tłumaczeń – często odzyskanie ich zawartości oznaczałoby konieczność odnalezienia plików z kilku lat działalności. Zalecane jest także, aby tłumacze pracowali na zdalnych pamięciach, wówczas znika problem backupu lokalnej, plikowej pamięci tłumaczeń.

Kopie zapasowe


Dzielenie materiału

Jednym z podstawowych zadań kierownika projektu jest sprawny podział zadań, a w szczególności rozdysponowanie otrzymanego materiału. Pomimo tego, że widać rosnącą fragmentaryzację projektów, nadal większość dużych projektów wymaga podziału pracy na przynajmniej kilku tłumaczy. Najczęściej materiał jest porcjowany na paczki, których przekład powinien tłumaczowi zająć od jednego do kilku dni. Bardzo rzadko zdarza się, że do tłumaczenia trafia większy wolumen – jest to głównie spowodowane dbaniem o bezpieczeństwo projektu.

Podział jest warunkowany wieloma czynnikami, z których najważniejsze to: termin projektu, wydajność dzienna tłumacza oraz jakość materiału, którą dany tłumacz z reguły dostarcza. Przy podziale kluczowa jest jednak dzienna wydajność. Są dwa przypadki, gdy przychodzi do dzielenia materiału:

1) Otrzymaliśmy duży zbiór małych plików. Najczęstszy przypadek, w którym pliki są grupowane i „zbierane” w paczki o określonej wielkości lub tematyce.

2) Otrzymaliśmy jeden ogromny plik. Dzielenie bywa trudne. Nie zawsze jest to dokument w formacie nadającym się do bezpiecznego podziału. Szczególnie ryzykowny jest podział formatów o złożonej strukturze.


Bardzo powszechny, ale niedoceniany (pod względem konsekwencji) problem to podpisywanie tłumaczeń w bazie. Sygnatura segmentu w pamięci tłumaczeń to bardzo istotna informacja dla wszystkich osób, które pracują w projekcie. Zerknijmy na przykładowych problemów:A – doświadczony korektor, B – początkujący tłumacz. Obaj uczestniczą w dużym projekcie ze wspólną pamięcią tłumaczeń (w tym wypadku nie jest istotne czy współdzieloną, czy nie)

Problem 1:Korektor był (wyjątkowo!) przepracowany i usiadł na komputerze tłumacza B lub z innej przyczyny pracował na identyfikatorze tłumacza B. Konsekwencje: zwiększone koszty i czas korekty.

Problem 2:Początkujący tłumacz kiepsko znał dany program i sam nie wiedząc jak ustawił identyfikator doświadczonego korektora. Konsekwencje: utrata zaufania do segmentów z bazy, ale wpierw – wprowadzenie w błąd innych tłumaczy, propagacja błędów…

Problem podpisywania tłumaczeń


Wewnętrzne dopasowania, czyli stary problem internal fuzzy

Przykład:To zdanie jest w bazie1

To zdanie jest w bazie2

Tego zdania nie ma w bazie1



Narzędzia dają taką możliwość – co z tym fantem zrobić?


•Fergus O’Connel „Project Management Guide”

•Peter Schulte „Complex IT Project Management”

•http://www.thebigword.com/SharingTranslationMemories.aspx

•A Guide to the Project Management Body of Knowledge, Fourth Edition, PMI, USA, 2008.

•http://www.prince-officialsite.com/nmsruntime/saveasdialog.asp?lID=603&sID=200

Przydatne linki


Dziękuję za uwagę.

„Zarządzanie projektami lokalizacyjnymi”

Documents

Transcript of „Zarządzanie projektami lokalizacyjnymi”