Proszę się dokład­nie zapo­znać z poniż­szą tre­ścią, ten doku­ment to stan­dar­do­wy spo­sób komu­ni­ka­cji w każ­dym moim projekcie.

Wprowadzenie

Podstawowym celem tej komu­ni­ka­cji jest dostar­cza­nie mi mate­ria­łów i recen­zo­wa­nie (uwa­gi do tre­ści) powsta­ją­cej lub aktu­ali­zo­wa­nej, dostęp­nej on-line, doku­men­ta­cji ana­li­tycz­no-pro­jek­to­wej. Dotyczy to zespo­łu orga­ni­za­cji ana­li­zo­wa­nej, póź­niej tak­że zespo­łów dostaw­ców roz­wią­zań. Wymiana tre­ści jest w 100% pro­wa­dzo­na pisem­nie (mate­ria­ły źró­dło­we, dys­ku­sje powią­za­ne z ele­men­ta­mi tre­ści powsta­ją­ce­go opra­co­wa­nia). Na życze­nie recen­zen­tów orga­ni­zo­wa­ne są tele- lub video- kon­fe­ren­cje, jed­nak nie zastę­pu­ją one pisem­nej for­my prze­ka­za­nia mi mate­ria­łów źró­dło­wych. Spotkania słu­żą wyłącz­nie do pro­wa­dze­nia uzgod­nień, wyja­śnień, szkoleń. 

Narzędzia i metody w projekcie

Podobnie jak wie­lu ana­li­ty­ków na świe­cie, zre­zy­gno­wa­łem z wywia­dów i cyklicz­nych gru­po­wych warsz­ta­tów w loka­li­za­cji klien­ta, na rzecz zdal­nej pra­cy opar­tej na prze­ka­za­nych mi pisem­nie mate­ria­łach (doku­men­tach źró­dło­wych) a tak­że (patrz: niska efek­tyw­ność spo­tkań i ich ogrom­ne kosz­ty), zaś stan­dar­do­wo zdal­na pra­ca w moich pro­jek­tach to obec­nie 100%. 

Dzięki temu łącz­na pra­co­chłon­ność (szcze­gól­nie po stro­nie kadr zama­wia­ją­ce­go) i koszt pro­jek­tu, są nawet o 70% niż­sze, w porów­na­niu z cyklicz­ny­mi spo­tka­nia­mi i uży­wa­niem opro­gra­mo­wa­nia biu­ro­we­go (ema­il, edy­tor tek­stu, arkusz kal­ku­la­cyj­ny) do komu­ni­ka­cji i wymia­ny tre­ści! (prze­czy­taj też: Dlaczego nie uży­wam pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia mate­ria­łów).

Jeżeli Zamawiający nale­ga na spo­tka­nia i warsz­ta­ty są one roz­li­cza­ne jako dodat­ko­we zlecenia. 

Zrezygnowałem tak­że z pro­stych metod opi­so­we­go spe­cy­fi­ko­wa­nia wyma­gań bazu­ją­cych wyłącz­nie na wywia­dach z przy­szły­mi użyt­kow­ni­ka­mi, bo są to meto­dy nie­sku­tecz­ne, tak powsta­ją­ce spe­cy­fi­ka­cje są nie­kom­plet­ne, stwa­rza­ją ogrom­ne ryzy­ko dla pro­jek­tu .

W trak­cie pro­jek­tu nie uży­wam pakie­tów biu­ro­wych, nie two­rzę arku­szy kal­ku­la­cyj­nych ani doku­men­tów w edy­to­rach tek­stów. Produktem ​„do czy­ta­nia” (i do ewen­tu­al­ne­go dru­ku) jest doku­ment PDF sta­no­wią­cy peł­ną spe­cy­fi­ka­cję z dia­gra­ma­mi i opi­su­ją­cym je tek­stem. Jako pro­dukt pra­cy prze­ka­zu­ję tak­że edy­to­wal­ny plik źró­dło­wy w for­ma­cie XMI zawie­ra­ją­cy wszyst­kie opra­co­wa­ne mode­le i struk­tu­ry, wyra­żo­ne w nota­cjach BPMN i UML. 

