Jak udokumentować zakres projektu w sposób czytelny i jednoznaczny

Krótki wpis po pew­nej nie dłu­giej dys­ku­sji na pew­nym forum. Jeden z dys­ku­tan­tów przy­to­czył defi­ni­cję zakre­su pro­jek­tu publi­ko­wa­ną w WIKI:

Zakres pro­jek­tu jest to moż­li­wie jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku projektu.

Zakres nigdy nie okre­śla kon­kret­nych zadań mają­cych na celu reali­za­cję pro­jek­tu. Odpowiada na pyta­nie, co powin­no być zro­bio­ne w pro­jek­cie. Wyznacza ramy do osza­co­wa­nia kosz­tu pro­jek­tu i cza­su reali­za­cji pro­jek­tu. Zakres, koszt i czas two­rzą para­me­try pro­jek­tu, tzw. ?magicz­ny trój­kąt?. (Zakres pro­jek­tu ? Wikipedia, wol­na ency­klo­pe­dia).

Tak więc mamy pyta­nie: co powin­no być zro­bio­ne w pro­jek­cie”? Pytanie jakie ja posta­wi­łem: czy­im pro­jek­cie”? Zakres pro­jek­tu dla kogo?

Księgowa

Zacznijmy od począt­ku, pew­na Księgowa chcę nowe opro­gra­mo­wa­nie, z jej per­spek­ty­wy pad­ną nastę­pu­ją­ce oczekiwania:

  1. wysta­wia­nie fak­tur sprze­da­ży (w załą­cze­niu wzo­ry faktur)
  2. reje­stra­cja zamó­wień klien­tów (w załą­cze­niu przy­kła­dy zamówień)
  3. opro­gra­mo­wa­nie ma dzia­łać bez­a­wa­ryj­nie (dopusz­cza­my prze­rwy trwa­ją­ce do godzi­ny cza­su ale nie czę­ściej niż raz w tygodniu)
  4. wysta­wio­ne fak­tu­ry mają być eks­por­to­wa­ne do biu­ra księgowego.
  5. z opro­gra­mo­wa­nia korzy­sta wyłącz­nie księgowa

Od księ­go­wej wię­cej bym nie ocze­ki­wał bo ta oso­ba ma za zada­nie opi­sać tyl­ko to cze­go potrze­bu­je do pra­cy. Tak zwa­ny biz­nes zawsze opi­sze potrzeb­ne mu narzę­dzie ze swo­jej per­spek­ty­wy, podob­nie jak moja mama, gdy popro­si­ła mnie o pomoc przy kup­nie nowe­go tele­wi­zo­ra: ma się nada­wać do odbio­ru kablów­ki, mieć HD i mie­ścić w rega­le pod książ­ka­mi. Więcej nie trze­ba. To ja pil­no­wa­łem by ambit­ny sprze­daw­ca nie wci­snął, nie zna­ją­cej się na tej tech­no­lo­gii eme­ryt­ce, wypa­sio­ne­go TV na raty o prze­kąt­nej wyma­ga­ją­cej osob­ne­go salonu.

Wracamy do księgowej

Mamy zakres pro­jek­tu, przy­po­mnę defi­ni­cję: moż­li­wie jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku pro­jek­tu. Opis księ­go­wej speł­nia te kry­te­ria. Ale mam pro­blem z resz­tą defi­ni­cji z WIKI: zakres okre­śla co powin­no być zro­bio­ne w pro­jek­cie”. I tu WIKI w moich oczach nie­ste­ty prze­mil­cza waż­ny fakt: o jaki pro­jekt cho­dzi, co jest tym pro­jek­tem, dla kogo jest to zakres projektu?

Na pyta­nie co powin­no być zro­bio­ne w pro­jek­cie” odpo­wie dopie­ro projektant.

Komu księ­go­wa posta­wi­ła zada­nie? Na pew­no nie pro­gra­mi­stom bo tu nie ma nic do kodo­wa­nia… Przedstawiony powy­żej zakres, to zakres dla Analityka biz­ne­so­we­go pro­jek­tan­ta. Ktoś musi zamie­nić opis funk­cjo­nal­no­ści nowe­go narzę­dzia (opro­gra­mo­wa­nie dla Księgowej) na jego pro­jekt (pamię­ta­my poprzed­ni arty­kuł o młot­ku). Księgowa opi­sa­ła wyma­ga­nia swo­je funk­cjo­nal­ne i poza-funk­cjo­nal­ne (ogra­ni­cze­nia jakościowe).

