złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Cynefin czyli co…

Od cza­su do cza­su spo­ty­kam się w pro­jek­tach z poję­ciem cyne­fin”. Najpierw typo­wy opis z jakim moż­na się zetknąć w sieci:

Cynefin jest swo­istą teo­rią, któ­rą moż­na wyko­rzy­stać do opi­su dzia­ła­nia skom­pli­ko­wa­nych sys­te­mów takich jak róż­ne­go rodza­ju przed­się­wzię­cia czy nawet rela­cje i pro­ble­my mię­dzy­na­ro­do­we. Jako model tłu­ma­czy i pró­bu­je pomóc w wybo­rze stra­te­gii dzia­ła­nia, wska­zu­jąc jed­no­cze­śnie wzor­ce postę­po­wa­nia, któ­re powin­ny być zde­cy­do­wa­nie inne w zależ­no­ści od tego w jakiej sytu­acji się znaj­du­je się fir­ma. W prak­ty­ce moż­na korzy­stać z Cynefin jako narzę­dzia wspie­ra­ją­ce­go zarzą­dza­nie pro­jek­tem, zespo­łem lub nawet orga­ni­za­cją. Od jakie­goś cza­su Cynefin prze­bi­ja się tak­że do ruchu agile’owego.

Model Cynefin ma pięć obsza­rów. Pierwsze czte­ry obsza­ry to:

Prosty – zwią­zek mię­dzy przy­czy­ną a skut­kiem jest dla wszyst­kich oczy­wi­sty. Proponowany sche­mat dzia­ła­nia: odczuj-kla­sy­fi­kuj-reaguj. Można sto­so­wać naj­lep­sze praktyki.

Skomplikowany – zwią­zek mię­dzy przy­czy­ną a skut­kiem wyma­ga ana­li­zy lub innej for­my badań i/lub zasto­so­wa­nia wie­dzy eks­per­tów. Proponowany sche­mat dzia­ła­nia: odczuj-ana­li­zuj-reaguj. Można sto­so­wać dobre praktyki.

Złożony – zwią­zek mię­dzy przy­czy­ną a skut­kiem mogą być dostrze­żo­ny w retro­spek­cji (z per­spek­ty­wy cza­su), ale nie da się go prze­wi­dzieć. Proponowany sche­mat dzia­ła­nia: son­duj-odczuj-reaguj. Możemy wykryć nową praktykę.

Chaos – nie ma żad­ne­go związ­ku mię­dzy przy­czy­ną a skut­kiem na pozio­mie sys­te­mów. Proponowany spo­sób dzia­ła­nia: dzia­łaj-odczuj-reaguj. Możemy odkryć powie­ścio­wą praktykę

Piąta dome­na zwa­na nie­po­rząd­kiem” to stan nie­wie­dzy o rodza­ju ist­nie­ją­cej przy­czy­no­wo­ści, w któ­rej oso­by wra­ca­ją do wła­snej stre­fy kom­for­tu pod­czas podej­mo­wa­nia decy­zji. (Źródło: Cynefin)

inne źró­dło podaje:

Model: Cynefin
Problem: Jakiego typu podej­ście zasto­so­wać w zależ­no­ści od kon­tek­stu?
Rozwiązanie: Użyj mode­lu Cynefin jako mode­lu decy­zyj­ne­go.
Opis tech­ni­ki: Główna myśl mode­lu Cynefin jest nastę­pu­ją­ca: zagad­nie­nia, z któ­ry­mi mamy do czy­nie­nia, nie są sobie rów­ne i może­my je podzie­lić ze wzglę­du na ich zło­żo­ność. Stosuj podej­ścia ade­kwat­ne do pozio­mu zło­żo­no­ści two­jej dzie­dzi­ny.
Proste (ang. sim­ple) ? to sys­te­my, w któ­rych jed­no­znacz­nie moż­na powią­zać przy­czy­nę ze skut­kiem. Do tego obsza­ru nale­żą dobrze roz­po­zna­ne, opi­sa­ne dzie­dzi­ny pro­ble­mo­we, gdzie dostęp­na jest wie­dza, gdzie wystę­pu­ją­ce pro­ble­my nie wyma­ga­ją zło­żo­nej inter­pre­ta­cji czy doświad­cze­nia.
Skomplikowane (ang. com­pli­ca­ted) ? są to sys­te­my, w któ­rych ist­nie­je powią­za­nie mię­dzy przy­czy­ną a skut­kiem, ale nie jest ono pro­ste do wykry­cia. Znalezienie roz­wią­za­nia pro­ble­mu wyma­ga wie­dzy eks­perc­kiej, duże­go doświad­cze­nia oraz zło­żo­nej ana­li­zy. Ponadto sys­tem tego typu jest sta­tycz­ny lub przy­naj­mniej mało zmien­ny (zmien­ność moż­na prze­wi­dzieć i prze­ana­li­zo­wać).
Złożone (ang. com­plex) ? są to sys­te­my, w któ­rych nie ma jed­no­znacz­nych powią­zań mię­dzy przy­czy­ną a skut­kiem, gdyż zmie­nia­ją się one w cza­sie ? moż­na je wykryć poprzez eks­pe­ry­men­ty i docie­ka­nia obec­ne­go sta­nu rze­czy. Posiadanie wie­dzy eks­perc­kiej nie jest wystar­cza­ją­ce, aby zna­leźć roz­wią­za­nie pro­ble­mu. Potrzebne są eks­pe­ry­men­ty i ana­li­za efek­tów podej­mo­wa­nych dzia­łań.. System tego typu to sys­tem żywy, orga­nicz­ny, zmien­ny w cza­sie.
Choatyczne (ang. cha­otic) ? są to sys­te­my w któ­rych bra­ku­je powią­zań mię­dzy przy­czy­ną i skut­kiem. Wszelkie sytu­acje alar­mo­we, poża­ry, kata­stro­fy są przy­kła­da­mi takich sys­te­mów.
Nieporządek (ang. disor­der) ? to sytu­acja, w któ­rej nie jeste­śmy w sta­nie okre­ślić, z jakie­go typu sys­te­mem mamy do czy­nie­nia. (Źródło: Model Cynefin)

A teraz porów­naj­my to ze zna­ną od lat ogól­na teo­rią Systemów, któ­ra tak kla­sy­fi­ku­je systemy:

System bywa tak­że nazy­wa­ny ?zor­ga­ni­zo­wa­ną zło­żo­no­ścią?. Klasyczna ogól­na teo­ria sys­te­mów opar­ta jest na mate­ma­tycz­nych mode­lach (rów­na­niach), opi­su­ją­cych reak­cję każ­de­go ele­men­tu sys­te­mu, i sys­te­mu jako całość, na okre­ślo­ne bodź­ce. Mechanizm dzia­ła­nia (zacho­wa­nia się) sys­te­mu to wyni­ko­wy ?wzór?. W meto­dzie nauko­wej zestaw takich mate­ma­tycz­nych rów­nań nazy­wa się ?mode­lem? lub po pro­stu teo­rią wyja­śnia­ją­cą. Równania opi­su­ją­ce te ele­men­ty to, zależ­nie od zło­żo­no­ści sys­te­mu, rów­na­nia linio­we (pro­ste) lub rów­na­nia nie­li­nio­we.