Do zdal­nej pra­cy wyko­rzy­stu­ję, i udo­stęp­niam klien­tom, jed­no z naj­lep­szych narzę­dzi wspie­ra­ją­cych takie pro­jek­ty na ryn­ku: opro­gra­mo­wa­nie PostMania fir­my Visual-Paradigm, z któ­re­go korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista i refe­ren­cje wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm, bez­pie­czeń­stwa wyko­rzy­sty­wa­ne­go repo­zy­to­rium VP). Visual-Paradigm to narzę­dzie CASE (ang. Computer Aided System Engineering, kom­pu­te­ro­we wspo­ma­ga­nie inży­nie­rii sys­te­mów). Stosuję go w całym pro­ce­sie ana­li­zy i mode­lo­wa­nia, oraz w toku two­rze­nia doku­men­ta­cji pro­jek­to­wej i zarzą­dza­nia nią. 

Wszystkie prze­sła­ne mi doku­men­ty są chro­nio­ne (kodo­wa­ne), ich kopie zapa­so­we są wyko­ny­wa­ne w try­bie dobo­wym. Powstające tre­ści są wer­sjo­no­wa­ne, wpro­wa­dza­ne zmia­ny są śle­dzo­ne i doku­men­to­wa­ne. Każda nowa treść lub jej zmia­na (zwa­na korek­tą – revi­sion) jest odno­to­wy­wa­na, ozna­czo­na w cza­sie i numerowana. 

Zapoznaj się z opi­sem: Visual Paradigm PostMania – Przewodnik Recenzenta.

Komunikacja

Poniżej porów­na­nie tra­dy­cyj­nej meto­dy pra­cy (po lewej) i pra­cy on-line z uży­ciem plat­for­my komu­ni­ka­cyj­nej Postmania (po prawej):

Proces wymiany informacji

Wymiana infor­ma­cji w pro­jek­cie pole­ga na ite­ra­cyj­nym pro­ce­sie dostar­cza­nia infor­ma­cji i mate­ria­łów źró­dło­wych do ana­li­zy oraz zgła­sza­niu uwag i potrzeb zmian do powsta­ją­ce­go na ich pod­sta­wie opra­co­wa­nia: mode­li i ich opi­sów. UWAGA! Notatki ze spo­tkań sta­no­wią dostar­cza­ny mate­riał, więc z zasa­dy robi je i prze­ka­zu­je stro­na udzie­la­ją­ca infor­ma­cji.

Na eta­pie audy­tu i pro­jek­to­wa­nia w pro­ce­sie tym bie­rze udział zespół pra­cow­ni­ków ana­li­zo­wa­ne­go pod­mio­tu. Po pod­pi­sa­niu umo­wy z dostaw­cą roz­wią­za­nia, tak­że zespół dostaw­cy. Od tego momen­tu zaczy­na się etap nad­zo­ru autor­skie­go pro­wa­dzo­ne­go przez Autora pro­jek­tu roz­wią­za­nia (Analityk). Proces komu­ni­ka­cji obra­zu­je poniż­szy diagram: 