Pominąłem tu ich spój­ność i kom­plet­ność. Jeżeli zacho­dzi ryzy­ko, że są nie­kom­plet­ne war­to je opra­co­wać sku­tecz­niej­szą meto­dą niż lista z pamię­ci” czy efekt burzy mózgów”, ale to inny temat ;). Ważne jest to, by te wyma­ga­nia były jed­no­znacz­ne, nie nad­mia­ro­we, spój­ne. Jak to osiągnąć?

Model wymagań czyli schemat blokowy

Poniżej dia­gram obra­zu­ją­cy dokład­nie to co opi­sa­ła Księgowa:

Po co ten obra­zek, sko­ro Księgowa to napi­sa­ła, prze­cież to to samo tyl­ko w posta­ci obraz­ka. Tak to to samo, pro­blem w tym, że gdy­by ten opis był tek­stem np. na 100 stron, nie­mal­że nie­moż­li­we było by wychwy­ce­nie nie­spój­no­ści i powtó­rzeń. Powyższy dia­gram pozwa­la spraw­dzić, czy mamy wła­ści­wie sko­ja­rzo­nych użyt­kow­ni­ków z tym jakie czyn­no­ści będą wyko­ny­wa­li, czy nie ma zdu­blo­wa­nych funk­cjo­nal­niej (jajecz­ka) i nakła­da­ją­cych się ról (ludzik, tak zwa­ny Aktor sys­te­mu). Najważniejszy jest tu pro­sto­kąt o nazwie Nowy Fajny System dla Księgowej, bo on poka­zu­je Zakres pro­jek­tu. Teraz wie­my, że wyko­naw­cę nie inte­re­su­je Biuro Księgowe, inte­re­su­je go tyl­ko jakie pyta­nie ma obsłużyć”.

Jeżeli pad­nie pyta­nie o szcze­gó­ły tych funk­cjo­nal­no­ści, nale­ży je jed­no­znacz­nie przy­po­rząd­ko­wać albo do Aktora albo do Systemu. Np. jak pad­nie pyta­nie o to, jak się nali­cza poda­tek VAT, powin­no paść dodat­ko­we pyta­nie: kto ten poda­tek ma nali­czać, Aktor czy System (podział odpo­wie­dzial­no­ści, zakres pro­jek­tu). Uporządkowanie tego da nam jasny zakres pro­jek­tu. Mając dobre narzę­dzie, moż­na z takie­go dia­gra­mu bez pro­ble­mu wyko­nać ocze­ki­wa­ny tek­sto­wy raport spe­cy­fi­ku­ją­cy wyma­ga­nia na sys­tem i wszel­kie ogra­ni­cze­nia jaki­mi są umie­jęt­no­ści akto­rów i wyma­ga­nia jako­ścio­we (tak zwa­ne poza-funkcjonalne).

Gdyby tych wyma­gań było nie kil­ka a kil­ka­dzie­siąt, bez takie­go mode­lu bar­dzo trud­ne było opra­co­wa­nie takiej spe­cy­fi­ka­cji bez ryzy­ka nie­spój­no­ści i bra­ków oraz zagwa­ran­to­wa­nie, że zakres pro­jek­tu jest jed­no­znacz­ny i dobrze prze­my­śla­ny. Po dru­gie jeden taki dia­gram zastę­pu­je kil­ka, kil­ka­na­ście stron tek­stu, a z czym łatwiej się nam będzie szyb­ko zapoznać?

Duża licz­bę wyma­gań, dla czy­tel­no­ści dia­gra­mów i upo­rząd­ko­wa­nia wyma­gań, dzie­li się na kil­ka takich dia­gra­mów np. kon­tek­sto­wo, tak by na jed­nym dia­gra­mie nie było wię­cej niż kil­ka­na­ście obiek­tów. Czy ten dia­gram, po powyż­szym komen­ta­rzu jest nie­zro­zu­mia­ły? Właśnie Państwo pozna­li Diagram Przypadków Użycia z nota­cji UML.

