Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzy­kiem to pro­za życia kie­row­ni­ków pro­jek­tów. Z jed­nej stro­ny doświad­czo­ny kie­row­nik pro­jek­tu powi­nien dosko­na­le radzić sobie z ryzy­kiem, z dru­giej zaś stro­ny prak­ty­ka pro­jek­tów poka­zu­je, że efek­ty są nie­ste­ty sła­be bo ok. 90% IT na świe­cie ma prze­kro­co­zne budże­ty i ter­mi­ny .

Jednym z cie­kaw­szych narzę­dzi zarzą­dza­nia ryzy­kiem jest mało popu­lar­ny tak zwa­ny sto­żek nie­pew­no­ści. Ogólna zasa­da pla­no­wa­nia mówi, że im bar­dziej w przy­szłość wybie­ga­ją pro­gno­zy tym bar­dziej są one nie­pew­ne. Jest nie tyl­ko intu­icyj­ne ale i udo­wod­nio­ne mate­ma­tycz­nie. Stożek nie­pew­no­ści to wykres poka­zu­ją­cy zwią­zek pomię­dzy kosz­ta­mi pro­jek­tu a posia­da­ną wie­dzą na eta­pie ini­cja­cji pro­jek­tu np. imple­men­ta­cji (dostar­cze­nia) opro­gra­mo­wa­nia. Poniżej jeden z przy­kła­dów jego zobrazowania:

Stożek nie­pew­no­ści

Stożek ten (sto­żek nie­pew­no­ści) to narzę­dzie empi­rycz­ne (!), obra­zu­je spo­dzie­wa­ne kon­se­kwen­cje jaki­mi są kosz­ty, gene­ro­wa­ne przez nie­pew­ność (przed­wcze­sne, nie­uda­ne pro­to­ty­py, wpro­wa­dza­nie zmian po przed­wcze­snym roz­po­czę­ciu prac imple­men­ta­cyj­nych i wdro­że­nio­wych, itp.). 

Na powyż­szym wykre­sie, czer­wo­na linia obra­zu­je kosz­ty eta­pu prac bez ana­liz i pro­jek­to­wa­nia (agi­le) a zie­lo­na kosz­ty prac poprze­dzo­nych ana­li­za­mi i pro­jek­to­wa­niem. Linie te spo­ty­ka­ją w punk­cie, w któ­rym wie­dza o osta­tecz­nej wer­sji pro­duk­tu jest już taka sama. Punkty ozna­czo­ne dia­men­tem” to kamie­nie milo­we pro­jek­tu. Wartość kosz­tu odnie­sie­nia 1.0 to sytu­acja, w któ­rej w momen­cie roz­po­czę­cia pro­jek­tu nie było­by żad­nych nie­wia­do­mych (ryzy­ko zakre­su pro­jek­tu = zero). Całkowity koszt pro­jek­tu to pola pod krzy­wy­mi (pomię­dzy daną krzy­wą a pozio­mem zero lewej osi). Praktyka poka­zu­je więc, że brak pla­no­wa­nia i pro­jek­to­wa­nia pod­no­si kosz­ty pro­jek­tu śred­nio czterokrotnie.

W przy­pad­ku apli­ka­cji będą­cej mono­li­tem wykres repre­zen­tu­je cały pro­jekt („water fall”, meto­da wodo­spa­do­wa), czy­li pro­jekt trwa­ją­cy nie raz kil­ka lat. Prawdopodobieństwo, że reali­za­cja deta­licz­nie zapla­no­wa­ne­go np. na 5 lat pro­jek­tu będzie wyma­ga­ła korek­ty pla­nów lub wpro­wa­dza­nia zmian do pro­jek­tu, gra­ni­czy obec­nie z pewnością:

W przy­pad­ku zasto­so­wa­nia metod obiek­to­wych, zorien­to­wa­nych na komponenty/mikroserwisy, wykres Stożek nie­pew­no­ści repre­zen­tu­je dostar­cze­nie jed­nej usłu­gi apli­ka­cyj­nej (przy­pa­dek uży­cia, imple­men­to­wa­nej jako kom­po­nent, patrz tak­że ite­ra­cyj­no-przy­ro­sto­we dostar­cza­nie opro­gra­mo­wa­nia jako kolej­nych usług apli­ka­cyj­nych, MVP: Minimum Value Product). Implementacja jed­nej takiej usłu­gi z regu­ły mie­ści się w jed­nym kwar­ta­le. W efek­cie prak­tycz­nie eli­mi­nu­je­my skut­ki nie­pew­no­ści, pla­nu­jąc reali­za­cję pro­jek­tu tak, by żad­ne pla­ny nie wybie­ga­ły zbyt dale­ko w przy­szłość (z regu­ły gra­ni­ca jest rok budże­to­wy). Jest to moż­li­we dzię­ki odej­ściu od mono­li­tycz­nej archi­tek­tu­ry apli­ka­cji. Realizacja pro­jek­tu wytwa­rza­nia apli­ka­cji o kom­po­nen­to­wej (np. mikro­ser­wi­sy) archi­tek­tu­rze wyglą­da jak poniżej:

Warto tu zwró­cić uwa­gę, że apli­ka­cje zbu­do­wa­ne w opar­ciu o jed­ną i cen­tral­ną bazę danych w mode­lu rela­cyj­nym (RDBMS) są wła­śnie typo­wy­mi mono­li­ta­mi, np. więk­szość powszech­nie zna­nych dużych sys­te­mów ERP. Duże sys­te­my rela­cyj­nych baz danych są z tego powo­du od daw­na krytykowane:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

W tym przy­pad­ku ofer­ty (obiet­ni­ce) dostaw­ców tego typu sys­te­mów (mono­li­ty) to zie­lo­na linia na dia­gra­mie Stożek nie­pew­no­ści, a fak­tycz­ne kosz­ty tych wdro­żeń, pole­ga­ją­ce na bie­żą­cej, pro­wa­dzo­nej ad-hoc adap­ta­cji, to linia czer­wo­na, co potwier­dza­ją sta­ty­sty­ki .

Źródła

Little, T. (2006). Schedule esti­ma­tion and uncer­ta­in­ty sur­ro­un­ding the cone of uncer­ta­in­ty. Software, IEEE, 23, 48 – 54. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​6​.82
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.

Mega projekty czyli jak zjeść słonia

Ku moje­mu zasko­cze­niu dość czę­sto dosta­ję pyta­nia o moż­li­wość zaan­ga­żo­wa­nia się w roli ana­li­ty­ka np. na rok na warun­kach: 100% cza­su na miej­scu u klien­ta a wyni­kiem ma być spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, któ­re­go reali­za­cja jest pla­no­wa­na na np. kolej­ne 5 lat. Nie ma to moim zda­niem żad­ne­go sen­su i nie anga­żu­je się w takie pro­jek­ty. Ale po kolei.

Już w roku chy­ba 2003 robi­łem ana­li­zę ryzy­ka dużych i dłu­gich pro­jek­tów, celem była oce­na praw­do­po­do­bień­stwa i kosz­tów wpro­wa­dza­nia zmian do zakre­su pro­jek­tu. Jak nie trud­no się domy­śleć, jest to – zmia­ny zakre­su – naj­bar­dziej nie­chcia­na rzecz w każ­dym pro­jek­cie. Materiał ten był pre­zen­to­wa­ny na jed­nej z kon­fe­ren­cji doty­czą­cych wdra­ża­nia sys­te­mów ERP.

Co spo­wo­do­wa­ło moje zain­te­re­so­wa­nie tym pro­ble­mem? To co każ­dy w tej bran­ży widział chy­ba naj­mniej raz w życiu: róż­ni­ca pomię­dzy pier­wot­ną spe­cy­fi­ka­cją a osta­tecz­nym pro­duk­tem. W dużych pro­jek­tach czę­sto te dwa sta­ny nie mają z sobą zbyt wie­le wspól­ne­go! Więc poja­wia się pyta­nie: po co robić wiel­ką ana­li­zę i doku­men­ta­cję sko­ro więk­szość tej doku­men­ta­cji, roz­dział po roz­dzia­le, lądu­je w koszu za spra­wą zarzą­dza­nia zmianą”?

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? 70% to zmia­ny zakre­su pro­jek­tu, (Raport Jama Sofware ? O wyma­ga­niach).

Popatrzmy na to:

Ryzyko projektu 1

Analiza i spe­cy­fi­ko­wa­nie wyma­gań to tak na praw­dę pro­gno­za mówią­ca, że to co teraz pro­jek­tu­je­my będzie w przy­szło­ści, w dniu odda­nia do użyt­ku, potrzeb­ne w takiej for­mie w jakiej wła­śnie to pro­jek­tu­je­my. Jak wie­my, pro­gno­zy są tym więk­szym błę­dem obar­czo­ne i bar­dziej w przy­szłość wybie­ga­ją. Powyższy dia­gram to typo­wy mega­pro­jekt. Linia prze­ry­wa­na obra­zu­je pew­ną hipo­te­tycz­ną gra­ni­cę, powy­żej któ­rej ryzy­ko błęd­nej pro­gno­zy prze­kra­cza np. 50% (czy­li kla­sycz­ny rzut monetą).

Innymi sło­wy, roz­po­czy­na­jąc mega­pro­jekt mamy nie­mal­że pew­ność, że jego zakres ule­gnie zmia­nie czy­li cała pra­ca powy­żej tej linii prze­ry­wa­nej pój­dzie do kosza (na koszt spon­so­ra projektu ;)).

W natu­ral­ny spo­sób nasu­wa się wnio­sek: nie nale­ży robić nic ponad tę prze­ry­wa­ną linię. Wtedy otrzy­ma­my taki diagram:

Ryzyko projektu 2