1. Członkowie zespo­łu Zamawiającego, w odpo­wie­dzi na moje pyta­nia, odpi­su­ją lub prze­ka­zu­ją okre­ślo­ne infor­ma­cje w for­mie doku­men­to­wej (przy­kła­dy doku­men­tów, doku­men­ty źró­dło­we, opi­sy itp.), a następ­nie zgła­sza­ją swo­je uwa­gi do powsta­ją­cych sche­ma­tów blo­ko­wych i powią­za­nych z nimi opi­sów, tak powsta­ją kolej­ne roz­dzia­ły wyko­ny­wa­ne­go rapor­tu z audy­tu i spe­cy­fi­ka­cji wyma­gań (sche­ma­ty blo­ko­we i ich opi­sy), któ­re na bie­żą­co udo­stęp­niam do wery­fi­ka­cji człon­kom zespo­łu Zamawiającego (recen­zen­ci); na każ­de żąda­nie uczest­ni­ków pro­jek­tu, wysy­łam aktu­al­ny draft Opracowania w posta­ci peł­ne­go tek­stu jed­no­li­te­go (plik pdf).
2. Po zakoń­cze­niu eta­pu ana­li­zy i spe­cy­fi­ko­wa­nia roz­wią­za­nia wybie­ra­ny jest dostaw­ca Rozwiązania. Dostawca roz­wią­za­nia (inte­gra­tor, deve­lo­per), po otrzy­ma­niu Wymagań (pro­dukt Analizy Biznesowej), jeże­li potrze­bu­je dodat­ko­wych infor­ma­cji, zgła­sza takie pyta­nia, w odpo­wie­dzi otrzy­mu­je uzu­peł­nio­ne opra­co­wa­nie Analiza Biznesowa i Projekt Techniczny. Wszelkie uzu­peł­nie­nia powsta­ją z udzia­łem Podmiotu audy­to­wa­ne­go, opi­sa­ne­go w Wymaganiach.
3. Tak aktu­ali­zo­wa­ny doku­ment: Analiza Biznesowa i Projekt Techniczny, jest jedy­ną for­mą prze­ka­zy­wa­nia infor­ma­cji pod­mio­to­wi dostar­cza­ją­ce­mu roz­wią­za­nie. Dzięki temu Zamawiający ma sta­le aktu­ali­zo­wa­ną doku­men­ta­cję opi­su­ją­cą jego dzia­łal­ność, a Dostawca ma spój­ny i kom­plet­ny opis wyma­gań w posta­ci jed­ne­go zwar­te­go opisu. 
4. Dostawca na pod­sta­wie tre­ści doku­men­tu Analiza Biznesowa i Projekt Techniczny, opra­co­wu­je swo­ją Koncepcję Wdrożenia. Ewentualne notat­ki spi­sy­wa­ne np. na spo­tka­niach przez Dostawcę, nie sta­no­wią sobą żad­nych uzgod­nień o wyma­ga­niach. Jedynym źró­dłem infor­ma­cji o pod­mio­cie audy­to­wa­nym jest Analiza Biznesowa i Projekt Techniczny, jako spój­ny, nie­sprzecz­ny i kom­plet­ny opis biz­ne­so­wy i opis wyma­gań Zamawiającego. 

Wymagania biznesowe czyli potrzeby Zamawiającego

Po wyko­na­niu audy­tu i mode­lu pro­ce­sów biz­ne­so­wych oraz opra­co­wa­niu reko­men­da­cji ewen­tu­al­nych zmian, okre­śla­ne są Potrzeby Zamawiającego. Są to wyma­ga­nia wobec roz­wią­za­nia, wyra­żo­ne przez Zamawiającego języ­kiem natu­ral­nym z per­spek­ty­wy przy­szłe­go użyt­kow­ni­ka roz­wią­za­nia. Zarówno w sfe­rze popra­wy efek­tyw­no­ści na eta­pie ana­li­zy pro­ce­sów biz­ne­so­wych, jak i w sto­sun­ku do opro­gra­mo­wa­nia, jeże­li jego zakup i wdro­że­nie oka­żą wyma­ga­nym rozwiązaniem. 

Zamawiający co do zasa­dy dostar­cza mi mate­ria­ły źró­dło­we, jed­nak gorą­co odra­dzam samo­dziel­ne pro­jek­to­wa­nie roz­wią­za­nia infor­ma­tycz­ne­go czy­li spi­sy­wa­nie ​„co i jak sys­tem ma coś robić” albo, co gor­sza, samo­dziel­ne two­rze­nie sche­ma­tów blo­ko­wych i opi­sów pro­ce­sów czy sys­te­mów IT, gdyż przy­no­si to wię­cej szko­dy niż pożyt­ku: samo­dziel­ne opra­co­wy­wa­nie tych sche­ma­tów pro­sty­mi pro­gra­ma­mi biu­ro­wy­mi, przez nie­przy­go­to­wa­ne do tego i nie­do­świad­czo­ne oso­by, jest pra­co­chłon­ne a uzy­ska­ne efek­ty rzad­ko kie­dy wno­szą war­tość do pro­jek­tu . Lepiej więc, gdy Zamawiający zro­bi to co bar­dzo dobrze potra­fi: spi­sze swo­je potrzeby. 