GeneralSystemTheoryMathematicalProblems

?Banalnie pro­ste? sys­te­my moż­na opi­sać jed­nym, pro­stym rów­na­niem linio­wym. Systemy uzna­wa­ne za ?łatwe? do ana­li­zy to te, dają­ce się opi­sać pro­stym ukła­dem kil­ku rów­nań linio­wych lub jed­nym rów­na­niem róż­nicz­ko­wym. Systemy wyma­ga­ją­ce do ich opi­su (zamo­de­lo­wa­nia) ukła­du bar­dzo wie­lu rów­nań linio­wych lub nawet kil­ku poje­dyn­czych róż­nicz­ko­wych, sta­ją bar­dzo trud­ne, a w mia­rę rosną­cej ilo­ści rów­nań (zło­żo­no­ści sys­te­mu), są po pro­stu nie­moż­li­we do roz­wią­za­nia meto­dą inną niż sta­ty­stycz­na (ite­ra­cje i bada­nie rezul­ta­tów). Pisząc ?ana­li­za? mamy tu na myśli moż­li­wość nie tyl­ko opi­sa­nia tymi rów­na­nia­mi sys­te­mu (bo to nie musi być trud­ne) ale ich (tych rów­nań) roz­wią­za­nie (przy­po­mi­nam: to wie­le rów­nań z wie­lo­ma zmien­ny­mi). (źr. Ogólna Teoria Systemów).

Od sie­bie dodam, że model sys­te­mu to struk­tu­ra obra­zu­ją­ca współ­pra­cu­ją­ce (mają­ce ze sobą inte­rak­cje) obiek­ty a owe rów­na­nia linio­we i nie­li­nio­we” to odpo­wie­dzi na bodź­ce (mówiąc języ­kiem metod obiek­to­wych są to meto­dy, reak­cje, odpo­wie­dzi, tych obiek­tów). Odpowiedź całe­go sys­te­mu moż­na więc opi­sać jed­nym rów­na­niem, dla­te­go w tytu­le tabe­li nazwa­no sys­tem pro­ble­mem mate­ma­tycz­nym, zło­żo­ność rów­na­nia opi­su­ją­ce­go odpo­wiedź sys­te­mu obra­zu­je sto­pień zło­żo­no­ści tego sys­te­mu. Dodam też, że ana­li­za obiek­to­wa pozwa­la posłu­gi­wać się cało­ścią lub poszcze­gól­ny­mi obiek­ta­mi zależ­nie od przy­ję­te­go pozio­mu abs­trak­cji. A teraz po raz kolej­ny defi­ni­cja systemu:

System: zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków i rela­cji) mię­dzy nimi (Sienkiewicz, 1994) (Źródło: Słownik Pojęć | Jarosław Żeliński IT-Consulting)

Napisanie więc, że są sys­te­my, w któ­rych nie ma jed­no­znacz­nych powią­zań mię­dzy przy­czy­ną a skut­kiem” albo w któ­rych bra­ku­je powią­zań mię­dzy przy­czy­ną i skut­kiem”, świad­czy o zwy­kłej nie­wie­dzy, o nie­zro­zu­mie­niu two­rzo­ne­go sys­te­mu (a nawet o nie­zro­zu­mie­niu defi­ni­cji same­go poję­cia sys­tem) a nie o tym, że nie ma w nim powią­zań”, bo gdy­by ich nie było nie był by to jeden sys­tem. Skrajność to stan w któ­rym nie jeste­śmy w sta­nie okre­ślić, z jakie­go typu sys­te­mem mamy do czy­nie­nia” czy­li nic nie kumam” i to moim zda­niem okre­śla całe podej­ście zwa­ne cyne­fin”.

To wła­snie to, co nie raz widu­ję w pra­cy nazy­wa­nej czę­sto agi­le”: podej­mo­wa­nie się pro­jek­tów przy cał­ko­wi­tym bra­ku zro­zu­mie­nia dzie­dzi­ny pro­ble­mu. To, czy nazwie­my to cha­osem, czy znaj­dzie­my nową mądrą” nazwę CYNEFIN, nicze­go nie zmie­nia. Po pro­stu brzy­twa Ockhama” po raz kolej­ny szy­der­czo się uśmie­cha… A pró­by napi­sa­nia opro­gra­mo­wa­nia w sytu­acji bra­ku zro­zu­mie­nia jaki ma być mecha­nizm jego dzia­ła­nia to po pro­stu szu­ka­nie kło­po­tów… i nie­ste­ty nadal czę­sto spo­ty­ka­ne zja­wi­sko czy­li szczur w labiryncie”… 

[doda­tek]

Ciekawostką jest tak­że archi­tek­tu­ra C4” (czy­taj opis). Jest to Cała teo­ria i meto­da” w któ­rej jest 100% tech­no­lo­gii i ZERO o biz­ne­so­wej dzie­dzi­nie i jej logi­ce… Bardzo czę­sto deve­lo­pe­rzy nie­ste­ty obie­cu­ję, ze sami napi­szą” to opro­gra­mo­wa­nie, a potem mozol­nie po omac­ku, wie­lo­ma pró­ba­mi, usi­łu­ją stwo­rzyć opro­gra­mo­wa­nie reali­zu­ją­ce logi­kę biz­ne­so­wą… jak szczur w labi­ryn­cie któ­ry któ­ry na każ­dą rzecz któ­rej nie rozu­mie znaj­du­je nową nazwę: raz CYNEFIN, raz C4… (tak na praw­dę C4 to co naj­wy­żej tyl­ko nowy pro­fil do UML, jed­na stro­na łącz­nie z komentarzami).

Metodologiczny dekalog naukowca

Swego cza­su pisałem:

Hipoteza ? osąd, teo­ria, któ­ra nie zna­la­zła jesz­cze potwier­dze­nia w fak­tach, lub w przy­pad­ku hipo­tez mate­ma­tycz­nych nie zosta­ła jesz­cze popraw­nie udowodniona.Stawianie i testo­wa­nie hipo­tez to jeden z pod­sta­wo­wych pro­ce­sów twór­cze­go myśle­nia oraz fun­da­men­tal­ny ele­ment pro­ce­su two­rze­nia nauki. (Źródło: Metoda nauko­wa w ana­li­zie wyma­gań | Jarosław Żeliński IT-Consulting)

