Tak zwane projekty internetowe

Dość czę­sto spo­ty­kam się z opi­nia­mi, że teraz opro­gra­mo­wa­nie pisze się zwin­nie bo jest to pro­ces twór­czy i nie­pla­no­wal­ny”, jedy­nym spo­so­bem są pro­to­ty­py, klient nie wie cze­go chce, pra­cu­je­my meto­dą pro­gra­mo­wa­nia eks­tre­mal­ne­go”, bo tyl­ko tak klient może szyb­ko zoba­czyć efek­ty i odkryć swo­je wyma­ga­nia. I dalej jesz­cze potok podob­nych argu­men­tów. Niestety pro­jek­ty te, doty­czą­ce pro­ce­sów biz­ne­so­wych, a nie tyl­ko roz­bu­do­wa­nych wizy­tó­wek firm czy całych sys­te­mów por­ta­lo­wych, czę­sto koń­czą się fia­skiem (znacz­nie prze­kro­czo­ne ter­mi­ny i budże­ty, a nie raz pozwy do sądu). Dzisiaj kil­ka słów wła­śnie na temat tak zwa­nych pro­jek­tów internetowych”.

Cztery lata temu (Dziwne pro­jek­ty …) komen­to­wa­łem pewien dziw­ny pro­jekt. W arty­ku­le tym napi­sa­łem mię­dzy innymi:

Szukając powo­dów takie­go sta­nu rze­czy [pro­ble­my z tymi wdro­że­nia­mi] odkry­łem cie­ka­wą rzecz: szu­ka­jąc w Internecie haseł pozwa­la­ją­cych odna­leźć fir­my wyko­nu­ją­ce stro­ny WWW dla firm gene­ral­nie poja­wia­ją się fir­my spe­cja­li­zu­ją­ce się w por­ta­lach i ser­wi­sach spo­łecz­no­ścio­wych. Nawet jeże­li mają na swo­jej liście refe­ren­cyj­nej duże fir­my czy insty­tu­cje publicz­ne to stro­ny te mają czę­sto wła­śnie wady opi­sa­ne w tym artykule.

Jak temu zara­dzić? Wydaje mi się, że pod­sta­wo­wym błę­dem jest anga­żo­wa­nie do tych [biz­ne­so­we opro­gra­mo­wa­nie] pro­jek­tów wła­śnie firm spe­cja­li­zu­ją­cych się w komu­ni­ka­cji inter­ne­to­wej a nie w two­rze­niu apli­ka­cji biz­ne­so­wych. Jeżeli fir­mie spe­cja­li­zu­ją­cej się two­rze­niu wizy­tó­wek inter­ne­to­wych i por­ta­li pro­mo­cyj­nych czy wize­run­ko­wych, zle­ci­my wyko­na­nie ser­wi­su, któ­re­go celem jest samo­ob­słu­ga zaku­pów, rekla­ma­cji czy skła­da­nia wnio­sków, to ser­wis ten będzie praw­do­po­dob­nie wyglą­dał jak Nasza Klasa albo YouTube (albo inne cudo Web 2.0 a ja do dziś nie wiem co to jest i nikt nie potra­fi mi wytłumaczyć).

Na czym polega ów problem? 

Otóż fak­tycz­nie na ryn­ku mamy wie­le firm, któ­re mają ogrom­ne doświad­cze­nie w two­rze­niu, nawet bar­dzo roz­bu­do­wa­nych, stron i por­ta­li WW. Bardzo doświad­cze­ni pro­gra­mi­ści, gra­fi­cy, spe­cja­li­ści od wygod­ne­go poru­sza­nia się po stro­nie”, dosko­na­le radzą­cy sobie z szyb­kim pisa­niem pro­to­ty­pów w języ­kach skryp­to­wych typu PHP, Ruby itp. Mają bar­dzo duże osią­gnię­cia w tej dzie­dzi­nie i wie­le refe­ren­cji. To fak­tycz­nie pro­jek­ty wręcz ska­za­ne na sto­so­wa­nie zwin­nych i eks­tre­mal­nych meto­dy pracy.