Kluczowe poję­cie na tym eta­pie to

potrze­ba: funk­cja, któ­rej bra­ku­je do osią­gnię­cia celu lub wyko­na­nia działania

Powstaje zesta­wie­nie wyma­gań biz­ne­so­wych wyra­żo­nych jako «potrze­by inte­re­sa­riu­szy». Zestawienie to nale­ży dostar­czyć w posta­ci tabeli:

Źródło wyma­ga­nia	Potrzeba	Obecny pro­blem
Dyrektor Logistyki	Zarzadzanie dosta­wa­mi nie­za­leż­nie dla każ­de­go zamówienia	Brak moż­li­wo­ści nad­zo­ru bie­żą­ce­go sta­nu czę­ścio­wej reali­za­cji zamówień
Dyrektor Handlowy	Dokumentowanie sprze­da­ży promocyjnej	Ręczne wsta­wa­nie do fak­tur cen innych niż katalogowe
Prezes	Bieżące śle­dze­nie war­to­ści przychodów	Brak wie­dzy o bie­żą­cej war­to­ści sprze­da­ży w okre­ślo­nym okresie

Zalecanym uzu­peł­nie­niem jest okre­śle­nie biz­ne­so­we­go celu pro­jek­tu na tle misji i wizji orga­ni­za­cji (patrz: Audyt spój­no­ści wizji i misji orga­ni­za­cji z jej dzia­ła­nia­mi):

• misja: (jak sobie wyobra­ża­my nasz przy­szły rynek), 
• wizja: (nasz wkład w osią­gnię­cie powyż­sze­go sta­nu rzeczy),
• cel biz­ne­so­wy orga­ni­za­cji: (pla­no­wa­na pozy­cja na ryn­ku, fuzja, inne), 
• klu­czo­wy pro­blem: (co jest głów­nym powo­dem ini­cja­cji projektu).

Wymagania biz­ne­so­we są pod­sta­wą roz­po­czę­cia pro­jek­to­wa­nia rozwiązana. 

Rola Recenzenta

Wprowadzenie

Struktura organizacyjna

Powyższy sche­mat to sfor­ma­li­zo­wa­na struk­tu­ra orga­ni­za­cyj­na zobra­zo­wa­na jako ​„drze­wo zależ­no­ści przełożony-podwładny”. 

Przepływ pracy czyli procesy biznesowe

Na powyż­szym sche­ma­cie poka­za­no pro­ces biz­ne­so­wy: aktyw­no­ści oraz ich dane wej­ścio­we i wyj­ścio­we. Wszelkie dodat­ko­we deta­le nio­są doku­men­ty (sym­bo­le z zagię­ty­mi roga­mi na dia­gra­mie powy­żej), regu­ły biz­ne­so­we (spi­sy­wa­ne w posta­ci zesta­wie­nia w tre­ści opra­co­wa­nia lub na sche­ma­tach np. powy­żej: Budżetowanie. BR002).

Dokument i jego treść 

Struktury doku­men­tów są doku­men­to­wa­ne jako ich uprosz­czo­ne sza­blo­ny, np. jak ten poniżej:

Struktury doku­men­tów nio­są naj­wię­cej deta­licz­nych infor­ma­cji o prze­twa­rza­nych danych i związ­kach mie­dzy nimi. 

Biznesowy słownik pojęć

