„Zarządzanie projektami lokalizacyjnymi”

1. „Zarządzanie projektami lokalizacyjnymi” Prowadzący: dr inż. Agenor Hofmann-Delbor LSP Software, Moravia IT agenorh@lspsoftware.pl

2. 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 Plan prelekcji

3. Ile jest tłumaczenia w lokalizacji? 35% Łączne wydatki na przetłumaczeniei sprawdzenie treści • 50% • Wydatki ponoszone na: • zarządzanie projektem • przygotowanie plików • kontrola wersji • identyfikacja plików • obróbka końcowa • dostawa 15% Koszty wytworzenia zasobów językowych do ponownego wykorzystania w kolejnych projektach

4. 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: • Budowania planu • 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.

5. Dwa główne etapy zarządzania projektami Planowanie projektu Realizowanie projektu

6. 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.

7. Sporządzanie listy zadań [1/2] 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ć.

8. Sporządzanie listy zadań [2/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

9. Ile jest zarządzania w… zarządzaniu 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.

10. Komunikacja w projekcie 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.

11. Zarządzanie zasobami [1/3] 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.

12. Zarządzanie zasobami [2/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….

13. Zarządzanie zasobami [3/3] Przykład wykresów Gantta’a Powiązane z konkretną osobą Powiązane z zadaniem

14. Zapewnianie bezpieczeństwa projektu [1/2] • 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: • Uwzględnienie marginesu bezpieczeństwa w planie projektowym (Contigency) • Wykonanie pełnej analizy ryzyka w ramach projektu

15. 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 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

16. Analiza ryzyka - przykład

17. Zmiany w trakcie trwania projektu 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ą?

18. Nieoficjalna klasyfikacja współpracowników… 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)

19. Zarządzanie w trakcie i po projekcie 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.

20. Przykład

21. Project management a inżynieria lokalizacji • 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

22. Przygotowanie do lokalizacji • Po podjęciu decyzji o lokalizacji następują kolejne etapy: • Wyodrębnienie materiału • 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.)

23. Wyodrębnianie materiału 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: • 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 • 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 • Dokumentacja – wybór zbioru dokumentów (x)html lub chm, zrzut listy plików z systemu CMS

24. Eksport i import z systemów CMS 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

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

26. Transmisja danych, weryfikacja poprawności plików 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ć.

27. 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.

28. Przygotowanie projektu do realizacji 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

29. Analiza projektu i jej przetwarzanie 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órzeniaobliczane 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.

30. Powtórzenia - przykład Przykład 1 – pojedynczy plik Tego 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 pliki Plik 1: Tego tekstu nie ma w bazie Ten tekst jest w bazie Plik 2: Tego tekstu nie ma w bazie Ten tekst jest w bazie Analiza wykaże po jednym segmencie 100% match oraz No Match

31. Tłumaczenie automatyczne (nie mylić z MT!) 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

32. Zarządzanie podzielonym materiałem 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

33. Konsolidacja i weryfikacja podzielonego materiału 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).

34. Kontrola jakości 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)

35. Testy QA - przykład

36. Dostarczanie materiału do zleceniodawcy 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). Uwaga: niejeden fantastycznie zlokalizowany projekt poległ na tym etapie.

37. Niestandardowe kroki w cyklu projektowym • 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

38. Sytuacje awaryjne 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.

39. Akceptacja projektu po stronie zleceniodawcy 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.

40. Aktualizacje 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.

41. Kopie zapasowe 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ń.

42. 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: • 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. • 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.

43. Problem podpisywania tłumaczeń 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…

44. 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 Tego zdania nie ma w bazie2 Tego zdania nie ma w bazie3 Narzędzia dają taką możliwość – co z tym fantem zrobić?

45. Przydatne linki • 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

46. Dziękuję za uwagę.