Utopia – czyli model ideału pomaga w projektach

Usługa ta sta­no­wi sobą audyt tre­ści i struk­tu­ry doku­men­tów w pro­ce­sach biz­ne­so­wych oraz opra­co­wa­nie mode­lu archi­tek­tu­ry IT w celu mapo­wa­nia doku­men­tów na apli­ka­cje, w któ­rych powsta­ją i są wyko­rzy­sty­wa­ne (inte­gra­cja). Są to wyłą­czo­ne i połą­czo­ne razem pierw­sze eta­py usług Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głów­nych celów i pro­duk­tów jest opra­co­wa­na stra­te­gia cyfry­za­cji i archi­wi­za­cji doku­men­tów w orga­ni­za­cji oraz zarzą­dza­nia ich treścią.

Ten wpis adre­su­ję przede wszyst­kim mene­dże­rom nie tyl­ko IT. Analitycy i pro­gra­mi­ści spo­koj­nie mogą go pomi­nąć, chy­ba, że …;) chcą wie­dzieć dla­cze­go powin­ny powsta­wać ide­ali­zo­wa­ne pro­jek­ty, kie­dy mogą cza­sem wyko­nać nie­ko­niecz­nie ide­al­ną imple­men­ta­cję i dla­cze­go nie nale­ży pomi­jać eta­pu pro­jek­to­wa­nia ide­ali­za­cji .

W jed­nym z ostat­nich wpi­sów w dys­ku­sji napi­sa­łem w komen­ta­rzach, że:

…jestem pury­stą for­mal­nym. Jednak nie dla­te­go, by pacy­fi­ko­wać pro­jek­ty orto­dok­sją. To efekt dwóch rze­czy: teo­ria pozna­nia jako restryk­cyj­ne pod­cho­dze­nie do seman­ty­ki, pozwa­la unik­nąć nie­jed­no­znacz­no­ści. Druga rzecz, to zde­fi­nio­wa­nie ide­ału, pozwa­la oce­nić (zmie­rzyć) odstęp­stwo kon­kret­ne­go pro­jek­tu od nie­go [od ide­ału]. To pozwa­la oce­nić ryzy­ko takie­go pro­jek­tu. Fizyka ma np. nie­ist­nie­ją­ce w natu­rze ide­al­ne waha­dło czy cia­ło dosko­na­le czar­ne , po co? By móc oce­nić błąd rze­czy­wi­stych obli­czeń. Zdaję sobie spra­wę, że to filo­zo­fia, ale taki mam cel , nie tyl­ko ana­li­zo­wać i mode­lo­wać ale w 100% rozu­mieć (Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu).

Dość czę­sto spo­ty­kam się z zarzu­tem, że to szko­dzi pro­jek­tom, że trze­ba z jed­nej stro­ny nagi­nać zasa­dy a z dru­giej, że nie ma co zaj­mo­wać się ide­al­ny­mi sys­te­ma­mi bo takich nie będzie, że ogra­ni­cze­nia pro­jek­tu, głów­nie czas i budżet, wyma­ga­ją psu­cia” bo na ide­ały nie ma czasu. 

To są nie­ste­ty, w moim mnie­ma­niu, tłu­ma­cze­nia ludzi nie potra­fią­cych tego ide­ału zro­bić czy­li nie­ma­ją­cych pomy­słu na wła­ści­we roz­wią­za­nie, czy­taj, nie potra­fią­cych pro­ble­mu rozwiązać. 

Droga na skró­ty to dro­ga nie­wie­dzy. Nie twier­dzę tu, że sens mają wyłącz­nie pro­jek­ty ide­al­ne. Twierdze, że na eta­pie ana­li­zy pro­ble­mu i pro­jek­to­wa­nia powi­nien powstać ide­ał, a dopie­ro na eta­pie ana­li­zy zakre­su pro­jek­tu i oce­ny wyko­nal­no­ści, jest miej­sce na ewen­tu­al­ne uprosz­cze­nia, bo tu są one czy­nio­ne świadomie.

Z tezą taką w lite­ra­tu­rze spo­ty­kam się bar­dzo rzad­ko, ale spo­ty­kam . Możliwe, że to bar­dzo odważ­na teza: 

więk­szość pro­jek­tów to roz­wią­zy­wa­nie nie­zro­zu­mia­ne­go problemu. 

Statystyki jed­nak zda­ją się potwier­dzać, że coś jest na rze­czy .

Na szczę­ście, nie ja jeden tak sądzę. Tu zacy­tu­ję tak­że blog pew­ne­go programisty:

cią­gle zmie­nia­ją­cy się pro­gram zwięk­sza swo­ją zło­żo­ność o ile nie pochy­li­my się nad kodem aby ją zmniej­szyć. Pisanie pro­gra­mów jest łatwe, wręcz banal­nie łatwe, jed­nak pisa­nie tak, aby dało się je dłu­go i w mia­rę tanio utrzy­my­wać jest bar­dzo trud­ne. Wynika to z dwóch zło­żo­no­ści. Jedna to zło­żo­ność same­go pro­ble­mu, dru­ga to zło­żo­ność przy­pad­ko­wa. Tą przy­pad­ko­wą two­rzy­my my sami ? pro­gra­mi­ści. Sami kom­pli­ku­je­my soft bar­dzo czę­sto zupeł­nie nie­po­trzeb­nie. Sami idąc na skró­ty gma­twa­my kod tak, że sta­je się z dnia na dzień coraz droż­szy w utrzy­ma­niu. To podra­ża­nie utrzy­ma­nia to wła­śnie dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny, jak każ­dy dług ma to do sie­bie, że im dłu­żej nie spła­ca­ny tym wię­cej będzie kosz­to­wać. (Dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt, Gorąco pole­cam cały ten cykl artykułów).

Tu autor pastwi się, i słusz­nie, na zacią­ga­niem dłu­gu, któ­ry ja postrze­gam jako dług nie tyl­ko tech­no­lo­gicz­ny. To dług nie­zro­zu­mie­nia mają­cy swój począ­tek już na eta­pie ana­li­zy: ktoś nie chciał do koń­ca zro­zu­mieć zło­żo­no­ści pro­ble­mu (patrz wytłusz­cze­nie w cyta­cie), zigno­ro­wał etap dogłęb­nej ana­li­zy pro­ble­mu i zaczął kodo­wać: zacią­gnął dług nie pono­sząc kosz­tu zro­zu­mie­nia tyl­ko zaczy­na od razu kodo­wać. Przypomnę, że pomi­ja­nie dogłęb­nej ana­li­zy i two­rze­nie kodu to imple­men­ta­cja cze­goś, cze­go wła­śnie nie chcie­li­śmy do koń­ca zro­zu­mieć. Czy to zda­nie nie brzmi strasz­nie? Co powstanie?

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­ną nawiąz­ką są wyda­wa­ne na kolej­ne mody­fi­ka­cje i popraw­ki (spła­ta dłu­gu, nie raz bar­dzo kosztowna).

O sku­tecz­nym zarzą­dza­niu, posia­da­niu wizji, napi­sa­no wie­le, nie jest to miej­sce na powie­la­nie tych prawd. Spójrzmy na poniż­szy cytat:

Społeczeństwo nie­zdol­ne do wyda­wa­nia na świat uto­pii i do poświę­ca­nia się jej zagro­żo­ne jest skle­ro­zą i ruiną. Mądrość, dla któ­rej nie ist­nie­ją żad­ne fascy­na­cje, zale­ca nam szczę­ście dane, goto­we. Wybór szczę­ścia wyobra­żo­ne­go czy­ni nas zdol­nym do zmia­ny, do wzro­stu. Emil Cioran (Business Dialog – Posłuchaj. Powiedz. Przynosimy radość owoc­nej roz­mo­wy)..

A teraz małe ćwi­cze­nie: zamień­cie pań­stwo sło­wo Społeczeństwo” na Organizacje”…

Powyższe wywo­dy, cza­sa­mi wspo­mi­nam o pro­ble­mie dłu­gu na kon­fe­ren­cjach czy na forach, natych­miast wywo­łu­ją pobud­kę zwo­len­ni­ków metod zwin­nych (co by to nie mia­ło zna­czyć). Wiem, że są podob­no róż­ne for­my zwin­no­ści, te dobre i te złe. Ale podob­no zakoń­czo­ne suk­ce­sem zwin­ne pro­jek­ty są jak Yeti: każ­dy o nich mówi a nikt nie widział. Tu zno­wu zacy­tu­ję przy­wo­ły­wa­ny już tu blog:

Modne ostat­nio pro­gra­mo­wa­nie agi­le czy też pro­gra­mo­wa­nie zwin­ne ozna­cza w dużym uprosz­cze­niu cią­głą ewo­lu­cję i cią­głe wpro­wa­dza­nie zmian, tak żeby być ela­stycz­nym na potrze­by biz­ne­su. Nie da się być agi­le budu­jąc mono­li­ty, nie da się być agi­le zacią­ga­jąc coraz to nowe dłu­gi tech­no­lo­gicz­ne. W koń­cu, nie da się być agi­le jeśli po roku czy dwóch wpro­wa­dza­nie zmian zaczy­na trwać dłu­żej i dłu­żej. Jeśli chce­my być agi­le to musi­my bar­dzo moc­no trzy­mać się zasad dobre­go pro­gra­mo­wa­nia. Musimy two­rzyć ela­stycz­ne i otwar­te kon­struk­cje zamiast mono­li­tów. SOLID w tym bar­dzo poma­ga cho­ciaż nie jest to jedy­na ?reli­gia?. Aby to zro­bić trze­ba poświę­cić odpo­wied­nią ilość cza­su i potu aby wypro­du­ko­wać dobry kawa­łek kodu. (Monolity to też dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt).