Można spo­tkać te dia­gra­my posze­rzo­ne o mało zro­zu­mia­łe dla laika poję­cia «extend», «inc­lu­de» i inne, jed­nak moim zda­niem to nie­po­trzeb­nie je kom­pli­ku­je i czy­ni nie­zro­zu­mia­ły­mi dla Zamawiającego, a to Zamawiający okre­śla wyma­ga­nia i dia­gram ten nie powi­nien u Zamawiającego budzić żad­nych wąt­pli­wo­ści (powi­nien się pod nim bez stra­chu pod­pi­sać). Jeżeli więc Państwu jako Zamawiającemu, ktoś da do pod­pi­su doku­men­ta­cję, któ­rej nie rozu­mie­cie w 100%, to po pro­stu nie pod­pi­suj­cie się pod nią, bo to zła doku­men­ta­cja sko­ro jej nie rozu­mie­cie, a powsta­ła dla Was bo macie ją podpisać.

Na tym byśmy poprze­sta­li gdy­by celem był zakup goto­we­go opro­gra­mo­wa­nia. A jak nie, jeże­li z jakie­goś powo­du musi­my mieć dedykowane?

Co dalej?

Diagram ten w 100% opi­su­je zakres pro­jek­tu z per­spek­ty­wy Zamawiającego, ale jest zupeł­nie bez­war­to­ścio­wy dla pro­gra­mi­sty (kode­ra). Bo zakres pro­jek­tu, opis, musi mieć adre­sa­ta. Zakres pro­jek­tu owszem ale dla kogo?

Szybki prze­gląd od koń­ca: zakres pro­jek­tu dla pro­gra­mi­sty (przy­po­mnę defi­ni­cję) jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku pro­jek­tu, to opis kodu jaki ma pro­gra­mi­sta wytwo­rzyć. Czy dia­gram Przypadków mu to powie? Absolutnie nie!

Zakres pro­jek­tu dla pro­gra­mi­sty stwo­rzy Architekt sys­te­mu, klu­czo­wa rola w każ­dej dobrej fir­mie pro­gra­mi­stycz­nej. Co jest zakre­sem pro­jek­tu dla Architekta sys­te­mu? Architekt ocze­ku­je opi­su tego jaką logi­kę ma reali­zo­wać opro­gra­mo­wa­nie, jaki­mi dany­mi i jak ma zarzą­dzać System. Kto to ma zrobić?

Analityk biznesowy

Powyższy dia­gram przy­pad­ków uży­cia, to pierw­szy etap pra­cy, ktoś – zno­wu Analityk biz­ne­so­wy bo poznał i zro­zu­miał biz­nes Zamawiającego na eta­pie opi­su wyma­gań biz­ne­so­wych, musi teraz powyż­sze zamie­nić na, naj­le­piej obiek­to­wy, model (doku­men­ta­cję) całej logi­ki biz­ne­so­wej (dane i meto­dy ich prze­twa­rza­nia) jaka ma być zaim­ple­men­to­wa­na: tak zwa­ny model dzie­dzi­ny systemu.

Zakładam, że uży­te zosta­ną obiek­to­we meto­dy i narzę­dzia imple­men­ta­cji. Obiektowe meto­dy ana­li­zy zdo­by­ły sobie uzna­nie bo dają jed­no­znacz­ne opi­sy, to teraz w zasa­dzie stan­dard w opro­gra­mo­wa­niu dla biznesu.

Zakres projektu dla Architekta

Tu poja­wią się więc: kla­sy, sekwen­cje, sta­tu­sy klas, algo­ryt­my metod. To jest zakres pro­jek­tu dla archi­tek­ta, któ­ry wpa­ku­je” to np. w struk­tu­rę uży­wa­ne­go fra­me­wor­ka i stwo­rzy zakres pro­jek­tu dla programistów.

Na zakończenie

