Analiza efektywności i kosztów czyli symulacja procesu

Wstęp

Produktem mode­lo­wa­nia pro­ce­sów biz­ne­so­wych są jakieś dia­gra­my, i z tym jeste­śmy oswo­je­ni. Od cza­su do cza­su moż­na usły­szeć o symu­la­cjach pro­ce­sów, lecz to już jed­nak znacz­nie rza­dziej. O symu­la­cjach pro­ce­sów pisze się mniej: Google Scholar (lite­ra­tu­ra nauko­wa) poka­zu­je ok. 5 mln publi­ka­cji na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, na temat ich symu­la­cji 2 mln mniej. Ale już Google („cały Internet”) odpo­wied­nio: 2,3 mld. i 282 mln. Jak widać w powszech­nym obie­gu symu­la­cje, jako temat, to trzy rzę­dy (tysiąc­krot­nie) mniej­sza ilość tek­stów! (wyszu­ki­wa­ne były hasła ang. «busi­ness pro­cess mode­ling» oraz «busi­ness pro­cess simu­la­tion»). Zastanówmy się dla­cze­go i co moż­na osią­gnąć symulacją.

Czytaj dalej… Analiza efek­tyw­no­ści i kosz­tów czy­li symu­la­cja pro­ce­su”

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w ??doku­men­ta­cji wyma­gań?. Jakim wyma­ga­niem jest ??zgod­ność z obo­wią­zu­ją­cym pra­wem?? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów ? a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z nich jest egze­kwo­wa­nie usta­lo­nych zasad.

Czytaj dalej… Odpowiedzialność admi­ni­stra­to­ra sys­te­mu”
Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

Modele as-is i to-be, czy warto je robić?

Z zamia­rem napi­sa­nia tego tek­stu noszę się już od kil­ku lat i za każ­dym razem mówi­łem sobie: ok, jesz­cze tyl­ko skoń­czę ten jeden pro­jekt i zoba­czy­my czy fak­tycz­nie ma to sens”. I tak od kil­ku lat. W koń­cu jed­nak uda­ło się.

Wprowadzenie

Popularność podej­ścia do mode­li pro­ce­sów biz­ne­so­wych, pole­ga­ją­ce­go na poka­za­niu róż­ni­cy”, trwa od cza­sów popu­la­ry­za­cji re-inży­nie­rii pro­ce­sów biz­ne­so­wych (lata 90-te) . Umowy na usłu­gi, zawie­ra­ją­ce w zakre­sie opra­co­wa­nie mode­lu «as-is» i «to-be» nadal są pod­pi­sy­wa­ne. Zakładam, że decy­zje o zakre­sie pro­jek­tu to indy­wi­du­al­ne potrze­by zama­wia­ją­cych. Ja opi­szę swo­je doświad­cze­nia i wnioski.

Głównym dekla­ro­wa­nym celem two­rze­nia obu tych mode­li jest zawsze porów­na­nie sta­nu obec­ne­go i pla­no­wa­ne­go, a następ­nie zde­cy­do­wa­nie o tym «co dalej». Zakłada się, że te mode­le powin­ny poka­zać war­tość doda­ną pro­jek­to­wa­nych zmian. Pierwszy pro­blem to koniecz­ność stwo­rze­nia dwu­krot­nie więk­szej ilo­ści doku­men­ta­cji, to zaś prze­kła­da sie na czas i koszt. W kon­se­kwen­cji wdro­że­nie pla­no­wa­nej zmia­ny bar­dzo odsu­wa się w cza­sie. Wynik każ­dej pier­wot­nie wyko­na­nej ana­li­zy dez­ak­tu­ali­zu­je się wraz z upły­wem cza­su, tym szyb­ciej im wię­cej szcze­gó­łów ona zawie­ra. Wpadamy tu w «kwa­dra­tu­rę koła». W arty­ku­le Cykl życia… zapy­ta­łem: Czego ocze­ku­je biz­nes: efek­tu czy pro­duk­tu? Wyniki ana­liz i reko­men­da­cje to pro­duk­ty pra­cy ana­li­ty­ka, wdro­żo­ne zmia­ny orga­ni­za­cyj­ne czy opro­gra­mo­wa­nie to tak­że pro­duk­ty. Te zawsze moż­na kupić i mieć. A czym jest efekt? Np. zwięk­sze­niem efek­tyw­no­ści… A to ozna­cza, że etap ana­li­zy i potem wdra­ża­nia roz­wią­za­nia, tak­że powi­nien cecho­wać się efektywnością!

W cza­sach zmian ryn­ko­wych zacho­dzą­cych w okre­sie poni­żej roku, każ­da stra­ta cza­su jest szko­dą, dwu­krot­ne wydłu­że­nie pro­ce­su ana­li­zy i opra­co­wa­nia reko­men­da­cji szczególnie.

Więc jak, sko­ro nie dwa mode­le: «as-is» i «to-be»?

Metody

Tu posłu­żę się pro­sty­mi meto­da­mi czy­li sche­ma­ty blo­ko­we i rzad­ko sto­so­wa­na a bar­dzo sku­tecz­na: ide­ali­za­cja . Nawiążę tak­że do mało popu­lar­nej a cie­ka­wej i bar­dzo sku­tecz­nej meto­dy­ki uspraw­nia­nia orga­ni­za­cji, tak­że opar­tej na ide­ali­za­cji, opi­sa­nej przez Ackof’a .

Rezultaty

Kluczem sku­tecz­ne­go pla­no­wa­nia roz­wo­ju orga­ni­za­cji jest stu­dium wyko­nal­no­ści pla­no­wa­nych zmian, a do tego bar­dzo przy­dat­na jest ide­ali­za­cja jako metoda.