Robimy tyl­ko to co z ryzy­kiem bli­skim zera zosta­nie zaim­ple­men­to­wa­ne bez zmian. Jak? Pierwszy etap to ana­li­za pro­ble­mu i pro­jek­to­wa­nie archi­tek­tu­ry cało­ści – model kom­po­nen­tów. Jest to jakaś logi­ka sys­te­mu na dość wyso­kim pozio­mie abs­trak­cji ale dają­ca się prze­te­sto­wać. Stanowi ona pod­sta­wę dal­szej pra­cy nad każ­dym kom­po­nen­tem osob­no (kolej­ne eta­py). Uszczegóławianie wyma­gań odkła­da­my na ostat­ni moment”. W ten spo­sób kwar­tał po kwar­ta­le” dopre­cy­zo­wu­je­my wyma­ga­nia na kolej­ny etap i reali­zu­je­my go. Co zysku­je­my? Nie wyrzu­ca­my do kosza nad­mier­nie szcze­gó­ło­wej i roz­le­głej doku­men­ta­cji wyma­gań, nie pono­si­my koszów pro­jek­to­wa­nia cze­goś co może wyle­cieć” z zakre­su za pół roku z powo­dów np. zmian na ryn­ku, może­my w dowol­nym momen­cie zmie­nić kolej­ne pla­no­wa­ne kom­po­nen­ty, usu­nąć jed­ne i opra­co­wać nowe bez ryzy­ka zbęd­nych kosztów.

Pierwszy etap ma pew­ną cechę: two­rzy (taki ma cel) jeden wspól­ny model wszyst­kich pro­jek­tów dla danej orga­ni­za­cji o wdzięcz­nej nazwie Architektura Korporacyjna. Kolejne kon­kret­ne kom­po­nen­ty archi­tek­tu­ry IT to kolej­ne pro­jek­ty, cechu­ją­ce się zro­zu­mia­nym umiej­sco­wie­niem w cało­ści orga­ni­za­cji i wia­ry­god­nym, spój­nym z cało­ścią zakresem.

Dlatego z regu­ły nie mają sensu:

  1. wdro­że­nia depar­ta­men­to­we ode­rwa­ne od resz­ty (np. Dział Handlowy sobie fun­du­je sam sys­tem CRM),
  2. pro­jek­ty trwa­ją­ce dłu­żej niż trzy kwar­ta­ły (ostat­ni kwar­tał to kolej­ne pla­no­wa­nie budże­tu na kolej­ny rok czy­li pla­no­wa­nie zmian),
  3. mega pro­jek­ty ERPII czy­li all in one” dla fir­my w ramach jed­ne­go projektu.

Więc jak zjeść sło­nia by się nie udła­wić? Powoli i po kawał­ku… I nie zapo­mi­naj­my, że wyzwa­niem może być nie tyle nowe opro­gra­mo­wa­nie co zmia­na nawy­ków ludzi… a nie ma nic gor­sze­go niż pla­no­wa­nie nowe­go opro­gra­mo­wa­nia dla sta­rych nawy­ków bo po co to robić?

Pamiętajmy, że zarzą­dza­nie zakre­sem pro­jek­tu jest tym kosz­tow­niej­sze im wię­cej szcze­gó­łów ten zakres posia­da. Projekt o 30 wyma­ga­niach vs. pro­jekt o 300 wyma­ga­niach to nie pro­jekt o 10-krot­nie więk­szym kosz­cie, ta róż­ni­ca będzie znacz­nie więk­sza (pomi­jam to jak w ogó­le zde­fi­niu­je­my wymaganie).

Tak więc prze­cięt­ny pro­jekt to dla ana­li­ty­ka pra­ca na nie wię­cej niż kwar­tał (mniej wię­cej). Jak ja opi­sać wyma­ga­nia na sys­te­my ERP? Nie są to set­ki szcze­gó­ło­wych wyma­gań, bo to nie ma sen­su. To opis archi­tek­tu­ry kor­po­ra­cyj­nej wraz z zesta­wem celów biz­ne­so­wych dla każ­de­go poten­cjal­nie kupo­wa­ne­go modu­łu (pod­sys­te­mu) oraz wyma­ga­nia jako testy poka­zu­ją­ce reali­za­cję tych celów. Tych testów (wyma­gań) będzie raczej 30 niż 300, zaś ewen­tu­al­ne dedy­ko­wa­ne funk­cjo­nal­no­ści są pro­jek­to­wa­ne na ostat­ni moment” jeże­li oka­że się, że żaden ryn­ko­wy pro­dukt ich nie ofe­ru­je a nam na praw­dę są one potrzebne.

P.S.

Stale mnie nur­tu­je pyta­nie: dla­cze­go tak czę­sto są ogła­sza­ne prze­tar­gi na mega­pro­jek­ty i są skła­da­ne ofer­ty na mega wdro­że­nia, sko­ro to co napi­sa­łem nie sta­no­wi żad­ne­go odkrycia? 🙂

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…