W moich oczach nie ma nic bar­dziej ryzy­kow­ne­go niż prze­ka­za­nie Opisu Księgowej od razu pro­gra­mi­stom do wyko­na­nia. Bo mamy tak na praw­dę trzy zakre­sy pro­jek­tu, każ­dy inny, każ­dy ma inne­go adre­sa­ta i każ­dy nale­ży udo­ku­men­to­wać ina­czej, ale zawsze jed­no­znacz­nie posta­wić zadanie.

Praca bez tego typu doku­men­tów, bez jasne­go wydzie­le­nia poszcze­gól­nych eta­pów ana­li­zy, tak czę­sto prak­ty­ko­wa­na przez wie­le firm IT, to atak na twier­dzę bez mapy tere­nu i strategii…

P.S.

Wpadł mi dziś ręce arty­kuł: Sygnity wyko­na sys­tem e Podatki. Powiem tyl­ko tyle: sys­tem za 232 mln. wyce­nio­no na pod­sta­wie opi­su (OPZ) mają­ce­go 23 stro­ny: http://​www​.mf​.gov​.pl/​_​f​i​l​e​s​_​/​m​i​n​i​s​t​e​r​s​t​w​o​/​p​r​z​e​t​a​r​g​i​/si…, jestem pod wra­że­niem metod wyce­ny. Każdy inny pro­jekt inży­nier­ski wart 232 mln. miał­by pew­nie pół kon­te­ne­ra doku­men­ta­cji prze­tar­go­wej, a tu pro­szę 23 strony…

Inne artykuły na podobny temat