Wytyczenie kierunku działań

Każda orga­ni­za­cja kie­dyś powsta­ła i od tego momen­tu zaczy­na żyć (co – uwa­ga – nie jest toż­sa­me z jej roz­wo­jem). Jeżeli podej­mu­je­my decy­zję o wpro­wa­dza­niu zmia­ny (a na począt­ku raczej tyl­ko dekla­ru­je­my taki zamiar) pierw­szy­mi rze­cza­mi jakie nale­ży okre­ślić są: cel i kie­ru­nek zmian. Jak już to wie­my, kolej­nym kro­kiem jest okre­śle­nie tego co i w jakim cza­sie chce­my osią­gnąć. Pamiętajmy, że ide­ał może nie być osią­gal­ny, jest jed­nak zawsze dosko­na­łym wyznacz­ni­kiem kie­run­ku (podob­nie jak rekor­dy olim­pij­skie dla spor­tow­ców, któ­rzy wie­dzą, że nigdy ich nie prze­kro­czą, ale mimo to wie­dzą co i po co tre­no­wać). Dlaczego? Bo klu­czo­wą wie­dzą jest zawsze to, ile mnie dzie­li od ide­ału i czy jest sens go osią­gać, bo roz­wią­za­nia powin­ny być wystar­cza­ją­cą dobre, a nie zawsze naj­lep­sze (co naj­wy­żej moż­li­wie najlepsze). 

Projektowanie ide­ału jest takim spo­so­bem myśle­nia o zmia­nie, któ­ry moż­na przed­sta­wić w pro­sty 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, jak osią­gnąć ideał.

Poniższy dia­gram poka­zu­je klu­czo­we punk­ty planu:

I teraz: Czy dokład­ny opis sta­nu aktu­al­ne­go jest potrzeb­ny, sko­ro klu­czo­we pyta­nie zawsze brzmi: co zmie­nić? Sprawdźmy. 

Wyobraźmy sobie, że robi­my porząd­ki w sta­rej piw­ni­cy a celem jest pozby­cie się rze­czy nie­po­trzeb­nych. Identyczną sytu­ację mamy z ple­ca­kiem, gdy dość regu­lar­nie wyjeż­dża­my np. w góry, nie chce­my jed­nak nosić zbęd­nych rze­czy. Są dwa moż­li­we podej­ścia do tego zadania:

  1. prze­glą­da­my wszyst­ko i zasta­na­wia­my się cze­go się pozbyć,
  2. odkła­da­my wszyst­ko na bok, i wybie­ra­my tyl­ko to o czym wie­my, że na pew­no nadal będzie potrzeb­ne i wie­my do cze­go, resz­ta zosta­je (z piw­ni­cy: wyrzucona). 

Można pró­bo­wać bro­nić każ­dej z tych metod, pro­blem w tym, że pierw­sza powo­du­je (prak­ty­ka to poka­zu­je), że zawsze zosta­je pra­wie wszyst­ko, a przy­by­wa nowego. 

Modelowanie organizacji

Natura czło­wie­ka to emo­cjo­nal­ne przy­wią­za­nie do tego co się już posia­da, a z natu­rą (emo­cje) trud­no wal­czyć. Dlatego war­to cza­sa­mi ją wspo­ma­gać (z tego same­go powo­du nie nale­ży same­mu nego­cjo­wać tego co jest dla nas bar­dzo waż­ne, a jak musi­my to robić sami, to nale­ży zre­zy­gno­wać z nego­cja­cji i z góry usta­lić korzyst­ne warun­ki lub zre­zy­gno­wać ).

Popatrzmy na zna­ny, nie tyl­ko moim czy­tel­ni­kom, od lat diagram:

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Pokazuje on trzy pod­sta­wo­we pozio­my opi­su (doku­men­to­wa­nia) orga­ni­za­cji. Najwyższy poziom to model biz­ne­so­wy, czy­li opis stra­te­gii (z regu­ły mie­ści się na jed­nej stro­nie maszy­no­pi­su). Najniższy to szcze­gó­ło­we opi­sy wyma­ga­nych kom­pe­ten­cji, zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry i zarzą­dze­nia, instruk­cje itp. Te dwa rodza­je opi­sów ma prak­tycz­nie każ­da orga­ni­za­cja bo nawet, jeże­li nie wyma­ga tego pra­wo, to wyma­ga­ją tego pod­sta­wy zarządzania. 

Środkowa war­stwa to coś, cze­go więk­szość orga­ni­za­cji nadal nie ma, bo uwa­ża­ją że nie jest to potrzeb­ne do bie­żą­ce­go, ope­ra­cyj­ne­go zarzą­dza­nia. Czym jest ten środ­ko­wy model? To jest tak zwa­ny wewnętrz­ny łań­cuch war­to­ści orga­ni­za­cji, czy­li opis tego jak powsta­ją jej pro­duk­ty i usłu­gi, i jaką poszcze­gól­ne pra­ce wno­szą war­tość doda­ną do cało­ści . Dokumentujemy go jako Model (mapa) Procesów Biznesowych, jest to abs­trak­cyj­ny model, pozba­wio­ny szcze­gó­łów, poka­zu­je to «co» robi­my i po co a nie «jak». Warto tu zwró­cić uwa­gę na waż­ną rzecz: 