Dlaczego te fir­my bar­dzo czę­sto roz­kła­da­ją się na tak zwa­nych pro­jek­tach biz­ne­so­wych? Moim zda­niem klu­czo­wym powo­dem są pró­by sto­so­wa­nia metod pra­cy i doświad­czeń wynie­sio­nych z pro­jek­tów por­ta­lo­wych na pro­jek­ty biz­ne­so­we. W pro­jek­tach por­ta­lo­wych ok. 90% logi­ki sta­no­wi widok i poru­sza­nie się po stro­nie WWW. W pro­jek­tach biz­ne­so­wych jest raczej odwrot­nie, ekra­ny to może 10% zło­żo­no­ści, resz­ta to wewnętrz­na logi­ka biz­ne­so­wa, regu­ły biz­ne­so­we, zło­żo­ne zależ­no­ści mię­dzy obiek­ta­mi biz­ne­so­wy­mi (ot choć­by pomię­dzy fak­tu­rą, zamó­wie­niem, rekla­ma­cją, cen­ni­kiem, sys­te­mem upu­stów i kre­dy­tów kupiec­kich czy­li ter­mi­nów płat­no­ści). Portale inter­ne­to­we to zło­żo­ne struk­tu­ry stron WWW i rela­tyw­nie bar­dzo pro­ste reje­stry (kont użyt­kow­ni­ków, pod­stron itp.) i rapor­ty (w zasa­dzie głów­nie fil­try). Firmy te bar­dzo czę­sto igno­ru­ją stan­dar­do­we wzor­ce pro­jek­to­we, choć­by te zale­ca­ją­ce cał­ko­wi­tą sepa­ra­cję logi­ki biz­ne­so­wej od obsłu­gi ekra­nów (i paku­ją część tej logi­ki w for­mu­la­rze ekra­no­we co dość szyb­ko źle się kończy).

To ma być przez WWW więc zlećmy to firmie od WWW”

Co się sta­nie, gdy fir­ma, np. tak zwa­na agen­cja inte­rak­tyw­na, mają­ca wie­lo­let­nie doświad­cze­nie w two­rze­niu nawet bar­dzo wyra­fi­no­wa­nych por­ta­li inter­ne­to­wych, dosta­nie zle­ce­nie np. na tak zwa­ny sys­tem biznesowy? 

Zastosuje swo­je zwin­ne meto­dy pra­cy, czy­li całą logi­kę biz­ne­so­wą wpa­ku­je (tak pla­nu­je zro­bić, bo cze­mu nie, do tej pory tak było) w por­tal, zacznie od two­rze­nia for­mu­la­rzy ekra­no­wych, wytwo­rzy kil­ka reje­strów (pro­stych tablic danych) i szyb­ko poka­że klien­to­wi dzia­ła­ją­cy pro­to­typ”, któ­re­go cała logi­ka, obej­mu­ją­ca nie­ste­ty tyl­ko prze­pły­wy ekra­nów i zawar­to­ści reje­strów, jest zako­do­wa­na w tych for­mat­kach ekra­no­wych. W lite­ra­tu­rze przed­mio­tu moż­na spo­tkać nawę tej czę­ści: cynicz­ny quick win”. 

Co się dzie­je dalej? Dalej klient po kolei zgła­sza kolej­ne wyma­ga­nia (bo pra­cu­je­my szyb­ko, zwin­nie i eks­tre­mal­nie) takie jak np. klien­ci mają indy­wi­du­al­ne ceny wg. sys­te­mu upu­stów”, klien­ci mają dedy­ko­wa­ne ter­mi­ny płat­no­ści na bazie sys­te­mu reguł wyni­ka­ją­ce­go z ich dotych­cza­so­wych obro­tów”, rekla­ma­cje są przyj­mo­wa­ne na bazie ter­mi­nów gwa­ran­cji, któ­re są róż­ne, zależ­nie od typu pro­duk­tu” itd. System por­ta­lo­wy zaczy­na być od środ­ka roz­sa­dza­ny rosną­ca ilo­ścią logi­ki biz­ne­so­wej przy­pi­na­nej” w przy­pad­ko­we, wyni­ka­ją­ce tyl­ko z bie­żą­ce­go kon­tek­stu (bo nie ma archi­tek­tu­ry ani logi­ki cało­ści sys­te­mu), miej­sca baz danych i ekra­nów. W efek­cie każ­de kolej­ne życze­nie zama­wia­ją­ce­go, owo­cu­je kolej­ny­mi, coraz kosz­tow­niej­szy­mi, roz­li­cza­ny­mi czas i mate­riał” eta­pa­mi, dość szyb­ko docho­dzi do momen­tu, gdy klu­czo­wym ogra­ni­cze­niem roz­wo­ju sys­te­mu jest sam roz­wi­ja­ny sys­tem. Pojawiają się coraz czę­ściej odpo­wie­dzi pro­gra­mi­stów: tego się tak nie da zro­bić”. Załatwienie bar­dziej zło­żo­nej spra­wy na stro­nie WWW taje się trud­ne bo odby­wa się po pro­stych tabe­lach, czy­li po pro­stych reje­strach”. Ktoś z Państwa odnaj­du­je się w tym scenariuszu?

Jak można to robić?

Popatrzmy na poniż­szy diagram:

Model pracy ze stroną WWW