Komentarze

  1. Sławomir Niemiec 6 września 2012 at 11:50

    Moim kole­dzy infor­ma­ty­cy dostrze­ga­ją zwy­kle sfor­ma­li­zo­wa­ne i dobrze dzia­ła­ją­ce pro­ce­sy, któ­re może wyko­ny­wać maszy­na”. W rze­czy­wi­sto­ści pro­ce­sy, w któ­rych bio­rą udział ludzie są bar­dzo skom­pli­ko­wa­ne. Z pew­no­ścią jest sztu­ką i wyma­ga spo­re­go doświad­cze­nia opi­sa­nie ich w spo­sób czy­tel­ny i jed­no­znacz­ny. Bez zdo­by­cia wie­dzy na temat dzia­ła­nia orga­ni­za­cji zama­wia­ją­ce­go, nie­jed­no­krot­nie spo­tka­łem się w swej pra­cy zawo­do­wej z duży­mi pro­ble­ma­mi w kolej­nych eta­pach pro­jek­tów informatycznych”.
    W tym kon­tek­ście, chcia­łem przy­to­czyć cie­ka­wą defi­ni­cję wie­dzy według Davnporta i Prusaka:
    Wiedza to płyn­ne połą­cze­nie ukształ­to­wa­ne­go doświad­cze­nia, war­to­ści, infor­ma­cji kon­tek­sto­wej i eks­per­ty­zy, któ­re zapew­nia­ją model oce­ny oraz pozwa­la­ją wcie­lić nowe doświad­cze­nia i infor­ma­cje. Swój począ­tek i odnie­sie­nie znaj­du­je w umy­słach ludzi posia­da­ją­cych wie­dze. Jest osa­dzo­na w doku­men­tach, repo­zy­to­riach, pro­ce­du­rach, pro­ce­sach, prak­ty­kach i nor­mach organizacyjnych.”

  2. Hania 6 września 2012 at 21:53

    Apropos PS. 10 mln bufo­ru na ryzy­ko nie­wła­ści­wych zało­żeń na każ­dą stronę 🙂

    To waż­ne, co Pan napi­sał o 3 per­spek­ty­wach (klient, archi­tekt, pro­gra­mi­sta). Warto o to zadbać…

    Jeśli cho­dzi o pisa­nie doku­men­ta­cji zro­zu­mia­łej dla klien­ta i jed­no­cze­śnie już przed­sta­wia­ją­cej wynik ana­liz (kom­plet­ność, spój­ność, zgod­ność z cela­mi), to wyda­je mi się wyzwa­niem. Ma Pan wię­cej spo­strze­żeń na ten temat? Co dla klien­tów jest zro­zu­mia­łe, co dla archi­tek­ta jest dobrą pod­sta­wą do dal­szej pra­cy? Czy to to samo lub czym się różni?

    • Jarek Żeliński 7 września 2012 at 09:38

      Pisanie doku­men­ta­cji zro­zu­mia­łej dla klien­ta to część pra­cy. Umownie” dzie­lę pro­jek­ty, a raczej to co opi­sze”, na dwie klu­czo­we czę­ści: audyt czy­li opis (model) tego co Klient robi (jego fir­ma, jak pra­cu­je itp.), to doku­ment, któ­ry powi­nien być w 100% rozu­mia­ny przez Klienta bo to jego opis. Np. opi­sa­ny dia­gram przy­pad­ków uży­cia. Potem jest jakiś pro­jekt”, jego adre­sa­tem jest już kto inny: Architekt/Developer. Tej czę­ści Klient nie musi rozu­mieć, a nawet czy­tać. Dlaczego? Bo to jest to cze­go klient nie potra­fi a jest mu potrzeb­ne”. Prosty inny przy­kład. Klient potrze­bu­je zawrzeć umo­wę z Chińskim part­ne­rem. Spotyka się z praw­ni­kiem, opi­su­je mu co jest celem umo­wy. Prawnik pyta o ryzy­ka pla­no­wa­nej współ­pra­cy i na tej pod­sta­wie opra­co­wu­je treść umo­wy. Te treść Klient czy­ta i zatwier­dza. Następnie tan sam praw­nik lub tłu­macz, tłu­ma­czy te umo­wę na Chiński. Tej czę­ści pra­cy Klient nie wery­fi­ku­je bo nie jest w sta­nie ale nie pozo­sta­je mu nic inne­go jak zaufać swo­je­mu usłu­go­daw­cy lub zrezygnować.

      Wydawało by się to wszyst­ko oczy­wi­ste, a mimo to tak wie­lu ludzi rzu­ca się od razu do roz­mo­wy z Chińczykami… Ci zaś chęt­nie je pro­wa­dzą bo robią za pie­nią­dze tego pierwszego. 

  3. Jarek Żeliński 7 września 2012 at 10:50

    Zacytuje trwa­ją­ca dys­ku­sję, zgło­szo­no w dys­ku­sji waż­ne pytanie:

    ” Powyższy dia­gram pozwa­la spraw­dzić, czy mamy wła­ści­wie sko­ja­rzo­nych użyt­kow­ni­ków z tym jakie czyn­no­ści będą wyko­ny­wa­li, czy nie ma zdu­blo­wa­nych funk­cjo­nal­niej (jajecz­ka) i nakła­da­ją­cych się ról (ludzik, tak zwa­ny Aktor systemu). ”

    Czyli jak rozu­miem, UC peł­ni funk­cje wery­fi­ka­cyj­ne. Dobrze.
    Po co w takim razie umiesz­czać je w doku­men­ta­cji ? Skoro UC nie prze­ka­zu­je żad­nej infor­ma­cji, poza tą, że jest dobrze” to moim skrom­nym zda­niem powin­no się ich uży­wać jedy­nie pod­czas two­rze­nia doku­men­ta­cji a z samej doku­men­ta­cji powin­ny takie dia­gra­my zostać wyklu­czo­ne. Za dużo” też zna­czy źle”.

    Kluczowym testem sen­su i war­to­ści tre­ści, np. doku­men­ta­cji wyma­gań, są (mogą być, gorą­co pole­cam) tak zwa­ne widły Hume’a”. Czym są owe Widły Hume?a? Każdą wypo­wiedź (zapis w doku­men­ta­cji) nale­ży spraw­dzić dwo­ma pytaniami:
    1. Co to znaczy?
    2. Skąd to wiesz?

    Jeżeli więc napi­szę w doku­men­ta­cji, że sys­tem ma .…” i tu poja­wi się skoń­czo­na lista wyma­gań (albo pro­jekt archi­tek­tu­ry itp.), oraz doło­żę do tego zapis: opra­co­wa­ne wyma­ga­nia są spój­ne i kom­plet­ne, to w pro­fe­sjo­nal­nie wyko­na­nej doku­men­ta­cji” powin­na poja­wić się odpo­wiedź na pyta­nie Co to zna­czy Spójne i kom­plet­ne” a potem na pyta­nie Skąd to wiemy”.

    Na pierw­sze pyta­nie odpo­wiedź udzie­la sł. j.polskiego:
    spój­ny ?logicz­nie powią­za­ny, har­mo­nij­ny, konsekwentny?,
    kom­plet­ny ?taki, w któ­rym nie bra­ku­je żad­ne­go z elementów?

    Czy do jakiejś książ­ki dołą­cza się słow­nik, żeby czy­tel­nik mógł sobie spraw­dzić, że w tek­ście nie ma błę­dów orto­gra­ficz­nych a każ­de sło­wo zosta­ło uży­te zgod­nie ze swo­im znaczeniem ?

    Nie, słow­ni­ki są powszech­nie dostęp­ne, wystar­czy podać któ­re­go uży­to (Tu SJP, PWN). 

    Na dru­gie pyta­nie odpo­wie­dzią są mode­le, któ­re jako narzę­dzia, któ­re posłu­ży­ły do wyspe­cy­fi­ko­wa­nia wyma­gań, poka­zu­ją skąd to wie­my, że są spój­ne i kompletne”. 

    Co do tezy Za dużo” zna­czy źle”, praw­da, wyma­ga jed­nak uzu­peł­nie­nia: co to zna­czy za dużo. Każdy dobrze opra­co­wa­ny doku­ment eks­perc­ki to jed­na stro­na” reko­men­da­cji i załą­czo­ne set­ki stron” ich uza­sad­nie­nia (pierw­sze czy­ta każ­dy, dru­gie ten kto chce). To uza­sad­nie­nie po pierw­sze uwia­ry­gad­nia reko­men­da­cje po dru­gie pozwa­la sko­rzy­stać z narzę­dzia (mode­li) do ewen­tu­al­nej kon­ty­nu­acji tej pra­cy (roz­wo­ju systemu).

    Tak więc spe­cy­fi­ka­cja wyma­gań mogła by mieć postać suchej listy i w zasa­dzie powin­na wystar­czyć. Takie doku­men­ty dostar­cza 99% klien­tów lub ich ana­li­ty­ków. Problem poja­wia się gdy zadać pyta­nie: czy wyma­ga­nia są spój­ne i kom­plet­ne? Jeżeli tak, to skąd to wiemy”?

    A cze­go się cze­piam? Bo jeże­li wyma­ga­nia nie są spój­ne i kom­plet­ne” to zacho­dzi ogrom­ne ryzy­ko nie­po­wo­dze­nia pro­jek­tu. Jedynym spo­so­bem mini­ma­li­za­cji tego ryzy­ka jest to skąd to wie­my, że są spój­ne i kompletne”

    Podstawowy błąd to twier­dze­nie w odnie­sie­niu do doku­men­ta­cji, że Less is more”. Powinna być na tyle obszer­na by wyja­śnia­ła wszyst­ko” ale nie powin­na zawie­rać żad­nych bana­łów, któ­re moż­na odsiać Widłami Hume’a”. Dobra doku­men­ta­cja zawie­ra dużo infor­ma­cji ale nie za dużo” bo to fak­tycz­nie źle.

  4. wojtek 11 września 2012 at 13:24

    co do P.S. to doku­ment na 23 stro­nie ma liste 15 zalacznikow 

    1 i 2 zalacz­nik maja razem 900 stron, pozo­sta­le 13 doku­men­tow jest gdzies po 50 stron kazdy…

    • Jarek Żeliński 11 września 2012 at 13:45

      To praw­da, jed­nak te załącz­ni­ki nie są pro­jek­tem a listą rze­czy do zro­bie­nia”, nawet pro­ce­sy nie są zamo­de­lo­wa­ne a jedy­nie wymie­nio­ne. To trosz­kę jak wyce­nić dra­pacz chmur mając w zamó­wie­niu jedy­nie wyma­ga­ną listę pomiesz­czeń i mapę naj­bliż­szej oko­li­cy… Moim zda­niem te 900 stron nie­wie­le wno­si do wyce­ny. Ten sys­tem będzie dopie­ro pro­jek­to­wa­ny w ramach reali­za­cji pro­jek­tu, dla­te­go nadal uwa­żam, że wyce­nio­no coś cze­go jesz­cze nie zapro­jek­to­wa­no. Dodam, że wyko­naw­ca, jako pro­jek­tant, będzie auto­rem pro­jek­tu i pro­duk­tu, inny­mi sło­wy zama­wia­ją­cy dosta­nie licen­cje lub pra­wa mająt­ko­we ale wie­dza o pro­duk­cie i tak zosta­je u Wykonawcy z pra­wem re-uży­cia… W ten spo­sób powsta­ją (tu zno­wu jest takie ryzy­ko) pro­duk­ty, któ­rych roz­bu­do­wa jest zle­ca­na bez prze­tar­gu z uwa­gi na pra­wa autor­skie (Wiele firm IT już tak się usta­wi­ło w Urzędach).

  5. wojtek 11 września 2012 at 15:20

    Przeciez na tym pole­ga reali­za­cja pro­jek­tu, klient ogla­sza­jac prze­targ okre­sla to co chce i jest to zapi­sa­ne nie na 23 stro­nach, a na 1500. Wydaje mi sie , ze chy­ba zda­nie każ­dy inny pro­jekt inży­nier­ski wart 232 mln. miał­by pew­nie pół kon­te­ne­ra doku­men­ta­cji prze­tar­go­wej, a tu pro­szę 23 stro­ny?” jest popro­stu bled­nym okre­sle­niem, bo 1500 stron doku­men­ta­cji jest chy­ba tym kon­te­ne­rem”. Zainteresowal mnie ten arty­kul przede wszyst­kim tym P.S.” i kon­tro­wer­sja zwia­za­na z 23 stro­na­mi, ale po 5 minu­to­wym prze­gla­dzie wca­le tak zle nie jest, jak Pan opisuje;)

    • Jarek Żeliński 11 września 2012 at 15:51

      Same 23 stro­ny” to przy­zna­ję mała pro­wo­ka­cja ale tyl­ko mała”. Rzecz w tym, że pozo­sta­łe set­ki stron, poza opi­sem idei, nicze­go nie wno­szą. Problem w tym, że to, ogło­szo­ny prze­targ i jego zakres, to zada­nie dla ana­li­ty­ka pro­jek­tan­ta a nie dla deve­lo­pe­ra. Jeżeli ana­li­tyk pro­jek­tant miał­by tu dużo danych do wyce­ny swo­jej usłu­gi ana­li­za i pro­jek­to­wa­nie”, tak nie widzę nawet jed­ne­go zda­nia do wyce­ny kosz­tu wytwo­rze­nia opro­gra­mo­wa­nia”, są dane o tym jakiej infra­struk­tu­ry się ocze­ku­je ale to dostar­cze­nie sprzę­tu”. Artykuł powyż­szy opi­su­je róż­ni­cę pomię­dzy wyma­ga­nia­mi dla pro­jek­tu reali­zo­wa­ne­go przez ana­li­ty­ka pro­jek­tan­ta” a wyma­ga­nia­mi dla pro­jek­tu reali­zo­wa­ne­go przez wytwór­cę”. Dla tego dru­gie­go ten OPZ nie zawie­ra nic co nada­wa­ło by się to rze­tel­nej wyce­ny. W moim, i nie tyl­ko, odczu­ciu pro­blem wie­lu takich pro­jek­tów (i prze­tar­gów) pole­ga na skła­da­niu ofert na bazie tyl­ko wizji”, któ­ra nie raz nie­wie­le ma wspól­ne­go z realia­mi odkry­wa­ny­mi w trak­cie pro­jek­tu. Po dru­gie, jeże­li ta sama fir­ma jest pro­jek­tan­tem i wyko­naw­cą nie ist­nie­je poję­cie nad­zo­ru autor­skie­go bo jak wyko­naw­ca ma sam sie­bie nad­zo­ro­wać? Jest to kurio­zal­na sytu­acja, któ­ra np. w innych dzie­dzi­nach inży­nie­rii jest wręcz niedopuszczalna.

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.