Brzytwa Ockhama (nazywana także zasadą ekonomii lub zasadą ekonomii myślenia) – zasada, zgodnie z którą w wyjaśnianiu zjawisk należy dążyć do prostoty, wybierając takie wyjaśnienia, które opierają się na jak najmniejszej liczbie założeń i pojęć. Tradycyjnie wiązana jest z nazwiskiem Williama Ockham
Od czasu do czasu spotykam się w projektach z pojęciem „cynefin”. Najpierw typowy opis z jakim można się zetknąć w sieci:
Cynefin jest swoistą teorią, którą można wykorzystać do opisu działania skomplikowanych systemów takich jak różnego rodzaju przedsięwzięcia czy nawet relacje i problemy międzynarodowe. Jako model tłumaczy i próbuje pomóc w wyborze strategii działania, wskazując jednocześnie wzorce postępowania, które powinny być zdecydowanie inne w zależności od tego w jakiej sytuacji się znajduje się firma. W praktyce można korzystać z Cynefin jako narzędzia wspierającego zarządzanie projektem, zespołem lub nawet organizacją. Od jakiegoś czasu Cynefin przebija się także do ruchu agile’owego.
Model Cynefin ma pięć obszarów. Pierwsze cztery obszary to:
Prosty – związek między przyczyną a skutkiem jest dla wszystkich oczywisty. Proponowany schemat działania: odczuj-klasyfikuj-reaguj. Można stosować najlepsze praktyki.
Skomplikowany – związek między przyczyną a skutkiem wymaga analizy lub innej formy badań i/lub zastosowania wiedzy ekspertów. Proponowany schemat działania: odczuj-analizuj-reaguj. Można stosować dobre praktyki.
Złożony – związek między przyczyną a skutkiem mogą być dostrzeżony w retrospekcji (z perspektywy czasu), ale nie da się go przewidzieć. Proponowany schemat działania: sonduj-odczuj-reaguj. Możemy wykryć nową praktykę.
Chaos – nie ma żadnego związku między przyczyną a skutkiem na poziomie systemów. Proponowany sposób działania: działaj-odczuj-reaguj. Możemy odkryć powieściową praktykę
Piąta domena zwana „nieporządkiem” to stan niewiedzy o rodzaju istniejącej przyczynowości, w której osoby wracają do własnej strefy komfortu podczas podejmowania decyzji. (Źródło: Cynefin)
inne źródło podaje:
Model: Cynefin Problem: Jakiego typu podejście zastosować w zależności od kontekstu? Rozwiązanie: Użyj modelu Cynefin jako modelu decyzyjnego. Opis techniki: Główna myśl modelu Cynefin jest następująca: zagadnienia, z którymi mamy do czynienia, nie są sobie równe i możemy je podzielić ze względu na ich złożoność. Stosuj podejścia adekwatne do poziomu złożoności twojej dziedziny. Proste (ang. simple) ? to systemy, w których jednoznacznie można powiązać przyczynę ze skutkiem. Do tego obszaru należą dobrze rozpoznane, opisane dziedziny problemowe, gdzie dostępna jest wiedza, gdzie występujące problemy nie wymagają złożonej interpretacji czy doświadczenia. Skomplikowane (ang. complicated) ? są to systemy, w których istnieje powiązanie między przyczyną a skutkiem, ale nie jest ono proste do wykrycia. Znalezienie rozwiązania problemu wymaga wiedzy eksperckiej, dużego doświadczenia oraz złożonej analizy. Ponadto system tego typu jest statyczny lub przynajmniej mało zmienny (zmienność można przewidzieć i przeanalizować). Złożone (ang. complex) ? są to systemy, w których nie ma jednoznacznych powiązań między przyczyną a skutkiem, gdyż zmieniają się one w czasie ? można je wykryć poprzez eksperymenty i dociekania obecnego stanu rzeczy. Posiadanie wiedzy eksperckiej nie jest wystarczające, aby znaleźć rozwiązanie problemu. Potrzebne są eksperymenty i analiza efektów podejmowanych działań.. System tego typu to system żywy, organiczny, zmienny w czasie. Choatyczne (ang. chaotic) ? są to systemy w których brakuje powiązań między przyczyną i skutkiem. Wszelkie sytuacje alarmowe, pożary, katastrofy są przykładami takich systemów. Nieporządek (ang. disorder) ? to sytuacja, w której nie jesteśmy w stanie określić, z jakiego typu systemem mamy do czynienia. (Źródło: Model Cynefin)
A teraz porównajmy to ze znaną od lat ogólna teorią Systemów, która tak klasyfikuje systemy:
System bywa także nazywany ?zorganizowaną złożonością?. Klasyczna ogólna teoria systemów oparta jest na matematycznych modelach (równaniach), opisujących reakcję każdego elementu systemu, i systemu jako całość, na określone bodźce. Mechanizm działania (zachowania się) systemu to wynikowy ?wzór?. W metodzie naukowej zestaw takich matematycznych równań nazywa się ?modelem? lub po prostu teorią wyjaśniającą. Równania opisujące te elementy to, zależnie od złożoności systemu, równania liniowe (proste) lub równania nieliniowe.
?Banalnie proste? systemy można opisać jednym, prostym równaniem liniowym. Systemy uznawane za ?łatwe? do analizy to te, dające się opisać prostym układem kilku równań liniowych lub jednym równaniem różniczkowym. Systemy wymagające do ich opisu (zamodelowania) układu bardzo wielu równań liniowych lub nawet kilku pojedynczych różniczkowych, stają bardzo trudne, a w miarę rosnącej ilości równań (złożoności systemu), są po prostu niemożliwe do rozwiązania metodą inną niż statystyczna (iteracje i badanie rezultatów). Pisząc ?analiza? mamy tu na myśli możliwość nie tylko opisania tymi równaniami systemu (bo to nie musi być trudne) ale ich (tych równań) rozwiązanie (przypominam: to wiele równań z wieloma zmiennymi). (źr. Ogólna Teoria Systemów).
Od siebie dodam, że model systemu to struktura obrazująca współpracujące (mające ze sobą interakcje) obiekty a owe „równania liniowe i nieliniowe” to odpowiedzi na bodźce (mówiąc językiem metod obiektowych są to metody, reakcje, odpowiedzi, tych obiektów). Odpowiedź całego systemu można więc opisać jednym równaniem, dlatego w tytule tabeli nazwano system problemem matematycznym, złożoność równania opisującego odpowiedź systemu obrazuje stopień złożoności tego systemu. Dodam też, że analiza obiektowa pozwala posługiwać się całością lub poszczególnymi obiektami zależnie od przyjętego poziomu abstrakcji. A teraz po raz kolejny definicja systemu:
System: złożony obiekt wyróżniony w badanej rzeczywistości, stanowiący całość tworzoną przez zbiór obiektów elementarnych (elementów) i powiązań (związków i relacji) między nimi (Sienkiewicz, 1994) (Źródło: Słownik Pojęć | Jarosław Żeliński IT-Consulting)
Napisanie więc, że są systemy, „w których nie ma jednoznacznych powiązań między przyczyną a skutkiem” albo „w których brakuje powiązań między przyczyną i skutkiem”, świadczy o zwykłej niewiedzy, o niezrozumieniu tworzonego systemu (a nawet o niezrozumieniu definicji samego pojęcia system) a nie o tym, że „nie ma w nim powiązań”, bo gdyby ich nie było nie był by to jeden system. Skrajność to stan w którym „nie jesteśmy w stanie określić, z jakiego typu systemem mamy do czynienia” czyli „nic nie kumam” i to moim zdaniem określa całe podejście zwane „cynefin”.
To własnie to, co nie raz widuję w pracy nazywanej często „agile”: podejmowanie się projektów przy całkowitym braku zrozumienia dziedziny problemu. To, czy nazwiemy to chaosem, czy znajdziemy nową „mądrą” nazwę CYNEFIN, niczego nie zmienia. Po prostu „brzytwa Ockhama” po raz kolejny szyderczo się uśmiecha… A próby napisania oprogramowania w sytuacji braku zrozumienia jaki ma być mechanizm jego działania to po prostu szukanie kłopotów… i niestety nadal często spotykane zjawisko czyli „szczur w labiryncie”…
[dodatek]
Ciekawostką jest także „architektura C4” (czytaj opis). Jest to Cała „teoria i metoda” w której jest 100% technologii i ZERO o biznesowej dziedzinie i jej logice… Bardzo często developerzy niestety obiecuję, ze „sami napiszą” to oprogramowanie, a potem mozolnie po omacku, wieloma próbami, usiłują stworzyć oprogramowanie realizujące logikę biznesową… jak szczur w labiryncie który który na każdą rzecz której nie rozumie znajduje nową nazwę: raz CYNEFIN, raz C4… (tak na prawdę C4 to co najwyżej tylko nowy profil do UML, jedna strona łącznie z komentarzami).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Hipoteza ? osąd, teoria, która nie znalazła jeszcze potwierdzenia w faktach, lub w przypadku hipotez matematycznych nie została jeszcze poprawnie udowodniona.Stawianie i testowanie hipotez to jeden z podstawowych procesów twórczego myślenia oraz fundamentalny element procesu tworzenia nauki. (Źródło: Metoda naukowa w analizie wymagań | Jarosław Żeliński IT-Consulting)
Nie raz w toku projektów mówię, że moja praca przebiega w taki – naukowy – własnie sposób: zbieram pewną niewielką partię danych, np. dwa, może trzy komplety dokumentów danego procesu biznesowego, i tworzę model tego procesu. Ten model to hipoteza: „Ten proces tak przebiega”. Kolejny „ruch” to testowanie modelu czyli próba jest falsyfikacji, szukania w analizowanej organizacji faktów przeczących tej tezie. Polega na wysłaniu do recenzji lub prezentacji opracowanego modelu procesu. Jeżeli uda się znaleźć zdarzenie lub dokument, którego model procesu nie tłumaczy (nie opisuje go), to znaczy, że model jest zły (został podważony) i należy go poprawić. Jeżeli w toku recenzji, żaden recenzent (recenzentem jest tu ekspert dziedzinowy z obszaru danego procesu biznesowego w analizowanej organizacji) nie podważy modelu, znaczy to, że model jest poprawny czyli odwzorowuje to co się dzieje w organizacji. To procedura zwana metodą naukową (model ten musi także spełniać wymogi formalne czyli zgodność z daną notacją, np. BPMN i ustalona pragmatyką tworzenia tych modeli).
Nie raz miewam „prośby” o dodanie do modelu procesu (jest nim diagram np. w notacji BPMN) czegoś niepotrzebnego albo wręcz kolidującego z zadeklarowaną notacją lub pragmatyką. Z reguły są to jakieś „a my czasem jest robimy to tak i tak” albo „proszę pokazać jeszcze to”. Praktycznie zawsze są to nadmiarowe szczegóły, opisujące pewne wybrane detaliczne czynności, które nie mają pływu na modelowany proces, stanowią jego naturę lub detal zawarty w dokumentach. Elementy, które na etapie modelowania procesów z zasady pomijamy bo są udokumentowane w procedurach, zakresach obowiązków, instrukcjach obsługi urządzeń, wzorach dokumentów itp. Drugi element często psujący modele to dodawanie na diagramach ikon i symboli z poza notacji. Zdarza się to w sytuacji, gdy poprosi o to któryś z recenzentów lub zrobi to sam analityk, który nie poradził sobie ze zrozumieniem danego „zjawiska”.
Takie zbyt szczegółowe lub przekłamane diagramy z reguły kończą życie na „śmietniku projektu” czyli na nieużywanej półce z dokumentami po ich zafakturowaniu.
W modelach systemów (wykonanych z użyciem notacji UML) najczęściej widuję złe (niezgodne z ich znaczeniem) użycie symboli UML. Dotyczy to głównie diagramów klas i diagramów przypadków użycia. Na diagramach klas są to najczęściej błędy wynikające z mylenia modeli pojęciowych i modeli struktury na jednym diagramie klas. Na diagramach przypadków użycia nie raz obserwuję całkowite odejście od reguł UML, do stosowania UML tak jak np. Power Pointa czyli „symbol jest fajny to go użyjemy do czego nam tylko pasuje”. Ma nie raz miejsce wprowadzanie kuriozalnych pojęć, z poza notacji UML typu „aktor czas”, „systemowy przypadek użycia” i inne dziwolągi prowadzące do ich mnożenia, tylko dopełniają bałaganu.
Nie raz przywoływałem tak zwaną „[[Brzytwę Ockhama]]”, jest to metafora, mówiąca, ze w nauce tworzenie nowych bytów musi mieć uzasadnienie, be tego wszelkie „nowe byty” stanowią tylko obraz niewiedzy i niezrozumienia, ideologicznego ukrycia braku możliwości dowiedzenia istnienia czegoś. Tu zacytuję fragment pewnego bloga (polecam lekturę całego cytowanego artykułu):
Nie będziesz mnożył bytów ponad miarę [treść tzw. Brzytwy Ockhama, przyp mój J.Ż.]. Tak jak nie należy bez przyczyny wybierać rozwiązania nadmiernie skomplikowanego, tak też nie wolno dowolnie dokooptowywać do swojego rozumowania dodatkowych bytów. Nie stosując się do tego zakazu, dla przywołanego wcześniej przykładu, moglibyśmy ukuć niezliczoną ilość kolejnych wyjaśnień. Katedry i piramidy mogli przecież wznieść przybysze z kosmosu, czarodzieje, duchy, demony, skrzaty? Byty można mnożyć bez końca, tłumacząc nimi każde obserwowane zjawisko. A jednak nie dajemy wiary zapewnieniom brzdąca twierdzącego, że cenny wazon w salonie uległ destrukcji w skutek działalności złośliwego poltergeista. W każdym razie, znaleziona opodal miejsca zdarzenia piłka, podsuwa nam znacznie prawdopodobniejsze wyjaśnienia. Dopuszczając do procesu naukowego krasnoludki, dżiny, wróżki i co tam chcecie, dochodzimy do nieuchronnego acz bezwartościowego wniosku, iż każda z dowolnie zmyślonych odpowiedzi jest równie dobra i równie (nie)prawdopodobna. (Źródło: Metodologiczny dekalog naukowca | Kwantowo.pl – astronomia, fizyka, nauka!)
Tak więc czytając czyjekolwiek opracowania, w szczególności analizy biznesowe i modele systemów, sprawdzajcie, czy ktoś nie umieścił tam analitycznych krasnoludków, kosmitów, dżinów itp. Takie byty na diagramach jak „aktor czas” czy „systemowy przypadek użycia”, świadczą wyłącznie o tym, że autor po prostu nie poradził sobie z analizą, nie do końca odkrył istotę tego co analizował i opisał, nie zrozumiał tego co modeluje. Dodawanie nowych bytów do notacji jak najbardziej jest możliwe, ale po pierwsze należy to robić poprawienie ale potrzeba taka jest bardzo rzadka. W obszarze analizy i modelowania obecna postać BPMN wystarczy aż nadto, do modelowanie oprogramowania zorientowanego obiektowo UML tym bardziej wystarczy. Takie upstrzone „wynalazkami” dokumenty być może są atrakcyjne ale kompletnie nieprzydatne.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Dzisiaj co nieco o filozofii i przypadkach użycia.
Dzielenie przypadków użycia na ?rodzaje? zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojecie ?przypadek użycia systemu?, gdzie systemem jest coś (podmiot zainteresowania), czyli ?analizowany/modelowany system? (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system (wymiennie „przedmiot zainteresowania”, „przedmiot analizy”), zanim będzie rozpatrywany, musi być określony (granice systemu, który jest częścią „nad” (super) systemu, a składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek użycia ma jedną definicję, ale w danym momencie rozpatrywanym systemem (przedmiot analizy) jest np. oprogramowanie ale też może nim być np. organizacja. Tak więc przypadek użycia ?oprogramowania? (np. wystawianie faktury VAT) niczym się nie różni od ?przypadku użycia? firmy sprzedającej rowery ?dostarczenie zamówionego roweru?? to co tu „robi różnicę” do granice systemu- kontekst: raz jest nią granica ?oprogramowania? a raz ?organizacji?.
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirementsof a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. […] Use cases, actors, and systems are described using use case diagrams.
9wytłuszczenia moje). Co my tu mamy:
Przypadek użycia oznacza specyficzne (konkretne) oczekiwane użycie systemu. Standardowo używany jest do zbierania [J.Ż. dokumentowania] wymagań na system, planowany do użycia.
Kluczowymi pojęciami łączonymi z Przypadkiem użycia są aktor oraz przedmiot zainteresowania (system).
Opisywanym z pomocą przypadków użycia przedmiotem jest system, który będzie wykorzystywany zgodnie z przypadkami użycia (w tym celu).
Użytkownik lub inny system może oddziaływać na opisywany przypadkami użycia przedmiot, nazywany jest wtedy aktorem. Aktorem jest każdy zewnętrzny w stosunku do opisywanego systemu element (byt).
Wymagane zachowanie opisywanego przedmiotu (system) może być opisane jednym lub wieloma przypadkami użycia, definiowanymi jako potrzeby aktora (w stosunku do systemu).
Przypadek użycia, aktor i system razem są określane jako diagram przypadków użycia.
Jak widać, nie ma tu żadnych kombinacji, dowolny system, jego otoczenie oraz interakcje tego otoczenia z nim samym opisujemy (modelujemy) z pomocą trzech pojęć pokrywających wszystkie wymagane elementy: kto/co, z czym i jakie ma interakcje.
Teraz proszę najpierw przeczytać to:
Dwie ważne rzeczy: „nie wolno bez potrzeby mnożyć liczby bytujących istot” to znana bardziej jako brzytwa Ockhama „„Nie należy mnożyć bytów ponad potrzebę” (Brzytwa Ockhama (nazywana także zasadą ekonomii lub zasadą ekonomii myślenia) ? zasada, zgodnie z którą w wyjaśnianiu zjawisk należy dążyć do prostoty, wybierając takie wyjaśnienia, które opierają się na jak najmniejszej liczbie założeń i pojęć. Tradycyjnie wiązana jest z nazwiskiem Williama Ockhama.). Druga: „nie wolno niepotrzebnie umniejszać odmian bytujących istot” . Razem są zwane jako „najwyższe prawa rozumu” (filozofa, badacza).
Powyższy wklejony cytat pochodzi z rozprawy Czworaki korzeń zasady racji dostatecznej Schopenhauera. Cytuję go, gdyż gorąco polecam filozofię analitykom (uczy logicznego myślenia i analizy), tę zaś zasadę polecam szczególnie, gdyż pozwala ona uniknąć niepotrzebnego mnożenia bytów np. w postaci „różnych rodzajów przypadków użycia” (dotyczy to także aktorów). W jednej z prac innego filozofa (nie pamiętam teraz którego), można znaleźć, że łamanie powyższej zasady (nadawanie nowych nazw nowym postrzeganym rzeczom) to wraz niezrozumienia”: „czego nie rozumiem nadam mu nową nazwę”. To zła droga…
Zacytuje fragment mojego referatu z pewnej konferencji:
…wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania, snooker – najtrudniejsza gra w bilarda – to tylko kule i kij i prawa fizyki. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania by zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP).
Tak więc, tylko trzy pojęcia: system, aktor i przypadek użycia zupełnie wystarczą by opisać system i jego (przyszłe, planowane) wykorzystanie czyli wymagania. I zawsze powinny wystąpić te trzy elementy na modelu. Mnożenie bytów na tym diagramie to raczej przyznanie się do porażki…
- Use cases are descriptive, not prescriptive [przypadki użycia są opisowe a nie nakazowe]
- There is a gap between these descriptions and a design [są wypełnieniem luki pomiędzy opisem a projektem]
___ Transcendentalny – będący warunkiem (możliwości) zaistnienia czegoś. W filozofii Kanta i jego kontynuatorów dotyczący apriorycznych form poznania, teoretycznie wykraczających poza przedmiot i treść poznania, a odnoszący się do warunków poznania pełnej rzeczywistości poznawczej tzn. prawdy absolutnej pojmowanej uniwersalnie przez wszystkie podmioty poznawcze. Innymi słowy, taka forma poznania otaczającej rzeczywistości, by każdy bez względu na jego umiejscowienie w niej, mógł stwierdzić jednoznaczność poznawczą, czyli prawdę – uniwersalną dla wszystkich istot poznawczych we wszechświecie.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
No nic nie poradzę na to, że znany w branży autor ([[Alistair Cockburn]]) moim zdaniem pływa w czymś co ja nazywam „mnożenie bytów”, świat zna to pod nazwą [[Brzytwa Ockhama]], tu raczej jest to zaprzeczenie tej zasadzie a w moich oczach A.C. jest mistrzem w tej dziedzinie:
Alistair Cockburn przytacza na swojej stronie definicję stwierdzającą, że ?komunikacja osmotyczna oznacza, że informacja przepływa w tle słyszana przez członków zespołu, dzięki czemu mogą zapoznać się z informacją jakby przez osmozę. Zwykle jest to realizowane przez zespół siedzący w jednym pomieszczeniu. W momencie, gdy jedna osoba zadaje pytanie, inni w pomieszczeniu mogą albo zareagować lub zignorować pytanie, zaangażować się w dyskusję lub kontynuować swoją pracę.? (źr. Komunikacja osmotyczna a proces).
Czytam sobie o tej komunikacji osmotycznej i dziw bierze, że takie słowotwórstwo ma miejsce. Dlaczego? Owa „osmotyczna komunikacja” to nic innego jak [[komunikacja metoda publish/subscribe]]. Prosty mechanizm, znany z teorii komunikacji mówiący, że system jakim jest ludzki mózg i ucho broniąc się przez nadmiarem informacji, odbiera wszystkie dźwięki ale reaguje jedynie na pewne „oczekiwane”. To oczekiwanie jest niczym innym jak „informacją pomocną”, np. w przeżyciu (kiedyś). To bardzo stary mechanizm ukształtowany przez ewolucje także u zwierząt. Dokładnie tak samo są nie raz projektowane systemy komunikujących się modułó, procesów, podsystemów.
Klasyczny przykład użycia tego wzorca projektowego w projektach:
Jak śledzę książki Pana Cockburn’a to niestety mam wrażenie, że po pierwsze Przypadki Użycia dawno stały się u niego „syndromem młotkowego” (człowiekowi, który dostanie do ręki wielki młotek natychmiast wszystko zaczyna kojarzyć się z gwoździem). Po drugie dziwi mnie, że można z takim zacięciem ignorować pozostałe dokonania tuzów analizy takich jak Yourdon, Fowler czy Evans.
Tak więc proponuję rozważenie, by zamiast wprowadzania nowego pojęcia: komunikacja osmotyczna (choć wiem, że brzmi super i pewnie pozwala zostać celebrytą niejednej konferencji) pozostać przy starym dobrym wzorcu publish/subscribe nie tylko w obszarze modelowania procesów czy oprogramowania ale także na niwie zwykłej komunikacji. Dla zainteresowanych wzorcem i jego zastosowaniem w modelach procesów więcej w artykule jaki napisałem o CRM.
A kończąc w kwestii Cockbourn’a i jego orędowników: osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu „user story” lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania.
Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą.
Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno „spotkasz kilka innych ładniejszych kobiet”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Regularnie czytam blog Filozofia marketingu pisany przez [[Macieja Tesławskiego]]. Wśród wielu powodów, dla których to robię są: stosowanie w pracy Brzytwy Ockhama (zwanej nie raz ekonomia myślenia, choć on sam chyba tego tak na swoim blogu nie nazywa) oraz to, że to co pisze o marketingu jest logiczne co bardzo lubię u ludzi (nie znoszę zaś pozbawionego konkretów bełkotu, którego niestety nie brakuje). Czytając kolejny wpis na jego blogu trafiłem na coś co pchnęło mnie to pewnych refleksji i zastanowienia:
Programy retencyjne mogą być B2B, B2C i multipartnerskie, lojalnościowe mogą być tylko B2C bo w biznesie decyzje zakupowe podejmuje się w znacznym stopniu racjonalnie a nie emocjonalnie.
Jeśli chodzi o ocenę działających programów retencyjnych, to podstawowy błąd jaki widzę to niewykorzystywanie bazy informacji o uczestnikach programu przez firmy. To jest potężny zbiór informacji o zachowaniach poszczególnych konsumentów, w połączeniu z danymi demograficznymi pozwala na ?poznanie? profilu najbardziej wartościowych konsumentów. Nie zauważyłem aby ktokolwiek to wykorzystywał. Dzieje się tak zapewne dlatego, że bazy danych rosną w postępie geometrycznym i przerastają możliwości ich bieżącego wykorzystywania. (źr. Do znudzenia o tej lojalności? | Filozofia marketingu.)
Celowo cytuję tak obszerny fragment (liczę na wybaczenie u autora) by zachować kontekst tego co wytłuściłem. W czym problem? W [[brzytwie Ockhama]] i tym…
…czy aby na pewno trzeba analizować te miliony zdarzeń.
Jak to się ma do systemów CRM? Prawdą jest, że lawinowo przybywa danych w bazach systemów CRM, których przetwarzanie potencjalnie może przynieść korzyści jednak nie prawdą jest, że zawsze im więcej tych danych tym lepiej. Mam cichą nadzieję, że ten krótki artykuł poszerzy tezy przytoczonego cytatu.
Marketingiem zajmuje się niejako z innej strony: modeluję zjawiska nim rządzące i muszę go rozumieć (stąd Tesławski jako jedna z kluczowych lektur po M.E.Porterze). Zgodnie z zasadą Arystotelesa: podstawą zrozumienia jest poznanie przyczyn. Analiza zjawisk, np. związanych z zachowaniami klientów, nie wymaga więc poznania setek czy milionów przypadków ich zachowań. Wymaga poznania i rozumienia tego czym się ci klienci kierują, co spowodowało takie a nie inne ich zachowania. Celem działań marketingowych (w rozumieniu analizy rynku) nie jest analiza historii a prognozowanie. Historie analizujemy by móc przewidywać jej dalszy ciąg i analiza historii to narzędzie a nie cel sam w sobie. Po drugie analiza i prognozowanie to nie wyręczanie menedżerów od podejmowania decyzji (co wielu mam wrażenie jednak robi) a jedynie wspomaganie ich w ich podejmowaniu.
Przykład pokrewny: poprawa jakości prognoz pogody ma swoje źródło nie w rosnącej ilości danych zebranych o pogodzie a w jakości modelu prognostycznego. Kiedyś prognozy pogody polegały na wyszukaniu w historii sytuacji najbliższej stanowi obecnemu, sprawdzeniu „co było potem” i uznawaniu, że „teraz też tak będzie”. Jednak to można sprowadzić to prognozowania na bazie „jak długo Indianie zbierali chrust” by ocenić nadchodzącą zimę. Obecne prognozy pogody są tworzone na bazie modeli atmosfery i zjawisk atmosferycznych: możliwe jest przewidywanie czegoś co nigdy w historia nie zaszło. Dane historyczne posłużyły do stworzenia tego modelu, potem do jego testowania (i nadal jest ulepszany…).
Inny przykład: jeżeli chce przewidzieć co się stanie gdy uderzę kulę kijem bilardowym, wystarczy dosłownie kilka obserwacji, kolejne już niczego nowego nie wniosą to stwierdzenia, że kula przemieści się w kierunku zbliżonym do kierunku uderzenia. Ktoś zapewne zauważył słowo „zbliżony” i mógłby forsować tezę, że należy powiększyć liczbę obserwacji. Tu zacytuję:
Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: „Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewną odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.” (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997)
Tak więc owszem, zbieranie danych np. o tym jakie, za co i kto zbiera punkty kupując coś w sklepie ma sens tylko do pewnego poziomu. Jeżeli chcemy na prawdę przewidzieć skutki naszych działań musimy zrozumieć zjawisko i zbudować jego model.
Tak więc skoro „… potężny zbiór informacji o zachowaniach poszczególnych konsumentów, w połączeniu z danymi demograficznymi pozwala na ?poznanie? profilu najbardziej wartościowych konsumentów”. Ten profil, jeśli powstaje, to właśnie model (ja to tak postrzegam). Jeśli będzie poprawny, będziemy w stanie z bardzo dużym prawdopodobieństwem przewidywać zachowania konsumentów. Czy tych danych musi być dużo? Czy rosnąca ilość tych danych wpłynie na poprawę jakości prognoz zachowań? Nie sądzę, gdyż prognozy bazujące na analizie trendów polegają tylko na ocenie tego, z jakim prawdopodobieństwem powtórzy się historia. Jeżeli chcemy ocenić nową kampanię, dane te – jako trend – są w zasadzie bezwartościowe: nigdy nie dadzą jako efekt niczego nowego, tylko coś, co już kiedyś było.
Dlatego hurtownie danych i tak zwane systemy [[Business Inteligence]], wszelkie systemy wspomagania decyzji, to albo analiza historii albo prognozowanie oparte na modelach. W kwestii marketingu lepiej jest, moim zdaniem, opracować model zjawiska, a do tego nie potrzebne są duże ilości danych a jedynie minimalny [[zestaw danych reprezentatywnych]] i to się nazywa zasadą ekonomii myślenia. Wielką zaś sztuką projektowania hurtowni danych dla systemów BI nie jest samo gromadzenie danych a właśnie ich odsiewanie, dlatego systemy analityczne integrowane z systemami CRM, te przeładowane danymi, bywają czasem bardziej szkodliwe niż pomocne.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Co jakiś czas spotykam się z czymś o nazwie 10 Zasad kaizen, które wzbudzają moje zdziwienie co do ich zrozumienia lub intencji albo uzasadnienia powstania danej zasady. Niewątpliwie to ja mogę także być tym, który nic nie zrozumiał i to także także należy wziąć pod uwagę, ale końcu wątpić znaczy myśleć :). Dlaczego poruszyłem tak dość obcy mi temat? Bo często spotykam się z cytowaniem tych zasad właśnie przy okazji analizy i projektowania, taki też będzie kontekst poniższych dywagacji. Tak wiec po kolei.
1. Problemy stwarzają możliwości
To prawda częściowa. Osobiście jestem wrogiem uogólnień. Jednak uogólnienie ma dwa oblicza: z jednej strony Przedmiotem wiedzy nie jest to, co jest indywidualne, lecz to, co jest ogólne.” (Arystoteles) ale uogólnienie wszystkiemu są winni cykliści to inne uogólnienie. Pierwsze polega na szukaniu wspólnych cech by odsiać pozostałe przypadkowe (to nauka), drugie to po protu wrzucanie wszystkiego do jednego worka a to już jest po protu głupota.
Tak więc najpierw pytanie: o jaki problem chodzi? Rozwiązanie problemu może polegać na umiejętnym zastosowaniu czegoś istniejącego (trzeba jednak wiedzieć, że to istnieje a nie odkrywać Amerykę po raz kolejny) a (znacznie rzadziej) na dokonaniu odkrycia. Tak zwane nowe możliwości to nic innego jak inny pomysł „na o samo” i warto pamiętać o starej dobrej [[brzytwie Ockhama]].
2. Pytaj 5 razy ?Dlaczego?? (Metoda 5 why)
To najśmieszniejsza Metoda (śmieszne jest nazywanie tego jakąś wielka metodą). Każda analiza problemu to najpierw próba odkrycia „przyczyn”, tak wiec ta rada (zasada) to raczej wskazówka dla laików w rodzaju „zanim coś zrobisz, pomyśl”.
3. Bierz pomysły od wszystkich
Tu przyznam, nie rozumiem intencji: czy chodzi o obserwację i wyciąganie wniosków, czy o proste naśladownictwo, czy wręcz o zwykłe pasożytnictwo. Niestety najczęściej spotykam się z tym ostatnim. Bo jeśli uznać „pomysł” za konkretne rozwiązanie konkretnego problemu to czym jest to „bierz od wszystkich”?
4. Myśl nad rozwiązaniami możliwymi do wdrożenia
To jest coś albo dziwnego albo oczywistego. Jeśli ktoś projektuje rozwiązanie nierealne to jest złym projektantem…
5. Odrzucaj ustalony stan rzeczy
To już mnie przerasta, gdyż odrzucanie „ustalonego stanu rzeczy” wymaga albo ogromnej odwagi albo ogromnej wiedzy albo jest po prostu kolejną naiwnością (żeby nie powiedzieć znowu wręcz głupotą) … Po drugie zasady 4. i 5. są w tym kontekście wręcz sprzeczne… No chyba, że zasada ta oznacza odrzucenie istniejących już rozwiązań ale wtedy kłoci się z zasadą 3.
6. Wymówki, że czegoś się nie da zrobić są zbędne
Kolejne lanie wody. Owszem Mojżesz pokonał morze na piechotę ale czy to ma być wyznacznik każdego kierownika projektu? Wymówki, wątpliwości, to cechy dobrego kierownika projektu, bo to świadczy o tym, ze rozumie czym jest ryzyko. Rozumiem, że ktoś może lubić adrenalinę ale to raczej sposób na hobby a nie na realizacje usług dla swoich klientów. Ci ostatnie nie muszą podzielać tego – adrenalina – hobby, szczególnie w odniesieniu do swoich firm.
7. Wybieraj proste rozwiązania ? nie czekając na te idealne
Akurat z tym należy się zgodzić ale też nie powinno się tego stosować jako zasadę bezwzględną, gdyż nieraz rozwiązanie proste po protu nie rozwiązuje problemu. Jeżeli stajemy przed problemem skręcenia mebli w salonie to prosty, znany każdemu śrubokręt jest prostym rozwiązaniem ale czy najlepiej rozwiązuje problem? Wiem, że to dziwnie brzmi, ale warto zacząć pracę później by zapytać czy nie ma czegoś lepszego, np. elektrycznej wkrętarki. Prawdą jest, że ryzykujemy rozpoczęcie pracy później (czas poświęcony na szukanie czegoś lepszego), ale też prawdopodobieństwo, że mimo to skończymy znacznie szybciej i mniej się napracujemy warte jest podjęcia tego ryzyka (próby szukania czegoś lepszego od śrubokręta).
8. Użyj sprytu zamiast pieniędzy
Tu poległem, bo czym jest tu spryt? Patrzymy do [[Słownika Języka Polskiego]]: spryt ?zdolność szybkiego, praktycznego radzenia sobie w trudnych sytuacjach?. Tak więc klasyczna [[tautologia]]. Bez sensu zupełnie.
9. Pomyłki koryguj na bieżąco
10. Ulepszenie nie ma końca
Dwie powyższe są tak oczywiste, że nie ma co pisać.
Tak wiec te i podobne „zasady” to w moich oczach jakieś oczywistości. Jednak czy złe? Hm.… czasami mam wrażenie, że wielu ludzi faktycznie powinno nawet te oczywistości poznać, z drugiej jednak strony zachodzi ryzyko, że ktoś uwierzy że proste stosowanie ich obligatoryjnie prowadzi do prostych sukcesów a to już jest ślepa uliczka. Ludzie często szukają „złotego środka” na wszystko, tak zwanej „[[srebrnej kuli]]”. Nie prostych recept, gdyby istniały nie było by problemów. Każdy problem (wyzwanie) to indywidualny problem w unikalnym środowisku. Jeżeli ktoś daje wiarę w to, że istnieje jakaś recepta na ich rozwiązywanie …
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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.