Nie raz w toku pro­jek­tów mówię, że moja pra­ca prze­bie­ga w taki – nauko­wy – wła­snie spo­sób: zbie­ram pew­ną nie­wiel­ką par­tię danych, np. dwa, może trzy kom­ple­ty doku­men­tów dane­go pro­ce­su biz­ne­so­we­go, i two­rzę model tego pro­ce­su. Ten model to hipo­te­za: Ten pro­ces tak prze­bie­ga”. Kolejny ruch” to testo­wa­nie mode­lu czy­li pró­ba jest fal­sy­fi­ka­cji, szu­ka­nia w ana­li­zo­wa­nej orga­ni­za­cji fak­tów prze­czą­cych tej tezie. Polega na wysła­niu do recen­zji lub pre­zen­ta­cji opra­co­wa­ne­go mode­lu pro­ce­su. Jeżeli uda się zna­leźć zda­rze­nie lub doku­ment, któ­re­go model pro­ce­su nie tłu­ma­czy (nie opi­su­je go), to zna­czy, że model jest zły (został pod­wa­żo­ny) i nale­ży go popra­wić. Jeżeli w toku recen­zji, żaden recen­zent (recen­zen­tem jest tu eks­pert dzie­dzi­no­wy z obsza­ru dane­go pro­ce­su biz­ne­so­we­go w ana­li­zo­wa­nej orga­ni­za­cji) nie pod­wa­ży mode­lu, zna­czy to, że model jest popraw­ny czy­li odwzo­ro­wu­je to co się dzie­je w orga­ni­za­cji. To pro­ce­du­ra zwa­na meto­dą nauko­wą (model ten musi tak­że speł­niać wymo­gi for­mal­ne czy­li zgod­ność z daną nota­cją, np. BPMN i usta­lo­na prag­ma­ty­ką two­rze­nia tych modeli).

Nie raz mie­wam proś­by” o doda­nie do mode­lu pro­ce­su (jest nim dia­gram np. w nota­cji BPMN) cze­goś nie­po­trzeb­ne­go albo wręcz koli­du­ją­ce­go z zade­kla­ro­wa­ną nota­cją lub prag­ma­ty­ką. Z regu­ły są to jakieś a my cza­sem jest robi­my to tak i tak” albo pro­szę poka­zać jesz­cze to”. Praktycznie zawsze są to nad­mia­ro­we szcze­gó­ły, opi­su­ją­ce pew­ne wybra­ne deta­licz­ne czyn­no­ści, któ­re nie mają pły­wu na mode­lo­wa­ny pro­ces, sta­no­wią jego natu­rę lub detal zawar­ty w doku­men­tach. Elementy, któ­re na eta­pie mode­lo­wa­nia pro­ce­sów z zasa­dy pomi­ja­my bo są udo­ku­men­to­wa­ne w pro­ce­du­rach, zakre­sach obo­wiąz­ków, instruk­cjach obsłu­gi urzą­dzeń, wzo­rach doku­men­tów itp. Drugi ele­ment czę­sto psu­ją­cy mode­le to doda­wa­nie na dia­gra­mach ikon i sym­bo­li z poza nota­cji. Zdarza się to w sytu­acji, gdy popro­si o to któ­ryś z recen­zen­tów lub zro­bi to sam ana­li­tyk, któ­ry nie pora­dził sobie ze zro­zu­mie­niem dane­go zja­wi­ska”.

Takie zbyt szcze­gó­ło­we lub prze­kła­ma­ne dia­gra­my z regu­ły koń­czą życie na śmiet­ni­ku pro­jek­tu” czy­li na nie­uży­wa­nej pół­ce z doku­men­ta­mi po ich zafakturowaniu.

W mode­lach sys­te­mów (wyko­na­nych z uży­ciem nota­cji UML) naj­czę­ściej widu­ję złe (nie­zgod­ne z ich zna­cze­niem) uży­cie sym­bo­li UML. Dotyczy to głów­nie dia­gra­mów klas i dia­gra­mów przy­pad­ków uży­cia. Na dia­gra­mach klas są to naj­czę­ściej błę­dy wyni­ka­ją­ce z myle­nia mode­li poję­cio­wych i mode­li struk­tu­ry na jed­nym dia­gra­mie klas. Na dia­gra­mach przy­pad­ków uży­cia nie raz obser­wu­ję cał­ko­wi­te odej­ście od reguł UML, do sto­so­wa­nia UML tak jak np. Power Pointa czy­li sym­bol jest faj­ny to go uży­je­my do cze­go nam tyl­ko pasu­je”. Ma nie raz miej­sce wpro­wa­dza­nie kurio­zal­nych pojęć, z poza nota­cji UML typu aktor czas”, sys­te­mo­wy przy­pa­dek uży­cia” i inne dzi­wo­lą­gi pro­wa­dzą­ce do ich mno­że­nia, tyl­ko dopeł­nia­ją bałaganu.

Nie raz przy­wo­ły­wa­łem tak zwa­ną „[[Brzytwę Ockhama]]”, jest to meta­fo­ra, mówią­ca, ze w nauce two­rze­nie nowych bytów musi mieć uza­sad­nie­nie, be tego wszel­kie nowe byty” sta­no­wią tyl­ko obraz nie­wie­dzy i nie­zro­zu­mie­nia, ide­olo­gicz­ne­go ukry­cia bra­ku moż­li­wo­ści dowie­dze­nia ist­nie­nia cze­goś. Tu zacy­tu­ję frag­ment pew­ne­go blo­ga (pole­cam lek­tu­rę całe­go cyto­wa­ne­go artykułu):

Nie będziesz mno­żył bytów ponad mia­rę [treść tzw. Brzytwy Ockhama, przyp mój J.Ż.]. Tak jak nie nale­ży bez przy­czy­ny wybie­rać roz­wią­za­nia nad­mier­nie skom­pli­ko­wa­ne­go, tak też nie wol­no dowol­nie doko­op­to­wy­wać do swo­je­go rozu­mo­wa­nia dodat­ko­wych bytów. Nie sto­su­jąc się do tego zaka­zu, dla przy­wo­ła­ne­go wcze­śniej przy­kła­du, mogli­by­śmy ukuć nie­zli­czo­ną ilość kolej­nych wyja­śnień. Katedry i pira­mi­dy mogli prze­cież wznieść przy­by­sze z kosmo­su, cza­ro­dzie­je, duchy, demo­ny, skrza­ty? Byty moż­na mno­żyć bez koń­ca, tłu­ma­cząc nimi każ­de obser­wo­wa­ne zja­wi­sko. A jed­nak nie daje­my wia­ry zapew­nie­niom brzdą­ca twier­dzą­ce­go, że cen­ny wazon w salo­nie uległ destruk­cji w sku­tek dzia­łal­no­ści zło­śli­we­go polter­ge­ista. W każ­dym razie, zna­le­zio­na opo­dal miej­sca zda­rze­nia pił­ka, pod­su­wa nam znacz­nie praw­do­po­dob­niej­sze wyja­śnie­nia. Dopuszczając do pro­ce­su nauko­we­go kra­sno­lud­ki, dżi­ny, wróż­ki i co tam chce­cie, docho­dzi­my do nie­uchron­ne­go acz bez­war­to­ścio­we­go wnio­sku, iż każ­da z dowol­nie zmy­ślo­nych odpo­wie­dzi jest rów­nie dobra i rów­nie (nie)prawdopodobna. (Źródło: Metodologiczny deka­log naukow­ca | Kwantowo​.pl – astro­no­mia, fizy­ka, nauka!)