System, któ­re­go celem jest pro­wa­dze­nie biz­ne­su” przez inter­net (nazy­wa­ne B2B, B2C, itp.) to połą­cze­nie dwóch zupeł­nie róż­nych obsza­rów: pierw­szy to stro­na por­ta­lo­wa”, któ­rej celem jest wywo­ła­nie zain­te­re­so­wa­nia, atrak­cyj­ne prze­ka­za­nie infor­ma­cji o fir­mie, zachę­ta do sko­rzy­sta­nia z ofer­ty, rekla­ma itp. To ten obszar dzia­łań, któ­ry w tra­dy­cyj­nym kon­tak­cie z klien­tem reali­zu­je sprze­daw­ca. Kolejny krok, to obsłu­ga typo­wo biz­ne­so­wych zda­rzeń, takich jak przy­ję­cie zamó­wie­nia czy wcze­śniej­sze przy­go­to­wa­nie ofer­ty, to zło­żo­na logi­ka biznesowa.

Projektując inter­ne­to­wy sys­tem obsłu­gi klien­ta tak na praw­dę roz­wią­zu­je­my dwa zupeł­nie odręb­ne pro­ble­my: musi­my zastą­pić sprze­daw­cę naszą nową stro­ną WWW oraz obsłu­żyć zda­rze­nia, któ­re wyge­ne­ru­je nasz (tu wir­tu­al­ny) sprzedawca.

Mamy tu dwa odręb­ne pro­jek­ty: opra­co­wa­nie por­ta­lu, i to jest robo­ta dla agen­cji inte­rak­tyw­nej. Drugi, to zapro­jek­to­wa­nie, wytwo­rze­nie (albo opi­sa­nie wyma­gań i zakup goto­we­go na ryn­ku) i zin­te­gro­wa­nie z por­ta­lem, czy­sto biz­ne­so­we­go, zło­żo­ne­go, opro­gra­mo­wa­nia wypcha­ne­go” trud­ną i zło­żo­ną logi­ka biznesową. 

Dlatego takie pro­jek­ty nale­ży dzie­lić na kom­po­nen­ty, na (pod)projekty, z któ­rych każ­dy moż­na (i ma to sens) reali­zo­wać odręb­ny­mi meto­da­mi pra­cy. Pierwszy (por­tal) zwin­nie”, dru­gi – logi­kę biz­ne­so­wą – pla­nu­jąc i pro­jek­tu­jąc. Architektura bazu­ją­ca na wzor­cach mogła by by wyglą­dać tak:

Model struktury portalowego oprogramowania

Użytkownik pra­cu­je z kom­po­nen­tem, odpo­wie­dzial­nym za wszel­ką spe­cy­fi­kę śro­do­wi­ska, w któ­rym pra­cu­je (pra­cow­nik i kom­pu­ter PC w fir­mie, klient przez por­tal WWW, klient przez smart­fo­na). Uznając zasa­dę her­me­ty­za­cji, logi­ka biz­ne­so­wa jest wyłącz­nie w jed­nym kom­po­nen­cie, nie ma jej w kom­po­nen­cie obsłu­gu­ją­cym GUI (nawet, jeże­li jest to roz­bu­do­wa­ny por­tal WWW obło­żo­ny ele­men­ta­mi reklam, logi­ki ofer­to­wej czy atrak­cyj­nej gra­fi­ki pre­zen­ta­cyj­nej). Portal WWW to może być roz­bu­do­wa­ny CMS (Content Management System np. taki jak word­press). Mam nadzie­ję, że widać zło” jakie wyrzą­dzi umiesz­cze­nie jakiej­kol­wiek logi­ki biz­ne­so­wej w kom­po­nen­tach bez­po­śred­nio dostęp­nych dla użyt­kow­ni­ka: logi­ka będzie powie­lo­na z róż­ny­mi ogra­ni­cze­nia­mi w wie­lu miej­scach. Zarządzanie jej zmia­ną będzie koszmarem.

Niewątpliwą zale­tą takiej archi­tek­tu­ry jest peł­na swo­bo­da w kolej­no­ści wdra­ża­nia poszcze­gól­nych grup użyt­kow­ni­ków roż­nych śro­do­wisk oraz cał­ko­wi­ta nie­za­leż­ność wszyst­kich tych kom­po­nen­tów, czy­li zmia­ny w jed­nym nie będą się pro­pa­go­wa­ły na pozo­sta­łe. Tezy jako­by umiesz­cza­nie czę­ści logi­ki biz­ne­so­wej w kom­po­nen­tach odpo­wie­dzial­nych za obsłu­gę użyt­kow­ni­ka na stro­nie nisz­czą powyż­sze zale­ty i pro­wa­dzą do sytu­acji, w któ­rej każ­da zmia­na zawsze wyma­ga prze­glą­du i testo­wa­nia całe­go systemu.

Inne artykuły na podobny temat