Nie ma żad­ne­go sen­su odwzo­ro­wy­wa­nie na sche­ma­tach blo­ko­wych szcze­gó­łów trze­ciej naj­niż­szej war­stwy, bo powsta­ją mon­stru­al­ne licz­by dia­gra­mów, któ­re nicze­go nie wno­szą do pro­jek­tu, bo ich przy­dat­ność jest co naj­mniej wątpliwa.

To «jak» to robi­my zawie­ra posia­da­na już doku­men­ta­cja w war­stwie trze­ciej, naj­niż­szej; nie ma więc sen­su powtór­ne jej doku­men­to­wa­nie na dia­gra­mach, powo­łu­je­my się na nią mode­lu­jąc pro­ce­sy (wię­cej w arty­ku­le Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji).

Czy war­to mieć taki model pro­ce­sów? Owszem, bo podej­mo­wa­nie decy­zji o zmia­nach bez takie­go mode­lu to lote­ria. Jednak jeże­li model jest zbyt szcze­gó­ło­wy (patrz powyż­sza uwa­ga), to nie tyl­ko opra­co­wa­nie go jest kosz­tow­ne i trwa dłu­go, ale zapo­zna­nie się z nim zaj­mu­je zbyt dużo cza­su, więc nikt tego nie robi. W efek­cie decy­zje są podej­mo­wa­ne tak, jak by tego mode­lu nie było. Kiedyś decy­zje o zmia­nach podej­mo­wa­no rzad­ko i każ­do­ra­zo­we, poprze­dza­ją­ce te decy­zje dłu­gie ana­li­zy, mia­ły sens. Obecnie decy­zje takie podej­muj­my nie raz «znie­nac­ka”, i nawet jeże­li nie są czę­ste, to nie ma cza­su na poprze­dza­nie ich ana­li­za­mi, a bez ana­li­zy skut­ków decy­zje ope­ra­cyj­ne są lote­rią. W efek­cie utrzy­my­wa­nie aktu­al­ne­go, ale bez zbęd­nych deta­li, mode­lu orga­ni­za­cji jest moż­li­we, opła­cal­ne i ma ogrom­ne zna­cze­nie (patrz Audyt orga­ni­za­cji, model Architektury Korporacyjnej).

Poprawnie opra­co­wa­ne mode­le (mapy) pro­ce­sów biz­ne­so­wych pozwa­la­ją zro­zu­mieć orga­ni­za­cję i prze­wi­dy­wać efek­ty pla­no­wa­nych zmian. 

(patrz: Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści)

Wdrażanie zmian

Popatrzmy na poniż­szy diagram:

(J. Żeliński, 2012)

Rozwój orga­ni­za­cji, poza bar­dzo rzad­ki­mi przy­pad­ka­mi, nie jest (nie powi­nien być) rewo­lu­cją. Pisali o tym nie raz kry­ty­cy przy­wo­ły­wa­nej na począt­ku Radykalnej Reorganizacji Procesów Biznesowych (mało któ­ra orga­ni­za­cja ją prze­trwa­ła) . Więc co zmie­niać i jak? Powyższy dia­gram mówi, że gene­ral­nie zmia­ny doty­czą naj­niż­szej war­stwy, ale żeby wie­dzieć gdzie jest jej gra­ni­ca, trze­ba mieć udo­ku­men­to­wa­ną tak­że tę środ­ko­wą. Zmiany pro­ce­sów biz­ne­so­wych są rzad­kie, doty­czą poje­dyn­czych pro­ce­sów, i nie są to rewolucje.

Przejście od lewej do pra­wej stro­ny to nasz ple­cak w góry: albo prze­glą­da­my wszyst­ko i pró­bu­je­my odrzu­cać nad­miar, albo wybie­ra­my tyl­ko to, o czym wie­my że będzie potrzeb­ne. Skąd mamy wie­dzieć, co będzie potrzeb­ne? Jeżeli wyko­na­my model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści, to zna­czy, że dosko­na­le wie­my co i po co robi­my, pozo­sta­je jedy­nie okre­śle­nie tego jak. I tu wła­śnie poja­wia się moment, w któ­rym okre­śla­my jak coś zro­bić naj­le­piej, a potem patrzy­my czy to jak to teraz robi­my jest takie jak być powin­no. Jeżeli tak, kon­ty­nu­uje­my (zabie­ra­my to ze sobą w kolej­ną podróż), jeże­li nie – zarzu­ca­my i sta­je sie to wyma­ga­niem, wobec nowe­go roz­wią­za­nia (bez roz­pa­mię­ty­wa­nia histo­rii, sen­ty­men­ty nie­ste­ty znisz­czy­ły już nie­jed­ną firmę).

W pro­jek­cie ana­li­zy i uspraw­nie­nia powsta­ją więc:

  1. Dokumentacja ryn­ko­we­go mode­lu biz­ne­so­we­go, czy­li opis stra­te­gii (w tym tak­że misja i wizja organizacji).
  2. Model moty­wa­cji biz­ne­so­wej pla­no­wa­nych zmian (wyty­cza­my kierunek).
  3. Model pro­ce­sów biz­ne­so­wych jako model wewnętrz­ne­go łań­cu­cha war­to­ści (to jest kil­ka­na­ście dia­gra­mów a nie kilkaset!).
  4. Analiza prze­twa­rza­nych infor­ma­cji i jej stan­da­ry­za­cja (ana­li­za doku­men­tów, biz­ne­so­wy słow­nik pojęć, regu­ły biz­ne­so­we, stan­da­ry­za­cja tre­ści doku­men­tów, są to pro­duk­ty aktyw­no­ści na mode­lach procesów).
  5. Wymagania biz­ne­so­we (czym ma się cha­rak­te­ry­zo­wać nowe rozwiązanie).
  6. Opis (model) roz­wią­za­nia, sta­no­wią­cy sobą tak na praw­dę wyma­ga­nie dla jego dostaw­cy (wyko­naw­cy).

