Nie raz poja­wia­ły się tu (mój blog) odnie­sie­nia do tak zwa­ne­go ide­ału (ide­ali­za­cja ) jako wzor­ca lub szkie­le­tu. W arty­ku­le o stu­dium wyko­nal­no­ści pisałem:

Brak wie­dzy o sta­nie ide­al­nym moż­li­wym i brak mode­lu, czy­ni ana­li­zę wyko­nal­no­ści bar­dzo ryzy­kow­ną, więc prak­tycz­nie bez­war­to­ścio­wą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów o jed­nym z kile­rów” pro­jek­tów ana­li­tycz­nych: utra­ta pano­wa­nia nad szczegółowością.

Detale, detale…

Praktycznie zawsze w toku odbio­ru wyni­ków prac ana­li­tycz­nych sły­szę: ale tu nie ma wie­lu rze­czy”. I jest to praw­da, ale nie ma (zosta­ły po pro­tu pomi­nię­te) rze­czy nie­istot­nych z per­spek­ty­wy ana­li­zy i jej celu. Firmy ist­nie­ją i roz­wi­ja­ją się lata­mi, nie raz nawet kil­ka­dzie­siąt lat. W tym cza­sie obra­sta­ją” w róż­ne lokal­ne spo­so­by”, mnó­stwo warian­tów osią­ga­nia kon­kret­nych, tych samych celów, nawet tych malut­kich lokal­nych. Bywają ich set­ki. Bardzo popu­lar­nym, wśród firm dostar­cza­ją­cych opro­gra­mo­wa­nie, spo­so­bem ana­li­zo­wa­nia” jest pisa­nie tak zwa­nych user sto­ry (histo­ryj­ki użyt­kow­ni­ka). Są to, opi­sa­ne sło­wa­mi pra­cow­ni­ka ana­li­zo­wa­nej fir­my, zda­rze­nia sta­no­wią­ce pod­sta­wę zro­zu­mie­nia” jak dana orga­ni­za­cja dzia­ła. Metoda ta jest obcią­żo­na poważ­ną wadą:

User sto­ry to per­spek­ty­wa użyt­kow­ni­ka i to ska­żo­na jego ogra­ni­czo­ną wie­dzą lub jej bra­kiem oraz ogra­ni­czo­nym doświad­cze­niem lub bra­kiem doświad­cze­nia. Duże, zdo­by­te w jed­nym miej­scu, doświad­cze­nie pra­cow­ni­ka, bez głęb­szej i szer­szej ana­li­zy, też nie popra­wia sytu­acji, czę­ściej ją jesz­cze pogar­sza (bo nikt nie podej­mu­je dys­ku­sji z tym ?dużym doświad­cze­niem?). (Źródło: User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać | | Jarosław Żeliński IT-Consulting

Opisy te bywa­ją nie raz bar­dzo boga­te, zebra­ne w toku wie­lo­go­dzin­nych, tak zwa­nych, warsz­ta­tów lub ankiet. Spisywane są nie raz ogrom­ne ilo­ści deta­li, któ­re zamiast cokol­wiek wyja­śnić, zaciem­nia­ją isto­tę rzeczy.

Jajko1

Powyższe zdję­cie przed­sta­wia coś co nazwę sta­nem obec­nym”. To widok jaki zasta­je ktoś, kto spoj­rzy na daną orga­ni­za­cję teraz”. Opisanie tego co widzi­my może zająć elo­kwent­nej oso­bie nawet wie­le stron tek­stu. Czy opis ten przy­bli­ży nas choć trosz­kę do odpo­wie­dzi na pyta­nie co to jest i jak to działa”?

Celem ana­li­zy jest zro­zu­mie­nie, z czym na praw­dę mamy do czy­nie­nia. Analityk swo­ją pra­cą powi­nien dopro­wa­dzić do powsta­nia doku­men­tu (mode­li…) obra­zu­ją­cych isto­tę rze­czy”, powi­nien w koń­cu odkryć, że powyż­sze to jest to:

Jajko0

Owszem, lata roz­wo­ju bada­nej fir­my, zawsze dopro­wa­dzą do powsta­nia ogrom­nej masy deta­li towa­rzy­szą­cych celo­wi biz­ne­so­we­mu, jed­nak ten cel się nie zmie­nia (cały pro­ces powsta­wia tej pisan­ki: źr. http://​kur​sy​krok​po​kro​ku​.blog​spot​.com/​2​0​1​6​/​0​2​/​k​o​s​z​y​c​z​e​k​-​n​a​-​j​a​j​k​o​-​p​i​s​a​n​k​e​-​k​u​r​s​-​k​r​o​k​-​p​o​.​h​tml).

Jeżeli więc mamy opra­co­wać reko­men­da­cje do zmian, zapro­jek­to­wać opro­gra­mo­wa­nie, to albo zro­zu­mie­my co i po co dana fir­ma robi, czym na praw­dę jest, albo zabrnie­my w doku­men­to­wa­nie ogrom­nej licz­by deta­li, dotych­cza­so­wych spo­so­bów osią­ga­nia celów, co potra­fi zabić pro­jekt” swo­ją szcze­gó­ło­wo­ścią (i zabe­to­no­wać, nie koniecz­nie dobry, stan obecny).

Przeprowadzenie ana­li­zy ma jeden cel: zro­zu­mieć. Nie jest jej celem opi­sy­wa­nie” cze­go­kol­wiek. Niestety wie­le firm pomi­ja ana­li­zy, idzie ścież­ką opi­sze­my co robi­my i wystarczy”.

Czego się spo­dzie­wać po pro­jek­cie, gdy sły­szę: nie ma cza­su na ana­li­zę, myśmy już pod­pi­sa­li umo­wę z wyko­naw­cą bo nasza fir­ma nie ma cza­su. Niestety naj­czę­ściej taki pro­jekt trwa znacz­nie dłu­żej niż pla­no­wa­no, pie­nią­dze oszczę­dzo­ne na ?zbęd­nym? pro­jek­to­wa­niu ide­ału z ogrom­na nawiąz­ką są wyda­wa­ne na kolej­ne mody­fi­ka­cje i popraw­ki (Źródło: Utopia ? czy­li model ide­ału poma­ga w pro­jek­tach | | Jarosław Żeliński IT-Consulting)

Tak więc, doku­men­ta­cja zawie­ra­ją­ca 10 dia­gra­mów pro­ce­sów biz­ne­so­wych pra­wie zawsze będzie lep­sza od tej zawie­ra­ją­cej 100 dia­gra­mów. Ta, któ­ra nie zawie­ra żad­ne­go, jed­nak będzie znacz­nie gorsza.….

Polecam świet­ną książ­kę na ten temat, w któ­rej autor pisze we wstępie: 

Projektowanie ide­ału jest takim spo­so­bem myśle­nia o zmia­nie, któ­ry moż­na przed­sta­wić w spo­sób: w roz­wią­zy­wa­niu pro­ble­mów, prak­tycz­nie dowol­ne­go rodza­ju, moż­na uzy­skać naj­lep­sze wyni­ki dzię­ki wyobra­że­niu sobie ide­al­ne­go roz­wią­za­nia, a następ­nie cof­nię­ciu się aż do miej­sca, w któ­rym znaj­du­jesz się w chwi­li obec­nej. Dzięki temu unik­niesz uro­jo­nych przez sie­bie prze­szkód, zanim jesz­cze w ogó­le poj­miesz, jaki ma być ide­ał. .

A na koniec pole­cam referat:

Alan Kay, 2015: Power of Simplicity

Źródła

Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne. https://​repo​zy​to​rium​.kozmin​ski​.edu​.pl/​p​l​/​p​u​b​/​3​442
McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Niaz, M. (1993). If Piaget’s epi­ste­mic sub­ject is dead, shall we bury the scien­ti­fic rese­arch metho­do­lo­gy of ide­ali­za­tion? Journal of Research in Science Teaching, 30(7), 809 – 812. https://​doi​.org/​1​0​.​1​0​0​2​/​t​e​a​.​3​6​6​0​3​0​0​717
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, 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 analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. Michał

    Zgodzę się, że drą­że­nie deta­li na począt­ku ana­li­zy jest bez­ce­lo­wa i zawsze war­to wyjść od pro­ce­sów, zro­zu­mieć cele fir­my i regu­ły, któ­re w niej funk­cjo­nu­ją. Ale męczy mnie pyta­nie – co dalej? Przecież jakieś opro­gra­mo­wa­nie trze­ba jed­nak wytwo­rzyć, a na pod­sta­wie samych mode­li pro­ce­sów i reguł, nawet naj­le­piej udo­ku­men­to­wa­nych, może być ciężko.
    Czy po zamo­de­lo­wa­niu przed­się­bior­stwa pra­ca ana­li­ty­ka się koń­czy? Czy nie powi­nien brać udzia­łu we wła­ści­wej pro­duk­cji roz­wią­za­nia, w ana­li­zie jego funk­cjo­nal­no­ści? Czy wte­dy wła­śnie wspo­mnia­ne wyżej user sto­ries (mając na uwa­dze nad­rzęd­ność ana­li­zy pro­ce­sów) nie sta­ją się przydatne?

    1. Jaroslaw Zelinski

      1. Zaczynanie od pro­ce­sów biz­ne­so­wych i bazo­wa­nie na nich pozwa­la zwe­ry­fi­ko­wać popraw­ność logi­ki cało­ści i unik­nąć odkry­wa­nia wyma­gań w trak­cie wdro­że­nia, pozwa­la same­mu zama­wia­ją­ce­mu oce­nić sens tego co zama­wia. Przypominam, że mode­le pro­ce­sów zawie­ra­ją tak­że: wzo­ry doku­men­tów i regu­ły biznesowe.
      2. Oprogramowanie to: inter­fejs użyt­kow­ni­ka, for­mu­la­rze i ich zawar­tość (pola) oraz logi­ka biz­ne­so­wa (regu­ły prze­twa­rza­nia zawar­to­ści tych pól), to tego ewen­tu­al­ne inte­gra­cje (gdy jakąś logi­kę reali­zu­je inne oprogramowanie). 

      Doskonałym wręcz spo­so­bem jest podej­ście pole­ga­ją­ce na zapro­jek­to­wa­niu przez ana­li­ty­ka archi­tek­tu­ry logicz­nej opro­gra­mo­wa­nia. Metoda dobrze opi­sa­na w lite­ra­tu­rze, bazu­je na nota­cjach BPMN (pro­ce­sy) a póź­niej UML (logi­ka apli­ka­cji). Pozwala prze­te­sto­wać całą logi­kę i wychwy­cić ewen­tu­al­ne błę­dy zanim jesz­cze powsta­nie kod. 

      Moim zda­niem (i tak robię) ana­li­tyk nie może uciec” z pro­jek­tu, od momen­tu roz­po­czę­cia imple­men­ta­cji sta­je się pro­duct owne­rem” (nad­zór autor­ski i zarzą­dza­nie zmia­ną, kon­takt z biz­ne­sem i deve­lo­pe­rem). Z moje­go doświad­cze­nia user sto­ry z ust przy­szłe­go użyt­kow­ni­ka ma taką war­tość jak wyobra­że­nia blon­dyn­ki (sor­ry ;)) o nowym samo­cho­dzie. Użytkownicy nie są spe­cja­li­sta­mi z zakre­su inży­nie­rii pro­gra­mo­wa­nia a nawet z obsza­ru zarządzania…

      Patrząc na goto­we opro­gra­mo­wa­nie widać, że skła­da się ono ze skoń­czo­nej ilo­ści wpro­wa­dza­nych infor­ma­cji, gru­po­wa­nych w for­mu­la­rze. Produktem pra­cy opro­gra­mo­wa­nia są te same (archi­wum) dane lub dane nowe lub zmie­nio­ne będą­ce wyni­kiem prze­twa­rza­nia. Przetwarzanie to regu­ły biz­ne­so­we i ewen­tu­al­ne wzo­ry matematyczne.

      Złożoność tkwi w ilo­ści związ­ków mię­dzy tymi dany­mi a nie w pra­cy ludzi. Analiza pole­ga na zro­zu­mie­niu tych związ­ków i udo­ku­men­to­wa­niu ich a nie na zapi­sa­niu co robią ludzie w fir­mie (bo robią masę rze­czy na masę róż­nych spo­so­bów). Ewentualne deta­le i baje­ry” w apli­ka­cji zapro­jek­tu­je pro­jek­tant GUI (UX designer).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.