Komentarze

  1. jacek2v 16 listopada 2013 at 12:13

    Czuję się w obo­wiąz­ku zapro­te­sto­wać prze­ciw­ko insy­nu­acjom jako­by pro­ces zwin­ne­go budo­wa­nia apli­ka­cji z defi­ni­cji nie jest pla­no­wa­ny 🙂 Otóż z zało­że­nia jest i powi­nien być planowany.
    Chciałbym też zwró­cić uwa­gę, że wspo­mnie­nie tu pro­gra­mo­wa­nia eks­tre­mal­ne­go odby­ło się chy­ba przez pomył­kę, albo miał Pan na myśli coś inne­go niż to: http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​E​x​t​r​e​m​e​_​p​r​o​g​r​a​m​m​ing.
    Nie wywa­ża się otwar­tych drzwi – jeśli wyma­ga­nia są okre­ślo­ne i nie­zmien­ne to po co sto­so­wać meto­dy­ki do zmien­nych i nie­okre­ślo­nych wymagań? 🙂

    • Jaroslaw Zelinski 16 listopada 2013 at 12:24

      Mowa o pla­no­wa­niu – agile/scrum – w sen­sie kto i czym się jutro zaj­mie”, czy pla­no­wa­niu pole­ga­ją­cym na okre­śle­niu co i po co ma powstać, zanim powstanie? 

      Ja tyl­ko opi­su­ję to, co spo­ty­kam w prak­ty­ce :), co do nazw (brak pla­nu, pro­gra­mo­wa­nie eks­tre­mal­ne) to ja tyl­ko cytu­je to, co sły­szę na pre­zen­ta­cjach tych firm… nie jestem spe­cja­li­stą od spor­tów eks­tre­mal­nych. Po dru­gie nie ma poję­cia zmien­ne wyma­ga­nia”. Jeżeli wyma­ga­nia” to cechy decy­du­ją­ce o przy­dat­no­ści cze­goś”, to zmien­ne mogą być co naj­wy­żej cele pro­jek­tu, jed­nak cele sen­sow­nie zarzą­dza­nych pro­jek­tów nie zmie­nia­ją się w trak­cie trwa­nia pro­jek­tów. Magiczne i mitycz­ne zmien­ne wyma­ga­nia” to raczej wyraz bez­sil­no­ści firm rzu­ca­ją­cych się na pro­gra­mo­wa­nie bez zro­zu­mie­nia biz­ne­so­we­go celu pro­jek­tu i bez planu.

      Proszę się więc odnieść do sce­na­riu­sza opi­sa­ne­go w czę­ści Zlećmy to fir­mie od WWW”…

  2. jacek2v 16 listopada 2013 at 12:55

    Mam na myśli co”->„jak”->„kiedy”->„kiedy”, czy­li całym pro­ce­sie. Bez okre­śle­nia celu” („co”) bar­dzo trud­no jest koń­czyć projekty :).
    Co do po co” to już róż­nie z tym bywa. Jak klient bar­dziej świa­do­my to obej­dzie się bez głęb­szej ana­li­zy, a jak nie to ana­li­za jest niezbędna.
    Będę się upie­rał :), poję­cie zmien­ne wyma­ga­nia” ist­nie­je i jest star­sze niż infor­ma­ty­ka. Jako dowód przed­sta­wię ist­nie­nie poję­cia zarzą­dza­nie zmianą” 🙂
    Faktem jest, że ter­min zmien­ne wyma­ga­nia” jest uży­wa­ny jako zasło­na dym­na”, gdy poja­wia się nie­chęć (brak kom­pe­ten­cji) do prze­pro­wa­dze­nia ana­li­zy lub planowania.

    Co do przy­kła­du z Zlećmy to fir­mie od http://WWW...”
    Dla mnie to oczy­wi­sta oczy­wi­stość, że nale­ży to podzie­lić na modu­ły (2, 3 … wię­cej?), a może i apli­ka­cje. Ponieważ: tak jest łatwiej, bar­dziej upo­rząd­ko­wa­nie, bez­piecz­niej, moż­na tym lepiej zarzą­dzać, .… itd. Co do róż­nych metod pra­cy to moim zda­niem nie ma to zna­cze­nia. Z opi­sa­ne­go przy­kła­du wyni­ka, że ta fir­ma po pro­stu nie ma kom­pe­ten­cji w opro­gra­mo­wa­niu biz­ne­so­wym. Klient błęd­nie zało­żył, że medium (WWW) defi­niu­je wykonawcę.
    Zwinność meto­dy­ki pole­ga na dosto­so­wy­wa­niu się do potrzeb klien­ta i projektu.
    Pamiętać też trze­ba , że każ­da meto­dy­ka jest dla LUDZI, a nie zespół dla meto­dy­ki. Czyli nie­któ­rzy będą dobrze się czu­li pra­cu­jąc w meto­dy­kach zwin­nych, a inni w water­fall (lub innych).

    • Jaroslaw Zelinski 16 listopada 2013 at 21:32

      Jeden komen­tarz: nie ist­nie­je poję­cie klient świa­do­my” bo klient nie jest deve­lo­pe­rem. Zaś my wie­my, że dla mnie to oczy­wi­sta oczy­wi­stość, że nale­ży to podzie­lić na modu­ły (2, 3 ? wię­cej?), a może i apli­ka­cje. co naj­waż­niej­sze :)” ale nie­ste­ty nie dla każ­de­go jest to taka oczy­wi­sta oczy­wi­stość”. Ale z tym, ze Zwinność meto­dy­ki pole­ga na dosto­so­wy­wa­niu się do potrzeb klien­ta i pro­jek­tu.” do mnie nie prze­ma­wia chy­ba, że jeste­śmy leka­rzem, któ­ry pozwa­la sobie by pacjent dyk­to­wał leka­rzo­wi recep­tę… i nie widzę tu żad­ne­go związ­ku z samo­po­czu­ciem ;). Powtórzę się: meto­dy­ka (w szcze­gó­łach) nie ma żad­ne­go zna­cze­nia, tu się zga­dzam, fak­tycz­nie waż­ne by się wybra­nej meto­dzie pra­cy dobrze czuć ale są pew­ne zasa­dy, któ­rych łama­nie to szu­ka­nie kło­po­tów: np. pomi­ja­nie eta­pu pro­of of con­cept”. Po dru­gie nie do koń­ca zga­dzam się, że to meto­dy są dla ludzi a nie odwrot­nie, bo meto­dy są po to by obni­żać ryzy­ka pro­jek­tów i mogą być (i nie raz są) uciąż­li­we” dla ludzi (np. doku­men­to­wa­nie spo­tkań, żąda­nie danych źró­dło­wych w posta­ci doku­men­tów w nie słowotoków…)

  3. krzysztof sadowski 16 listopada 2013 at 18:04

    Nie moż­na sta­wiać zna­ku rów­no­ści pomię­dzy zwin­ny podej­ściem, a apli­ka­cja­mi napi­sa­ny­mi z jako­ścią pro­to­ty­pu (logi­ka biz­ne­so­wa w UI, brak testów auto­ma­tycz­nych itd.). To że wspo­mnia­ne fir­my tak pod­cho­dzą do wytwa­rza­nia opro­gra­mo­wa­nia wyni­ka z ich bra­ku doświad­cze­nia w dużych pro­jek­tach ze skom­pli­ko­wa­ną logi­ka biz­ne­so­wa. Podejrzewam, że skoń­czy­ło by się to tak samo nie­za­leż­nie od uży­te­go pro­ce­su wytwór­cze­go. Jeśli kto­kol­wiek pró­bu­je uspra­wie­dli­wić jakość swo­je­go dzie­ła” (a raczej jej brak) przy­ję­tym pro­ce­sem któ­ry wyko­rzy­stu­je, to jest to co naj­mniej nie poważne.

    • Jaroslaw Zelinski 16 listopada 2013 at 21:22

      Zgadzam się w 100% z wyja­śnie­niem: To że wspo­mnia­ne fir­my tak pod­cho­dzą do wytwa­rza­nia opro­gra­mo­wa­nia wyni­ka z ich bra­ku doświad­cze­nia w dużych pro­jek­tach ze skom­pli­ko­wa­ną logi­ka biz­ne­so­wa.”, pro­blem w tym, że to robią, mamią klien­tów tym, ze będzie szyb­ko i tanio” i nazy­wa­ją to robią Agile”, … Zgadzam się, że żaden pro­ces wytwór­czy nie impli­ku­je jako­ści kodu (opro­gra­mo­wa­nia), ale moim zda­niem trud­no też nazwać pro­ces pozba­wio­ny eta­pu pro­of of con­cept” sen­sow­nym pro­ce­sem wytwórczym …

  4. Jaroslaw Zelinski 16 listopada 2013 at 21:59

    Po kil­ku pyta­niach mailem, dopi­sa­łem aka­pit z archi­tek­tu­rą w UML.

  5. jacek2v 16 listopada 2013 at 22:40

    1.„klient świa­do­my” klient bar­dziej świadomy” 🙂
    2.Zdrowie jest pacjen­ta, a nie leka­rza. Lekarz nie powi­nien i nie ma pra­wa leczyć wbrew woli pacjen­ta (oprócz przy­pad­ków ubez­wła­sno­wol­nie­nia). Jeśli pacjent i lekarz nie mogą się doga­dać co do spo­so­bu lecze­nia, pacjent uda­je się do inne­go leka­rza. Jeśli klien­to­wi nie podo­ba się spo­sób podej­ścia do pro­jek­tu wyko­naw­cy (ana­li­ty­ka, deve­lo­pe­ra itp.) to szu­ka inne­go. Nie wyobra­żam sobie umo­wy reali­zo­wa­nej bez wza­jem­ne­go zro­zu­mie­nia i współ­pra­cy, bo developer/analityk sobie coś wymy­ślił i tak ma być bo to lepiej. Nie cho­dzi tu o wcho­dze­nie sobie w kom­pe­ten­cje. Klient i wyko­naw­ca cały czas komu­ni­ku­ją się na pozio­mie wyma­gań, potrzeb i celów.

    • Jaroslaw Zelinski 16 listopada 2013 at 23:16

      To: Zdrowie jest pacjen­ta, a nie leka­rza. Lekarz nie powi­nien i nie ma pra­wa leczyć wbrew woli pacjen­ta” to bar­dzo cynicz­na for­mu­ła, bo lekarz skła­da przy­się­gę Hipokratesa: przede wszyst­kim nie szko­dzić” a IT deve­lo­pe­rzy – wie­lu – wła­śnie szko­dzą zja­da­jąc budżet klien­ta, obie­cu­jąc nie raz coś, cze­go nie są w sta­nie dostarczyć … 

      Kolejny cynizm to uzna­nie, ze klient jest doro­sły i sam wybie­ra … w Kodeksie Cywilnym ist­nie­je poje­cie usłu­gi pro­fe­sjo­nal­nej nakła­da­ją­ce na usłu­go­daw­cę tak zwa­ne sta­ran­ne dzia­ła­nie”, na bazie tego zapi­su nie­któ­re fir­my pro­gra­mi­stycz­ne sto­su­ją­ce agi­le” prze­gry­wa­ją pro­ce­sy w sądach o odszko­do­wa­nia za np. brak doku­men­ta­cji co dowo­dzi nie­sta­ran­ne­go działania” 😉 

      Kolejny cynizm: w rela­cji lekarz-pacjent nie ma poję­cia wza­jem­ne­go zro­zu­mie­nia, bo pacjent nie ma poję­cia o medy­cy­nie, podob­nie jak nie ma poję­cia o pra­wie zle­ca­jąc coś praw­ni­ko­wi, czy nie zna obce­go języ­ka zle­ca­jąc coś tłu­ma­czo­wi itp. Są okre­ślo­ne ryzy­ka i zata­ja­nie ich (lub igno­ro­wa­nie) jest cyni­zmem. Prawo budow­la­ne chro­ni nas przed śmier­cią ofiar kata­strof budow­la­nych, dla­te­go wymu­sza okre­ślo­ne podej­ście. Katastrofy pro­jek­tów IT to nie śmierć ludzi a budże­tów (może poza opro­gra­mo­wa­niem sprzę­tu medycz­ne­go ale tam agi­le” jest zakazane). 

      Daleki jestem od prze­ko­ny­wa­nia do jakiej­kol­wiek meto­dy pra­cy ale moim zda­niem, prze­rzu­ca­nie 100% ryzy­ka pro­jek­tu na klien­ta i bra­nie za to pie­nię­dzy jest w moich oczach cynicz­ne, cze­go zresz­tą wyra­zem jest for­so­wa­nie umów T&M przez zwin­ne” zespoły.

  6. Jaroslaw Zelinski 16 listopada 2013 at 23:24

    Proponuję, z bra­ku ści­słej defi­ni­cji, nie uży­wać poję­cia meto­dy zwin­ne”, a pisać o sto­so­wa­nych fazach pro­ce­su wytwa­rza­nia opro­gra­mo­wa­nia. Dwie klu­czo­we to pro­of of con­cept (PoC) i wyko­na­nie. PoC do dowód słusz­no­ści np. logi­ki i archi­tek­tu­ry kodu, któ­ry to pro­jekt i jego PoC powi­nien powstać przed wytwo­rze­niem kodu. Druga rzecz to sto­so­wa­nie (lub nie) wzor­ców pro­jek­to­wych itp. to jest archi­tek­tu­ry roz­wią­zu­ją­cej pro­blem zmien­no­ści wyma­gań – to decy­du­je o jako­ści efek­tu koń­co­we­go. Jednak zno­wu wra­ca temat tego, ze pro­jekt archi­tek­tu­ry powi­nien powstać przez powsta­niem kodu. Zaczynanie pro­jek­tu od razu od kodo­wa­nia jest po pro­stu ryzy­kow­ne i pro­wa­dzi czę­sto do powsta­nia niskiej jako­ści oprogramowania. 

    • jacek2v 17 listopada 2013 at 09:52

      Zaczynanie pro­jek­tu od razu od kodo­wa­nia jest po pro­stu ryzy­kow­ne i pro­wa­dzi czę­sto do powsta­nia niskiej jako­ści oprogramowania”
      To zbyt posu­nię­ta generalizacja. 

      Często zaczę­cie od kodo­wa­nia jest naj­bar­dziej opty­mal­nym podej­ściem. Dotyczy to zwłasz­cza pro­jek­tów inno­wa­cyj­nych, nie­sza­blo­no­wych. Np. PoC‑e z któ­ry­mi się spo­tka­łem były w więk­szo­ści testa­mi, czy tech­no­lo­gia zadzia­ła. Czyli zaczy­na­no od kodo­wa­nia, aby spraw­dzić kon­cep­cję architektury.

    • Jaroslaw Zelinski 17 listopada 2013 at 16:41

      PoC to nie tyl­ko testy tech­no­lo­gii (i raczej rzad­ko są to testy tech­no­lo­gii) a testy pomy­słu na reali­za­cję okre­ślo­nej logi­ki w taki a nie inny spo­sób (np. jak imple­men­ta­cja zare­agu­je na zmia­ny gdzieś tam…), np. jak skon­stru­ować kil­ka agre­ga­tów by bar­dzo praw­do­po­dob­ne przy­szłe zmia­ny nie wyma­ga­ły prze­ra­bia­nia całe­go kom­po­nen­tu. I o to cho­dzi, testy archi­tek­tu­ry zaczy­na­ne od razu jej imple­men­ta­cji (czy­li od kodo­wa­nia) to pomi­nię­cie oce­ny same­go pomy­słu na papie­rze, co jest o nie­bo tańsze.

  7. jacek2v 17 listopada 2013 at 09:39

    Odpowiedzialność za wła­sne czy­ny to nie cynizm.
    Rzetelne wyko­ny­wa­nie swo­jej robo­ty – zgod­nie z dobry­mi prak­ty­ka­mi tj. infor­mo­wa­nie o moż­li­wych kon­se­kwen­cjach pod­ję­tych przez klien­ta decy­zji – to nie prze­rzu­ca­nie ryzyka.

    • Jaroslaw Zelinski 17 listopada 2013 at 16:48

      Cynizmem jest prze­rzu­ca­nie odpo­wie­dzial­no­ści na kogoś, kto nie zna się na tym co kupu­je, to kla­sycz­ne nabi­ja­nie w butel­kę oso­by kupu­ją­cej uży­wa­ny samo­chód a nie zna­ją­cej się na samo­cho­dach, od nie­uczci­we­go sprze­daw­cy sprze­da­ją­ce­go pico­wa­ne samo­cho­dy na gieł­dzie. Owszem, moż­na powie­dzieć, że jak ktoś tak kupu­je to jego pro­blem w koń­cu jest doro­sły. Ja zada­je pyta­nie: czy to uspra­wie­dli­wia nie­uczci­wość sprze­daw­cy uży­wa­nych samochodów?

      Jeżeli zaś idzie­my w kie­run­ku dobrych prak­tyk, to one raczej nie zale­ca­ją kodo­wa­nia z pomi­ja­niem PoC. Samo infor­mo­wa­nie klien­ta o skut­kach nie jest dobrą prak­ty­ką, bo mogę go regu­lar­nie infor­mo­wać, że kolej­na zmia­na wystro­ju miesz­ka­nia spo­wo­du­je w mojej tech­no­lo­gii” wybu­rza­nie cało­ści, ale nie jest to dobra prak­ty­ka pole­ga­ją­ca na rze­tel­nym infor­mo­wa­niu klien­ta, a paskud­na prak­ty­ka pro­wa­dze­nia na koszt klien­ta nie­prze­my­śla­nej budowy…

      Moim zda­niem, przy­tła­cza­ją­ca więk­szość pro­gra­mi­stów nie potra­fi nicze­go poza kodo­wa­niem, i nie jest to ich wada, wadą jest dopie­ro uzna­nie, że tyl­ko kodo­wa­nie pro­wa­dzi do powsta­nia oprogramowania. 

  8. jacek2v 17 listopada 2013 at 18:53

    Ad.PoC: Testowanie roz­wią­za­nia na papie­rze to takie poboż­ne życze­nia”, że będzie działać 🙂

  9. Michał Stachura 29 listopada 2013 at 22:08

    Witam

    Panie Jarosławie, cie­ka­wy i inte­re­su­ją­cy artykuł.
    Zastanawiam się czy bio­rąc pod uwa­gę, że klient prze­waż­nie nie jest świa­do­my bo nie jest deve­lo­pe­rem” wła­śnie cho­ciaż­by dla tego nie powin­no się zawsze budo­wać pro­to­ty­pu czy makie­ty poka­zu­ją­cej dzia­ła­nie” pro­jek­to­wa­nej apli­ka­cji biznesowej.

    Nie cho­dzi o zaczy­na­nie od makie­ty ale wcze­śniej czy póź­niej powin­na się moim zda­niem poja­wić po to żeby klien­ta bar­dziej uświa­do­mić co dostanie.

    • Jaroslaw Zelinski 30 listopada 2013 at 15:23

      Tylko, że pro­blem więk­szo­ści opro­gra­mo­wa­nia biz­ne­so­we­go nie pole­ga na jego wyglą­dzie, a na tym co i jak ten pro­gram przetwarza.…Jeżeli więc mowa o por­ta­lu rekla­mu­ją­cym fir­mę, gdzie 90% tego co chce klient to treść ekra­nu, to jestem się w sta­nie zgo­dzić, ale jeże­li pro­blem pole­ga na tym, ze jeden pro­sty ekran np. fak­tu­ry sprze­da­ży (a jej wygląd regu­lu­je usta­wa), ma pod sobą zło­żo­ny np. sys­tem raba­to­wa­nia i kre­dy­tów kupiec­kich (logi­ka usta­la­nia upu­stów i ter­mi­nów płat­no­ści), to meto­dą pro­to­ty­po­wa­nia tu żad­ne­go pro­ble­mu nie roz­wią­że­my za to kolej­ny­mi pro­to­ty­pa­mi nabi­je­my kosz­ty pro­jek­tu (dodam, że pro­jek­ty zwin­ne to nigdy umo­wy fixed-pri­ce). Podaje ten przy­kład bo widzia­łem naście pro­jek­tów wdro­żeń np. sys­te­mów CRM koń­czą­cych się w sądzie, dla­te­go że dostaw­ca bar­dzo szyb­ko dostar­czał stro­ny WWW ale nie uda­wa­ło mu się zaim­ple­men­to­wać (obie­ca­ne­go) zarzą­dza­nia sprzedażą”.

    • Michał Stachura 30 listopada 2013 at 21:17

      Makieta albo śmierć!!!” (żar­cik taki :))

      Zgodzę się, że makie­ta nie roz­wią­że zło­żo­nych pro­ble­mów tech­nicz­nych, któ­re dzie­ją się w tle i są core” biz­ne­su. Nie moż­na prze­ce­niać jej war­to­ści. Myślę że powin­no się ją trak­to­wać jako dobre uzu­peł­nie­nie ana­li­zy i opi­su pro­ce­sów biz­ne­so­wych, a nie jako wytycz­nych dla programisty 🙂
      Tu chy­ba wszyst­ko zale­ży od fir­my, Pan zna przy­pad­ki pro­ce­sów sądo­wych gdzie pro­jekt został poło­żo­ny mimo że miał makie­ty i stro­ny www, ja znam takie, gdzie budo­wa dużych sys­te­mów biz­ne­so­wych roz­po­czy­na­ła się od makiet i była koń­czo­na pro­jek­tem zre­ali­zo­wa­nym w ter­mi­nie. Z tym że… makie­ta była tu final­nie czę­ścią doku­men­ta­cji a nie jej głów­nym elementem :).

      Makieta to taka karo­se­ria dla samo­cho­du (war­stwa pre­zen­ta­cji z powiedz­my jakąś mini­mal­ną logi­ką zaszy­tą i nic ponad to). Bez sil­ni­ka i całych bebe­chów samo­chód nie poje­dzie, bez makie­ty klient (czy też spon­sor pro­jek­tu) może mieć pro­blem z ogar­nię­ciem cało­ści. Tak więc chy­ba po pro­stu nie ma co prze­ce­niać jej roli, moż­na (dla wygo­dy klien­ta i pro­gra­mi­sty) ją roz­ry­so­wać i zro­bić. Na pew­no nie zaszko­dzi, tro­chę tyl­ko wydłu­ży pro­ces ana­li­zy, na pew­no ten czas zwró­ci się w dwój­na­sób na eta­pie programowania.

    • Jaroslaw Zelinski 30 listopada 2013 at 23:24

      Wypada się zgo­dzić :), dodam, że makie­ty ekra­nów (lub wzo­ry doku­men­tów) to stan­dar­do­wy – nie tyl­ko u mnie – ele­ment defi­ni­cji przy­pad­ku uży­cia. Ważne by nie zapo­mi­nać, że 99% samo­cho­du jest pod maską 🙂 i same makie­ty nic nie powie­dzą o tym jak jest skonstruowany :).

    • Michał Stachura 30 listopada 2013 at 23:55

      Ci co zapo­mi­na­ją o tym to Ci, któ­rzy póź­niej spo­ty­ka­ją się z klien­tem w sądzie 🙂

    • Jaroslaw Zelinski 1 grudnia 2013 at 08:54

      🙂

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.