Jeżeli pozbę­dzie­my sie nad­mia­ro­wych, o wąt­pli­wej war­to­ści doda­nej dla tego pro­jek­tu, prac, to całość trwa od dwóch do sze­ściu mie­się­cy, zależ­nie od wiel­ko­ści orga­ni­za­cji. W dużych orga­ni­za­cjach łatwo jest podzie­lić mode­le na dzie­dzi­no­we obsza­ry, w któ­rych wdra­ża się lokal­ne samo­dziel­ne roz­wią­za­nia, wystar­czy zapla­no­wać ich inte­gra­cję. Mając model infor­ma­cyj­ny (doku­men­ty i ich wza­jem­ne zależ­no­ści) nie jest to trud­ne. Wbrew temu co mówią, dostaw­cy kom­plek­so­wych mono­li­tycz­nych sys­te­mów, nie jest żad­nym ryzy­kiem to że kil­ka dzia­łów prze­twa­rza te same dane, waż­ne jest zagwa­ran­to­wa­nie stan­da­ry­za­cji tych danych oraz ich nośni­ków czy­li doku­men­tów . Jeżeli bez pro­ble­mu mogą współ­pra­co­wać ze sobą dwie odręb­ne fir­my, to podob­nie mogą to robić wydzia­ły tej samej fir­my, tym bar­dziej że w dowol­nym momen­cie taki wydział może zostać wydzie­lo­ny jako osob­ny pod­miot, i po tej prze­mia­nie to wszyst­ko nadal dalej dzia­łać. Włączenie do wnę­trza orga­ni­za­cji innej fir­my podob­nie, nigdy nie powin­na to być rewo­lu­cja infor­ma­tycz­na i wymia­na wszystkiego. 

Podsumowanie

Praktyka poka­zu­je, że powyż­sze spraw­dza sie dosko­na­le. Rezygnacja z deta­licz­nych mode­li as-is nie przy­no­si stra­ty jako­ści pro­jek­tu, nie pod­no­si też jego ryzy­ka, a zna­ko­mi­cie skra­ca czas i tym samym obni­ża koszt tego eta­pu pra­cy (mode­lo­wa­nie pro­ce­sów). Owszem, nie raz na począt­ku sły­sza­łem od spon­so­ra pro­jek­tu: chce­my zoba­czyć te zmia­ny, chce­my widzieć róż­ni­ce”. Jednak ofer­ta wyko­na­nia takiej usłu­gi w dwóch warian­tach: zawie­ra­ją­ca model «as-is» i bez tego mode­lu (ofer­ta fixed-pri­ce bo innych niż umo­wa o dzie­ło na tym eta­pie od lat nie skła­dam: klien­ci chcą znać kosz­ty przed a nie po pro­jek­cie), od kil­ku lat w 100% przy­pad­ków koń­czy się rezy­gna­cją z doku­men­to­wa­nia deta­li i mode­li pro­ce­sów as-is”. Więcej w arty­ku­le Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści.

Uważam, że w cza­sach gdy czas to pie­niądz”, a czas ten liczy­my obec­nie w tygo­dniach a nie w latach, pro­jek­ty ana­li­tycz­ne trwa­ją­ce ponad kwar­tał (czy pół roku w bar­dzo dużej orga­ni­za­cji) są stra­tą cza­su i środków. 

Kluczowe pyta­nie na koniec: 

Kiedy powsta­ją szcze­gó­ły nowe­go roz­wią­za­nia? W toku pro­jek­to­wa­nia i wdrożenia…

…i jest to bar­dzo bez­piecz­ne i zara­zem efek­tyw­ne, bo mając archi­tek­tu­rę roz­wią­za­nia (wewnętrz­ny model łań­cu­cha war­to­ści i model archi­tek­tu­ry roz­wią­za­nia) wie­my «co» ma powstać, pozo­sta­je już tyl­ko na bie­żą­co podej­mo­wać decy­zje «jak» ma to wyglądać. 

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi?. ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Sprawując ze swo­jej stro­ny nad­zór nad dostaw­cą roz­wią­za­nia, jego nabyw­ca panu­je nad wszyst­kim. Mogę tyl­ko pod­su­mo­wać to tak: to co napi­sał Ackoff 15 lat temu i ponad 20 lat temu : podej­ście takie spraw­dza sie doskonale. 

(tak reali­zo­wa­ne były moje pro­jek­ty dla wie­lu małych firm, kil­ku insty­tu­cji publicz­nych, w tym Kancelarii Senatu i Żandarmerii Wojskowej, a tak­że dla KGHM SA)

Źródła

Cohen, H. (2006). Wynegocjuj to! (T. Misiorek, Trans.). Wydawnictwo Helion.
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
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Rittel, H. W. J., & Webber, M. M. (2014). Dylematy ogól­nej teo­rii pla­no­wa­nia. Zarządzanie publicz­ne, 1, 13.
Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy, 104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a gene­ral the­ory of plan­ning. Policy Sciences, 4(2), 155 – 169. https://​doi​.org/​1​0​.​1​0​0​7​/​B​F​0​1​4​0​5​730
Coffey, B. (2017). Unpacking the impli­ca­tions of label­ling envi­ron­men­tal issu­es as wic­ked pro­blems.’ 16.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Ackoff, R. L. (1999). From data to wis­dom. In Ackoff’s Best (pp. 170 – 172). John Wiley & Sons.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji (Ł. Ludwicki, Trans.). Polskie Wydawnictwo Ekonomiczne.
Rupper, P., & Muler, R. (1996). Process Reengineering (T. Soróbka, Trans.). ASTRUM.

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