Tak więc czy­ta­jąc czy­je­kol­wiek opra­co­wa­nia, w szcze­gól­no­ści ana­li­zy biz­ne­so­we i mode­le sys­te­mów, spraw­dzaj­cie, czy ktoś nie umie­ścił tam ana­li­tycz­nych kra­sno­lud­ków, kosmi­tów, dżi­nów itp. Takie byty na dia­gra­mach jak aktor czas” czy sys­te­mo­wy przy­pa­dek uży­cia”, świad­czą wyłącz­nie o tym, że autor po pro­stu nie pora­dził sobie z ana­li­zą, nie do koń­ca odkrył isto­tę tego co ana­li­zo­wał i opi­sał, nie zro­zu­miał tego co mode­lu­je. Dodawanie nowych bytów do nota­cji jak naj­bar­dziej jest moż­li­we, ale po pierw­sze nale­ży to robić popra­wie­nie ale potrze­ba taka jest bar­dzo rzad­ka. W obsza­rze ana­li­zy i mode­lo­wa­nia obec­na postać BPMN wystar­czy aż nad­to, do mode­lo­wa­nie opro­gra­mo­wa­nia zorien­to­wa­ne­go obiek­to­wo UML tym bar­dziej wystar­czy. Takie upstrzo­ne wyna­laz­ka­mi” doku­men­ty być może są atrak­cyj­ne ale kom­plet­nie nieprzydatne.

przypadek użycia aktor czas

Ach ten przypadek użycia czyli filozofia

Dzisiaj co nie­co o filo­zo­fii i przy­pad­kach użycia.

usecase pandoraDzielenie przy­pad­ków uży­cia na ?rodza­je? zawsze budzi­ło mój sprze­ciw, w UML (w ory­gi­na­le) mamy jed­no poje­cie ?przy­pa­dek uży­cia sys­te­mu?, gdzie sys­te­mem jest coś (pod­miot zain­te­re­so­wa­nia), czy­li ?analizowany/modelowany sys­tem? (patrząc na sys­tem w rozu­mie­niu teo­rii sys­te­mów, tu zwra­cam uwa­gę na fakt, że UML to nie tyl­ko IT). Wobec tego sko­ro sys­tem (wymien­nie przed­miot zain­te­re­so­wa­nia”, przed­miot ana­li­zy”), zanim będzie roz­pa­try­wa­ny, musi być okre­ślo­ny (gra­ni­ce sys­te­mu, któ­ry jest czę­ścią nad” (super) sys­te­mu, a skła­da się z pod­sys­te­mów, pole­cam Sienkiewicz, Teoria Systemów), otrzy­ma­my pro­stą rzecz: przy­pa­dek uży­cia ma jed­ną defi­ni­cję, ale w danym momen­cie roz­pa­try­wa­nym sys­te­mem (przed­miot ana­li­zy) jest np. opro­gra­mo­wa­nie ale też może nim być np. orga­ni­za­cja. Tak więc przy­pa­dek uży­cia ?opro­gra­mo­wa­nia? (np. wysta­wia­nie fak­tu­ry VAT) niczym się nie róż­ni od ?przy­pad­ku uży­cia? fir­my sprze­da­ją­cej rowe­ry ?dostar­cze­nie zamó­wio­ne­go rowe­ru?? to co tu robi róż­ni­cę” do gra­ni­ce sys­te­mu- kon­tekst: raz jest nią gra­ni­ca ?opro­gra­mo­wa­nia? a raz ?orga­ni­za­cji?.

Proste poję­cie przy­pad­ku uży­cia jest pięk­ne bo pro­ste. Popatrzmy do ory­gi­nal­nej spe­cy­fi­ka­cji (OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1):

16. Use Cases

16.1 Overview

Use cases are a means for spe­ci­fy­ing requ­ired usa­ges of a sys­tem. Typically, they are used to cap­tu­re the requ­ire­ments of a sys­tem, that is, what a sys­tem is sup­po­sed to do. The key con­cepts asso­cia­ted with use cases are actors, use cases, and the sub­ject. The sub­ject is the sys­tem under con­si­de­ra­tion to which the use cases apply. The users and any other sys­tems that may inte­ract with the sub­ject are repre­sen­ted as actors. Actors always model enti­ties that are out­si­de the sys­tem. The requ­ired beha­vior of the sub­ject is spe­ci­fied by one or more use cases, which are defi­ned accor­ding to the needs of actors. […] Use cases, actors, and sys­tems are descri­bed using use case dia­grams.

9wytłuszczenia moje). Co my tu mamy:

  1. Przypadek uży­cia ozna­cza spe­cy­ficz­ne (kon­kret­ne) ocze­ki­wa­ne uży­cie sys­te­mu. Standardowo uży­wa­ny jest do zbie­ra­nia [J.Ż. doku­men­to­wa­nia] wyma­gań na sys­tem, pla­no­wa­ny do użycia. 
  2. Kluczowymi poję­cia­mi łączo­ny­mi z Przypadkiem uży­cia są aktor oraz przed­miot zain­te­re­so­wa­nia (sys­tem).
  3. Opisywanym z pomo­cą przy­pad­ków uży­cia przed­mio­tem jest sys­tem, któ­ry będzie wyko­rzy­sty­wa­ny zgod­nie z przy­pad­ka­mi uży­cia (w tym celu).
  4. Użytkownik lub inny sys­tem może oddzia­ły­wać na opi­sy­wa­ny przy­pad­ka­mi uży­cia przed­miot, nazy­wa­ny jest wte­dy akto­rem. Aktorem jest każ­dy zewnętrz­ny w sto­sun­ku do opi­sy­wa­ne­go sys­te­mu ele­ment (byt).
  5. Wymagane zacho­wa­nie opi­sy­wa­ne­go przed­mio­tu (sys­tem) może być opi­sa­ne jed­nym lub wie­lo­ma przy­pad­ka­mi uży­cia, defi­nio­wa­ny­mi jako potrze­by akto­ra (w sto­sun­ku do systemu).
  6. Przypadek uży­cia, aktor i sys­tem razem są okre­śla­ne jako dia­gram przy­pad­ków użycia. 

Jak widać, nie ma tu żad­nych kom­bi­na­cji, dowol­ny sys­tem, jego oto­cze­nie oraz inte­rak­cje tego oto­cze­nia z nim samym opi­su­je­my (mode­lu­je­my) z pomo­cą trzech pojęć pokry­wa­ją­cych wszyst­kie wyma­ga­ne ele­men­ty: kto/co, z czym i jakie ma interakcje.

