Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę!
Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy i „nieuchronność” kary za niepowodzenie. W efekcie Dostawca szybko staje się „Panem projektu”, bo to on dostarcza rozwiązanie, zna się, a bywa że szantażuje. Przewaga merytoryczna Dostawcy nad Zamawiającym jest tak wielka, że ten ostatni w zasadzie nie jest w stanie panować nad projektem. Powoli rynek to dostrzega i dlatego od kilku lat niemalże każda moja umowa na projektowanie zawiera także nadzór autorski (to forma kontroli efektów pracy dostawcy).
Nadal bardzo często Dostawca tworzy jednak pewną atmosferę: „to my realizujemy Wasz projekt i wszystko – Wy także – od nas zależy, nadzór autorski psuje Wam harmonogram bo my musimy te dokumenty czytać i tworzyć”. Dwa razy w ostatnich pięciu lat zdarzyło mi się, że faktycznie Zamawiający zrezygnował z nadzoru autorskiego, bo członkowie zespołu zaczęli „trzymać stronę Dostawcy”, mimo informacji o szkodliwości zmian wprowadzanych przez z Dostawcę. Oba projekty skończyły się niestety klęską (mam kontakt z praktycznie każdym byłym klientem).
Projekt wdrożeniowy bez nadzoru merytorycznego, to bardzo często równia pochyła: od podpisania umowy na wdrożenie z dostawcą jest już tylko coraz gorzej, bo Dostawca upraszcza logikę systemu, pomija trudne do realizacji wymagania, stale organizuje spotkania, na których legitymizuje te zmiany w prosty sposób sposób: „to co macie w dokumentacji wymagań jest złe (nie da się, nikt tak nie robi itp.), nasz system realizuje to inaczej, zróbmy to prościej i szybciej a też będzie dobrze”. Zamawiający z reguły nie ma po swojej stronie żadnych kompetencji by ocenić skutki takich „propozycji” i na spotkaniach godzi się na to, podpisując kolejne notatki projektowe z takich „warsztatów”, małymi kroczkami funkcjonalność dostarczanego produktu oddala się od faktycznych potrzeb i wymagań. Projekt kończy się tak, że Zamawiający „dostał dokładnie to co chciał a nie to co jest mu potrzebne”. Statystyki projektów IT są bezlitosne: ok. 2/3 projektów to nadal projekty nieudane. [2]
Tam gdzie mój projekt był kolejnym podejściem, po poprzednim nieudanym, wyżej opisana sytuacja była praktycznie zawsze przyczyną wcześniejszej porażki. Paradoksalnie jest to – porażka – wręcz standardowa sytuacja, gdy Zamawiający najpierw wybiera Dostawcę a potem zleca mu analizę wymagań i kierowanie projektem.
Zjawisko to zawsze kojarzy mi się ze znanym w psychologii efektem nazywanym Syndrom Sztokholmski. Jest to sytuacja, w której ofiara, wbrew zdrowemu rozsądkowi, zaczyna sympatyzować ze swoim oprawcą.
[Syndrom Sztokholmski] …ofiara porwania czy zakładnik traci krytycyzm wobec swojej sytuacji, zaczyna wierzyć, ze jej oprawca działa w słusznym celu, i darzyć go sympatią. Jak twierdzi amerykańska psycholog, dr Natalie de Fabrique, zajmująca się badaniem tego syndromu, syndrom sztokholmski pojawia się u ofiar nieświadomie, to instynktowny, psychologiczny mechanizm obronny, dzięki któremu łatwiej jest im odnaleźć sens tego, co się dzieje, i uniknąć załamania nerwowego. [3]
W wielu projektach wdrożeniowych mamy podobną sytuację: pracownicy zamawiającego, zamiast działać na rzecz siebie czy swojego pracodawcy, zaczynają trzymać stronę Dostawcy, który żali się, że ma problem z terminami i przerzuca winę za to na swojego klienta. Po pewnym czasie dochodzi do tego, że zespół Zamawiającego tak się „zżył z pracownikami Dostawcy”, że zaczyna ich bronić przed własnymi przełożonymi. Są Dostawcy, którzy celowo stwarzają takie sytuacje (np. organizując wyjazdowe szkolenia i warsztaty z noclegami), ale nie raz dzieje się „samoistnie”. Popatrzmy na poniższą listę, czy nie przypomina Wam to czegoś?
Objawy i symptomy syndromu sztokholmskiego to: – pozytywne uczucia ofiary wobec sprawcy; – zrozumienie przez ofiarę motywów i zachowań sprawcy i podzielanie jego poglądów; – pozytywne uczucia sprawcy względem ofiary; – pomocne zachowania ofiary wobec sprawcy; – negatywne uczucia ofiary wobec rodziny, przyjaciół, autorytetów próbujących ją ratować; – niezdolność zaangażowania się w zachowania, które mogłyby doprowadzić do jej uwolnienia od sprawcy. Syndrom sztokholmski nie dotyczy wszystkich osób dotkniętych tragicznymi zdarzeniami. By zaistniał, muszą wystąpić określone warunki. Ofiara: – spostrzega, że jej przeżycie zależy od dobrej woli sprawcy; – nie widzi możliwości ucieczki; – dostrzega drobne uprzejmości ze strony sprawcy; – jest izolowana od perspektyw odmiennych od perspektywy sprawcy. [4]
Popatrzmy zatem na projekt wdrożeniowy, w którym:
Zespól Zamawiającego wierzy, że „być albo nie być” firmy, zależy od powodzenia projektu,
Zespół Zamawiającego nie widzi alternatywy dla tego wdrożenia,
Zespół Zamawiającego widzi, że Dostawca od czasu do czasu idzie mu na rękę (realizowanie drobnych zachcianek Zamawiającego w zakresie projektu),
Zespół Zamawiającego jest izolowany od innych perspektyw i spojrzenia na realizowany projekt (silne dążenie Dostawcy do wyeliminowania zewnętrznego nadzoru merytorycznego, audytów, nadzoru autorskiego).
Psycholodzy co do jednego są zgodni: człowiek nie jest w stanie bronić się przed swoimi emocjami, dlatego często jedynym sposobem obrony przed manipulacją jest unikanie kontaktu z manipulantem. Nie ma tu znaczenia czy to manipulacja celowa czy nieuświadomiona.
Lekarstwo na sytuacje, takie jak wyżej opisana, jest tylko jedno: zrezygnować z warsztatów grupowych z Dostawcą! Jak to komuś mówię to ma miejsce przerażenie i padają słowa „Ale przecież praca grupowa jest najefektywniejsza! Tak uczyli na szkoleniu i mówili na konferencjach”. W literaturze nie raz spotykałem się z podejściem odradzającym warsztaty grupowe i burze mózgów z uwagi a ich duże koszty i nieefektywność. Nie jest jednak takich opinii zbyt wiele, bo mit efektywności pracy grupowej jest wiecznie żywy (mimo tego, że badania naukowe pokazują, że praca grupowa jest mniej efektywna niż praca samodzielna).
Jednak od czasu do czasu spotykam się książkami czy wpisami na blogach, że odejście od idei JAD (ang. Joint Application Development) wydatnie poprawiło jakość projektów (sam IBM proponuje w to miejsce całkowite zastąpienie warsztatów analizą dokumentów źródłowych a potem pisemne formułowanie uwag i zarządzanie zakresem projektu z użyciem ścisłej procedury, co paradoksalnie trwa krócej, jest tańsze i daje znacznie lepsze efekty).
Co ciekawe, idea taka pojawiła się w np. tak zwanej zwinnej metodzie zarządzania projektem SCRUM, w postaci roli Product Ownera (PO) jako osoby praktycznie całkowicie separującej zespół zamawiającego od zespołu Dostawcy (business vs. developers):
There are several aspects about this role which I think are critical to understand: Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.[…]
The role of Product Owner (Scott Ambler, Agile Modeling)
Ciekawe jest to, że większość znanych mi zespołów deklarujących pracę zgodną ze SCRUM, to zespoły developerskie, które praktycznie całkowicie rezygnują z prawdziwej roli PO. Jak? Po prostu wyznaczają na PO jednego z pośród członków zespołu developerskiego, co jest pogwałceniem zasad SCRUM. Skutek jest taki, że osoba, której podstawową rolą jest zarządzanie funkcjonalnością produktu i separowanie Developera od Zamawiającego, pracuje na rzecz developera i godzi się na każdą zmianę korzystną dla swojego zespołu. Niestety w projektach programistycznych jest to niemalże reguła. W projektach budowlanych (setki lat doświadczeń) dla odmiany jest to prawnie zakazane: nie wolno łączyć roli nadzoru autorskiego (architekt i projektant) ani z rolą wykonawcy ani z rolą inwestora.
Na koniec polecam ciekawy artykuł na podobny temat:
Polacy kupują mieszkania bez usług i zieleni. Wybierają szczelnie ogrodzone betonowe pustynie bez przedszkoli, placów zabaw i komunikacji. A obok rozwiązań prawnych to właśnie decyzje konsumentów ukształtują nam przestrzeń na kolejne dziesięciolecia. (żr. Ufamy deweloperom bardziej niż lekarzom. Przypomina to syndrom sztokholmski).
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Kolejna godna polecenia książka na rynku. Nie miałem czasu by wcześniej ją opisać ale w końcu udało się. Ale od początku, wrócimy do niej.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania „na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: „czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”. W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: „ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako Model Driven Architecture (MDA):
W czym problem? Nauczyć się pracować na modelach (abstrakcje systemu) a nie od razu na kodzie (a raczej poprzedzić kodowanie analizą i projektowaniem), nauczyć się wzorców projektowych i przede wszystkim obiektowego myślenia (paradygmatu) czyli analizy i projektowania. Wykonanie – implementacja na końcu a nie na początku (podobnie jak baza danych: w metodach obiektowych projektujemy utrwalanie na końcu!). Po drugie, niestety, nie raz słyszałem o dostawców: „nie mamy interesu w tym by projekt trwał krótko”, to jednak tylko argument za tym by nie zlecać im projektowania a tylko realizację.
MDA to trzy kluczowe etapy: CIM, PIM i PSM (szczegółowo opisałem w artykule o analizie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to analiza biznesowa, nie ma ona nic wspólnego z oprogramowaniem, jej celem jest zrozumienie i udokumentowanie tego co robią przyszli użytkownicy systemu oraz wskazanie zakresu projektu dostarczenia oprogramowania. Drugi to PIM czyli opracowanie modelu logiki systemu bez względu na to w jakiej technologii powstanie, tu milczącym założeniem jest, że będzie to technologia obiektowa jednak język programowania może być dowolny.
Dużą zaletą tego podejścia jest to, że opracowanie modelu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgodne z PZP (Prawo Zamówień Publicznych) bo nie determinuje implementacji ale dokładnie opisuje oczekiwania. Uważam, że jest to najlepszy sposób tworzenia OPZ, bo nie pozostawia dowolności w kwestii funkcjonalności rozwiązania. Jaki mamy tu problem? Należy oddzielić projektowanie od realizacji czyli mamy dwa etapy projektu zamiast jednego, dwóch wykonawców (analiza i projektowanie oraz realizacja). Wady? Nie, korzyści bo wykonawca i tak musi jakiś projekt opracować, po drugie wycena na bazie projektu jest daleko mniej ryzykowna niż „wycena na bazie koncepcji”, zresztą skutki wszyscy obserwujemy na rynku. Ale wracamy do tematu :).
Proces od analizy do projektu
Dwa pierwsze (CIM i PIM) to pierwsze etapy procesu powstawania oprogramowania: Analiza Biznesowa i jej produkt oraz projektowanie rozwiązania i jego produkt. Między nimi ma miejsce określenie zakresu, którego produktem jest model przypadków użycia (od 2015 roku w UML 2.5.x ten diagram jest modelem uzupełniającym)
Analiza biznesowa
Zgodnie z zaleceniami opracowujemy model CIM czyli tworzymy model tego „jak działa biznes”. Produktem tego etapu są modele procesów biznesowych (raczej [[BPMN]] niż [[UML]]). Muszą się one jednak cechować ustalonym poziomem abstrakcji (nie powinny być zbyt szczegółowe) i muszą uwzględniać rozdział kompetencji pracowników (ich nie komputeryzujemy) od ich specyficznych dla danej organizacji i procesu (te będą wspierane przez nowe oprogramowanie). Dobrą praktyką jest poprzedzanie tego etapu (uzupełnienie go) o analizę i model architektury korporacyjnej. To jest ostatni gwizdek na wprowadzanie ewentualnych ulepszeń zarządzania (reinżynieria procesów) w organizacji. Kolejny etap to
Opracowanie modelu przypadków użycia
Przypadki użycia, usługi systemu dla użytkowników, to celowe interakcje użytkownika z systemem. Ich cechą powinna być kompletność, bo przypadek użycia to realizacja konkretnego celu biznesowego przez użytkownika. Poprawnie opracowany taki model pozwala mapować czynności z modelu procesów wprost na przypadki użycia (ale nie koniecznie jeden do jednego, przypadków użycia może być mniej, bo ta sama usługa systemu może posłużyć do realizacji kilku celów biznesowych, np. utworzenia danych jak i ich podglądu czy korekty, przykładem mogą być tak zwane [[CRUD]]«y) (kliknij tu by zobaczyć to na przykładzie narzędzia jakiego używam).
Każda czynność kandydująca na przypadek użycia powinna być opisana scenariuszem jej realizacji opisującym jak planujemy tę usługę zrealizować. Jest to tak zwany dialog użytkownik-system. Model przypadków użycia to także definicja zakresu projektu programistycznego (robimy to i tylko to).
Opracowanie modelu dziedziny
Specyfikacja usług systemu (przypadki użycia) to tak zwane wymagania funkcjonalne. Jest to stanowczo za mało by cokolwiek (w szczególności oprogramowanie) mogło powstać. Problem w tym, że samo stwierdzenie „system ma wciągać śmieci” nijak się nie ma do konstrukcji urządzenia jakim jest odkurzacz. Wymaganie pozafunkcjonalne, że „ma ich wciągać co najmniej 90%” także nic nie mówi o tym co na prawdę ma zostać wytworzone. Brakuje PROJEKTU.
Takim projektem jest model dziedziny, jednak nie jest to diagram klas na którym pokażemy, że np. istnieje związek logiczny brudnego dywanu z odkurzaczem! bo to jest tylko model pojęciowy (słownik pojęć). Model dziedziny systemu to model dziedzinowej logiki jaką należy odwzorować w oprogramowaniu. Owszem, jest to także Diagram klas UML, ale zupełnie inny niż tak zwany model konceptualny, który po prostu jest tylko słownikiem (i często jest mylony z modelem danych!).
Model dziedziny systemu to sedno analizy obiektowej. To model całej logiki biznesowej aplikacji: klasy, ich operacje i atrybuty. Nie powinien to być na pewno tak zwany [[anemiczny model dziedziny]] a niestety takie właśnie są one w większości projektów jakie widuję.
Na tym etapie, modelowanie dziedziny systemu, powstają „suche” klasy, bez metod i atrybutów (tak, bez atrybutów!). W projektach złożonych systemów, powstanie modelu dziedzinowego powinno być poprzedzone powstaniem modelu komponentów (także stosowny diagram UML), który jest pośrednią warstwą abstrakcji w takich projektach. W takim przypadku początkowo operujemy praktycznie tylko na klasach abstrakcyjnych i ich interfejsach (są to interfejsy tych komponentów).
Projektowanie realizacji czyli testowanie modelu dziedziny
Mając model dziedziny, czyli listę specjalizowanych „wykonawców” konkretnych prac, możemy przystąpić do testów scenariuszy przypadków użycia. Takim testem jest próba zrealizowania scenariusza przypadku użycia z pomocą obiektów modelu dziedziny. Na tym etapie powstaje diagram sekwencji (lub sterowania interakcją, przepływu interakcji) dla każdego przypadku użycia. Dobrą praktyką jest stosowanie tu diagramów przepływu interakcji. Służą one do modelowanie nietrywialnych przypadków użycia, przepływu scenariuszy alternatywnych, ekranów itp.
W trakcie tworzenia diagramu sekwencji projektowane są operacje klas (metody to ich realizacje). Diagram sekwencji opisuje dialog pomiędzy obiektami prowadzący do zrealizowania zadania, jakim jest cel przypadku użycia (jego stan końcowy). Dialog taki to nic innego jak wywołania operacji obiektów przez inne obiekty (lub własnych). Po opracowaniu diagramu sekwencji obiekty, które brały w niej udział „wzbogacą” się w projekcie o swoje operacje. Na tym etapie może się okazać, że pewne obiekty zmieniają swoje stany. Dla ich klas projektujemy diagramy maszyny stanowej. Jeżeli okaże się, że jakiś obiekt wykonuje nietrywialne zadania (obliczeniowe, złożony proces itp.), jego operację, która za to odpowiada, dokumentujemy z pomocą np. diagramu czynności – taki algorytm to Metoda danej Operacji. Za każdym razem sprawdzamy zgodność z oczekiwaniami użytkownika i uzupełniamy klasy o niezbędne atrybuty, w szczególności, jeżeli reprezentują one dokumenty czy formularze.
Projekt wykonany
Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu „technikaliami” (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to „trywialny problem”, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta).
Poniżej produkty takiej analizy i projektowania w postaci diagramów (modeli), pierwszy to BPMN, pozostałe UML:
Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD ([[Joint Application Development]]), jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.
To jest właśnie problem nazywany „użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.
Larman’s UML Process
Use Cases
Define user interaction with the system.
Underline nouns to identify concepts in the problem domain.
Conceptual Model
Use the underlined nouns from the use cases to create the concepts in the conceptual model.
Some of the nouns, if they identify simple data types, are used to create attributes of these concepts.
Create associations between the concepts.
System Sequence Diagram
Create system sequence diagrams for each use case scenario.
Each sequence event in the diagram corresponds to a user interaction with the system specified by the expanded use case.
System Contracts
Specify post-conditions for each system event in the system sequence diagrams.
Use the conceptual model to identify objects created, associations formed, and attributes modified.
Collaboration Diagram
Create a collaboration (or sequence) diagram for each system event in the system sequence diagrams.
Assign responsibilities to classes in the conceptual model to fulfill the post-conditions in the contracts.
Use associations from the conceptual model in conjunction with patterns (Expert, Creator) to assign responsibilities.
Class Diagram
Add methods and additional attributes which were discovered in the collaboration diagrams to the classes in the conceptual model.
Code
Create classes with their names, attributes and method signatures taken from the class diagram.
For each method on a class, use the collaboration diagrams to find the sequence of messages generated when the method is called and create at least one line of code for each message.
You can create several different views of the users» requirements. Each view provides a particular type of information. When you create these views, it is best to move frequently from one to another. You can start from any view.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.