Czytaj dalej… Analiza nie musi być przed­wdro­że­nio­wa”

Pokłosie webinarium MAP IT

15 Maja 2020 odby­ło się cie­ka­we wir­tu­al­ne spo­tka­nie (zapo­wie­dzi). Zarejestrowało sie ponad 1200 osób, ponad poło­wa tej licz­by bra­ła fak­tycz­nie udział. To ozna­cza, że mają sens zapo­wia­da­ne i poru­szo­ne tam tematy. 

O konferencji

Konferencja MAP IT ? Management, Analiza i Produkt w IT zor­ga­ni­zo­wa­na zosta­ła przez Hannę Wesołowską z ana­li­za IT. Ogromne ukło­ny dla Eleny Zhukovej, Olgi Springer z Product Vision oraz pozo­sta­łych zna­ko­mi­tych pre­le­gen­tów ? Jarka Łojewskiego z Fundacji Dobra Porażka, Michała Bartyzela oraz Michała Redy i Mateusza Kapicy z Product Vision. Ostatnim refe­ra­tem był mój refe­rat o for­ma­li­zmach w ana­li­zie i projektowaniu.

Zainteresowanie spo­tka­niem prze­szło naj­śmiel­sze ocze­ki­wa­nia. Na kon­fe­ren­cję zapi­sa­ło się ponad 1200 osób. W cią­gu dnia poja­wi­ło się 1086 uni­kal­nych użyt­kow­ni­ków. W szczy­to­wym momen­cie mie­li­śmy nie­mal 800 osób słu­cha­ją­cych na żywo.

Nad tech­nicz­ną stro­ną przy­go­to­wa­nia i prze­bie­gu wyda­rze­nia czu­wał Piotr Król ze stu­dia 306 w Gdyni. Piotr obsłu­gu­je wyda­rze­nia tej ska­li (i więk­sze) w wie­lu bran­żach, m.in. dla mar­ke­tin­gow­ców, tra­de­rów. Podkreślił, że nasze wyda­rze­nie zgro­ma­dzi­ło dużą widow­nię jak na dzia­ła­nia orga­nicz­ne (nie­wspo­ma­ga­ne płat­ny­mi rekla­ma­mi w Internecie), dostrzegł dużą, w porów­na­niu z inny­mi bran­ża­mi, fre­kwen­cję oraz zaan­ga­żo­wa­nie uczestników.

Nie było jesz­cze takie­go wyda­rze­nia łączą­ce­go tema­ty­kę zarzą­dza­nia przed­się­bior­stwem, ana­li­zy biz­ne­so­wej i zarzą­dza­nia pro­duk­tem w IT. Ogromnym suk­ce­sem było nie tyl­ko licz­ne przy­cią­gnię­cie zain­te­re­so­wa­nych. 94% uczest­ni­ków kon­fe­ren­cja bar­dzo przy­pa­dła do gustu ? 40% oso­bom podo­ba­ła się bar­dzo (5 w ska­li na 6) a 54% osób było wręcz zachwy­co­nych (6/6). Znakomite oce­ny otrzy­ma­ła tak­że każ­da z pre­lek­cji! Nie było tam sła­bej, ani nawet śred­niej pre­zen­ta­cji. Uczestnicy doce­ni­li wyso­ki poziom merytoryczny.

Kolejna edy­cja MAP IT pla­no­wa­na jest jesz­cze na 2020. Śledź komu­ni­ka­ty na ana­li­za IT.

O moim referacie

Dla mnie każ­de wystą­pie­nie publicz­ne to nauka i infor­ma­cja zwrot­na z ryn­ku. Publikuję na gorą­co wpi­sa­ne uwa­gi uczest­ni­ków, żeby sobie i Wam poka­zać, że: uwa­żam, że ma sens pra­ca moja i mi podob­nych, ma sens sku­pie­nie się głow­nie na scep­ty­kach bo poka­zu­ją, że pro­blem ist­nie­je i nale­ży go identyfikować. 

Moja pre­zen­ta­cja była: krót­ka (30 minut), nie­co cha­otycz­na, sku­pio­na na jed­nej przy­kła­do­wej doku­men­ta­cji pro­jek­tu, któ­rą uzna­ję za wręcz orto­dok­syj­nie for­mal­ną (kil­ka­na­ście stron, 50% to sche­ma­ty blo­ko­we UML). Skupiłem się na tym, że rynek odbior­ców opro­gra­mo­wa­nia wska­zu­je na źró­dło pro­ble­mu i czym jakie są ocze­ki­wa­nia ryn­ku, tak­że na jego pato­lo­gii. Okrojony czas skut­ko­wał tym, że sku­pi­łem sie nie na tre­ści tej doku­men­ta­cji, a na wska­za­niu tego tego, jakie ryzy­ka pro­jek­tu (inży­nie­ria opro­gra­mo­wa­nia) niwe­lu­je każ­da jej część. Nie był bym sobą, gdy­bym nie iro­ni­zo­wał, to pro­wo­ku­je emo­cje, a emo­cje zmu­sza­ją do nie­sza­blo­no­we­go myślenia.