Teraz pro­szę naj­pierw prze­czy­tać to:

schopenhauer_czworaki_korzen_zasady_racji_dostatecznej

Dwie waż­ne rze­czy: nie wol­no bez potrze­by mno­żyć licz­by bytu­ją­cych istot” to zna­na bar­dziej jako brzy­twa OckhamaNie nale­ży mno­żyć bytów ponad potrze­bę” (Brzytwa Ockhama (nazy­wa­na tak­że zasa­dą eko­no­mii lub zasa­dą eko­no­mii myśle­nia) ? zasa­da, zgod­nie z któ­rą w wyja­śnia­niu zja­wisk nale­ży dążyć do pro­sto­ty, wybie­ra­jąc takie wyja­śnie­nia, któ­re opie­ra­ją się na jak naj­mniej­szej licz­bie zało­żeń i pojęć. Tradycyjnie wią­za­na jest z nazwi­skiem Williama Ockhama.). Druga: nie wol­no nie­po­trzeb­nie umniej­szać odmian bytu­ją­cych istot” . Razem są zwa­ne jako naj­wyż­sze pra­wa rozu­mu” (filo­zo­fa, badacza).

Powyższy wkle­jo­ny cytat pocho­dzi z roz­pra­wy Czworaki korzeń zasa­dy racji dosta­tecz­nej Schopenhauera. Cytuję go, gdyż gorą­co pole­cam filo­zo­fię ana­li­ty­kom (uczy logicz­ne­go myśle­nia i ana­li­zy), tę zaś zasa­dę pole­cam szcze­gól­nie, gdyż pozwa­la ona unik­nąć nie­po­trzeb­ne­go mno­że­nia bytów np. w posta­ci róż­nych rodza­jów przy­pad­ków uży­cia” (doty­czy to tak­że akto­rów). W jed­nej z prac inne­go filo­zo­fa (nie pamię­tam teraz któ­re­go), moż­na zna­leźć, że łama­nie powyż­szej zasa­dy (nada­wa­nie nowych nazw nowym postrze­ga­nym rze­czom) to wraz nie­zro­zu­mie­nia”: cze­go nie rozu­miem nadam mu nową nazwę”. To zła droga…

Zacytuje frag­ment moje­go refe­ra­tu z pew­nej konferencji:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to tyl­ko kule i kij i pra­wa fizy­ki. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Tak więc, tyl­ko trzy poję­cia: sys­tem, aktor i przy­pa­dek uży­cia zupeł­nie wystar­czą by opi­sać sys­tem i jego (przy­szłe, pla­no­wa­ne) wyko­rzy­sta­nie czy­li wyma­ga­nia. I zawsze powin­ny wystą­pić te trzy ele­men­ty na mode­lu. Mnożenie bytów na tym dia­gra­mie to raczej przy­zna­nie się do porażki…

Na koniec pole­cam tak­że Prezentacja (skrót) książ­ki Rebeki Wirfs-brock. Uwaga o pro­jek­to­wa­niu i przy­pad­kach użycia:

What?s Missing From Use Cases:

- Use cases are descrip­ti­ve, not pre­scrip­ti­ve [przy­pad­ki uży­cia są opi­so­we a nie nakazowe]

- There is a gap betwe­en the­se descrip­tions and a design [są wypeł­nie­niem luki pomię­dzy opi­sem a projektem]

___
Transcendentalny – będą­cy warun­kiem (moż­li­wo­ści) zaist­nie­nia cze­goś. W filo­zo­fii Kanta i jego kon­ty­nu­ato­rów doty­czą­cy aprio­rycz­nych form pozna­nia, teo­re­tycz­nie wykra­cza­ją­cych poza przed­miot i treść pozna­nia, a odno­szą­cy się do warun­ków pozna­nia peł­nej rze­czy­wi­sto­ści poznaw­czej tzn. praw­dy abso­lut­nej poj­mo­wa­nej uni­wer­sal­nie przez wszyst­kie pod­mio­ty poznaw­cze. Innymi sło­wy, taka for­ma pozna­nia ota­cza­ją­cej rze­czy­wi­sto­ści, by każ­dy bez wzglę­du na jego umiej­sco­wie­nie w niej, mógł stwier­dzić jed­no­znacz­ność poznaw­czą, czy­li praw­dę – uni­wer­sal­ną dla wszyst­kich istot poznaw­czych we wszechświecie.

Komunikacja osmotyczna czyli po Brzytwie przypadków użycia

No nic nie pora­dzę na to, że zna­ny w bran­ży autor ([[Alistair Cockburn]]) moim zda­niem pły­wa w czymś co ja nazy­wam mno­że­nie bytów”, świat zna to pod nazwą [[Brzytwa Ockhama]], tu raczej jest to zaprze­cze­nie tej zasa­dzie a w moich oczach A.C. jest mistrzem w tej dziedzinie:

Alistair Cockburn przy­ta­cza na swo­jej stro­nie defi­ni­cję stwier­dza­ją­cą, że ?komu­ni­ka­cja osmo­tycz­na ozna­cza, że infor­ma­cja prze­pły­wa w tle sły­sza­na przez człon­ków zespo­łu, dzię­ki cze­mu mogą zapo­znać się z infor­ma­cją jak­by przez osmo­zę. Zwykle jest to reali­zo­wa­ne przez zespół sie­dzą­cy w jed­nym pomiesz­cze­niu. W momen­cie, gdy jed­na oso­ba zada­je pyta­nie, inni w pomiesz­cze­niu mogą albo zare­ago­wać lub zigno­ro­wać pyta­nie, zaan­ga­żo­wać się w dys­ku­sję lub kon­ty­nu­ować swo­ją pra­cę.? (źr. Komunikacja osmo­tycz­na a pro­ces).

Czytam sobie o tej komu­ni­ka­cji osmo­tycz­nej i dziw bie­rze, że takie sło­wo­twór­stwo ma miej­sce. Dlaczego? Owa osmo­tycz­na komu­ni­ka­cja” to nic inne­go jak [[komu­ni­ka­cja meto­da publish/subscribe]]. Prosty mecha­nizm, zna­ny z teo­rii komu­ni­ka­cji mówią­cy, że sys­tem jakim jest ludz­ki mózg i ucho bro­niąc się przez nad­mia­rem infor­ma­cji, odbie­ra wszyst­kie dźwię­ki ale reagu­je jedy­nie na pew­ne ocze­ki­wa­ne”. To ocze­ki­wa­nie jest niczym innym jak infor­ma­cją pomoc­ną”, np. w prze­ży­ciu (kie­dyś). To bar­dzo sta­ry mecha­nizm ukształ­to­wa­ny przez ewo­lu­cje tak­że u zwie­rząt. Dokładnie tak samo są nie raz pro­jek­to­wa­ne sys­te­my komu­ni­ku­ją­cych się modu­łó, pro­ce­sów, podsystemów.

Klasyczny przy­kład uży­cia tego wzor­ca pro­jek­to­we­go w projektach:

Jak śle­dzę książ­ki Pana Cockburn’a to nie­ste­ty mam wra­że­nie, że po pierw­sze Przypadki Użycia daw­no sta­ły się u nie­go syn­dro­mem młot­ko­we­go” (czło­wie­ko­wi, któ­ry dosta­nie do ręki wiel­ki mło­tek natych­miast wszyst­ko zaczy­na koja­rzyć się z gwoź­dziem). Po dru­gie dzi­wi mnie, że moż­na z takim zacię­ciem igno­ro­wać pozo­sta­łe doko­na­nia tuzów ana­li­zy takich jak Yourdon, Fowler czy Evans.

Tak więc pro­po­nu­ję roz­wa­że­nie, by zamiast wpro­wa­dza­nia nowe­go poję­cia: komu­ni­ka­cja osmo­tycz­na (choć wiem, że brzmi super i pew­nie pozwa­la zostać cele­bry­tą nie­jed­nej kon­fe­ren­cji) pozo­stać przy sta­rym dobrym wzor­cu publish/subscribe nie tyl­ko w obsza­rze mode­lo­wa­nia pro­ce­sów czy opro­gra­mo­wa­nia ale tak­że na niwie zwy­kłej komu­ni­ka­cji. Dla zain­te­re­so­wa­nych wzor­cem i jego zasto­so­wa­niem w mode­lach pro­ce­sów wię­cej w arty­ku­le jaki napi­sa­łem o CRM.

A koń­cząc w kwe­stii Cockbourn’a i jego orę­dow­ni­ków: oso­bi­ście i bar­dzo subiek­tyw­nie uwa­żam, że nawet jeśli dowol­ną kupę mało spój­ne­go tek­stu roz­ło­ży­my na wier­sze i kolum­ny dowol­nej ilo­ści tabel (to się cza­sem nazy­wa cza­sem nada­wa­niem tek­sto­wi struk­tu­ry) to taki tekst nadal będzie mało spój­ny. Przypadki uży­cia jako tabe­la­rycz­na for­ma zapi­su user sto­ry” lub wyma­gań funk­cjo­nal­nych, nie uzy­ska­ją spój­no­ści poprzez sam fakt ich stabelaryzowania.

Przypadki uży­cia zaś jako efekt ana­li­zy cało­ści zacho­wań i świa­do­me­go wybo­ru czę­ści z nich to jest dopie­ro spój­ny i kom­plet­ny opis wyma­gań. Bo jak to ktoś powie­dział: kom­plet­na lista naj­ład­niej­szych kobiet w danym mie­ście to nie lista spo­tka­nych ład­nych w ostat­nim mie­sią­cu a lista wybra­nych spo­śród wszyst­kich w tym mie­ście. Taka lista ma sens bo nie gro­zi nam to, ze następ­ne­go dnia w tym mie­ście spo­tka­my inna ładniejszą.

Jeżeli ktoś Ci przy­nie­sie spe­cy­fi­ka­cję przy­pad­ków uży­cia do sys­te­mu i nie będzie potra­fił jed­no­znacz­nie odpo­wie­dzieć na pyta­nie dla­cze­go jest ich aku­rat tyle a nie np. jeden mniej lub dwa wię­cej albo dla­cze­go aku­rat te a nie inne, to naj­praw­do­po­dob­niej zna­czy to, że pod­czas wdro­że­nia na pew­no spo­tkasz kil­ka innych ład­niej­szych kobiet”.

Ekonomia myślenia – brzytwa Ockhama

fin_tableRegularnie czy­tam blog Filozofia mar­ke­tin­gu pisa­ny przez [[Macieja Tesławskiego]]. Wśród wie­lu powo­dów, dla któ­rych to robię są: sto­so­wa­nie w pra­cy Brzytwy Ockhama (zwa­nej nie raz eko­no­mia myśle­nia, choć on sam chy­ba tego tak na swo­im blo­gu nie nazy­wa) oraz to, że to co pisze o mar­ke­tin­gu jest logicz­ne co bar­dzo lubię u ludzi (nie zno­szę zaś pozba­wio­ne­go kon­kre­tów beł­ko­tu, któ­re­go nie­ste­ty nie bra­ku­je). Czytając kolej­ny wpis na jego blo­gu tra­fi­łem na coś co pchnę­ło mnie to pew­nych reflek­sji i zastanowienia:

Programy reten­cyj­ne mogą być B2B, B2C i mul­ti­part­ner­skie, lojal­no­ścio­we mogą być tyl­ko B2C bo w biz­ne­sie decy­zje zaku­po­we podej­mu­je się w znacz­nym stop­niu racjo­nal­nie a nie emocjonalnie.

Jeśli cho­dzi o oce­nę dzia­ła­ją­cych pro­gra­mów reten­cyj­nych, to pod­sta­wo­wy błąd jaki widzę to nie­wy­ko­rzy­sty­wa­nie bazy infor­ma­cji o uczest­ni­kach pro­gra­mu przez fir­my. To jest potęż­ny zbiór infor­ma­cji o zacho­wa­niach poszcze­gól­nych kon­su­men­tów, w połą­cze­niu z dany­mi demo­gra­ficz­ny­mi pozwa­la na ?pozna­nie? pro­fi­lu naj­bar­dziej war­to­ścio­wych kon­su­men­tów. Nie zauwa­ży­łem aby kto­kol­wiek to wyko­rzy­sty­wał. Dzieje się tak zapew­ne dla­te­go, że bazy danych rosną w postę­pie geo­me­trycz­nym i prze­ra­sta­ją moż­li­wo­ści ich bie­żą­ce­go wyko­rzy­sty­wa­nia. (źr. Do znu­dze­nia o tej lojal­no­ści? | Filozofia marketingu.)

Celowo cytu­ję tak obszer­ny frag­ment (liczę na wyba­cze­nie u auto­ra) by zacho­wać kon­tekst tego co wytłu­ści­łem. W czym pro­blem? W [[brzy­twie Ockhama]] i tym…

…czy aby na pewno trzeba analizować te miliony zdarzeń.

Jak to się ma do sys­te­mów CRM? Prawdą jest, że lawi­no­wo przy­by­wa danych w bazach sys­te­mów CRM, któ­rych prze­twa­rza­nie poten­cjal­nie może przy­nieść korzy­ści jed­nak nie praw­dą jest, że zawsze im wię­cej tych danych tym lepiej. Mam cichą nadzie­ję, że ten krót­ki arty­kuł posze­rzy tezy przy­to­czo­ne­go cytatu.