Podstawą zro­zu­mia­ło­ści i jed­no­znacz­no­ści doku­men­ta­cji jest jed­no­li­ty, spój­ny i kom­plet­ny słow­nik pojęć dla całe­go pro­jek­tu (gene­ral­nie doty­czy całej orga­ni­za­cji). Celem jest zapew­nie­nie jed­no­znacz­no­ści tre­ści nie tyl­ko doku­men­ta­cji pro­jek­to­wej ale też wszyst­kich ele­men­tów na mode­lach pro­ce­sów i sys­te­mu jakim jest opro­gra­mo­wa­nie. Co do zasa­dy słow­nik ma postać alfa­be­tycz­nej listy, jed­nak klu­czo­we dla zro­zu­mie­nia i inter­pre­ta­cji poję­cia, dodat­ko­wo wery­fi­ku­je­my z pomo­cą tak zwa­ne­go mode­lu poję­cio­we­go (dia­gram klas UML, lub model fak­tów SBVR, ). Jest to sche­mat blo­ko­wy, na któ­rym umiesz­cza­my klu­czo­we poję­cia i łączy­my je związ­kiem gene­ra­li­za­cji lub okre­ślo­nym fak­tem (pre­dy­kat). W ten spo­sób spraw­dza­my, czy poję­cia te two­rzą popraw­ne i praw­dzi­we zda­nia w języ­ku natu­ral­nym danej dzie­di­zny. Np. poniżej:

Powyższe czy­ta­my:

• kopia doku­men­tu i ory­gi­nał doku­men­tu to rodzaj (typ) dokumentu
• fak­tu­ra jest typem dokumentu
• sys­tem kan­ce­la­ryj­ny zapew­nia popraw­ny obieg dokumentów
• doku­ment jest przy­po­rząd­ko­wa­ny do sprawy

UWAGA! Ten dia­gram to nie jest pro­ces biznesowy!

Mechanizm działania systemu

Mogą sie poja­wić inne, uzu­peł­nia­ją­ce sche­ma­ty blokowe: 

Dokument (każ­dy obiekt lub kom­po­nent w sys­te­mie) mogą mieć sta­ny i sta­tu­sy, mode­lo­wa­ne jak poniżej:

Powyższe to tre­ści adre­so­wa­ne do pra­cow­ni­ków orga­ni­za­cji ana­li­zo­wa­nej. Są czę­ścią rapor­tu z Audytu Procesów Biznesowych Organizacji.

To co system ma robić czyli wymagane usługi aplikacji i zakres projektu

Wymagania Zamawiającego (biz­ne­so­wy kon­tekst i oto­cze­nie pro­jek­tu) doku­men­to­wa­ne są jako model usług aplikacji:

Następująca po niej część doku­men­ta­cji, zaty­tu­ło­wa­na Opis Techniczny Oprogramowania, tak­że zawie­ra sche­ma­ty blo­ko­we, są to jed­nak spe­cja­li­stycz­ne mode­le adre­so­wa­ne do dostaw­cy opro­gra­mo­wa­nia, któ­ry skła­da­jąc ofer­tę musi oświad­czyć, że zna stan­dar­do­we tech­ni­ki ana­li­zy i mode­lo­wa­nia sys­te­mów infor­ma­cyj­nych (w tym sys­te­my nota­cyj­ne BPMN i UML). 

Spotkania

W ramach reali­zo­wa­nej usłu­gi odby­wa­ją się spo­tka­nia sta­tu­so­we (usta­le­nia pla­no­wa­nych dzia­łań w pro­jek­cie). Wszelkie dodat­ko­we warsz­ta­ty ini­cjo­wa­ne przez Zamawiającego sta­no­wią dodat­ko­we płat­ne spotkania. 

Spotkania są reali­zo­wa­ne jako video- i tele- kon­fe­ren­cje. Standardowo wysy­łam link do spo­tka­nia on-line. Jeżeli macie Państwo w swo­jej fir­mie wdro­żo­ny swój wła­sny sys­tem wide­okon­fe­ren­cyj­ny, może być on uży­wa­ny w pro­jek­cie. Jedynym ogra­ni­cze­niem jest brak koniecz­no­ści insta­lo­wa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na moim komputerze. 

Źródła