Znamienne jest to, że chy­ba wszy­scy pre­le­gen­ci uży­wa­li sło­wa pro­dukt” w sto­sun­ku do opro­gra­mo­wa­nia. Byłem chy­ba jedy­nym pre­le­gen­tem pra­cu­ją­cym po stro­nie kupu­ją­ce­go. Dla mnie, jako ana­li­ty­ka i pro­jek­tan­ta, opro­gra­mo­wa­nie jest narzę­dziem, jakie naby­wa orga­ni­za­cja. Oprogramowanie jako pro­dukt, to per­spek­ty­wa dostaw­cy. To jest moim zda­niem to, co róż­ni­ło mój refe­rat od pozo­sta­łych i mam nadzie­ję, że posze­rzy­ło uczest­ni­kom spoj­rze­nie na pro­ble­my tej branży. 

Mój refe­rat miał wie­le pozy­tyw­nych komen­ta­rzy, co moty­wu­je do dal­szej pra­cy, ale były i kry­tycz­ne. Poniżej wła­śnie te uwa­gi do mojej pre­zen­ta­cji i moje wyja­śnie­nia ;), a,bo usprawiedliwienia. 

jak zwykle Pan Jarosław skupia się bardzo na UML, który chyba przez większość agile’owców jest czymś przestarzałym

UML to sfor­ma­li­zo­wa­na meto­da gra­ficz­ne­go doku­men­to­wa­nia wyni­ków ana­liz i pro­jek­tów. Od wie­lu lat UML jest roz­wi­ja­ny, powsta­ją dedy­ko­wa­ne wydaw­nic­twa na temat mode­lo­wa­nia w inży­nie­rii (SySoM), świat wska­zu­je że w bran­ży IT jest poważ­ny pro­blem (tyl­ko ok. 15% pro­jek­tów inży­nie­rii koń­czy się suk­ce­sem). Moją inten­cją jest jed­nak odkry­cie tego co jest przy­czy­ną suk­ce­sów tych 15%… Pojęcie agi­le­’ow­ca nie­ste­ty koja­rzy się z pro­jek­ta­mi reali­zo­wa­ny­mi meto­dą prób i błę­dów i bez żad­nej meto­dy… Niestety to brak metod jest prze­sta­rza­ły”…

widać, że p. Jarosław zatrzymał się na publicu i jest trochę oderwany od rzeczywistości

Nie wiem skąd teza, że for­ma­li­zmy to cecha insty­tu­cji publicz­nych. Wielokrotnie w pre­zen­ta­cji przy­wo­ły­wa­łem doświad­cze­nie z pro­jek­tów dla firm pry­wat­nych, nie mają­cych żad­nych rygo­rów narzu­ca­ją­cych for­ma­lizm… Wiem, że ludzie nie lubią­cy for­ma­li­zmów, czę­sto nie słu­cha­ją nicze­go inne­go niż zgod­ne­go ich poglą­dem.. W tej pre­zen­ta­cji celo­wo w 100% bazo­wa­łem na fak­tach… (sek­tor zwa­ny public to ok. 30% moich klientów).

stereotypy, mnóstwo utrwalonych stereotypów, m.in. programisty-klikacza i inne. 🙁

Tu poja­wia się wie­le nie­po­ro­zu­mień i nie­ste­ty mani­pu­la­cji. W pre­zen­ta­cji celo­wo poświę­ci­łem dedy­ko­wa­ny czas” na rela­cje odbior­cy opro­gra­mo­wa­nia z jego dostaw­cą. Podkreślałem rolę sepa­ra­cji pro­jek­to­wa­nia od wyko­na­nia. Podstawowym powo­dem jest kon­flikt inte­re­su pro­jek­tan­ta i wyko­naw­cy (pierw­szy mak­sy­ma­li­zu­je zakres pro­jek­tu i mini­ma­li­zu­je jego koszt, dru­gi dokład­nie odwrot­nie, bo koszt zama­wia­ją­ce­go to przy­chód dostaw­cy). Trzeba tu sobie jasno powie­dzieć: w pro­jek­cie deve­lo­per nie powi­nien być pro­jek­tan­tem. Jeżeli jakiś pro­gra­mi­sta czu­je w sobie tak­że ducha pro­jek­tan­ta, to może i dobrze, ale nie powi­nien peł­nić obu ról jed­no­cze­śnie w jed­nym i tym samym projekcie. 

Oryginale materiały pokonferencyjne od organizatora

