Temat: Książka BPMN 2.0 po polsku
Trochę komentarzy się nazbierało, bardzo dziękuję za Wasze zdanie.
@Jarek: No to temat bramek mamy załatwiony :-), tak jak wcześniej pisałem, nie będę się upierał. To w gruncie rzeczy jest drobnostka. Zawrę swoje spostrzeżenia nt. „bram” w przypisie autora lub czymś podobnym. Bardzo podoba mi się Twoja wypowiedź o „semiotyce”. Jeśli mi się to uda, to spróbuję także skonsultować kilka rzeczy w mojej książce z koleżanką, która jest językoznawcą. Staram się dbać o język tekstów, a także o podejście do „spolszczania” obcych terminów. Niestety w literaturze „fachowej” to jest bardzo trudne. Bo albo fachowiec nie rozumie językoznawcy, albo odwrotnie :-)
@Stanisław: Pojęcie „żetonu” jest genialnie zdefiniowane w specyfikacji BPMN. Jednak ja w książce całkowicie unikam jego używania. Nadrabiam to np. rysunkami. Nie używam „żetonów” bo to jest kolejne pojęcie, które utrudnia rozumienie nowym użytkownikom BPMN. Podjąłem tę decyzję bo w dzisiejszych czasach wiele osób czyta książkę od środka, od końca, albo jeszcze inaczej. Więc im mniej nowych pojęć, tym łatwiej się czyta. Wymaga to ode mnie jakiegoś dodatkowego wysiłku w formułowaniu tekstu, ale jak na razie wychodzi mi na to, że „żeton” nie jest konieczny. Tak sądzę – ale jeszcze nie skończyłem pisać.
@Piotr: Dziękuję za sugestie. Choć praktycznie się nie znamy (byłem u Ciebie kiedyś dawno temu na jednym szkoleniu), dość dobrze przewidziałem to jakie tematy poruszysz, jeśli zabierzesz głos :-) Sprawdziło się, myślę więc, że kiedyś będzie trzeba się spotkać :-) jeszcze raz. Przed opublikowaniem książki nie chcę się wypowiadać zbyt dosadnie o publikacjach dotyczących BPMN. Napiszę tylko tyle: błędów w publikacjach o BPMN i BPM w ogóle jest tak dużo, że uznałem, że napisanie książki to naprawdę dobry pomysł :-)
Jeśli chodzi o wzorce, to dziękuję za ofertę :-) , ale – całkowicie szczerze – brakuje już czasu na dołożenie tak zacnego tematu. Poza tym, jak już wcześniej pisałem, jak dla mnie temat doskonale nadaje się na odrębną książkę :-) Ja zresztą nie czuję się specjalistą w dziedzinie wzorców – przeczytałem kilka książek (nie rozdziałów :-)) na ten temat i uważam, że temat jest bardzo szeroki. Poza tym – to chyba jest najważniejsze – wzorce opisywać jest sens wtedy, gdy podaje się praktyczne przykłady ich zastosowania i dyskutuje nad tym, dlaczego warto, na co uważać i kiedy zaniechać stosowania danego wzorca. A to oznacza, że 1 wzorzec = 1 rozdział. 43 dodatkowe rozdziały to już dla mnie za dużo :-) A 1 rozdział ze wszystkim wzorcami bez komentarza, to za mało.
Plakat znam :-), za każdym razem, gdy kończę rozdział, sprawdzam. Czy nie ma w nim błędów :-) Żartuję. Ale tak na szybko, znaczek plusa wewnątrz czynności nie oznacza, że czynność jest rozpisana na innym diagramie, tylko po prostu, że jej szczegóły są pominięte pomimo, że nie jest to czynność atomowa. Transakcja nie „może być”, ale „jest” obsługiwana protokołem transakcyjnym. Innymi słowy, nawet jeśli nie jest to proces wykonywalny (i technologia transakcji nie jest określona), to zakłada się, że taka czynność jest kontrolowana mechanizmem transakcyjnym, co gwarantuje pewne rzeczy istotne dla biznesu. „Call activity” to czynność wywołania, a nie czynność „wywoływana”. Chodzi o to, że sama ta czynność wywołania może być czymś więcej niż czynność, która jest przez nią wywoływana. Jest więc różnica między czynnością wywołania i czynnością wywoływaną :-) Itd. Nie chcę jednak kontynuować, bo nie wiem też czy jest to kwestia złej interpretacji, ścisku na A3, czy niedoskonałości pierwowzoru (gdzieś widziałem ten plakat w wersji angielskiej z mniejszą liczbą autorów w stopce). Plakat jest wygodny i pewnie popularny, ale nie jest wg. mnie wzorcem „terminologii” i zresztą nie tym chyba miał być.
Jeśli teraz zamiast „pula” wprowadzimy np. „partnera”, to co zrobimy z potem „partnerem”? Jestem otwarty, ale jak widać to wszystko nie jest takie trywialne i nie jest kwestią naszych przyzwyczajeń, ale konieczności porządkowania. Żeby standard był standardem :-) Jeszcze raz dziękuję za głos w dyskusji.
@Joanna: Dziękuję za sugestie. Gdy zabierałem się za pisanie książki, odpowiedziałem sobie na kilka ważnych pytań. Jednym z nich było to „dla kogo piszę?”. Uznałem, że dla studentów, samouków BPMN-a, analityków biznesowych, którzy nie mają czasu na szkolenie, ewentualnie dla osób, które po jakimś szkoleniu potrzebują wsparcia i dla całej tej reszty ludzi, która jest większością :-). Czyli tych, którzy z jakiegoś powodu potrzebują mieć pod ręką książkę o notacji BPMN. We wszystkich jednak przypadkach zakładam, że są to osoby, które nie tylko chcą się nauczyć „rysować”, ale chcą dobrze rozumieć co „modelują”, jaki jest związek tych modeli z technologiami. Tak, uważam, że do „wypowiadania się” o BPMN-ie trzeba mieć praktyczne pojęcie o SOA, ale nie jest to książka o SOA. Po prostu, spora część tego co modeluje się w BPMN-ie ma sens właściwie tylko wtedy, gdy odnosi się do technologii. Całkowicie się z Tobą zgadzam. Książka którą ja piszę, ma być materiałem do nauki dla tych, którzy notacji jeszcze nie znają. Zahacza o SOA itp. ale raczej w taki sposób, żeby to pojęcie przybliżyć i wyjaśnić BPMN w tym kontekście. Stąd moja wypowiedź na blogu. Doświadczeni użytkownicy BPMN nie znajdą w książce nic nowego. Nie mam takiego zamiaru :-) Albo inaczej, chcę najpierw napisać o samej notacji, po to, żeby później (kiedyś) napisać o tym co jeszcze bardziej mnie w procesach fascynuje. Odwrotna kolejność jest moim zdaniem zła, choć niestety wielu specjalistów-pisarzy ma właśnie takie podejście. Oczywiście mam plan, żeby książkę aktualizować w przyszłości razem ze standardem BPMN. Ale nadal ma to być podstawa do nauczenia się tej notacji.
***
Z tą kolaboracją i pulą, to jest problem, który w podobnej wersji, jakiś czas temu miałem już przy okazji UML-a. Słowo „kolaboracja” ma we współczesnej polszczyźnie inne znaczenie i jest odradzane, jeśli ma być użyte tam, gdzie chodzi o zwykłą współpracę (
http://poradnia.pwn.pl/lista.php?id=8892). Rzecz jednak w tym, że a) mi tutaj nie chodzi o synonim słowa „współpraca”, tylko o nazwę jakiegoś elementu notacji opisanej i funkcjonującej głównie w języku obcym, b) w kwestii „spolszczania” obcojęzycznych technologii trzeba wybierać między tłumaczeniem, które pasuje do oryginału bardziej znaczeniowo, bardziej fonetycznie, albo w ogóle pozostawiać nieprzetłumaczone. To trzecie wyjście jest najwygodniejsze (dla leniwych :-) użytkowników języka polskiego).
Czasem udaje się znaleźć coś co jest bliskie fonetycznie i całkiem nieźle pasuje „znaczeniowo”, jak np. owa „pula”. Bywa jednak, że trzeba wybrać, czy to ma brzmieć naturalnie w języku polskim, czy przede wszystkim ma nie wprowadzać bałaganu i brzmieć trochę gorzej w „codziennej” polszczyźnie, ale być usprawiedliwione „żargonem fachowym”. BPMN jest już obecnie bardzo popularny na całym świecie. Nawet jeśli teraz w książce użyję „basenu” czy „diagramu współpracy”, to i tak wszędzie będziemy spotykali się z terminem „collaboration” i „pool”. W efekcie w kręgach specjalistów od modelowania w BPMN-ie będzie mimowolnie występowała ta „kolaboracja” i „pula” :-)
Z przetłumaczeniem „kolaboracja” jako „współpraca” lub podobnie może być problem. Dokładnie taki sam, jaki mieli praktycznie chyba wszyscy polscy „pisarze” od UML-a. Do dziś dzień niepoprawnie i wymiennie (?!) używa się nazw diagramów aktywności, interakcji, sekwencji, przepływu, współpracy, kolaboracji, kooperacji itd. Chaos totalny, a wystarczyło „sprowadzić” do polskiego te oryginalne słowa ze specyfikacji OMG, dać im polską fleksję i po problemie! :-)
Kalka fonetyczna z natury jest niedoskonała, ale poza tą „fonetyczną” niedoskonałością innych jej zarzucić nie można…
Wydaje mi się też, że tłumaczenie z obcego na polski czasem polega nie tylko na poszukiwaniu najwłaściwszego odpowiednika w sensie znaczeniowym, ale także na „operowaniu” językiem i wprowadzaniu nowej terminologii na nasz polski „grunt”. W końcu chodzi o to, żeby wraz ze wzrostem naszej wiedzy wzbogacić także nasz język.
Szymon Drejewicz edytował(a) ten post dnia 11.07.11 o godzinie 18:31
пропозиції роботи