Cóż, o SOLID za nie­dłu­go napi­szę wię­cej, dziś podam jed­ną z klu­czo­wych zasad, nazwał bym ją klu­czo­wym wyma­ga­niem poza­funk­cjon­la­nym: pro­jekt ma być odpor­ny na zmia­ny i otwar­ty na roz­sze­rze­nie. Jak to osią­gnąć? jest tyl­ko jeden spo­sób: wyko­nać dobry pro­jekt. Dobry czy­li prze­my­śla­ny, z peł­nym zro­zu­mie­niem pro­ble­mu i świa­do­mym odkła­da­niem pew­nych prac.

Na zakoń­cze­nie przy­znam, że wśród moich nie­do­szłych klien­tów i pro­gra­mi­stów mam wie­lu wro­gów. To Ci, któ­rzy uwa­ża­ją, że ana­li­zy i pro­jek­to­wa­nie ide­ału (co by tu sło­wo nie mia­ło ozna­czać) na samym począt­ku są bez sen­su, bo i tak wyma­ga­nia biz­ne­su się zmie­nią, więc i pro­gram będzie się zmie­niał. Ja wte­dy pytam: zmie­niał czy roz­sze­rzał? Jeżeli wyma­ga­nia się zmie­nia­ją to raczej sygnał, że nie zosta­ły na począt­ku prze­my­śla­ne… Ale wyma­ga­niem powi­nien być cel a nie aktu­al­ne środ­ki jego osią­ga­nia! Biznes tak­że ma skłon­no­ści do zacią­ga­nia opi­sy­wa­ne­go dłu­gu… Na koniec w kwe­stii wro­gów pół żar­tem i pół serio:

Chińczycy hoł­du­ją powie­dze­niu: ?jak posie­dzisz wystar­cza­ją­co dłu­go nad brze­giem rze­ki, to zoba­czysz tru­py swo­ich wro­gów pły­ną­ce z prą­dem”. No więc sobie siedzę.

… i nie raz je oglą­dam… a sie­dzę sobie ana­li­zu­jąc i pro­jek­tu­jąc… 😉 i nie jestem tu sam…

Źródła