image.png
  • Wiecej cza­su.
  • Za szyb­ko, zbyt chaotycznie
  • wydlu­zyc czas 🙂
  • -
  • Za mało czasu 🙁
  • cie­ka­we podej­ście no i dokumentacja
  • Konkretne przy­kła­dy.
  • cel­nie i dobrze, w opar­ciu o przy­kła­dy, choć tro­chę butnie 😉
  • świet­na pre­zen­ta­cja – zabaw­nie i prze­kor­nie, jak zawsze:)
  • Proszę wydłu­żyć 🙂
  • Dobra pre­zen­ta­cja, ale jak zwy­kle Pan Jarosław sku­pia się bar­dzo na UML, któ­ry chy­ba przez więk­szość agi­le­’ow­ców jest czymś przestarzałym
  • Za krót­ko i za mało. Z chę­cią uczest­ni­czył bym nawet i w tygo­dnio­wym jego wykładzie.
  • Super
  • Pan Jarek może i bez pre­zen­ta­cji – po pro­stu opo­wia­dać o doświadczeniu 😀
  • Duży kon­kret logicz­ny, jest o czym mysleć.
  • Kontrowersyjne, choć bar­dzo praw­dzi­we podej­ście do pro­jek­to­wa­nia sys­te­mu, opi­sy­wa­nia wyma­gań. Szkoda, że nie było pola do dys­ku­sji, z Panem Jarkiem pew­nie moż­na było­by godzi­na­mi dyskutować.
  • kon­kret­nie, z przy­kła­dem i na temat
  • Wydłużyć czas prezentacji
  • całość wystą­pie­nia świetna
  • Jarka się lubi albo nie­na­wi­dzi 🙂 SUPER
  • widać, że p. Jarosław zatrzy­mał się na publi­cu i jest tro­chę ode­rwa­ny od rzeczywistości
  • Mnóstwo mię­sa” i nie owi­ja­nia w bawełnę.
  • Łał. To to na co się cze­ka­ło. Wielkie Podziękowania. Prosimy częściej.
  • Na plus – pre­zen­ta­cja cie­ka­wie popro­wa­dzo­na. UML nie umarł 🙂
  • krót­ko zwie­zle i na temat z praw­dzi­wym przykladem
  • Prezentacja faj­na Szkoda, że po tej pre­zen­ta­cji nie mógł się wypo­wie­dzieć ktoś ze świa­ta zwin­ne­go by zro­bić taką małą kontrę. Albo może nawet taki ring” gdzie mogły by się zetrzeć ze sobą 2 oso­by z tra­dy­cyj­ne­go i zwin­ne­go spo­so­bu wytwa­rza­nia oprogramowania 😉
  • Totalnie inne podej­ście do pro­ble­mu. Inny świat. Lepiej jest poka­zać licz­by niż o nich opo­wia­dać. Po za tym super.
  • Dla mnie nie­co za trud­ne słow­nic­two i za szyb­ko, bo nie zaj­mu­ję się ana­li­zą biz­ne­so­wą, a w IT pra­cu­ję od nie­daw­na. Lubię takie kon­tro­wer­syj­ne i pro­wo­ka­tyw­ne podej­ście, skła­nia­ją­ce do samo­dziel­ne­go myśle­nia, a nie śle­pe­go podą­ża­nia za trendami.
  • Było dokład­nie tak, jak się spo­dzie­wa­łem i jak mia­łem nadzie­ję, że będzie 🙂
  • Plus za kon­kret­ną pre­zen­ta­cję z kon­kret­nym przykładem.
  • ten sar­kazm prze­szka­dza w odbio­rze fak­tów, nie mogłam się sku­pić na treści
  • wię­cej takich wystą­pień i dłuż­sze proszę 🙂
  • Merytorycznie nic do zarzu­ce­nia. Za szyb­ko, z pew­nych ele­men­tów moż­na było zre­zy­gno­wać. Pytanie jaki był cel? Jeśli prze­ko­nać nie­prze­ko­na­nych, to pew­nie się nie udało.
  • Dla mnie może nie­co zbyt aka­de­mic­kie” wystą­pie­nie. Ale znów brak mery­to­rycz­nych uwag. Za sła­ba jestem w te klocki.
  • podo­ba­ło mi się wyja­śnia­nie i tłu­ma­cze­nie wszyst­kie­go po chłop­sku”, tro­chę takiej cię­tej, acz­kol­wiek dow­cip­nej iro­nii któ­ra spra­wia że trze­ba pomy­śleć nad sobą
  • Prezentacja byłą ist­ną wisien­ką na tor­cie pod kątem tema­ty­ki i podej­ścia do spo­so­bu wyko­ny­wa­nia ana­li­zy i two­rze­nia doku­men­ta­cji. Oczywiście ogrom­ny nie­do­syt i przy­dał­by się cały dzień z Panem Jarkiem aby wła­ści­wie poukła­dać sobie w gło­wie wszyst­ko tak jak trze­ba i prze­stać mar­no­wać czas na zbęd­ne dzia­ła­nia i opi­sy w dokumentacji
  • Klasa… Super mery­to­ry­ka, ener­gia, przy­kła­dy, kon­kre­ty, bez­po­śred­niość, no rewe­la­cja. Dużo cie­ka­wiej się mi Pana Jarka słu­cha niż czy­ta 😛 Pozdrawiam Was wszyst­kich ser­decz­nie! Te wszyst­kie powyż­sze uwa­gi to już cze­pial­stwo, bo było serio cudow­nie ^^ DZIĘKUJE!!
  • Dużo przy­dat­nych wnio­sków z doświad­cze­nia, jed­nak nie podo­ba­ła mi się roz­wią­złość pre­lek­cji i zbyt wie­le (choć cie­ka­wych) dygresji
  • To jest hit, jak będę duży chciał­bym być Jarkiem. Konkret zarów­no jeśli cho­dzi o narzę­dzia, jak i podej­ście do produktu.
  • Za mało cza­su dla Jarka – ale pre­zen­ta­cja była na praw­dę świetna…
  • Powinno być wię­cej cza­su zare­zer­wo­wa­ne na taki wykład. Był bar­dzo cie­ka­wy i szko­da, że musiał zostać skró­co­ny. Chętnie wysłu­cha­ła­bym tej pre­zen­ta­cji z więk­szy­mi szczegółami.
  • Trochę za szyb­ko, ale pod­kre­śle­nie waż­nych punk­tów doku­men­ta­cji ana­li­tycz­nej. Podpowiedź zwią­za­na z narzę­dziem do dokumentacji.
  • Tak na prze­kór wszyst­kim, faj­nie pomy­śla­na – bra­kło tro­chę… slajdów!
  • W pre­zen­ta­cji było kil­ka cie­ka­wych momen­tów oraz spo­ro wie­dzy ana­li­tycz­nej, nie­ste­ty nie odpo­wia­da­ła mi for­ma. Pan Jarek za szyb­ko mówił, bar­dzo cha­otycz­nie przez co bar­dzo szyb­ko moż­na było zgu­bić wątek.
  • Trzeźwe spoj­rze­nie na pro­ces wytwór­czy oprogramowania.
  • Za mało cza­su – ta pre­zen­ta­cja powin­na trwać zde­cy­do­wa­nie dłużej
  • n/d
  • Za mało cza­su i za szyb­ko, lepiej było­by godzi­nę – bo bar­dzo cie­ka­we i świet­nie opowiedziane
  • Nie widzia­łam, bar­dzo żałuję!
  • No cóż. Klasa.
  • Po pro­stu WOW. Nic dodac nic ująć 🙂
  • + przy­kła­dy z życia – za mało cza­su na dokład­niej­sze omówienie
  • Zwięzłe i na temat. Lubie bez­po­śred­niość i szcze­rość. W tej pre­zen­ta­cji to bylo. Bardzo na plus
  • Idealne zakoń­cze­nie cie­ka­wej kon­fe­ren­cji, oby takich więcej
  • Fajnie jak­by Jarek zapo­znał odbior­ców z pla­nem wystąpienia.
  • Przydatne informacje,wiedza praktyczna
  • Widać że pro­wa­dzą­cy poświę­cił zde­cy­do­wa­nie mniej cza­su na przy­go­to­wa­nie się, niż inni (do cze­go z resz­tą sam się przy­znał). Dużo śmiesz­nych uwag i być może cen­nych aneg­dot, ale prze­ka­za­nych w spo­sób chaotyczny.
  • Duża wiedz, ale tro­chę bra­ko­wa­ło wpro­wa­dze­nia, przez pierw­szą część nie do koń­ca było wia­do­mo, co pre­lek­cja chce poka­zać, tro­chę chaotyczna.
  • Merytorycznie 6, sam kon­kret i prak­tycz­na wie­dza. Nie tra­fia jed­nak do mnie kom­plet­nie całe show” wokół i robie­nie z sie­bie na siłę kogoś nie­chcia­ne­go w śro­do­wi­sku. Średnia wycho­dzi 3,5, ale jed­nak mery­to­ry­ka jest waż­niej­sza, więc 4 🙂
  • Widziałem 3 min, bez audio, old scho­ol ana­li­za w czy­stej postaci 😉
  • Ten Pan mógł­by opo­wia­dać 3h a nie 30 min i też by się dobrze słuchało.
  • Poglądy Jarka pozo­sta­ją w asy­me­trii do wcze­śniej­szych pre­zen­ta­cji, ale jego cha­ry­zma i zaan­ga­żo­wa­nie robi wra­że­nie, a przed­sta­wio­ne przy­kła­dy z pro­jek­tów dają do myślenia.
  • Temat spo­ko, ale dla mnie for­ma tro­chę jed­nak nie dosto­so­wa­na do ilo­ści cza­su. Poczucie humo­ru nie moje ale wie­dzę doceniam:)
  • Podobało się wszyst­ko. Szkoda że tak krót­ko I pro­wa­dzą­cy się moc­no spieszyl
  • Brak
  • Niestety nie moglam byc do konca
  • Było super
  • Stereotypy, mnó­stwo utrwa­lo­nych ste­reo­ty­pów, m.in. pro­gra­mi­sty-kli­ka­cza i inne. 🙁
  • Podobało mi się prak­tycz­ne podej­ście, wie­dza i przy­go­to­wa­nie pro­wa­dzą­ce­go. Zdecydowanie za mało czasu.
  • Ogromna wie­dza, tyl­ko za dużo nie­czy­tel­nej gra­fi­ki w prezentacji
  • nie oglą­da­łem
  • Super że dosta­je­my punkt widze­nia zupeł­nie prze­ciw­ny do całej resz­ty pre­le­gen­tów 🙂 Nie do koń­ca się zga­dzam (ale też nie do koń­ca się zga­dzam z Michałem R.), ale świet­nie jest takiej wizji posłuchać.
  • Jarek jest mistrzem sam w sobie. Ma ogrom wie­dzy prak­tycz­nej, więc moż­na by słu­chać go godzi­na­mi… w kon­tek­ście 30 minu­to­we­go wykła­du, któ­ry powi­nien poka­zać jak wyma­ga­nia biz­ne­so­we archi­tek­tu­ra i logi­ka apli­ka­cji, cięż­ko powie­dzieć że to się uda­ło. Prezentacja nie pozwa­la­ła na prze­pro­wa­dze­nie słu­cha­ją­cych przez ten pro­ces, bo nie było jed­ne­go przy­kła­du. Jarek mówiąc szu­kał w pre­zen­ta­cji odpo­wied­nich slaj­dów i szyb­ko je oma­wiał, co pro­wa­dza­ło cha­os. Pokazany dia­gram sekwen­cji był na ekra­nie 3 sekun­dy, więc nawet nie zdą­ży­łam zoba­czyć co zawie­ra. Na taką kon­fe­ren­cję, zde­cy­do­wa­nie lep­szym pomy­słem był­by pro­sty przy­kład i kil­ka slaj­dów, któ­re prze­pro­wa­dzą przez ten proces.
  • REWELACJA 🙂
  • Konkretna, prak­tycz­na pre­zen­ta­cja, uświa­da­mia­ją­ca ana­li­ty­ko­wi-odbior­cy, jakich dotych­czas popeł­nia­nych w pra­cy błę­dów nale­ży unikać.
  • za dużo tema­tów Jarek chciał poru­szyć. Powinien się sku­pić albo na swo­jej filo­zo­fi pro­wa­dze­nia pro­jek­tów, albo na dokumentacji