Marketingiem zaj­mu­je się nie­ja­ko z innej stro­ny: mode­lu­ję zja­wi­ska nim rzą­dzą­ce i muszę go rozu­mieć (stąd Tesławski jako jed­na z klu­czo­wych lek­tur po M.E.Porterze). Zgodnie z zasa­dą Arystotelesa: pod­sta­wą zro­zu­mie­nia jest pozna­nie przy­czyn. Analiza zja­wisk, np. zwią­za­nych z zacho­wa­nia­mi klien­tów, nie wyma­ga więc pozna­nia setek czy milio­nów przy­pad­ków ich zacho­wań. Wymaga pozna­nia i rozu­mie­nia tego czym się ci klien­ci kie­ru­ją, co spo­wo­do­wa­ło takie a nie inne ich zacho­wa­nia. Celem dzia­łań mar­ke­tin­go­wych (w rozu­mie­niu ana­li­zy ryn­ku) nie jest ana­li­za histo­rii a pro­gno­zo­wa­nie. Historie ana­li­zu­je­my by móc prze­wi­dy­wać jej dal­szy ciąg i ana­li­za histo­rii to narzę­dzie a nie cel sam w sobie. Po dru­gie ana­li­za i pro­gno­zo­wa­nie to nie wyrę­cza­nie mene­dże­rów od podej­mo­wa­nia decy­zji (co wie­lu mam wra­że­nie jed­nak robi) a jedy­nie wspo­ma­ga­nie ich w ich podejmowaniu.

Przykład pokrew­ny: popra­wa jako­ści pro­gnoz pogo­dy ma swo­je źró­dło nie w rosną­cej ilo­ści danych zebra­nych o pogo­dzie a w jako­ści mode­lu pro­gno­stycz­ne­go. Kiedyś pro­gno­zy pogo­dy pole­ga­ły na wyszu­ka­niu w histo­rii sytu­acji naj­bliż­szej sta­no­wi obec­ne­mu, spraw­dze­niu co było potem” i uzna­wa­niu, że teraz też tak będzie”. Jednak to moż­na spro­wa­dzić to pro­gno­zo­wa­nia na bazie jak dłu­go Indianie zbie­ra­li chrust” by oce­nić nad­cho­dzą­cą zimę. Obecne pro­gno­zy pogo­dy są two­rzo­ne na bazie mode­li atmos­fe­ry i zja­wisk atmos­fe­rycz­nych: moż­li­we jest prze­wi­dy­wa­nie cze­goś co nigdy w histo­ria nie zaszło. Dane histo­rycz­ne posłu­ży­ły do stwo­rze­nia tego mode­lu, potem do jego testo­wa­nia (i nadal jest ulepszany…).

Inny przy­kład: jeże­li chce prze­wi­dzieć co się sta­nie gdy ude­rzę kulę kijem bilar­do­wym, wystar­czy dosłow­nie kil­ka obser­wa­cji, kolej­ne już nicze­go nowe­go nie wnio­są to stwier­dze­nia, że kula prze­mie­ści się w kie­run­ku zbli­żo­nym do kie­run­ku ude­rze­nia. Ktoś zapew­ne zauwa­żył sło­wo zbli­żo­ny” i mógł­by for­so­wać tezę, że nale­ży powięk­szyć licz­bę obser­wa­cji. Tu zacytuję:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­ną odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre opro­gra­mo­wa­nie.” (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997)

Tak więc owszem, zbie­ra­nie danych np. o tym jakie, za co i kto zbie­ra punk­ty kupu­jąc coś w skle­pie ma sens tyl­ko do pew­ne­go pozio­mu. Jeżeli chce­my na praw­dę prze­wi­dzieć skut­ki naszych dzia­łań musi­my zro­zu­mieć zja­wi­sko i zbu­do­wać jego model.

Tak więc sko­ro „… potęż­ny zbiór infor­ma­cji o zacho­wa­niach poszcze­gól­nych kon­su­men­tów, w połą­cze­niu z dany­mi demo­gra­ficz­ny­mi pozwa­la na ?pozna­nie? pro­fi­lu naj­bar­dziej war­to­ścio­wych kon­su­men­tów”. Ten pro­fil, jeśli powsta­je, to wła­śnie model (ja to tak postrze­gam). Jeśli będzie popraw­ny, będzie­my w sta­nie z bar­dzo dużym praw­do­po­do­bień­stwem prze­wi­dy­wać zacho­wa­nia kon­su­men­tów. Czy tych danych musi być dużo? Czy rosną­ca ilość tych danych wpły­nie na popra­wę jako­ści pro­gnoz zacho­wań? Nie sądzę, gdyż pro­gno­zy bazu­ją­ce na ana­li­zie tren­dów pole­ga­ją tyl­ko na oce­nie tego, z jakim praw­do­po­do­bień­stwem powtó­rzy się histo­ria. Jeżeli chce­my oce­nić nową kam­pa­nię, dane te – jako trend – są w zasa­dzie bez­war­to­ścio­we: nigdy nie dadzą jako efekt nicze­go nowe­go, tyl­ko coś, co już kie­dyś było.

Dlatego hur­tow­nie danych i tak zwa­ne sys­te­my [[Business Inteligence]], wszel­kie sys­te­my wspo­ma­ga­nia decy­zji, to albo ana­li­za histo­rii albo pro­gno­zo­wa­nie opar­te na mode­lach. W kwe­stii mar­ke­tin­gu lepiej jest, moim zda­niem, opra­co­wać model zja­wi­ska, a do tego nie potrzeb­ne są duże ilo­ści danych a jedy­nie mini­mal­ny [[zestaw danych repre­zen­ta­tyw­nych]] i to się nazy­wa zasa­dą eko­no­mii myśle­nia. Wielką zaś sztu­ką pro­jek­to­wa­nia hur­tow­ni danych dla sys­te­mów BI nie jest samo gro­ma­dze­nie danych a wła­śnie ich odsie­wa­nie, dla­te­go sys­te­my ana­li­tycz­ne inte­gro­wa­ne z sys­te­ma­mi CRM, te prze­ła­do­wa­ne dany­mi, bywa­ją cza­sem bar­dziej szko­dli­we niż pomocne.

10 Zasad kaizen – ale z głową

fin_tableCo jakiś czas spo­ty­kam się z czymś o nazwie 10 Zasad kaizen, któ­re wzbu­dza­ją moje zdzi­wie­nie co do ich zro­zu­mie­nia lub inten­cji albo uza­sad­nie­nia powsta­nia danej zasa­dy. Niewątpliwie to ja mogę tak­że być tym, któ­ry nic nie zro­zu­miał i to tak­że tak­że nale­ży wziąć pod uwa­gę, ale koń­cu wąt­pić zna­czy myśleć :). Dlaczego poru­szy­łem tak dość obcy mi temat? Bo czę­sto spo­ty­kam się z cyto­wa­niem tych zasad wła­śnie przy oka­zji ana­li­zy i pro­jek­to­wa­nia, taki też będzie kon­tekst poniż­szych dywa­ga­cji. Tak wiec po kolei.

1. Problemy stwarzają możliwości