Niaz, M. (1999). The role of ide­ali­za­tion in scien­ce and its impli­ca­tions for scien­ce edu­ca­tion. Journal of Science Education and Technology, 8(2), 145 – 150.
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
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
Jørgensen, M., & Moløkken-Østvold, K. (2006). How lar­ge are softwa­re cost over­runs? A review of the 1994 CHAOS report. Information and Software Technology, 48(4), 297 – 301. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​5​.​0​7​.​002
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Matthews, M. R. (2004). Idealisation and Galileo’s pen­du­lum disco­ve­ries: Historical, phi­lo­so­phi­cal and peda­go­gi­cal con­si­de­ra­tions. Science & Education, 13(7 – 8), 689 – 715.

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Robert Tulicki-Sypolowski 21 lutego 2013 at 11:45

    Świetny arty­kuł! Zgadzam się w 100%. Powinniśmy dążyć do ide­ału jako punk­tu odnie­sie­nia (inna spra­wa, że trze­ba wyczuć kie­dy na tej dro­dze się zatrzy­mać). Ale ozna­cza to, że musi­my wie­dzieć czym jest ten ideał.

    Przychodzi mi na myśl taka reflek­sja: sta­raj­my się two­rzyć rze­czy pięk­ne! Piękno to prze­cież nie tyl­ko sztu­ka czy natu­ra. Piękne mogą być pra­wa fizy­ki czy mode­le mate­ma­tycz­ne. W infor­ma­ty­ce ozna­cza to dla mnie prze­my­śla­ny model, czy­tel­ną archi­tek­tu­rę, spój­ną logi­kę, dobrze zde­fi­nio­wa­ne modu­ły itd.

    A dla­cze­go powin­ni­śmy to robić? Słyszałem ostat­nio myśl, któ­ra świet­nie nada­je się na podsumowanie:

    Jeżeli coś dobrze wyglą­da to jest szan­sa, że będzie dobrze dzia­łać. Ale jak coś wyglą­da fatal­nie to na pew­no jest schrzanione.”

    Weźmy to sobie do ser­ca. Projektujmy rze­czy dobrze wyglą­da­ją­ce, bli­skie ide­ało­wi – i piękne 🙂

    • Rafał Osiecki 24 lutego 2013 at 17:19

      Dobrze powie­dzia­ne. Niestety z defi­ni­cją pięk­na jest tak jak z d**ą i szczo­tecz­ką do zębów, każ­dy ma wła­sną. Czasem naszą defi­ni­cję musi­my zbu­do­wać począw­szy od odkry­cia prawd pod­sta­wo­wych, co do któ­rych zgod­ni będą wszy­scy interesariusze. 

      Za naj­więk­szy pro­blem w dro­dze do ide­ału uwa­żam ludz­kie EGO, któ­re potra­fi przy­sło­nić zdro­wy roz­są­dek. Bywamy głu­si na argu­men­ty, sku­pia­jąc się na wła­snym subiek­tyw­nym poczu­ciu pięk­na, zamiast dążyć do odkry­cia pięk­na obiek­tyw­ne­go, co cza­sem koń­czy się taki­mi potwor­ka­mi jak Pałac Parlamentu w Bukareszcie.

  2. jacek2v 23 lutego 2013 at 11:52

    Kluczowe jest dąże­nie do ide­ału”. Nie ma ide­al­nych projektów 🙂

    • Jarek Żeliński 25 lutego 2013 at 07:51

      podob­nie jak nie ma ciał dosko­na­le czarnych.…

      i nikt nie twier­dzi że są, pro­blem w tym, że nie zna­jąc ide­ału nawet nie wie­my czy war­to się za pro­jekt brać. Kolejna rzecz nie­lu­bia­na przez wie­lu dostaw­ców nie tyl­ko IT: stu­dium wyko­ny­wal­no­ści… Bardzo wie­le zarzu­co­nych pro­jek­tów zosta­ło roz­po­czę­tych choć nie mia­ło to żad­ne­go real­ne­go uza­sad­nie­nia. Idiotyczna praw­da” w rodza­ju wszy­scy wie­dzą, że się nie da, a ten co nie wie­dział zro­bił” jest typo­wym beł­ko­tem guru samo­roz­wo­ju”…

  3. jacek2v 25 lutego 2013 at 10:05

    To nie jest kwe­stia zna­jo­mo­ści ide­ału, tyl­ko mądre­go podej­ścia do wdro­że­nia. Np. błę­dem jest zakła­da­nie, że każ­dy sys­tem infor­ma­tycz­ny uspraw­ni dzia­ła­nie przed­się­bior­stwa. Należy wyko­nać bada­nie” – nazwij­my je stu­dium wyko­nal­no­ści – któ­re zwe­ry­fi­ku­je zało­że­nia. Zgadzam się, że takie bada­nie powin­no obej­mo­wać szer­szy zakres niż sam sys­tem, ale powin­no też nie być zbyt szcze­gó­ło­we ze wzglę­du na koszty.

    W infor­ma­ty­ce wszyst­ko da się zro­bić, tyl­ko nie wszyst­ko ma sens i się opłaca 🙂

    • Jarek Żeliński 25 lutego 2013 at 10:51

      Wdrożenie sys­te­mu IT, doty­czy to jakie­go­kol­wiek narzę­dzia pra­cy, ma w zasa­dzie dwa cele: uspraw­nie­nie lub umoż­li­wie­nie robie­nia cze­goś. Co do pra­co­chłon­no­ści Studium wyko­ny­wal­no­ści: ono tak­że musi być ren­tow­ne. Dlatego naj­pierw nale­ży oce­nić co zyska­my jeże­li uspraw­ni­my lub umoż­li­wi­my robie­nia cze­goś”, potem trze­ba oce­nić ryzy­ko i usta­lić budżet na stu­dium wykonywalności.

  4. Cichy 21 czerwca 2013 at 13:15

    Jak porów­ny­wać model ide­al­ny z rze­czy­wi­stym ? Jest na to spo­sób np w Visual Paradigm ? Generowanie takie­go porów­na­nia w doku­men­ta­cji pro­jek­to­wej było by potęż­nym narzę­dziem w wykry­wa­niu ogra­ni­czeń, dłu­gu tech­no­lo­gicz­ne­go a tak­że w oce­nie ryzy­ka i kosz­tu utrzy­ma­nia projektu.

    • Jarek Żeliński 21 czerwca 2013 at 14:31

      Jeżeli podej­dzie­my do tego tak, że as-is to model rze­czy­wi­sty a to-be to ide­al­ny to jeste­śmy w domu :), pyta­nie brzmi co pod­le­ga porów­na­niu” czy­li jakie kry­te­ria oce­ny (coś jak u ludzi: porów­nać moż­na oce­ny w szko­le, wzrost, wagę,… ale coś z tego trze­ba wybrać). A poję­cie «dłu­gu tech­no­lo­gicz­ne­go” bar­dzo mi się podo­ba, tu jeże­li uznać, że stan ide­al­ny to stan robi­my to zgod­nie z zasa­da­mi” to takie porów­na­nie jest dobrym narzę­dziem do oce­ny tego długu…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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