To praw­da czę­ścio­wa. Osobiście jestem wro­giem uogól­nień. Jednak uogól­nie­nie ma dwa obli­cza: z jed­nej stro­ny Przedmiotem wie­dzy nie jest to, co jest indy­wi­du­al­ne, lecz to, co jest ogól­ne.” (Arystoteles) ale uogól­nie­nie wszyst­kie­mu są win­ni cykli­ści to inne uogól­nie­nie. Pierwsze pole­ga na szu­ka­niu wspól­nych cech by odsiać pozo­sta­łe przy­pad­ko­we (to nauka), dru­gie to po pro­tu wrzu­ca­nie wszyst­kie­go do jed­ne­go wor­ka a to już jest po pro­tu głupota.

Tak więc naj­pierw pyta­nie: o jaki pro­blem cho­dzi? Rozwiązanie pro­ble­mu może pole­gać na umie­jęt­nym zasto­so­wa­niu cze­goś ist­nie­ją­ce­go (trze­ba jed­nak wie­dzieć, że to ist­nie­je a nie odkry­wać Amerykę po raz kolej­ny) a (znacz­nie rza­dziej) na doko­na­niu odkry­cia. Tak zwa­ne nowe moż­li­wo­ści to nic inne­go jak inny pomysł na o samo” i war­to pamię­tać o sta­rej dobrej [[brzy­twie Ockhama]].

2. Pytaj 5 razy ?Dlaczego?? (Metoda 5 why)

To naj­śmiesz­niej­sza Metoda (śmiesz­ne jest nazy­wa­nie tego jakąś wiel­ka meto­dą). Każda ana­li­za pro­ble­mu to naj­pierw pró­ba odkry­cia przy­czyn”, tak wiec ta rada (zasa­da) to raczej wska­zów­ka dla laików w rodza­ju zanim coś zro­bisz, pomyśl”.

3. Bierz pomysły od wszystkich

Tu przy­znam, nie rozu­miem inten­cji: czy cho­dzi o obser­wa­cję i wycią­ga­nie wnio­sków, czy o pro­ste naśla­dow­nic­two, czy wręcz o zwy­kłe paso­żyt­nic­two. Niestety naj­czę­ściej spo­ty­kam się z tym ostat­nim. Bo jeśli uznać pomysł” za kon­kret­ne roz­wią­za­nie kon­kret­ne­go pro­ble­mu to czym jest to bierz od wszystkich”?

4. Myśl nad rozwiązaniami możliwymi do wdrożenia

To jest coś albo dziw­ne­go albo oczy­wi­ste­go. Jeśli ktoś pro­jek­tu­je roz­wią­za­nie nie­re­al­ne to jest złym projektantem…

5. Odrzucaj ustalony stan rzeczy

To już mnie prze­ra­sta, gdyż odrzu­ca­nie usta­lo­ne­go sta­nu rze­czy” wyma­ga albo ogrom­nej odwa­gi albo ogrom­nej wie­dzy albo jest po pro­stu kolej­ną naiw­no­ścią (żeby nie powie­dzieć zno­wu wręcz głu­po­tą) … Po dru­gie zasa­dy 4. i 5. są w tym kon­tek­ście wręcz sprzecz­ne… No chy­ba, że zasa­da ta ozna­cza odrzu­ce­nie ist­nie­ją­cych już roz­wią­zań ale wte­dy kło­ci się z zasa­dą 3.

6. Wymówki, że czegoś się nie da zrobić są zbędne

Kolejne lanie wody. Owszem Mojżesz poko­nał morze na pie­cho­tę ale czy to ma być wyznacz­nik każ­de­go kie­row­ni­ka pro­jek­tu? Wymówki, wąt­pli­wo­ści, to cechy dobre­go kie­row­ni­ka pro­jek­tu, bo to świad­czy o tym, ze rozu­mie czym jest ryzy­ko. Rozumiem, że ktoś może lubić adre­na­li­nę ale to raczej spo­sób na hob­by a nie na reali­za­cje usług dla swo­ich klien­tów. Ci ostat­nie nie muszą podzie­lać tego – adre­na­li­na – hob­by, szcze­gól­nie w odnie­sie­niu do swo­ich firm.

7. Wybieraj proste rozwiązania ? nie czekając na te idealne

Akurat z tym nale­ży się zgo­dzić ale też nie powin­no się tego sto­so­wać jako zasa­dę bez­względ­ną, gdyż nie­raz roz­wią­za­nie pro­ste po pro­tu nie roz­wią­zu­je pro­ble­mu. Jeżeli sta­je­my przed pro­ble­mem skrę­ce­nia mebli w salo­nie to pro­sty, zna­ny każ­de­mu śru­bo­kręt jest pro­stym roz­wią­za­niem ale czy naj­le­piej roz­wią­zu­je pro­blem? Wiem, że to dziw­nie brzmi, ale war­to zacząć pra­cę póź­niej by zapy­tać czy nie ma cze­goś lep­sze­go, np. elek­trycz­nej wkrę­tar­ki. Prawdą jest, że ryzy­ku­je­my roz­po­czę­cie pra­cy póź­niej (czas poświę­co­ny na szu­ka­nie cze­goś lep­sze­go), ale też praw­do­po­do­bień­stwo, że mimo to skoń­czy­my znacz­nie szyb­ciej i mniej się napra­cu­je­my war­te jest pod­ję­cia tego ryzy­ka (pró­by szu­ka­nia cze­goś lep­sze­go od śrubokręta).

8. Użyj sprytu zamiast pieniędzy

Tu pole­głem, bo czym jest tu spryt? Patrzymy do [[Słownika Języka Polskiego]]: spryt ?zdol­ność szyb­kie­go, prak­tycz­ne­go radze­nia sobie w trud­nych sytu­acjach?. Tak więc kla­sycz­na [[tau­to­lo­gia]]. Bez sen­su zupełnie.

9. Pomyłki koryguj na bieżąco

10. Ulepszenie nie ma końca

Dwie powyż­sze są tak oczy­wi­ste, że nie ma co pisać.

Tak wiec te i podob­ne zasa­dy” to w moich oczach jakieś oczy­wi­sto­ści. Jednak czy złe? Hm.… cza­sa­mi mam wra­że­nie, że wie­lu ludzi fak­tycz­nie powin­no nawet te oczy­wi­sto­ści poznać, z dru­giej jed­nak stro­ny zacho­dzi ryzy­ko, że ktoś uwie­rzy że pro­ste sto­so­wa­nie ich obli­ga­to­ryj­nie pro­wa­dzi do pro­stych suk­ce­sów a to już jest śle­pa ulicz­ka. Ludzie czę­sto szu­ka­ją zło­te­go środ­ka” na wszyst­ko, tak zwa­nej „[[srebr­nej kuli]]”. Nie pro­stych recept, gdy­by ist­nia­ły nie było by pro­ble­mów. Każdy pro­blem (wyzwa­nie) to indy­wi­du­al­ny pro­blem w uni­kal­nym śro­do­wi­sku. Jeżeli ktoś daje wia­rę w to, że ist­nie­je jakaś recep­ta na ich rozwiązywanie …